I agree with Tim and with Tim's suggested API, in particular "withfile". Involving the shell in something as basic and inherently portable as writing to a file opens up a world of portability issues, in addition to the performance and readability problems mentioned. Given that some platforms (Windows) have ARG_MAX limits and have adopted "command files" as the official workaround, a command line generator (which is fundamentally all make does) should have the native capability to create those kinds of command lines. IMHO.
In general there seems to be a curious resistance to adding functions, implying fear of a slippery slope such that the next thing you know make will have hundreds of functions. I don't see that happening - it seems to me the list of potential new functions adding basic, core make functionality is pretty limited. Right now there are viable proposals for two path-cleanup functions plus this one. There may be a few others but I suspect the number of proposals that will ever pass the core functionality test is less than 10, maybe a lot less, so I think a strong case can be made to just let them in and keep make a simple, standalone, single-file program which doesn't require inline Lisp and complex dynamic loader semantics and so on. Or perhaps I'm wrong and make would add a couple of new functions per release, forever. How bad would that be? David Boyce _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
