On Tue, Mar 15, 2016 at 8:46 PM, Pedro Giffuni <p...@apache.org> wrote: > Hello; > > I have been noticing damjan's great advance in merging the gbuild stuff. > > IMO, this is a great thing that will likely be unnoticed by our users > as it has no real effect on the binaries but it is significant in improving > the build experience. > > Now, it appears the only thing holding a new release is a lack of > leadership within the community. Either someone steps in or we just have a > team of people do things. In any case I think a gbuild merge > forces to take some consideration. > > Given the changes will be big, if we want a new release code soonish, > we should branch AOO42 before the merge, avoiding any potential risk. > If we are still taking longer, say 1-2 months, then we have ample time to > sort out any eventual issue and we shouldn't worry about it. > > Of course we can merge gbuild and then fork from a past point anytime, > but now is a good time to decide about releases.
All the gbuild branch patches have now been ported to the gbuild-integration branch. Please don't start testing yet: let me fix the sd inconsistencies, do a RAT scan and investigate any wrongly licensed files, compare bvt and fvt qa test results with trunk, and check for other obvious bugs before we start testing other platforms. > Thinking about gbuild and what follows ... > > First of all congratulation to Damjan, this is very cool. Thank you, and can the rest of you please make similar contributions ;-) ? > From my perspective, it's OK to depend on two or more build tools (we > do use ant, etc) as long as one of them is not DMake, so if we want > to use scons, I am fine with it but we will have to move Python to > gbuild. Things are looking fun ;). > A lot of my initial enthusiasm about SCons faded after I saw it had problems with MSVC on Cygwin, the authors themselves admitted SCons is slow for large projects, and the KDE project tried using it for about a year and then gave up and moved to something else (CMake?). I am not sure gbuild has the ability to run configure+make yet the way dmake does. In the short term I plan some more improvements to gbuild, like fixing --enable-symbols to do the same thing on dmake and gbuild modules. > Regards, > > Pedro. > Regards Damjan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
