[Libreoffice] Announce: gnumake in LibreOffice

[Norbert Thiebaud]

Hi all,

I've been working for some time to integrate into LibreOffice the
great work from Bjoern Michaelsen to migrate the build system to
gnumake.

If you are not familiar with his work, I invite you to read his blog
posts on the subject:

http://blogs.sun.com/GullFOSS/entry/gbuild_to_boldy_go_where
http://blogs.sun.com/GullFOSS/entry/gbuild_how_to_migrate_a
http://blogs.sun.com/GullFOSS/entry/gbuild_how_to_setup_a
http://blogs.sun.com/GullFOSS/entry/gbuild_eyecandy_for_developers
http://blogs.sun.com/GullFOSS/entry/gbuild_meet_the_new_boss

I have cherry picked the work he has done on the gnumake2 cws.
I did that by converting that cws to one big git repo, then I used git
to extract and generate patches for all the relevant commit (base on
the commit message that conveniently all contained 'gnumake2')

Then I manually applied these 230+ patches in  the 19 git repos of a
feature branch, 'fixing' merge breakage as best I could along the way.

Few patches were not merged, there are 3 main reasons:

1/ they were patches on part of OOo that are not in LibreOffice (some
infrastructure things are different)
2/ they were related on other development work that has not been
merged yet in LibreOffice, like the work on uno-registration (They may
or may not eventually be merged, but that decision was out of the
scope of this work)
3/ they were too smart for me, conflicted, and I could not 'make them
work' at the time.

The later categories was reduce later in the process, when what these
patches were addressing became more obvious to me, and I usually
end-ed up achieving the same result (hopefully) on my own later...
Still some are still not merged, and may still need to be addressed.


I diverted a bit from the original with regard of the integration with build.pl

Instead of simply replacing the content of build.lst for a module that
is migrated, I added the support for gbuild.lst in build.pl (new flag
--gmake), conditioned on the environment variable USE_GMAKE=1 in the
top Makefile. if the later is set and if a module has a gbuild.lst,
then it is used to build the module in preference to build.lst
gbuild.lst typically contain a minimal build.lst needed to trigger a
gmake of that module.

The idea is to allow for co-existance at a module level. The benefit
is that if there is a problem one can still easily build the old-way.
I hope this will allow for this work to get into master faster and
with less blocking disruptions. As long as the old-build works, any
gmake problems is not blocking.
Eventually, when a modules, in master, has been tested on all
platform, then build.lst can be converted so that the only build
method become gmake.

The main draw-back is that create an opportunity for
double-maintenance issues in the interval, but since I could not test
any of it on Windows, I don't think I can avoid it.

I also added the conversion to gmake of sc and starmath


So, how can you help ?

The work is available on the feature/gnumake2.1 branch.

Please build that branch using the two following ways:

First, make clean; make; make dev-install and test as you normally do
-- this is to verify that the existing build has not be adversely
affected --
and then
USE_GMAKE=1 make clean
USE_GMAKE=1 make
make dev-install
and tests

Please post the result of your experience on this list.

The first goal is to make sure that the regular dmake build is
un-affected. When that is confirmed for windows, then I can merge this
to master, and the rest of the work can continue there.

I intend to rebase that branch before merging to master (ideally as a
fast-forward), so do not branch or merge that branch.. it will not
last, and will not be merged into master.
For that reason, please send patches to the mailing list rather than
pushing to that branch.

Norbert