Re: [cygwin] cwrapper emits wrapper script

[Charles Wilson]

Ralf Wildenhues wrote:
> Certainly.  I was merely trying to not infer that you'd have to do even
> more work than the lot that you're already doing.  Of course if you're
> ambitious go for it.  ;-)
>
> Thanks for fixing the MinGW case here.

Sure.

> > > Hmm, maybe one after the `rm -f "$prefix/bin/..."' and one after the
> > > `$MAKE uninstall' line?
> > Tabled.  Don't want to tackle more than one thing in a patch, you know. <g>
>
> Yes, but that particular two-line change could go in before everything
> else, given that it fixes the failure.

I'll take a look.  During my most recent testsuite run on mingw, tho, I 
didn't see the problem (which is typical of this particular mingwism).

> Yes, yes.  I was thinking out loud and it was late...

Been there, done that, got the T-shirt.

> Hmm.  OK.  But since you undefine DEBUG anyway (and you've kept that for
> the changed macro), there was no underlying problem here, no? 

You are correct.

> Anyway,
> keeping this change is fine.

Thanks.  This is weird, tho.  On the 1.5 branch (25 Nov 2005):
  cvs diff -r 1.334.2.104 -r 1.334.2.105 ltmain.in

+/* -DDEBUG is fairly common in CFLAGS.  */
+#undef DEBUG
+#if defined DEBUGWRAPPER
+# define DEBUG(format, ...) fprintf(stderr, format, __VA_ARGS__)
+#else
+# define DEBUG(format, ...)
+#endif

was committed all at once.  On the trunk (6 Nov 2003) at
   cvs diff -r 1.352 -r 1.353 ltmain.in
only the following hunk was committed

+#if defined DEBUGWRAPPER
+# define DEBUG(format, ...) fprintf(stderr, format, __VA_ARGS__)
+#else
+# define DEBUG(format, ...)
+#endif

and the brown-paper-bag fix came along a year later (1 Nov 2004) after 
the file had been moved from <top>/ltmain.in to <top>/config/ltmain.m4sh 
(but before it was moved AGAIN to <top>/libltdl/config/ltmain.m4sh):

    cvs diff -r 1.17 -r 1.18 ltmain.m4sh

+/* -DDEBUG is fairly common in CFLAGS.  */
+#undef DEBUG

And it was a year after THAT (25 Nov 2005), that the now-improved 
version was committed to the 1.5 branch.  I had forgotten that the 
exectuable wrappers went into HEAD first.

> This is because $ECHO can be much much more expensive than echo, forking
> and all.  Not on w32 especially (unless you happen to use a shell such
> as dash), but in general, yes.

Ack.

> > okay.  But don't come crying to me if somebody populates your argv[] with 
> > non-null-terminated strings.
>
> How would that be possible?  ISO C guarantees them to be strings, i.e.,
> null-terminated runs of characters.

You must have missed my invisible <sarcasm> tag.

> > if test -n "$TARGETSHELL" ; then
> >   # no path translation at all
> >   lt_newargv1="$TARGETSHELL"
> > else
> [...]
> >   esac
> > fi
> > << now use $lt_newargv1 unconditionally >>
>
> Sounds viable.  (picky note: on the right hand side of a shell
> assignment, there is no need for double quotes, as word splitting is
> disabled there.)

Ack.

> I think using strchr is clearer.

Okay.

> > > > +  if ( (shwrapperFILE = fopen (newargz[1], "wb")) == 0 )
> > > Why binary?
> > [snip explanation]
> OK, thanks for the explanation.

> > > What's that extra ; for BTW?
> > If !DEBUGWRAPPER, then LTWRAPPER_DEBUGPRINTF() goes away completely, and 
> > gcc complains about the empty body in the for loop.
>
> D'oh.  Thanks.

See side thread.

> > > strrchr?
> > Nope, can't do that here.  IS_DIR_SEPARATOR(c) checks whether c is '\\' OR 
> > '/'; trying to use strrchr in that situation is more confusing than it is 
> > worth.
>
> Ah, ok.  Sorry.

FYI, I'm going to focus on the argz patch before returning to this one. 
(I am pushing a bit, because if possible and acceptable to 
[Ralf|Gary|others], I want to get both the argz stuff and as much of the 
"eliminate .exe/shell wrapper in same directory confusion" work as I 
can, into libtool-HEAD before Steve Ellcey commits the updated "libtool 
ToT" files to gcc svn...which if I'm reading the tea leaves correctly is 
Real Soon Now)

--
Chuck