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

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.

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.