On Tuesday 22 November 2011, Bob Friesenhahn wrote: > On Tue, 22 Nov 2011, Stefano Lattarini wrote: > > >> In order for this to work, Automake would need to become self-hosting > >> (not need other packages to be installed in advance) and written only > >> in a GNU-approved and FSF-copyrighted portable implementation > >> language. > >> > > Honestly, my idea was to follow the "lead" of Quagmire here, and use > > GNU make's own "extensibility" ($(eval), $(call), self-reflection > > features like $(.VARIABLES), etc.) as a leverage. If we don't, we'd > > better try to create a new-generation build system instead, as you've > > proposed. > > I would like to use a build system which maintains a formal record of > input files used, as well as their signatures, so that the software is > properly built even if a file is set back in time (e.g. replaced with > an older version). I would also like to use a build system which > intelligently avoids unnecessary re-linking of objects and libraries > but always re-links when needed. I would like to use a build system > which can intelligently distribute builds across multiple machines if > necessary. Can pure GNU make syntax be used to accomplish all that? > I honestly don't know. But I *guess* that, if it can, it would require a lot of work, and probably a lot of hacks.
> > That sounds like a too grand, over-reaching plan to me; and its very > > concept seems to be somewhat at odds with the Unix philosophy. > > How so? It is true that Kernighan & Pike recommend simplicity but > they don't recommend inefficiency either. Today the GNU build system > suffers from considerable inefficiency and a huge amount of > complexity. > Sadly true. Starting to take advantage of GNU make might help in mitigating this. Or maybe this is just wishful thinking; we won't know until we try it out. > If GNU is willing to require that a GNU build tool be > installed in advance, then that build tool should be the best > fit for the actual requirements as possible. > But GNU make is not a "random" GNU tool -- it's a mature, well-known, alredy widespread tool, already used and required by non-trivial build systems (e.g., Linux kernel's, and git's). > In autotools, great effort is made to try to write shell, sed, awk, > and m4 code which works portably across many implementations > [micro-nit: this is not the case anymore for the m4 code, which has been since long requiring GNU m4] > and requires a great many fork/exec calls and opening, reading, writing, > and closing of files. If GNU is to require installing a build tool > then that build tool should entirely eliminate any need to worry about > syntax portability so that scripts can be written to do exactly what > is required. > Again, I'm not opposed to the idea (which might have a large acceptance after all, judging from CMake success). But I find it ortoghonal to the proposal under discussion, which has a much narrower and less "speculative" scope (note that "speculative" is to be intended in its good sense here!). Regards, Stefano
