|
From: | Jacob Bachmeyer |
Subject: | Re: [PATCH 3/3][DejaGNU] target: Wrap linker flags into `-largs'/`-margs' for Ada |
Date: | Tue, 21 May 2019 19:04:18 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.22) Gecko/20090807 MultiZilla/1.8.3.4e SeaMonkey/1.1.17 Mnenhy/0.7.6.0 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |