Re: Extension proposal

[Eray Ozkural (exa)]

Hi,

"Paul D. Smith" wrote:
> 
> Hi Eray;
> 
> Thanks for the patch.
> 
> However, you should be aware that the major new feature for the next
> release of GNU make, which will be 3.80, is a superset of the change you
> are proposing.  The read.c file is being (indeed, has already been)
> fairly extensively reworked.
> 

I do wonder what changes are coming to GNU make as the superset of the
changes I proposed. I had two changes:

  * foreach takes an optional arg (separator)
  * interpret treats its arg string like an included Makefile.

These are rather independent changes, so it would be nice if either
of them could be included or worked out for a next version. If I can
get hold of the alpha version which you've been talking about I guess
I can be of help.

> Also, you make use of very advanced functionality (fmemopen) which
> isn't available even on the large majority of modern UNIX versions, much
> less on the other supported platforms such as Windows, DOS, VMS, and
> Amiga.  I cannot accept code for fundamental (makefile-level) changes in
> GNU make's syntax which is not portable, or at least mostly portable.
> The reason GNU make still uses K&R style function declarations, for
> example, is because make is a fundamental part of the GNU bootstrap
> toolchain, and as such it _must_ work on even very old systems without
> ANSI compilers [*].
> 

I see, so my changes to read.c are pretty much toying around. If the
3.80 read.c provides similar parsing functionality than I suppose it
would be possible to do similar things in a portable way.

I'm still fond of the foreach optional arg though ;)

> It would be good to contact me about potential new functionality you are
> interested in adding to make so we can be sure there isn't overlap and
> duplication of work.  Also, we need to be sure the paperwork is properly
> handled.
> 

I'd be glad to contribute to GNU make. The documentation has to be
handled properly, of course.

The new functionality I'm interested would be adding new functions
or advanced features that allow more generalized constructs. I know this
is vague, but for instance I proposed these changes because I needed
something like the following:

$(PROGRAMS)_OBJFILES = $(patsubst %.cxx,%.o, $($(PROGRAMS)_CXXFILES))

I wanted this to work when PROGRAMS is a list, but of course there should
be a way to tell make what a list is. The proper way seemed to be using
foreach, so that's why I came up with the changes that would support

$(interpret $(foreach prg,$(PROGRAMS),$(prg)_OBJFILES := $(patsubst %.cxx,%.o, 
$($(prg)_CXXFILES)),newline))

So basically, I think it's possible to revamp make so that we have
a small lisp-like functional language in it. some evaluation function
would be a good place to start. Without bloat, sure.

Another set of changes would be about making make more customizable and
robust. I'm not sure how it'd be done but some kind of file modification
detection that involves checksums would be great.

Thanks,

-- 
Eray (exa) Ozkural
Comp. Sci. Dept., Bilkent University, Ankara
e-mail: address@hidden
www: http://www.cs.bilkent.edu.tr/~erayo