openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damjan Jovanovic <>
Subject Re: Next release and gbuild
Date Thu, 17 Mar 2016 04:42:54 GMT
On Tue, Mar 15, 2016 at 8:46 PM, Pedro Giffuni <> 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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message