I would like to present some ideas about how to improve the
building of OpenOffice. Maybe this can serve as a basis for a
face-to-face discussion at FOSDEM.
Makefiles in general and our build environment in particular have a
declarative and an imperative part. In short dependencies are declared
and build recipes are given as instructions. This is reflected by
both our build systems. For dmake we have makefile.mk files in all
source directories. They contain basically the names of libraries to
build and c++ files to compile. The recipes that define how to link
and compile are located in solenv/inc/. This is similar for gbuild.
There are a couple of makefiles (named Makefile, Module...mk,
Library...mk and so on) in the top level module directories. They
also just declare the set of files to compile or link. The gbuild
recipes can be found in solenv/gbuild/.
This observation together with my (our) unhappiness of the current
state of our build systems lead me to the following "insight". One
obstacle when playing around with other build tools, like cmake or
ninja or just plain GNU make makefiles (as opposed to our
meta-programming gbuild files) is the syntax of how our dependencies
are declared. It would be so much easier when they would be stored in
a file format that is both machine and human readable and not tied to
one specific program.
What if we used XML files to represent the dependencies? We could
convert the gbuild makefiles into XML files with very similar
structure. A simple Perl script or Java program (both understand XML
and are part of our build prerequisites) can convert the XML file to
gbuild files that would be almost identical to what we have today.
And when we want to try alternatives, we can provide other converters
and make experiments. See [2] for an example.
Such a converter could be more complex than just do a simple syntax
translation. For using ninja [1], which is described as "assembler"
and has no %.o : %c rules and no if/else/fi, we would need more than
that. But still less than cmake because our compiler (and other build
tool) detection is done by configure.
Using XML files would probably not much of an overhead. The
translation into makefiles has to be done only when the makefile/XML
representation changes. The additional dependencies, one per current
makefile (less than 10 in the average module), are negligible compare
to the dependencies for several hundreds of source files and several
thousands of headers.
But again, this is not (yet) a proposal for change.
Just the basis for discussion.
It is also not (yet) a non-proposal for changing the build system
completely.
Just the idea to express our "business logic" in a way that is
independent from the build system (whichever we use/will use).
Best regards,
Andre
[1] http://martine.github.io/ninja/manual.html
[2] Excerpt from sw/Library_sw.mk:
$(eval $(call gb_Library_add_linked_libs,sw,\
avmedia \
basegfx \
comphelper \
...
vcl \
vos3 \
xo \
$(gb_STDLIBS) \
))
$(eval $(call gb_Library_add_exception_objects,sw,\
sw/source/core/SwNumberTree/SwNodeNum \
sw/source/core/SwNumberTree/SwNumberTree \
sw/source/core/access/acccell \
...
sw/source/ui/wrtsh/wrtsh3 \
sw/source/ui/wrtsh/wrtsh4 \
sw/source/ui/wrtsh/wrtundo \
))
->
<library="sw">
<linked-libraries>
<library-reference name="avmedia"/>
<library-reference name="basegfx"/>
<library-reference name="comphelper"/>
...
<library-reference name="vcl"/>
<library-reference name="vos3"/>
<library-reference name="xo"/>
<library-reference variable="gb_STDLIBS"/>
</linked-libraries>
<source-files language="c++" exception_handling="yes">
<file name="sw/source/core/SwNumberTree/SwNodeNum.cxx"/>
<file name="sw/source/core/SwNumberTree/SwNumberTree"/>
<file name="sw/source/core/access/acccell"/>
...
<file name="sw/source/ui/wrtsh/wrtsh3"/>
<file name="sw/source/ui/wrtsh/wrtsh4"/>
<file name="sw/source/ui/wrtsh/wrtundo"/>
</source-files>
</library>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
