Nvm the PR has been rejected. I was hoping my source-code annotation initiative would be given more thoughtful consideration.
On Tue, Oct 24, 2023 at 10:38 AM Axel R. <[email protected]> wrote: > Yep the PR is up for review. It was indeed a trivial issue, there was a > file under packaging/ that needed the new file listed and the Linux builds > started working. > > I have one more trivial issue where a file locally formatted with > clang-format -I --style=file doesn’t pass the formatting test on the online > build. > > For some reason the local convention appears to mandate spaces before > opening parentheses as in MACRO (x) or __attribute (x) which is not > aligned with most C and C++ formatting rules of the world, where a space > precedes a parenthesis only after language keywords. > > The existing code isn’t conforming strictly to the .clang-format file that > is checked-in with the project. Some of the existing files change if I run > clang-format on them with that formatting file, and spaces get added before > some of the few existing parentheses that don’t have one already (e.g. > __declspec(dllimport) in zmq.h) > > The clang-* build targets created by CMake on Windows fail because they > call chmod for some reason, so I suspect a new .clang-format file does not > get created? But why is it needed to set write attributes on existing files > during builds? And why any build artefact was checked-in (if that is the > case that .clang-format is supposed to be generated) > > There should not be so much frictions around minor formatting > discrepancies. I think this nonstandard spacing policy should be abrogated. > > “Put a space before an open parenthesis only in control flow statements, > but not in normal function call expressions and function-like macros.” > https://llvm.org/docs/CodingStandards.html > > This is aligned with most formatting conventions back to the original K&R > and I think this project should return to that instead of standing out in a > nonstandard way, and the formatting rules file should be checked-in and not > generated as it does not work on all platforms today (unless there is a > compelling reason to create that file during builds?) > > Thoughts? > > —Axel > > > Sent from my iPhone > > On Oct 24, 2023, at 04:05, Arnaud Loonstra <[email protected]> wrote: > > Seems a trivial problem. Have you created the PR already? > > On 22/10/2023 10:04, Axel R. wrote: > > Hi, I'm trying to submit a PR, but the Linux builds fail. I added a new > include\zmq_sal.h next to include\zmq.h and #included it as "zmq_sal.h" > from zmq.h, which builds locally on Windows as well as on Github. However, > the Linux builds fails ("../../src/../include/zmq.h:34:10: fatal error: > zmq_sal.h: No such file or directory") I tried #include <zmq_sal.h> to no > avail. Any idea? How was zmq_utils.h included? > > > _______________________________________________ > > zeromq-dev mailing list > > [email protected] > > https://lists.zeromq.org/mailman/listinfo/zeromq-dev > > _______________________________________________ > zeromq-dev mailing list > [email protected] > https://lists.zeromq.org/mailman/listinfo/zeromq-dev > >
_______________________________________________ zeromq-dev mailing list [email protected] https://lists.zeromq.org/mailman/listinfo/zeromq-dev
