patchmake - Patches: patch #5809, @file response file support

 
 

You are not allowed to post comments on this tracker with your current authentication level.

patch #5809: @file response file support

Submitter:  None
Submitted:  Mon 19 Mar 2007 03:32:52 PM UTC
   
 
Category:  None Priority:  5 - Normal
Status:  None Privacy:  Public
Assigned to:  None Originator Email:  -email is unavailable-
Open/Closed:  Open Fixed Release:  None

Tue 02 Oct 2007 01:25:39 PM UTC, comment #5: 

I got the latest version of this via the mailing list.  I'll take a look.  Thanks.

Paul D. Smith <psmith>
Group administrator
Mon 16 Apr 2007 02:13:16 PM UTC, comment #4: 

Support is now being added to GCC/libiberty's @file support to write out a new @file to pass to subprocesses, so that could be used in GNU make when available if you do want to support long option lists for sub-makes.

http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00979.html

Anonymous
Thu 22 Mar 2007 05:09:33 AM UTC, comment #3: 

It's true that the most common flags that are specified many times and might break a command line length on a POSIX system are -o and -W, and neither of those are passed down anyway.  The only other flag I can think of that might appear multiple times is -I and it seems unlikely that there would need to be enough of these to break something on a POSIX system.

However, make also runs on DOS systems and these have severely restricted command line lengths: on systems like this the @file would be very useful but would probably be needed for flags like -I as well.  I'm not familiar enough with the system there to know how large an environment variable can legally be.

Tools like binutils and gcc can get away with this behavior more easily than make, because those tools aren't intended to be invoked recursively, as make is.

Anyway, you raise some good points; perhaps the right answer is to just not support passing @file recursively.  I would like to think about exactly how this will work.

Paul D. Smith <psmith>
Group administrator
Thu 22 Mar 2007 01:55:51 AM UTC, comment #2: 

The original use case is for the @file to contain -o options, which are documented as not being passed down; the use is of the form "make @file MAKE='make @file'".  So it's of use in practice even without support for passing down long lists of options.  There's the same limitation in GCC and GNU binutils: they don't currently support using @files to pass long lists down to subprocesses called internally, but are still useful in many cases without that.

Anonymous
Thu 22 Mar 2007 01:41:17 AM UTC, comment #1: 

I was thinking about this patch today and I realized there's a big missing piece in this implementation.

Remember that make is almost always invoked in a recursive manner.  Further recall that many of the command line options provided to make are passed down to sub-makes.  This is done through the environment (by setting the MAKEFLAGS environment variable and exporting it).

The current implementation of this feature would allow very large command lists to be provided to the top-level make, but as soon as make tried to invoke itself recursively and add all those options to the environment, the exec() of the sub-make will fail due to the environment being too large.

It's not immediately obvious how to fix this problem: of course the first thought is to add the @file to the MAKEFLAGS variable, and not the expansion of that file.  This would make the patch much more complex, but it could be done.  The problem is that not all options are passed down to sub-makes.  So, either we would have to say that all options in @files ARE passed down, even if they wouldn't be if they were on the command line, or we have to realize we're in a sub-make and ignore any options found in the @file that wouldn't normally be passed to sub-makes.

One other thing: obviously most of the time the sub-make is invoked in a different directory than the parent make, so the @file parameter would have to be translated to have the fully-qualified pathname of the original @file before being added to MAKEFLAGS.

Anyway, these are all do-able things but it does mean this feature needs more work than we currently have in this patch.

Paul D. Smith <psmith>
Group administrator
Mon 19 Mar 2007 03:32:52 PM UTC, original submission:  

http://lists.gnu.org/archive/html/bug-make/2006-09/msg00008.html

Sometimes you wish to invoke a program with too many or too long arguments
to fit in ARG_MAX.  For example, I have a case where a script wishes to
invoke make with many -o options.

There is a de facto standard solution to this problem, which is that a
command line argument of the form "@file" causes arguments to be read from
"file" (a "response file") if it exists.  (If "file" doesn't exist,
"@file" is taken literally as an ordinary command-line argument.)  This
feature is supported by GCC and GNU binutils, for example; I think it
originated on Windows, but it is useful everywhere with any command line
limit.

I'd like to have this feature in GNU make.  The patch below is my current
implementation of it for CVS HEAD make.  argv.c, the main part of the
implementation, is taken from GNU libiberty as used by GCC and binutils to
implement this feature, with a minimum of changes to be usable without the
rest of libiberty.  The documentation is also taken from libiberty.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #12211:  make-atfile2 added by None (15KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by psmith (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2007-03-19 None Attached File- Added make-atfile2, #12211

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code