You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Andre Fischer <aw...@gmail.com> on 2014/01/17 09:26:35 UTC
Building OpenOffice revisited (again)
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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Building OpenOffice revisited (again)
Posted by jan i <ja...@apache.org>.
On 17 January 2014 09:26, Andre Fischer <aw...@gmail.com> wrote:
> 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.
>
Quite a nice idea, its more or less the base we use in the capstone project.
With the capstone project we try to convert the current system to a visual
studio solution, which are xml. The idea being that we can easy
1) convert it to a generic xml structure
2) build a vc and makefile generator (basically just a huge style sheet)
I was going to talk about it at FOSDEM, but due to some unfortunate (but
logical) clashes, preferred not to.
rgds
jan I.
>
> 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-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: Building OpenOffice revisited (again)
Posted by Kay Schenk <ka...@gmail.com>.
On Fri, Jan 17, 2014 at 9:59 AM, Kay Schenk <ka...@gmail.com> wrote:
>
>
> On Fri, Jan 17, 2014 at 12:26 AM, Andre Fischer <aw...@gmail.com> wrote:
>
>> 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
>>
>>
> Any move to making tracking dependencies (build setups) for the modules
> better/easier is a move in the right direction. We have quite an
> inconsistent mix right now. Look at what's in /connectivity vs /comphelper
> as an example.
>
> Discuss away! :)
>
I've had a bit more time to think about this and do some investigation.
Using XML files for specs does seem like a nice way to go and would open up
some other administrative options for us.
This so reminded me of ant but for C++, I started looking around...and
yes, there are some ant building tools for C++ out there -- commercial not
open source -- but I know this isn't what you meant really. Anyway, I look
forward to hearing more about this.
>
>
>> [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-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
>
>
> --
>
> -------------------------------------------------------------------------------------------------
> MzK
>
> "Cats do not have to be shown how to have a good time,
> for they are unfailing ingenious in that respect."
> -- James Mason
>
--
-------------------------------------------------------------------------------------------------
MzK
"Cats do not have to be shown how to have a good time,
for they are unfailing ingenious in that respect."
-- James Mason
Re: Building OpenOffice revisited (again)
Posted by Kay Schenk <ka...@gmail.com>.
On Fri, Jan 17, 2014 at 12:26 AM, Andre Fischer <aw...@gmail.com> wrote:
> 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
>
>
Any move to making tracking dependencies (build setups) for the modules
better/easier is a move in the right direction. We have quite an
inconsistent mix right now. Look at what's in /connectivity vs /comphelper
as an example.
Discuss away! :)
> [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-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
--
-------------------------------------------------------------------------------------------------
MzK
"Cats do not have to be shown how to have a good time,
for they are unfailing ingenious in that respect."
-- James Mason