Re: [Libreoffice] Announce: gnumake in LibreOffice

Great work, but out of curiosity wouldn't it be better to use cmake 
instead since we are cross compiling for different platforms?

On 1/17/11 4:14 AM, Norbert Thiebaud wrote:
> 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
> _______________________________________________
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice