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
_______________________________________________
DejaGnu mailing list
DejaGnu@gnu.org
https://lists.gnu.org/mailman/listinfo/dejagnu
