[perl #40225] Making Makefiles...
Will Coleda
# Please include the string: [perl #40225]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40225 >
I'd like to add a few features to the genfile() code when generating
makefiles...
1) allow inclusion of other makefile.in files: this will allow us to
break up root.in into more maintainable chunks.
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>@
so, in tcl's makefile, I might have something like:
@FILES languages/tcl runtime/builtin/*.pir
which would use the full path (languages/tcl/runtime/builtin/*.pir)
to actually find the files from parrot root, but then generate the
list in the makefile relative to the tcl directory (where the
makefile is going to be used.)
I'm posting to see if anyone has any syntax suggestions or previous
art I should be looking at first. I'm tempted to leave @@ to mean
"items from config only" and perhaps have something else for these
more meta directives. (back to ${}? something else?)
Thoughts?
--
Will "Coke" Coleda
wi...@coleda.com
Will Coleda
Feedback still welcome, might as well leave it as a ticket now.
Leopold Toetsch
> 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):SVN_ENTRIES=@SVN_ENTRIES@
#INVERSE_CONDITIONED_LINE(SVN_ENTRIES):SVN_ENTRIES=
Will Coleda
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)
#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):SVN_ENTRIES=@SVN_ENTRIES@
> #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.
Joshua Hoblitt
>
> 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)
I think it's a mistake to use a make-like syntax. That's just going to
lead to maintenance confusion down the road. Someone, someday is going to change
it thinking that's it's just GNU make syntax.
Why don't you just embed blocks of Perl code instead of inventing a new
syntax?
-J
--
Will Coleda
On Aug 23, 2006, at 4:10 PM, Joshua Hoblitt wrote:
> On Wed, Aug 23, 2006 at 02:24:45PM -0400, Will Coleda wrote:
>>
>> 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)
>
> I think it's a mistake to use a make-like syntax. That's just
> going to
> lead to maintenance confusion down the road. Someone, someday is
> going to change
> it thinking that's it's just GNU make syntax.
>
I agree, that could be an issue, but we can easily have this syntax
generate an exception if an unexpected keyword is generated. I'll see
if I can add that to my work in progress.
This particular tradeoff of maintenance confusion on makefiles is a
step in the right direction, IMO.
> Why don't you just embed blocks of Perl code instead of inventing a
> new
> syntax?
>
The whole point of using the gmake syntax is that it is the opposite
of "inventing a new syntax". It is reusing the portions we need from
an existing syntax.
As to just using perl: that makes it more complicated for the people
who have to maintain the rules, by requiring more code to do the same
thing, and then duplicating that code across N uses in M makefiles.
That said, I don't particularly care about the actual syntax as long
as I can declare these sorts of things with a minimal fuss. But in
place of a decision from Chip, I'll go with this for now.