This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 4.2 Project: "@file" support


> but I don't think DJ and I are yet seeing eye-to-eye on (b).

I think it's a bad idea to choose a solution that requires each
application (we have many) to be modified to call an extra function.
It would be far better to have the OS manage it transparently.

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.

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.

DJGPP and Cygwin hosted programs won't ever use this, because @files
will already be expanded, but we can optimize that later.

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)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]