Re: [PATCH] Cwrapper should not eat -- arguments

[Charles Wilson]

Ralf Wildenhues wrote:
> > no application that you link will be runnable.  So any test that depends  
> > on running a compiled executable will fail unless it is skipped. But it  
> > sure won't PASS.
>
> Sure.  Thing is, we already have dozens of similar tests in the new
> testsuite.  They mostly work as expected, skipping if a test cannot be
> run at all.

OK.

> > > Just because we don't use the cwrapper in
> > > a test, doesn't mean that the test would now magically fail to pass "--"
> > > on to the real program. 
> > Okay, but now you have a wierd case. Suppose your test case relies on  
> > *running* the target executable, not just "I successfully linked it".  
> > There are several cases:
> [...]
> > This is a LOT of special casing.
>
> You are thinking too complicated.  The test is to be as follows: we
> build a program linked against an uninstalled library.  The program
> echoes its arguments.  If we can execute the program at all, then we
> require that its output contain the arguments we passed it (due to wine
> debug blurb, we ignore extra output).  If the program cannot be
> executed, we skip the test.  That is the only special case.

OK.

> You cannot expect that our testsuite will uncover bugs in systems other
> than the one for which the build tree is configured.  Let's not try to.

Ack.

> > (2) cross-to-mingw, $build has emulation environment -- this should work.\
>
> Same idea again.  The testsuite shouldn't try to verify that FOO_PATH
> was modified by the script.  Instead, it should try to execute the
> uninstalled program, and thereby verify that the runtime linker can
> actually *find* the uninstalled library.  Test the feature that is
> supposed to work, not the way by which our actual implementation makes
> it work.

Ack.

> Let me reformulate this more generally: whenever at all possible, do
> not reimplement the libtool.m4 or ltmain logic within the testsuite.
> If you absolutely have to differentiate, do not do it based on $host or
> similar, but on libtool variables (those output by './libtool --config)
> so that you at least reuse the libtool.m4 logic.

That seems reasonable.

> I am aware that we're deviating from this ideal quite a bit, but that
> doesn't make it a less worthwhile goal.
>
> Likewise, ltmain should ideally not use $host either, but I digress ...

Err...yeah, about that...

--
Chuck