PATCH: Support "@file"

[Mark Mitchell]

Nick Clifton wrote:

>> OK to apply?
> 
> Yes, but I think that the section describing the @<file> syntax ought to
> be extended to mention that:
> 
>   * The command-line options read from the file are treated as if they
> had been included on the original command line at the point where the
> @<file> was used.
> 
>   * The @<file> syntax cannot be used inside the file being parsed.

The second point is actually not true; DJ asked that I make it support
recursion.  I committed my changes, using the following for the
documentation:

--

@item @@@var{file}
Read command-line options from @var{file}.  The options read are
inserted in place of the original @@@var{file} option.  If @var{file}
does not exist, or cannot be read, then the option will be treated
literally, and not removed.

Options in @var{file} are separated by whitespace.  A whitespace
character may be included in an option by surrounding the entire
option in either single or double quotes.  Any character (including a
backslash) may be included by prefixing the character to be included
character with a backslash.  The @var{file} may itself contain
additional @@@var{file} options; any such options will be processed
recursively.

--

which I think satifies your requests.

> Also it occurs to me that maybe we ought to have a long-option
> equivalent of @<file>, eg something like:
> 
>   --extra-switches-from-file=<file>
> 
> This would mean changing libiberty to allow an entry point into the body
> of the expandargv() function or else getting the various different
> projects that use libiberty's expandargv() function to agree on a name
> of the long option.  What do you think ?

If we do it, I think we should do that in the existing expandargv.  That
will ensure it's consistent across all programs which use expandargv,
which seems like a good thing.

I shall now work on as/ld docs for @file.

Thanks,

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