Re: [PATCH 3/3][DejaGNU] target: Wrap linker flags into `-largs'/`-margs' for Ada

[Jacob Bachmeyer <jcb62281@gmail.com>]

Maciej Rozycki wrote:
> On Thu, 16 May 2019, Jacob Bachmeyer wrote:
>
>   
>>>  I suspect the origins may be different, however as valuable as your 
>>> observation is functional problems have precedence over issues with code 
>>> structuring, so we need to fix the problem at hand first.  I'm sure 
>>> DejaGNU maintainers will be happy to review your implementation of code 
>>> restructuring afterwards.
>>>       
>> My concern is that your patch may only solve a small part of the problem 
>> -- enough to make your specific case work, yes, but then someone else 
>> will hit other parts of the problem later and we spiral towards "tissue 
>> of hacks" unmaintainability.
>>     
>
>  I think however that fixing problems in small steps as they are 
> discovered is also a reasonable approach and a way to move forward: 
> perfect is the enemy of good.
>   

Fair enough; observe the small patches I have recently submitted to DejaGnu.

>  So I don't think the prospect of making a comprehensive solution should 
> prevent a simple fix for the problem at hand that has been already 
> developed from being applied.
>   

I recognize a difference between "simple but complete" (an ideal 
sometimes achieved in practice) and "simple because incomplete" (which 
does not actually fix the problem).  My concerns are that your patch may 
be the latter.

>  IOW I don't discourage you from developing a comprehensive solution, 
> however applying my proposal right away will help at least some people and 
> will not block you in any way.
>   

Correct, although, considering how long my FSF paperwork took, I might 
be able to finish a comprehensive patch before your paperwork is 
completed.  :-)

>> The biggest hint to me that your patch is incomplete is that it only 
>> adds -largs/-margs to wrap LDFLAGS.  I suspect that there are other 
>> -?args options that should be used also with other flag sets, but those 
>> do not appear in this patch.  Do we know what the GNU Ada frontend 
>> actually expects?
>>     
>
>  At first glance it looks to me we should be safe overall as compiler 
> flags are supposed to be passed through by `gnatmake' (barring switch 
> processing bugs, as observed with 1/3), and IIUC assembler flags are 
> considered compiler flags for the purpose of this consideration as 
> `gnatmake' does not make assembly a separate build stage.  So while we 
> could wrap compiler flags into `-cargs'/`-margs', it would only serve to 
> avoid possible `gnatmake' switch processing bugs.
>   

I am not sure if those are actually bugs in `gnatmake' or the result of 
an incomplete specification for `gnatmake' -- I suspect that --sysroot= 
may have been added to the rest of GCC after `gnatmake' was written and 
whoever added it did not update the Ada frontend.

>  There's also `-bargs' for binder switches, but I can't see any use for it 
> here.
>
>  Finally boards are offered the choice of `adaflags', `cflags', 
> `cxxflags', etc. for the individual languages, where the correct syntax 
> can be used if anything unusual is needed beyond what I have noted above.
>   

Which also raises the issue of "cflags_for_target" (used regardless of 
language and currently always taken from the "unix" board configuration) 
and how that is supposed to make sense and whether it should be 
similarly split into language-specific values or simply removed.  I have 
already submitted a patch to draw that value from the actual host board 
configuration.

>  I'll defer any further consideration to the Ada maintainers cc-ed; I do 
> hope I haven't missed anything here, but then Ada is far from being my 
> primary area of experience.
>   

Likewise, hopefully some of the Ada maintainers will be able to shed 
light on this issue.  And I hope Ben (the DejaGnu maintainer) is okay -- 
I would have expected him to comment by now.

>>>  The ordering rules are system-specific I'm afraid and we have to be 
>>> careful not to break working systems out there.  People may be forced to a 
>>> DejaGNU upgrate, due to a newer version of a program being tested having 
>>> such a requirement, and can legitimately expect their system to continue 
>>> working.
>>>       
>> We can start by simply preserving the existing ordering until we know 
>> something should change, but the main goal of my previous message was to 
>> collect the requirements for a specification for default_target_compile 
>> so I can write regression tests (some of which will fail due to known 
>> bugs like broken Ada support in our current implementation) before 
>> embarking on extensive changes to that procedure.  Improving 
>> "target.test" was already on my local TODO list.
>>     
>
>  You are welcome to go ahead with your effort as far as I am concerned.
>   

I am working on it.  :-)

-- Jacob