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

[Akim Demaille]

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 :)

> 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!