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
