Am Mittwoch, 23. August 2006 16:38 schrieb Will Coleda:

> I'd like to add a few features to the genfile() code when generating
> makefiles...

A general note: instead of inventing more and more custom make extensions, 
which all needs post-processing, I'm proposing to use a few needed gmake 
extensions. If gmake is not available, we would process the files like now 
and resolve custom syntax by some (probably) perl equivalents. 

If gmake is available, no processing is needed at all (given that some config 
include file was generated during Configure.pl time).

Instead of creating more and more config-time stuff, which needs more and more 
re-configs, we should put such operations just where they belong: into the 
Makefile. We might even be able run 'make -j8' eventually, when all the 
config dependencies are resolved.

> 1) allow inclusion of other makefile.in files: this will allow us to
> break up root.in into more maintainable chunks.

include other_makefile

> 2) create a directive that expands to a list of files that match a
> certain filter. something like:
>
> @FILES <path to dir from root> <glob to match files>@

The necessity of having root based file paths ist just coming from the 
separation of make and config, where the former is running in the targetdir 
(e.g. languages/tcl but the latter is running in parrot root). We should 
first get rid of that anomaly, then we have:

FILES = $(wildcard runtime/builtins/*.pir)

Proposal:

1) all dirs (which need some make support) contain GNUmakefile
   - generated parts are .included
   - if gmake is available, this file is the prefered makefile and will be run
   - if arch doesn't have gmake GNUmakefile is processed to create Makefile

2) we define a few usable extensions
   - include file
   - $(wildcard ..)
   - ifeq / else / endif  [1]
   - a few more

3) the generation of makefiles should be split from Configure.pl into a 
separated process, which is invoked by Configure.pl as a last step, but 
should also be runnable standalone and for one language.

leo

[1] we use that already with this syntax:
#CONDITIONED_LINE(SVN_ENTRIES):[EMAIL PROTECTED]@
#INVERSE_CONDITIONED_LINE(SVN_ENTRIES):SVN_ENTRIES=

Reply via email to