Re: Proposals for new features.

[R. Bernstein]

There's no question that GNU Make is a basic part of infrastructure of
free software. and no question that it needs to be available on
various OS's, backward compatible, POSIX compliant, reliable, etc.

But as a result of this and the limited resources, the time between
GNU Make releases tends to take a while.

That's where remake comes in. Since its releases don't have to be as
perfect and it doesn't have to support all of those OS's, it can be
more agile and try things of a more experimental nature. And it can
release these ideas earlier to get more rapid exposure. I've found
thie helpful in moving the ideas to maturity.

As the ideas mature, they can then get adopted/adapted.

I've never touted remake as something to use in production. I
certainly don't use it for that. It's just a tool I use to help me
deal with large Makefiles. For that, it works fine for my needs ;-)



Paul Smith writes:
 > 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
 > 
 > 
 > _______________________________________________
 > Make-alpha mailing list
 > address@hidden
 > http://lists.gnu.org/mailman/listinfo/make-alpha
 >