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

[Maciej W. Rozycki]

On Mon, 18 May 2020, Jacob Bachmeyer wrote:

> You are looking for the calls matching attempts to invoke gnatmake using 
> "remote_exec host" and you may consider the braced strings containing 
> gnatmake commands to be the output of the test as that is what your 
> patches will change.  (The first of these is:  
> {m68k-unknown-aout-gnatmake foo.adb -midp -fada -E 
> -I/usr/gnemul/idp/include} as far as the matching rules are concerned; 
> whitespace (including newlines) is not significant except as token 
> delimiters.  Line wrap and indentation is freely used here.)  Note that 
> the arguments given in those commands are not related to what the GNU 
> Ada tools actually expect or accept; they are dummy parameters to ensure 
> that the various configuration values are used, and that the usage of 
> those does not unintentionally change when default_target_compile is 
> rewritten.

 Thanks, I have updated them in v2.

> Which brings me to another question:  do some of those tests even make 
> sense for Ada?  Will the rewritten procedure need to accept different 
> sets of "type" values for different languages?

 I skimmed over and nothing obviously silly has caught my eye.  I may not 
be the best reviewer for Ada pieces though.  Certainly the harness ought 
to do act reasonably with respect to the board description parameters set 
up, regardless of the language used by a particular test case.  Board 
parameters are properties of the test environment and are supposed to be 
language-agnostic.

> I was unclear.  My concern was ensuring that the various options passed 
> in to default_target_compile (both as options and as configuration) are 
> correctly sorted into compiler/linker/etc. bins and passed with proper 
> mode switches to the Ada frontend.  For example, the "optimize=" option 
> is specifically for the compiler, while the "ldflags=" option is 
> specifically for the linker.

 Right, I have reviewed the original change and fixed a bunch of omissions 
from v1.  Also most notably multilib flags need to go both to the compiler 
and to the linker, as they are interpreted by both, though differently.

 I have posted v2 now.  I hope it's good enough to go in as it stands.  
Otherwise I'll have to defer any further development here until I'm done 
with my other commitments.

  Maciej