Re: Make -Wc,foo behave like -Xcompiler foo in link mode.

[Ralf Wildenhues]

Hi Peter,

* Peter Rosin wrote on Tue, Sep 08, 2009 at 09:44:46AM CEST:
> Den 2009-09-07 21:09 skrev Ralf Wildenhues:
> >>>+  eval "`$LIBTOOL --tag=$tag --config | $EGREP 
> >>>'^(wl|archive_cmds|reload_cmds)='`"
> >>You are not using $reload_cmds anywhere.
> >
> >Indeed; I added it because I thought of running a reload command, until
> >I realized that it wouldn't contain these flags anyway.  Removing it.
> >Thanks.
> 
> Still there :-)

D'oh.  Save before sending.  Thanks for checking!

> >Yeah, stresstest is ugly to debug.  I always run with -v -x to get as
> >many clues as possible.  But if you'd like to add more markers, feel
> >free to.

> Adding -x really helps, thanks for the hint! But it isn't really
> optimal when all commands seem to originate from line 24. E.g.

> ../../tests/flags.at:24: { test -n "$CC" && test "X$CC" != Xno; } || (exit 77)
> ../../tests/flags.at:24: $LIBTOOL --tag=CC --mode=compile $compile -c $source
> ../../tests/flags.at:24: $LIBTOOL -n --tag=CC --mode=compile $compile        
> $flag-foo -c $source
> ../../tests/flags.at:24: $FGREP " -foo" stdout

Ouch.  Hmm, that's due to the m4_foreach construct.  I don't know how to
fix that, short of expanding the test into one for each tag.  Maybe
something can be done upstream at the Autotest level about this.

> But the test isn't that long so not a major problem.

OK.  Anyway, the -x output shows variables expanded, that should help to
see what the particular command was about.

> >Does it pass for you?
> 
> Yes. gcc-3.4/cygwin-1.5 and msvc/msys are both ok. At least after I
> apply my "-Wc,"-patch, didn't have that originally on the msvc branch
> which threw me off track for a while... So, I can report that the test
> only seems to catch the original bug if $wl is non-empty. Probably
> good enough though...

Well, if $wl is empty, then it would seem to me that it doesn't really
matter on this particular system whether libtool prepends that to flags
or not.  You can't really expect the testsuite to expose a system-
specific bug on every other system.  We can try to make tests as widely
exposing as possible, but we shouldn't do so beyond reasonable effort.

My idea of the ideal Libtool test suite is to get as many semantics
covered as possible for the system and compiler combination at hand,
and then before a release do regression tests on as many systems and
with as many compilers as possible, to then be reasonably sure that
we don't regress.  I don't see another realistic way.

Of course, things like tests for Darwin-specific bugs, where the test
happens to be pretty much system-agnostic, can only help if run on all
systems.

BTW, you are free to merge from master to pr-msvc-support (after testing
that the merged tree still works as desired, of course) when you like.
That can only help.

Thanks,
Ralf