On Sat, 2013-09-21 at 07:28 +0000, Edward Welbourne wrote: > > I've never understood why someone would use $(shell ...) in a recipe... > > I mean, the recipe will be run in the shell!! > > I remember we once had a library where the command-line to the archiver > was too long (about a quarter megabyte, IIRC). We worked round this by > having a temporary scratch dir, hard-linking every .o file into it, then > running the archiver in that directory, so as to trim all the paths off > .o files and get the command-line short enough. We *would* have > populated the scratch-dir by generating rules with define and eval and > having those do the job, but some project managers weren't happy to let > build machines take any software changes, not even the make upgrade to > get define/eval working properly, so we hacked it by having the archiver > command start by populating the scratch-dir. Of course, it couldn't do > that by running a single command (the command-line would have been too > long ...) so we did it with a $(shell ...) per object file via $(foreach > ...). It was kinda ugly but it worked ;^>
Yeah, I guess that's a legit reason. The next release of GNU make will have the $(file ...) function which will make that a LOT more efficient. Maybe you can convince TPTB to finally take a change :-). > (Separate infrastructure for auto-creating directories looked after the > .exists target, creating its directory.) I think we could, with > hind-sight, have used the foreach to generate one command per object > file, all separated with semicolons, so that no single command was too > big for the shell, No, that wouldn't work. It's not the individual command (between simicolons) that's too long, the problem is that make can't invoke the shell itself because the command line + environment is too large. The only way to work around this limitation is to avoid invoking a single command that's too long. > All but one of those I've looked into is manifestly less powerful than > make (and I'm still waiting for my former colleagues to get the > exception released to open source). I have no illusions that there aren't very serious issues with make and I have nothing bad to say about people who choose a different tool, or even write a different tool. Make is weighed down by standardization and history, so starting over from scratch has a lot of appeal. On the other hand starting over from scratch with an entirely different syntax means you have a significant disadvantage in terms of familiarity. _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
