On Aug 23, 2006, at 1:46 PM, Leopold Toetsch via RT wrote:
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 you mean "inventing more syntax", I fully agree. I'm currently
working on stealing the gmake syntax you've pointed out on IRC.
Thanks. If there are any current transformations that we're doing
that could be done in gmake, open a ticket and I'll change the syntax
we use.
But we still need these extensions, since gmake is *NOT* always going
to be available, to the best of my knowledge. Some kind of processing
of the makefiles needs to occcur - even if we don't allow things like
$(wildcard), we still need to process @FOO@ expansions.
If gmake is available, no processing is needed at all (given that
some config
include file was generated during Configure.pl time).
My only concern about that (after dealing with the relative paths
issue you address below) is that we might end up with different
behavior from gmake vs. our own handrolled version - obviously due to
separate code paths, but also potentially due to subtle changes due
to when the code is being executed. (at build time vs. at config time).
This might also be impacted by the very old "get rid of make" ticket
- but in that case, we can just always fallback to our handrolled
version.
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.
This is a red herring. Make dependencies need to be improved for this
to happen. Whether we use build time vs. config-time constructs
doesn't really matter. I think the syntax I'm adding here (which is
now based on gmake!) should actually make it *easier* to document the
dependencies, since we'll now be able to do it more declaratively,
and cross-platform to boot.
1) allow inclusion of other makefile.in files: this will allow us to
break up root.in into more maintainable chunks.
include other_makefile
This is fine for static sections, as we discussed on IRC. I think
there's still a maintenance win to having multiple .in's that can get
folded into a single constructed Makefile (as opposed to having
multiple .in's transformed into multiple makefiles which then include
each other at make time; and as opposed to a single monolithic .in)
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.
#3 is the last item blocking http://rt.perl.org/rt3/Ticket/
Display.html?id=31633 from getting resolved, I think.
This is not a bad proposal - I'd extract it from this ticket and have
it considered on its own merits.
leo
[1] we use that already with this syntax:
#CONDITIONED_LINE(SVN_ENTRIES):[EMAIL PROTECTED]@
#INVERSE_CONDITIONED_LINE(SVN_ENTRIES):SVN_ENTRIES=
To sum up: for now, I'm working on being able to support:
$(addprefix runtime/builtin,$(notdir $(wildcard languages/tcl/
runtime/builtin/*.pir)))
Which looks like gmake, but will be expanded at config time: once we
fixup where/when language makefiles are generated, this will simplify
to:
$(wildcard runtime/builtin/*.pir)
And going forward, we might disable the config-time expansion of this
depending on what make we're using, so that gmake does it instead of
Configure. (but this way it should work out of the gate on nmake, and
whatever else folks are building with.)
Regards.
--
Will "Coke" Coleda
[EMAIL PROTECTED]
