Am Mon, 11 Jan 2010 14:07:23 +0100
schrieb Thorsten Behrens <t...@openoffice.org>:
> Ok, took longer than expected to find enough time for this, but here
> we go:
Hi Thorsten,
great to hear from you about this.
> 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
Valid point, but lets leave cross-platform builds out of the discussion
of a simple DSL for the build tasks as they have little to do with each
other, ok?
> 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
Quoting a band from Hamburg: "Jein" (=Yes and No).
Of course, there is a lot of superfluous syntax in the current
description, but you are dropping some information too:
- Where is the information which naming convention the tl-lib is
following?
- What about the files in tools/bootstrp, that are not generating
object files that should be liked into rscdep (sspretty.cxx for
example)?
The first information is hidden in you translation-implementation,
which I think is not better that having it explicit in the makefile.
While "Beautiful is better than ugly.", there is also "Explicit is
better than implicit.".
The cleanest way (which is still dirty) IMHO would be to have the
mapping of libs and naming conventions defined in one global file (in
solenv/inc).
The root problem of course is the use of pretty silly naming conventions
(platform in the filename, wtf?) and the use of different
contradicting naming conventions.
The second information is of course a problem with our source tree, but
unfortunately it seems not at all uncommon to have *.cxx files for
totally different libs in the same dir in the OOo source tree (sw is an
example of a total mess in that regard). If we had "clean
dirs" (only sources for one binary in one dir), it would be rather easy
to implement this in GNU make itself (but it will cost a bit of
performance, as make would need to collect all source files on every
run).
Using a "gnu make generator" for globbing the list of source files
generates a new set of problems when one thinks about how the generator
is run. The generator might actually be run:
a) manually or
b) always (on every make call)
c) only when it needs to be run by checking dependencies
b) likely is a performance hog (needs investigation covering all the
cornercases like idl-compilation etc.).
a) is evil, as it introduces shaky dependencies and little is gained by
it. Lemme explain: We are introducing dynamically collected source
files so that a dev does not need to manually declare the additional
file to the build system. With b) however, we traded "manually
declaring the source file" against "manually needing to regenerate the
makefiles", which I feel to be not much gain as both will be forgotten
by the careless dev.
c) would be nice. Unfortunately, it is not cheap to find out if a
makefile needs to be regenerated as it depends on the dirstate of the
source tree (or to be more specific: the parts of the source tree that
are referenced in it). Finding out _if_ a makefile needs to be
regenerated is likely just as or more expensive that just generating
it, thowing us back to solution b) with its drawbacks.
> 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.
> ...
>
> What do you think?
Looking a lot better that the GNU make input files, that are currently
used in the GNU make prototype for sure. However, I wonder how the
deeply nested lists and maps of python are looking to the
(python)-untrained eye. Subjecting an unsuspecting colleague to the
syntax will tell, I guess.
Another thing to be considered with this is the introduction of python
as a dependency that early in the toolchain. AFAIK currently we have
these dependencies for the build system:
- make (currently dmake which itself depends on another make to be
build)
- bash/tcsh
(actually POSIX-sh http://markmail.org/message/mrl5rywac6tjpq4i
seems do, which is good and should be kept that way)
- coreutils/findutils
- autoconf
- Perl (for build.pl)
- C-compiler and related toolchain (most importantly a C-Preprocessor)
- quite a few more that I have forgotten (we should really collect a
complete list for this)
I think we should get rid of the dependency on Perl, but at the same
time, I dont think we should introduce one on Python.
Given that the syntax of the "build task description language" should
be simple (because, if one needs it to be complex, one is likely Doing
It Wrong(tm)) I wonder, if something that can be processed by the
POSIX-shell or the C-Preprocessor would not be possible too(*).
Actually, I am rather confident that would be possible.
Still, there remains the problem with makefile generation (when? what
are the dependencies? does the generator glob for files or does the GNU
make build system do this?), which I guess we should discuss first,
because "All problems in computer science can be solved by another
level of indirection except for the problem of too many layers of
indirection."
Best Regards,
Bjoern
(*) When I am just talking about lean deps, I am just concerned about
translation. Validation for saneness and code style of the generator
files is not the same usecase and might use fat deps IMHO (being
run comparable to cwslocalize).
--
===========================================================================
Sitz der Gesellschaft:
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin Haering
===========================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org
For additional commands, e-mail: dev-h...@tools.openoffice.org
