openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Don Lewis <>
Subject Re: Next release and gbuild
Date Thu, 17 Mar 2016 05:15:01 GMT
On 17 Mar, Damjan Jovanovic wrote:
> 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.

Have you added $(CCNUMVER) on the gbuild side?  I've been using that on
the dmake side to tweak optimization settings on individual files on
specific compiler version and architecture combinations.  There is one
particular compiler bug that affects files on both of the gbuild and
dmake sides.  In the FreeBSD port I have to detect the compiler version
and do a global optimization change because I can't do a fine-grained
tweak on the gbuild side.

It might make sense for configure to figure out CCNUMVER and just pass
it in as another environment variable.

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

View raw message