Re: [PATCH] Add command line option to map file prefixes

[Joshua Watt]

On Sat, May 9, 2020 at 3:22 AM Akim Demaille <address@hidden> wrote:
>
> Hi Joshua,
>
> > Le 8 mai 2020 à 19:26, Joshua Watt <address@hidden> a écrit :
> >
> > On 5/8/20 2:39 AM, Akim Demaille wrote:
> >
> >> It appears that your approach is not sufficient for synclines.  I toyed
> >> with it, and the generated #lines are not adjusted.
> >>
> >> I'm somewhat bugged that this relies on a new option, mostly because it
> >> means that it cannot be controlled from within the grammar file itself.
> >> Do you really think we need a list of rules?  Do you have evidence for
> >> that need?
> >>
> >> If not, maybe we can find a solution which would rely only on %define/-D.
> >
> >
> > I think there is a bit of missing background, which I will attempt to 
> > provide here (and fix up my commit message to also include):
> >
> > This option is intended to be use in conjunction with the 
> > "-fdebug-prefix-map" [1] option in GCC (and other compilers).
>
> That's news to me, thanks a lot for the additional details.  Prior art 
> clearly settles it: that's the right name for the option, and of course we'll 
> use `=` too.
>
> > When this option is used, you don't necessarily *have* to change the #line 
> > directives because the compiler will map them for you when the source code 
> > is compiled. However, I can also see the argument that bison should handle 
> > the mapping internally, and it doesn't look like it would be too hard to 
> > apply the mapping to #line directives also, so I can do that if you would 
> > like.
>
> Yes, I understand why it's not needed, but I would definitely like the #lines 
> to be adjusted too.  You seem to grok enough of bison to handle it yourself, 
> otherwise I'll do it afterwards.
>
> > I don't think this is the type of thing you'd want to be able to control 
> > from the grammar files themselves; it's entirely an option that needs be 
> > specified by the user compiling the source code (since only they know the 
> > prefix mapping) and allowing to be set in the grammar file seems like it 
> > would only cause confusion and/or broken compiles (at least for the purpose 
> > of making builds reproducible).
>
> I've seen projects with several build systems, and being able to factor 
> things is a good thing.  But I agree it's a weak argument here.
>
>
> >> We are now getting rid of our hand-written list structures
> >> in favor gnulib's implementation of lists.  Not much of a big deal,
> >> but I'd rather avoid stepping backward at this point.
> >
> > Ok, I'm not very familiar with gnulib, but I'll look up how to do that and 
> > fix it.
>
> Do waste time on this though.  If you get it to work quickly, all the better.
>
> >> Out of curiosity, why do you prefer "&filename[oldprefix_len]" to
> >> "filename + oldprefix_len"?  The latter seems more natural to me.
>
> That's a real question :)

Habit. I've written a lot of code where pointer math was eschewed as
being "unclear", with a preference for address of index, with the idea
its more clear. I'm not real sold it matters :)

>
> > I did originally want to put it in output.at, but it looked like that was 
> > all language agnostic. I'll move it there and add the other relevant 
> > languages.
>
> Excellent.
>
> You don't need to make one large commit.  Each commit must pass the test 
> suite, but we like small commits, so you can treat skeletons one by one for 
> instance, or adding tests later.
>
> Cheers!