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

Maciej W. Rozycki wrote:
> Unrecognized `gnatmake' switches are not implicitly passed on to the 
> linker, so just pasting board `ldflags' and any other linker flags 
> verbatim into `add_flags' to use for the invocation line of `gnatmake' 
> will make them ignored at best.
>
> [...]
>
> For `gnatmake' to pass switches on to the linker the `-largs' switch has 
> to be used, which affects all the switches that follow until a switch is
> seen that changes the selection, like `-margs', which resets to the 
> initial state of the switch interpretation machine.
>
> Wrap linker flags into `-largs'/`-margs' for Ada then, carefully 
> preserving the place these flags are placed within `add_flags', as 
> surely someone will have depended on that, [...]

Fortunately, `add_flags' is a procedure local variable in 
default_target_compile, so it is not visible outside of that procedure.

This patch really exposes a significant deficiency in our current 
implementation of default_target_compile:  the order of various flags 
can be significant, but we only have that order implicitly expressed in 
the code, which goes all the way back to (of course) the "Initial 
revision" that is probably from a time before Tcl had the features that 
will allow significant cleanup in here.

Rather than introducing more variables, I propose changing add_flags to 
an array and collecting each category of flags into its own element, 
then emitting those elements in a fixed order to build the `opts' list. 
This would also allow us to easily support other cases, for example, 
prefixing "special" linker flags with "-Wl," or similar handling for 
other frontends. I think we only need to support GCC command syntax, 
which simplifies the issue a bit, but even GCC frontends are not 100% 
consistent, as this issue with gnatmake shows.


What categories do the flags currently accumulated in `add_flags' 
cover?  I see at least:
    - compiler flags (adaflags/cxxflags/dflags/f77flags/f90flags)
    - explicit additional flags ("additional_flags=" option)
    - explicit ldflags ("ldflags=" option)
    - libraries ("libs=" option)
    - preprocessor search paths ("incdir=" option)
    - linker search paths ("libdir=" option and [board_info $dest libs])
    - linker script ("ldscript=" option or [board_info $dest ldscript])
    - optimization flags ("optimize=" option)
    - target compiler flags from host ([board_info $host cflags_for_target])
    - type selection flag ("-c"/"-E"/"-S")
    - target compiler flags ([board_info $dest cflags] *regardless* of 
the compiler selected)
    - target linker flags ([board_info $dest ldflags])
    - special flags for C++ ([g++_link_flags])
    - an attempt to locate libstdc++, also regardless of compiler
    - debug flags, if the "debug" option is given
    - the math library
    - "-Wl,-r" if board_info knows a "remote_link" key
    - "-Wl,-oformat,[board_info $dest output_format]" if that is defined
    - multilib flags, currently *prepended* if defined
    - a destination file

Some of these could probably be combined and I may have combined 
categories that should be separate in the above list.  The GNU toolchain 
has always been a kind of "magic box that just works" (until it doesn't 
and the manual explains the problem) for me, so I am uncertain what the 
ordering rules for combining these categories should be.  Anyone know 
the traditional rules and, perhaps more importantly, what systems need 
which rules?

-- Jacob