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 <j...@apache.org> 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
provides.
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
buildbot).
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 :-)
-Andre
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
