On Tue, Jun 13, 2023 at 7:41 PM Chris Johns <chr...@rtems.org> wrote: > > On 14/6/2023 10:20 am, Joel Sherrill wrote: > > > > > > On Tue, Jun 13, 2023, 4:43 PM Chris Johns <chr...@rtems.org > > <mailto:chr...@rtems.org>> wrote: > > > > On 14/6/2023 5:47 am, Joel Sherrill wrote: > > > > > > > > > On Tue, Jun 13, 2023 at 9:51 AM Sebastian Huber > > > <sebastian.hu...@embedded-brains.de > > <mailto:sebastian.hu...@embedded-brains.de> > > <mailto:sebastian.hu...@embedded-brains.de > > <mailto:sebastian.hu...@embedded-brains.de>>> > > > wrote: > > > > > > On 13.06.23 00:04, Gedare Bloom wrote: > > > > "b _ARM_Exception_default\n" > > > > : > > > > - : [cpufsz] "i" (sizeof(CPU_Exception_frame)), > > > > - [cpuspoff] "i" (offsetof(CPU_Exception_frame, > > register_sp)), > > > > - [v7mlroff] "i" (offsetof(ARMV7M_Exception_frame, > > register_lr)), > > > > - [cpuvecoff] "J" (offsetof(CPU_Exception_frame, vector)), > > > > - [cpuvfpoff] "i" (ARM_EXCEPTION_FRAME_VFP_CONTEXT_OFFSET), > > > > - [cpacr] "i" (ARMV7M_CPACR), > > > > - [vfpsz] "i" (ARM_VFP_CONTEXT_SIZE) > > > > + : [cpufsz] "i"( sizeof( CPU_Exception_frame ) ), > > > > > > If we place operators (e.g. &&, ||, ...) at the end of a broken > > line, > > > then we should do this for the : as well. > > > > > > > > > OK. > > > > > > > > > > > > My current preference would be to format all non-third-party > > sources > > > with a standard clang-format selection. I guess in the long run, > > this > > > will be the easiest approach to maintain. If we use exotic > > options, then > > > we may up ending as clang-format maintainers. > > > > > > > > > I think this is the thing we have to keep in mind and I even said I > > would > > > go along with compromises when we started. Get as close as you can > > > and we will have to accept that -- for now. We should definitely file > > tickets > > > with clang-format and ourselves to track things we don't like. If we > > get an > > > option in the future whether we or someone else implements it, we can > > > use it and reformat again. Those hopefully are not that invasive. > > > > Sounds like a plan. > > > > I am a little concerned about the version of clang-format I need as some > > machines I work on are no at current OS versions. > > > > > > I am finding myself experimenting with it for a customer's C++ project. So > > far, > > I have not matched the style. But I am now on Rocky 9 since I built it from > > source and needed cmake 3 at least. So you can't be on an old distribution > > and > > build from source. > > I use clang-format on a couple projects with something close the standard > format. It works well. > > > And Doxygen has and three different major versions between RHEL 7, 8, and 9. > > Using a configuration file from one on another seems to give you warnings > > about > > unknown options or obsolete options. > > > > Mixing new and old systems is a pain. > > It is but we have to for reasons specific to local sites. > As a developer tool that can be used also by CI tools to automate style fixes, I view the availability of clang-format as less of a concern (than say a specific version of gcc). People can still create and send commits without having the tool.
If someone ends up proposing a requirement for clang-format clean patch submissions, then it becomes a problem. > Chris > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel