Re: Proposals for new features.

[Paul Smith]

First I think I should set some ground rules/expectations.  I don't want
people to spend a lot of time and effort then be disappointed.

My position on GNU make is that it is a critical part of the basic
infrastructure of free software, and I'm not willing to do anything to
upset that.  Not to mention being used by thousands of non-free software
projects.  One part of that is ensuring that GNU make is maximally
portable; because GNU make is a part of the compiler bootstrap suite it
must be as portable as possible.  This is frustrating as it complicates
the code and limits the facilities of the underlying operating system
that we can make use of, but I still consider that any port that is
still used should be maintained as long as feasible.

Also, there is a POSIX standard definition for the "make" program and
while it's pretty weak, I won't change GNU make to violate that standard
in any egregious way (for example, changing the default introductory
character for recipes from tabs to another character).

That being said, obviously GNU make has a long history of adding
important new features and I want to continue that.  So for example, as
I mention below I'm happy to allow the user to change the recipe
introduction character as long as the default is unchanged.

Finally, there are a number of other versions of make out there, many of
which have features that GNU make still doesn't.  There are also some
extra features mentioned in the POSIX rationale section.  Wherever
reasonable we should implement features using that syntax rather than
inventing our own.

I don't maintain, myself, that make and/or GNU make is the greatest
build tool that could ever exist, and while I would love it to become
that, it can't come at the expense of backward compatibility and
standards adherence.

On Sat, 2007-09-01 at 10:54 +0200, Ramón García wrote:

> - Filenames with spaces. This does not look very difficult.

There have been numerous threads about this over the years.  There are
easier and harder ways to go about it, and ways that are less and more
acceptable to me from a user-interface and implementation standpoint.

> - A easier syntax. The syntax of tabs for recipes is awkward in modern
> times. It is confusing for starters. Backward compatibility can be
> preserved with command line options and flags in rules.

As above, as long as you change your proposal so that the "command line
options and flags in rules" are used to change the recipe introduction
character FROM the default, which remains TAB, then I'm happy with this.

In fact, you may have noticed that I recently modified GNU make so that
the recipe introduction character is in a variable rather than a
constant.  I have a workspace that goes further, but allowing a variable
to be set to define that character.  I didn't commit it because I ran
into a little glitch: the recipes are not just parsed at makefile
read-in time: they're also parsed when make is going to execute a job.
To preserve that means that the recipe introduction character has to be
stored with the rule so that it can be used during parsing in
job.c/command.c.  I wasn't willing to increase the size of the rule
structure for that.

My current changes (not complete) change the code so that the removal of
the recipe introduction character all happens during read-in and none of
it is handled during job.c/command.c.

> With this change, I would also include executing the lines of a single
> recipe in a single shell invocation. This would make it easier to
> write recipes in alternative languages like Python, Perl o Tcl.

Again, this cannot become the default behavior because it is not correct
according to the POSIX standard.

However, other versions of make and indeed the POSIX rationale itself do
provide for a special .ONESHELL: pseudo-target which, if defined, gives
the behavior you mention: the entire recipe is passed to a single shell,
preserving newlines and all.  I would love for this to be implemented.
Note that you need to be careful to preserve the fast path wherever
possible; I would say that if .ONESHELL is defined you only fast-path
recipes that contain a single line.

> - Some mechanism to make it easier to make high level rules, which are
> equivalent to a set of lower level rules, but conceptually close to
> what the developer intends. Something closer to ant. In ant, one
> writes some like:
>   <target name="compile" depends="init"
>         description="compile the source " >
>     <!-- Compile the java code from ${src} into ${build} -->
>     <javac srcdir="${src}" destdir="${build}"/>
>   </target>
> 
>  which is more or less equivalent to
> 
> compile: init
>        javac ....
> 
> Except that javac is not a just command: instead javac is a piece of
> java code that evaluates dependencies dynamically.
> 
>   What I have in mind now is something that allows a target to
> determinate dyncamilly some of its dependencies when called. For
> instance, a builtin variable .MORE_PREREQS that is evaluated to render
> a list of prerequisites at run time

It seems like this could be handled with the existing eval capabilities,
IF we enabled them to declare prerequisites in the second phase of
processing (today there is a special flag that disallows this after the
dependencies have been snapped).

In order to do this the current snap_deps() needs to be enhanced so that
it can be run at any time during make processing.  This idea leads to a
LOT of complex situations that we'd need to consider and resolve (not to
mention some non-trivial coding).

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.mad-scientist.us
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist