Mathias Bauer wrote: > > Understood. I pretty much agree with the goals, assume you did your > > due diligence on verifying that gnu make does not trip over on the > > full input set (that was my point of cautioning you, with the bjam > > story), and am now trying to explore ideas on how to make the actual > > makefiles appealing - the current state is not convincing, just > > plainly because they're not substantially different from the ideal > > dmake makefile in the existing system - and with their redundancies, > > will suffer the same bitrot as the old system. > Sounds good. :-) > Any improvement would be welcome. > Ok, took longer than expected to find enough time for this, but here we go:
After my initial performance worries had been sorted out, there are
basically two points left I'd require from an all-new build system:
- declarative syntax, as little duplication as possible
- ability to do cross-platform builds
For the former, look at this gnu makefile snippet (taken from
gnu_make cws):
[...]
$(eval $(call gb_Executable_Executable,rscdep))
$(eval $(call gb_Executable_set_linked_libs,rscdep,\
$(call gb_OOoLibrary_get_linknames,\
tl \
) \
))
$(eval $(call gb_Executable_add_exception_objects,rscdep,\
tools/bootstrp/appdef \
tools/bootstrp/command \
[etc.]
Call me purist, but there's a lot of noise in these lines, that
convey little, if any information. Plus, there's redundancy, in the
form of name prefixes, gnu make plumbing to call, etc., and also the
need to exhaustively list all object files (by listing paths names
of cxx files, stripped from the .cxx extension).
But the actual information contained in the above lines is actually
this:
rscdep source files: tools/bootstrp/*
rscdep link libs: tl
So I hacked up some python to parse a sort of declarative input
file, and generate gnu makefiles with Björn's eval framework out of
that. Corresponding to the above lines, this would be the input
snippet:
targets: [
{
executable: {
name: 'rscdep'
arch: host
}
sources: {
glob: '*.cxx'
paths: ['tools/bootstrp']
}
linking: ['tl']
} ]
I think it's cleaner, and there's definitely not much (should I say
any?) redundancy left. Additionally, one can enhance the script to
generate makefiles for pretty much every make tool of this world,
including eclipse/netbeans/visual studio project files.
The "arch: host" line is not yet fleshed out in the script, nor in
the gnu_make cws, but is indented for doing cross-builds: just
annotate every target with one out of "arch: [host:target:both]" to
later advise the build system which output architecture to compile
for.
Prototypical script, input files & patch against CWS gnu_make
attached (to handle input file globs). For testing, call it like
this: ./gmakegen.py tools_rscdep.in
What do you think?
-- Thorsten
gnumakegen.tgz
Description: application/compressed-tar
pgpJpcsblWlGK.pgp
Description: PGP signature
