FSF copyright is Ok for me, I've been contributing to free software before (fvwm2 & emacs/gnus). For my company, it's in the mutual interest as well.
Well, I'd do the sensible thing and reduce the amount of #line output - and especially suppress it after line-continuation backslashes, where it's disrupting the sematic of that continued statement (c/c++/makefiles, ....) Since --synclines is already an opt-in feature, I don't see it as a huge problem to reduce the number of inserted #line directives to a reasonable level (i.e. less spamming of multi-line expansions, but rather a 'reset line number' after the block - at least that's what the C preprocessor & similar tools do - I have bene writing Compilers for DSPs for a decade). Worst case, we could extend the --syncline parameter with an optional '=feature-set' part: --syncline=feature1,feature2,.... e.g.: --syncline=line-continuation to switch on line-continuation-awareness That could get an own '=\', if other line-continuation characters surface for other languages. --syncline=commentstart=/*,commentend=*/ to suppress the emission within multi-line C comments /* ... */ So my C/makefile use cases would be covered by --syncline= line-continuation,commentstart=/*,commentend=*/ Maybe allow abbreviations: --syncline= lc,cs=/*,ce=*/ Maybe add an M4OPTIONS environment variable for defaults? What is the qualification process for a submission? Is there an official acceptance-test / review process or is there a test suite to pass? Cheers, Albrecht -----Original Message----- From: Eric Blake <ebl...@redhat.com> Sent: Wednesday, May 26, 2021 5:10 PM To: Kadlec, Albrecht <albrecht.kad...@elektrobit.com> Cc: bug-m4@gnu.org Subject: Re: --synclines adds #line 4711 after #define xyz(abc) ...\ CAUTION: This email originated from outside of the Elektrobit organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. On Sat, Dec 26, 2020 at 06:26:42PM +0000, Kadlec, Albrecht wrote: > Hi, > > We are using GNU m4 1.4.18: are there any plans for extensions a'la a > c-mode via -synclines=c,'#line __line__ "__file__"' > (also defining the lead-in per file) to add line-continuation awareness and > maybe even comment awareness ? > Or a function > syncline(`#line '__line__ "__file__") > to enable switching on/off/changing the syntax? > Do you accept up-streaming contributions? -> next deadline/release? Contributions are okay if you are willing to assign copyright to the FSF; however, I must be fair and warn you that a contribution to teach m4 how to report dependency tracking more like gcc has now stalled for several years, because there has been very little active development on m4. Adding new macros must be done carefully (we don't want to break existing use of m4 where the new macro name had other purposes). Also, POSIX is fairly vague at what synclines do, stating only: > The following options shall be supported: > > -s > Enable line synchronization output for the c99 preprocessor phase (that > is, #line directives). [https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpubs.opengroup.org%2Fonlinepubs%2F9699919799%2Futilities%2Fm4.html&data=04%7C01%7C%7C23490762951141be962d08d92058e703%7Ce764c36b012e4216910d8fd16283182d%7C0%7C0%7C637576389818831668%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Mvh9xKIyinIMlrOEC7mXhz2K2EGGQJuc6AbMfJXVl40%3D&reserved=0] with no mention of what format those lines must take (either on the description for m4, or for c99). But changing their output is also a risk if it is not done as an opt-in manner, so figuring out how to opt-in (or even if opting in is possible for a given build of m4) needs to be thought about. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org