link: "Recursive Make Considered Harmful"

Andrew Hacking ahacking at optusnet.com.au
Tue Jan 11 17:42:19 PST 2005


On Tue, 2005-01-11 at 22:22, Jeroen Ruigrok/asmodai wrote:
> -On [20050111 12:42], Christopher Vance (christopher at xxxxxx) wrote:
> >It's the use of shell commands to change make's behaviour - and not
> >just file content - that I consider a significant part of the problem.
> 
> Nice to see you saying that, because I was wondering if a good build tool
> needs any external dependencies at all in the terms of shell scripts.
> 
> The only things I can envision are things like compiler compilers and such
> tools that need to generate file X from template file Y.
> 
> >I think building would be more maintainable if the shell stuff was up
> >front to set parameters, etc., before doing any file construction, and
> >then never got invoked again in all the myriad recursions.
> 
> I agree to that.  I am just hard thinking if this is a reasonable
> assumption.  I cannot envision much right now that need external shell
> scripting or such given a sufficiently decent command set inside the build
> tool.
Some places where I have been forced to use shell variable assignment in
makefiles:
    - os/arch/platform detection eg: 'uname' for multi-platform builds.
    - converting pathnames (when dealing with Windoze systems)
    - wild-carding, eg: just pull in *.c as sources without having to
specify them manually.
    - interfacing to other build systems to extract variables
    - interfacing to source code control systems

As previously stated, shell/external variable assignment is not bad/evil
if done up front before the construction phase. Its when its evaluated
partway through a build that prevents the dependency graph from being
pre-calculated up front.

The build tool would need to provide the flexibility to invoke
custom/external functions for assigning/mutating any number of variables
based on any number of input arguments.  Such functions would have to be
idempotent (ie no side affects).

-Andrew Hacking






More information about the Kernel mailing list