[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Extending gmake to make it less dependant on the shell
From: |
Eli Zaretskii |
Subject: |
Re: Extending gmake to make it less dependant on the shell |
Date: |
25 Mar 2004 07:57:57 +0200 |
> From: Matt Lavoie <address@hidden>
> Date: Wed, 24 Mar 2004 12:13:42 -0800
>
> It occurs to me that there is a core set of simple os-related functions that
> makefiles typically use. The short list below is just an example. If these
> became part of gmake -- the resulting makefiles would be much less reliant
> on shells, thus minimizing the conditional code necessary in the makefiles.
> [ In addition, the lack of general expression evaluation in gmake also
> forces some reliance on the shell's conditional processing. ]
>
> Functions:
> echo string
> remove file
> remove tree
> make directory (w/ nesting)
> remove directory (w/ recursive + force options)
> copy <file1> <file2>
>
> Thoughts?
The idea is okay, IMHO, but I'm afraid that the list of built-ins
required to achieve what you want will not stop at the short list you
presented. I've seen not-so-complex Makefile's that use tools like
Sed, `find', and awk, rely on elaborate shell-specific command-line
quoting, and other features that will give you trouble if you drag
such a Makefile across platforms. Even a simple `cd $FOO' will break
on Windows if the value of $FOO includes a drive letter.
So I'm not sure how practical would it be to implement a set of
built-ins that could solve a reasonably large proportion of such
problems. I guess more research is needed to gather typical
non-portable constructs in Makefile's, before a decision could be
made.