openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andre Fischer <>
Subject Re: Make x Dmake x Build (Was: Re: [Error] Compile AOO on Debian amd64)
Date Fri, 19 Apr 2013 08:07:47 GMT
On 19.04.2013 07:56, J├╝rgen Schmidt wrote:
> On 4/19/13 12:33 AM, Kay Schenk wrote:
>> On Thu, Apr 18, 2013 at 2:11 PM, janI <> wrote:
>>> I am deep in the building system at the moment with my l10n work, and what
>>> we have now in trunk is approx 2/3 orignal dmake (that btw also seem to
>>> have at least 2 generations) and 1/3 gbuild, this combination does a good
>>> job of confusing anyone who tries to understand the system. Just to make
>>> things worse, the gbuild part is split in as many files as possible.

When I last made a count for my ApacheCon talk we had 176 modules built 
with dmake and 18 built with gbuild.

>>> So I should have written "dont try to understand it, just accept it",
>>> actually someone else in here said something similar to me a couple of
>>> month ago.
> Exactly that is the problem, the work on gbuild is not yet finished and
> we have a mix of gnu make and dmake. The gbuild is the outcome of an
> analysis how to improve the build system. I believe it is not bad and
> our friends from LO have more or less finished the work but I also
> believe that it is too complex and can be done much simpler.
> It's nearly impossible to debug and not easy to understand. It tried to
> hide the complexity from single makefiles in the modules and introduced
> soe kind of new scripting language based on gnu make. I am not sure if
> that was the best approach.

I doubt that, too.  I am also not sure if the right problems where 
addressed when gbuild was 'designed'.  Two ways in which it failed 
completely are

- build speed on Windows.  gbuild was written on some *nix variant 
(probably Linux or Solaris) and optimized for that.  Windows was not 
liked much by the gbuild developers, and that shows.

- the gbuild system is probably harder to maintain than the dmake 
system.   Maintainability is one of the key points in an open source 
project as large as ours.  When only a select few can understand and 
maintain it, then that is not enough.

>>>> I saw all this mixture too in my build experience, and well...couldn't
>>>> figure out why. It seems historically dmake was used to speed things

The dmake build system was 'invented' when computers where much slower 
than today, but the source code tree was not that much smaller.

Global dependencies on file level could not have been reasonable 
modeled, just too much data.   A solution for this are dependencies on 
module basis.  This is what the first line in <module>/prj/build.lst 

Full builds, even full builds of modules like sw took too much time to 
do on a regular basis.  Therefore, when you changed a file in one 
directory, then you wanted to just compile this file or at most the 
whole directory and then build the affected libraries.  All this is 
possible with the dmake system, which is basically directory based. Call 
build in <module> and it builds the whole module but got to directory in 
<module>  and run dmake and it compiles just that directory.  These 
dependencies of a module on its directories is described by the 
remaining lines in <module>/prj/build.lst.

Computers are faster today, global dependencies have become a possible 
way to make the build process faster (ie compile less by only compiling 
files that depend on modified files) and more reliable (it is probably a 
missing inter-module dependency that sometimes breaks our build on the 
That is what gbuild tries to do.  But, if you know what you are doing 
and want to compile just a couple of files that you are interested in, 
then that is not possible anymore with gbuild.

>>> along,
>>>> but, well...I'm not sure how/why it's being used now exactly.
>>> Actually the wiki/gbuild have a pretty good description. The people who
>>> started gbuild did a real good job of analyzing the dmake build and an even
>>> better job of documenting their findings.

I am not so sure about that. One result of that analysis was that cmake 
would not be good tool to build AOO, with reasons that where challenged 
by one of cmakes developers (Bill Hoffman) but, as far as I know, never 
answered by the gbuild developers.  To me, the analysis looked more like 
serving a predefined outcome.

>>> I am right now (slowly) in the progress of writing a document, with demands
>>> to a solid, easy to understand build system, based on my experience from a
>>> system about 4-5 times bigger than AOO.

I am eagerly looking forward to reading what you are writing.  I myself 
are working on a replacement for gbuild but that my turn out too 
experimental/radical for real world usage.  But I am learning a lot 
about the inner workings of gbuild.

>> Great! I look forward to it! Although I have *used* make systems a lot
>> throughout my career, I've never ever constructed one, so much of this is a
>> mystery to me.
> Me too and we can can benefit from something that we understand better
> and that is potentially not so generic but where makefiles are readable.
>>>> And, yes, I saw the gbuild branch was basically inactive and tried to

The gbuild branch is about converting a few more module to gbuild but 
from what I know (and I could easily be wrong) that would still leave 
the majority of modules unchanged.

>>> tract
>>>> down some info on that, but couldn't find much discussion about it.
>>>> We do indeed need to devote discussion time to our build process after
>>>> 4.0.   I would hope we could at least make things simpler for folks
>>> wanting
>>>> to partial builds of areas.

Interesting.  I hope that we don't go back to dmake to accomplish that 
goal :-)

>>> In my world, we can make it VERY simple...but even though gbuild is pretty
>>> new, it uses the same philosofy as dmake, so it does not really change
>>> things. I have a couple of ideas, admitted a bit radical, but they would
>>> allow us to use standard make. My intention is to take the discussion, when
>>> I have something to present, instead of starting the discussion with a
>>> piece of blank paper.
> I am looking forward to hear, read or see more
>>> Another thing we need to discuss is packaging, would it not be ideal if
>>> people could just make writer, when working on that. I would like to see a
>>> download page, where the user select which parts of AOO he/she wants to
>>> download.

That has been tried in the past and maybe you will succeed.  Does not 
the Windows installer allow us to just install one application?
The main problem here is the dependencies between the modules.  I think 
that there are not many libraries that you will not need for the Writer.
If you still want to support OLE, you even have to bring Calc and 
Impress along and then you basically need everything.

>>> I hope you like to appetizer :-)

I am waiting for the main dish :-)


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

View raw message