From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Wed, 9 May 2018 12:14:56 -0400 Subject: [U-Boot] GCC 7.x vs. C++ comments In-Reply-To: <20180509154052.5E0B424000A@gemini.denx.de> References: <5B756B92-A9EE-4227-9D8E-887F6E8E1597@theobroma-systems.com> <20180509111627.GD12235@bill-the-cat.ec.rr.com> <20180509113837.59F33240036@gemini.denx.de> <20180509114828.GG12235@bill-the-cat.ec.rr.com> <20180509124654.BFF71240036@gemini.denx.de> <20180509134905.GK12235@bill-the-cat.ec.rr.com> <20180509154052.5E0B424000A@gemini.denx.de> Message-ID: <20180509161456.GM12235@bill-the-cat.ec.rr.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Wed, May 09, 2018 at 05:40:52PM +0200, Wolfgang Denk wrote: > Dear Tom, > > In message <20180509134905.GK12235@bill-the-cat.ec.rr.com> you wrote: > > > > > Marek already said what was on my mind, and got ignored. > > > Would it have changed anything if I had posted another complaint? > > > > Ignored, no. Counts as a veto? No. And if you had chimed in too, I > > don't know if that would have gotten anyone else to also chime in. > > This does not really convince me. > > IMO it makes no sense to blow up mailing list traffic with extensive > voting for such things. Marek said everything that needed to be > said, and repeating it would IMO not add any weight to it. If you > really want a poll including more people, then explicitly start one > - but please not on the mailing list, at least not fuch such > details. I honestly couldn't think of a better way to see if anyone cared besides an RFC to the mailing list. > > It's not futile, but here's as best I can tell, the arguments: > > Against Linux Kernel style SPDX tags: > > I think this argument is wrong from the start. This is not about > "Linux Kernel style SPDX tags". There is two different topics, > which are actually independent, and should be treated as such: > > - Linux Kernel style SPDX tags, or rather more modern SPDX tags > including the needed operators to deal with exceptions, multiple > licenses, etc. When I invented the SPDX tags I did not foresee > this need (my fault), but I'm still proud that U-Boot introduced > this mechanism at all. > > Yes, it is necessary to adapt the new developments in this area. And for the record, it's a good thing you did. Since we were the best example of a project going all-in on the tags for a long while I know the people that did the kernel scheme looked at what we had. > - Comment style. This is just a matter of coding style and > preferences. Whether you use C comments (single line or > multi-line) or C++ comments does not make any difference > technically. I disagree on these being separate. I copy/pasted the relevant part of the kernel documentation as an update to our doc but where it goes (first line) and how it goes (comments like ....) are as much a part of the style as the syntax. I'd argue that where the license copies go and some directory structure there-of is also part of it but I think our locations are more set in stone, but we can live with it. > U-Boot has been discouraging the use of C++ comments for 18 years, > and I still see no good reason to change this. [And yes, we also > have the rule not to meddle with code copied from other projects.] I don't want to have it buried here but maybe it's time to talk about fully adopting C99 (or, GNU C99). Did you happen to read https://lkml.org/lkml/2017/11/25/133 that Yamada-san passed along? Having read that after converting the tags that my first regex missed, maybe we were wrong 18 years ago. > > - Don't like // style comments > > - Visually inconsistent / jarring > > - Against existing coding style. > > > > For Linux Kernel style SPDX tags: > > - Has higher visibility. > > ??? I can't parse this. In which way has > > // SPDX-License-Identifier: GPL-2.0+ > > "higher visibility" than > > /* SPDX-License-Identifier: GPL-2.0+ */ > > or even I was pointing out first line vs somewhere within the top comment block as I don't consider comment format vs location different items. > /* > * SPDX-License-Identifier: GPL-2.0+ > */ > > ? > > [IMO, the last form is the most visible one.] > > And since when do we care about a single line of white space or two > when it comes to consistency or readability? > > > - Has tooling to enforce correctly formatted tags. > > > > - Shorter (enforced as a single line comment means we don't have people > > spacing around it). > > Come on, this argument is really lame. That the SPDX tag meant the same as the whole license text was part of the reason to convert. > > - Consistent expectations for our overlapping developer community. > > Please explain? Who associates SPDX tags with C++ comments? This This is again part of the difference in counting comment format as part of it, or not. > is silly. We don't use these in Makefiles, or in shell scripts, or > in ... We sometimes do for Makefiles, almost always do in shell scripts. > And when talking about consistency - what about this in the current > Linux Kernel tree: > > arch/x86/kernel/apic/apic_common.c: * SPDX-License-Identifier: GPL-2.0 > arch/s390/tools/gen_opcode_table.c:/* SPDX-License-Identifier: GPL-2.0 */ > arch/arm64/crypto/sha3-ce-glue.c:/* SPDX-License-Identifier: GPL-2.0 */ > arch/arm64/crypto/sha512-ce-glue.c:/* SPDX-License-Identifier: GPL-2.0 */ > arch/riscv/kernel/ftrace.c:/* SPDX-License-Identifier: GPL-2.0 */ > arch/riscv/kernel/module-sections.c:/* SPDX-License-Identifier: GPL-2.0 > drivers/tty/hvc/hvc_riscv_sbi.c:/* SPDX-License-Identifier: GPL-2.0 */ > drivers/memory/brcmstb_dpfe.c: * SPDX-License-Identifier: GPL-2.0 > drivers/soc/amlogic/meson-mx-socinfo.c: * SPDX-License-Identifier: GPL-2.0+ > drivers/soc/amlogic/meson-gx-pwrc-vpu.c: * SPDX-License-Identifier: GPL-2.0+ > drivers/soc/amlogic/meson-gx-socinfo.c: * SPDX-License-Identifier: GPL-2.0+ > drivers/i2c/busses/i2c-sprd.c: * SPDX-License-Identifier: (GPL-2.0+ OR MIT) > drivers/pinctrl/meson/pinctrl-meson-axg-pmx.c: * SPDX-License-Identifier: (GPL-2.0+ or MIT) > drivers/pinctrl/meson/pinctrl-meson-axg.c: * SPDX-License-Identifier: (GPL-2.0+ or MIT) > drivers/virt/vboxguest/vboxguest_core.c:/* SPDX-License-Identifier: (GPL-2.0 OR CDDL-1.0) */ > drivers/virt/vboxguest/vboxguest_linux.c:/* SPDX-License-Identifier: GPL-2.0 */ > drivers/virt/vboxguest/vboxguest_utils.c:/* SPDX-License-Identifier: (GPL-2.0 OR CDDL-1.0) */ > drivers/watchdog/rtd119x_wdt.c: * SPDX-License-Identifier: GPL-2.0+ > drivers/rtc/rtc-rtd119x.c: * SPDX-License-Identifier: GPL-2.0+ > drivers/rtc/rtc-sc27xx.c: * SPDX-License-Identifier: GPL-2.0 > ... > > > Yes, 47 files is only a small fraction compared against the 5261 > C files with C++ commented tags. But consistency of apparently not a > real issue when it comes to comment style in Linux. Inconsistent rollout? Tags went in good bit before the document that said how/where they should be was finally merged. I'm sure it's on the kernel janitors list for someone to fixup, or there's patches slowly in-flight to do so. > > Things that could be taken, without changing overall formatting: > > - Logic operators for exceptions/dual-license/etc > > Right, this is completely independent and out of question here. Agreed. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: