4.2 Project: "@file" support

Mark Mitchell mark@codesourcery.com
Sat Aug 27 00:08:00 GMT 2005


DJ Delorie wrote:

> However, I don't see a way to do that for *all* OSs, and people seem
> to want that.  So while I won't actively support it in libiberty, I
> won't hinder it either.

Great!

> To make it as unobtrusive as possible, I request that the
> application-side only require one line:
> 
> 	functionname(&argc, &argv);
> 
> Let's name it something generic, and assume that *all* command line
> fiddling will be done within that function, and that the application
> never need worry about it - ever.

OK.

> I suggest that DJGPP's implementation define the functionality (at
> least, the parts that make sense to implmement globally), as we've had
> over a decade of experience with it, and thus it's likely to cause the
> least surprises:
> 
> http://www.delorie.com/bin/cvsweb.cgi/djgpp/src/libc/crt0/c1args.c?rev=1.10
> 
> (search for expand_response_files)

First, let me say that I don't feel strongly about anything after this 
point in this mail.  So, I can be pushed around pretty easily here; I'm 
more after some solution than any particular one.

I found the DJGPP code a little complicated, but I'm sure I can work it 
out.  I also did some additional experiments with MSVC and found some 
slightly odd behaviors, like double-quoting works, in general, but:

   "foo
   bar"

is actually two arguments.  I guess I'd argue that the behavior Windows 
people probably *most* expect is MSVC (rather than DJGPP), but that may 
not be true of GNU people in particular, who might be more likely to 
have used DJGPP.

However, I have a counter-proposal, which is that we use libiberty's 
existing buildargv.  That seems maximally consistent.  I didn't do that 
originally because I didn't know it was there, until very late in the 
game.  We would have to factor out the code so that we could avoid the 
buildargv behavior that creates a non-empty argv from an empty string, 
but other than that it seems like we could just leverage the quoting 
behavior that's already there.

Thanks,

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304



More information about the Gcc mailing list