Re: Building OpenOffice.org with GNU make

classic Classic list List threaded Threaded
67 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: Building OpenOffice.org with GNU make

Thorsten Behrens-3
Hi Bjoern, *,

so first off, really cool to see thoughts & effort spent on this:

http://blogs.sun.com/GullFOSS/entry/building_openoffice_org_with_gnu

I didn't really spent much time mulling over this, it's basically
just my current random thoughts on it:

 - regarding parallelization, that's surely fixable with much less
   effort in build.pl, no?
 - what kind of dependency tracking is missing in the current system?
 - the question of correct dependencies is probably rather
   orthogonal to the question of which build system to use. much of
   the problems here are in modules like scp2, helpcontent,
   writerfilter etc. where tons of stuff is built via ad-hoc rules
   that simply don't get dependencies right. Having those handled in
   a declarative way would convince me a bit better, that a change
   in the build system actually addresses these issues -
   (see also Kay's
   http://blogs.sun.com/GullFOSS/entry/and_what_about_make)

More generally, I'd guess the whole make system question, once
posed, has a much (if not more) potential for religious wars than
the dscm question. :)

In line with that, why not using autotools? It's ugly, it has many
drawbacks, but it's _the_ standard for FLOSS. Plus, it has excellent
cross-build capabilities, something I consider increasingly
important. Or something like cmake, which could give you project
files for common IDEs (see
http://lists.freedesktop.org/archives/ooo-build/2009-August/000181.html
for some initial attempts)?

Cheers,

-- Thorsten

attachment0 (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Building OpenOffice.org with GNU make

Michael Stahl-3
On 04/12/2009 18:41, Thorsten Behrens wrote:
> Hi Bjoern, *,
>
> In line with that, why not using autotools? It's ugly, it has many
> drawbacks, but it's _the_ standard for FLOSS. Plus, it has excellent
> cross-build capabilities, something I consider increasingly
> important.

well, we already use autoconf, and imho there is nothing wrong with that.

automake mainly lets you write portable makefiles, that work in any
POSIX-compliant make.
nowadays, that seems pretty useless to me: if you want "make" then just
use GNU make, it's portable, and powerful.
no need to care about whatever crappy make implementation ships with some
ancient OS.

also, when i last used it, it seemed to me that automake kind of
encourages writing recursive makefiles (i.e. makefiles that invoke make
for subdirectories), which is an awful idea (because make needs to stat
everything all over again for every invocation); but i am not sure to what
extent that is really automake's fault (could you just have a single
Makefile.am, or at least one that includes the ones from subdirectories?).

but the real problem comes with libtool... on windows.
when i last used autotools (which is... 4 years ago), libtool was a shell
script some 10.000 lines long.
starting a process on that so-called OS takes _ages_, so it is not
unsurprising that building C/C++ code on windows with a long shell script
is _very_ slow.
iirc, on the same hardware it was 5-10 times slower building on
windows(mingw/msys) than on linux.
oh, and what is libtool's support for MSVC like? does it exist at all?
so unless someone proves me wrong here it seems to me that libtool is not
really an option.

oh, another reason to use automake would be that it nicely wraps libtool,
which is then also irrelevant.

but on the other hand, autotools indeed make cross compiling very easy.

> Or something like cmake, which could give you project
> files for common IDEs (see
> http://lists.freedesktop.org/archives/ooo-build/2009-August/000181.html
> for some initial attempts)?

hmmm... cmake also seemed nice last i looked at it...

but regarding IDEs, Bjoern just yesterday tried loading the sw module and
the inc directory from the solver into some IDEs...
iirc, visual studio parsed the headers for half an hour, and was then
unusably slow; netbeans (with some gigabytes of heap) was barely usable.

does anybody really use an IDE for developing OOo?
from what i know people use text editors, or they use an IDE basically
like a text editor.

> Cheers,
>
> -- Thorsten

regards, michael

--
"Most programming environments are meta-engineered to make typical
 software easier to write. They should instead be meta-engineered to
 make incorrect software harder to write." -- Daniel J. Bernstein


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: Building OpenOffice.org with GNU make

Rene Engelhard-7
On Fri, Dec 04, 2009 at 09:46:56PM +0100, Michael Stahl wrote:

> but the real problem comes with libtool... on windows.
> when i last used autotools (which is... 4 years ago), libtool was a shell
> script some 10.000 lines long.
> starting a process on that so-called OS takes _ages_, so it is not
> unsurprising that building C/C++ code on windows with a long shell script
> is _very_ slow.
> iirc, on the same hardware it was 5-10 times slower building on
> windows(mingw/msys) than on linux.
> oh, and what is libtool's support for MSVC like? does it exist at all?
> so unless someone proves me wrong here it seems to me that libtool is not
> really an option.

Did anyone in this discussion propose libtool? I didn't see it.
(You can use automake without libtool)

Grüße/Regards,

Rene

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Building OpenOffice.org with GNU make

Thorsten Behrens-3
In reply to this post by Michael Stahl-3
Michael wrote:
> [reasons against autotools]
>
Granted. Though re-working OOo's make system in and of itself will
consume substantial resources, so I guess the question whether to
code another make system that's only used inside OOo, or whether to
use/extend something that's in wide-spread use out there deserves
some thoughts ...

> [cmake]
>
> but regarding IDEs, Bjoern just yesterday tried loading the sw module and
> the inc directory from the solver into some IDEs...
> iirc, visual studio parsed the headers for half an hour, and was then
> unusably slow; netbeans (with some gigabytes of heap) was barely usable.
>
Reportedly eclipse works rather well with a limited set of modules;
which will be more or less attained via the split build endeavour at
some point in time.
 
> does anybody really use an IDE for developing OOo?
> from what i know people use text editors, or they use an IDE basically
> like a text editor.
>
I know a few cases where people have tried; ultimately though, if
one becomes a core dev, folks work on OOo the way you describe it
(which may be related to the fact that maintaining those project
files manually is a PITA). But may considerably lower the barrier of
entry for new devs.

Cheers,

-- Thorsten

attachment0 (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Re: Building OpenOffice.org with GNU make

Kohei Yoshida-2
In reply to this post by Michael Stahl-3
On Fri, 2009-12-04 at 21:46 +0100, Michael Stahl wrote:

> but regarding IDEs, Bjoern just yesterday tried loading the sw module
> and
> the inc directory from the solver into some IDEs...
> iirc, visual studio parsed the headers for half an hour, and was then
> unusably slow; netbeans (with some gigabytes of heap) was barely
> usable.
>
> does anybody really use an IDE for developing OOo?
> from what i know people use text editors, or they use an IDE basically
> like a text editor.

I use SlickEdit, which some people regard as IDE, though the SlickEdit
developers themselves insist on calling it a text editor because it
doesn't require you to create a project before you are able to edit
files.

I'm probably biased since I used to work for them, but from a variety of
IDEs and IDE-like text editors I've tried, SlickEdit is the only one
that can handle C++ projects the size of OOo.  Eclipse comes close, but
its handling of C++ is rather limited, and it takes a long time for it
to start up.

Oh BTW, SlickEdit can tag source files inside, say, sw in less than a
minute or a few minutes depending on the speed of your machine.

But there is still a reason why you may want to create a solution file
for Visual Studio even if you don't use it for hacking.  Many developers
use whatever IDE's or text editors they have faith in, and use Visual
Studio just for building the project on Windows.

Kohei

--
Kohei Yoshida - OpenOffice.org Engineer - Novell, Inc.
<[hidden email]>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Building OpenOffice.org with GNU make

Björn Michaelsen-2
In reply to this post by Thorsten Behrens-3
Am Sat, 5 Dec 2009 00:08:45 +0100
schrieb Thorsten Behrens <[hidden email]>:

> Michael wrote:
> > [reasons against autotools]
> >
> Granted. Though re-working OOo's make system in and of itself will
> consume substantial resources, so I guess the question whether to
> code another make system that's only used inside OOo, or whether to
> use/extend something that's in wide-spread use out there deserves
> some thoughts ...

Well, automake provides few additional features we need for building OOo
and we have lots of requirements that wont be provided by automake
because OOo is special (huge, cross platform and almost a distribution
of its own). Also, automake, in addition to being ugly, is not without
dependencies itself: amongst them Perl(*).

Best Regards,

Bjoern Michaelsen

(*) Yes, I know, that should not matter as it is intended to be run
_before_ configure by the "developer" and not by the "user" (in
autotools terms: those who want to compile the product are called
users, which might be a bit confusing at first), but still.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Building OpenOffice.org with GNU make

Björn Michaelsen-2
In reply to this post by Thorsten Behrens-3
Am Fri, 4 Dec 2009 18:41:08 +0100
schrieb Thorsten Behrens <[hidden email]>:

>  - regarding parallelization, that's surely fixable with much less
>    effort in build.pl, no?
Currently we are starting one dmake-process per directory and that
dmake process does paralellization the directory. Implementing a
recursive jobserver that communicates between dmake and build.pl would
not only be ugly, it would also be a major effort.
>  - what kind of dependency tracking is missing in the current system?
Those that bite you on compatible builds. The only way to work around
those reliably is to throw away and rebuild all dependent modules. Also
we currently have many, many intermodule dependencies that are implicit
and thus very fragile. Just ask Mathias -- he had to deal with a lot of
those when working on the split build stuff.

>  - the question of correct dependencies is probably rather
>    orthogonal to the question of which build system to use. much of
>    the problems here are in modules like scp2, helpcontent,
>    writerfilter etc. where tons of stuff is built via ad-hoc rules
>    that simply don't get dependencies right. Having those handled in
>    a declarative way would convince me a bit better, that a change
>    in the build system actually addresses these issues -
>    (see also Kay's
>    http://blogs.sun.com/GullFOSS/entry/and_what_about_make)
We are using a declarative language -- also Kay knows what we are doing
and has contributed valuable input. I guess he would tell me, if I
tried something obviously wrong. ;-)
And yes, the build system to use is only "the color of the bikeshed",
but this is a chance to get rid of quite a bit of self-maintained
dependencies. As said elsewhere, the effort never aimed to simple
replace build.pl/dmake with GNU make for its own sake.

> More generally, I'd guess the whole make system question, once
> posed, has a much (if not more) potential for religious wars than
> the dscm question. :)
Yes, and it shows in the comments of the blog.

> In line with that, why not using autotools? It's ugly, it has many
> drawbacks, but it's _the_ standard for FLOSS. Plus, it has excellent
> cross-build capabilities, something I consider increasingly
> important. Or something like cmake, which could give you project
> files for common IDEs (see
> http://lists.freedesktop.org/archives/ooo-build/2009-August/000181.html
> for some initial attempts)?
see my other replies here and on the blog. As a sidenote: project files
for common IDEs only give you more trouble, if they are one way (and
they currently all are): They are a just minor simplification for
newcomers for a simple build without changing anything. But I leave it
to you to explain to release engineers, why it is their job to translate
the changes made by a new dev in his IDE-project back to the cmake
source. They will rightfully refuse that. Thus the newcomer will have
to fiddle with the makefiles again manually, winning nothing in the end
(other than additional confusion and probably some needless
communication on mailing lists).

Best Regards,

Bjoern Michaelsen


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: Building OpenOffice.org with GNU make

Thorsten Behrens-3
Björn Michaelsen wrote:
> >  - regarding parallelization, that's surely fixable with much less
> >    effort in build.pl, no?
> Currently we are starting one dmake-process per directory and that
> dmake process does paralellization the directory. Implementing a
> recursive jobserver that communicates between dmake and build.pl would
> not only be ugly, it would also be a major effort.
>
That's not what I meant. The reason to also hand over a specific
dmake option for multi-processor builds is that sometimes only one
or two directories have their actual dependencies satisfied & are
thus buildable. So it would be ~trivial to only hand "-P16" over to
build.pl, and let it distribute that across the active dmake
instances.

> >  - what kind of dependency tracking is missing in the current system?
> Those that bite you on compatible builds.
>
Ah. That's what I thought. So nothing inherently missing in
dmake/build.pl, but "just" bugs in the makefiles.

> >  - the question of correct dependencies is probably rather
> >    orthogonal to the question of which build system to use. much of
> >    the problems here are in modules like scp2, helpcontent,
> >    writerfilter etc. where tons of stuff is built via ad-hoc rules
> >    that simply don't get dependencies right. Having those handled in
> >    a declarative way would convince me a bit better, that a change
> >    in the build system actually addresses these issues -
> >    (see also Kay's
> >    http://blogs.sun.com/GullFOSS/entry/and_what_about_make)
> We are using a declarative language -- also Kay knows what we are doing
> and has contributed valuable input. I guess he would tell me, if I
> tried something obviously wrong. ;-)
> And yes, the build system to use is only "the color of the bikeshed",
> but this is a chance to get rid of quite a bit of self-maintained
> dependencies. As said elsewhere, the effort never aimed to simple
> replace build.pl/dmake with GNU make for its own sake.
>
Sorry, but
http://hg.services.openoffice.org/hg/cws/gnu_make/raw-file/2518db232510/sw/prj/target_lib_msword.mk
then leaves a lot to be desired. There's still loads of redundancy -
and actually, when compared to a dmake-style makefile without the
carried-over cargo-cult contents - quite similar.

> see my other replies here and on the blog. As a sidenote: project files
> for common IDEs only give you more trouble, if they are one way (and
> they currently all are): They are a just minor simplification for
> newcomers for a simple build without changing anything. But I leave it
> to you to explain to release engineers, why it is their job to translate
> the changes made by a new dev in his IDE-project back to the cmake
> source. They will rightfully refuse that. Thus the newcomer will have
> to fiddle with the makefiles again manually, winning nothing in the end
> (other than additional confusion and probably some needless
> communication on mailing lists).
>
Yes. And? It's still significantly lowering the barrier of entry.
Loads of other projects do it (with the same limitation). And the
need to add a new file to the project is usually not the first, not
the second, but the nth thing you do when starting to hack ...

So stepping back a bit, I should probably mention (again) that I
find the general idea really great - the make system is  truly
arcane & leaves a lot to desire. But despite your initial request for
input, plans & thoughts, I cannot but have the impression you're
already quite determined to follow the outlined route - sadly the
build system has seen quite a few attempts for change; and survived
all of them ~unmodified, thus some extra thought & consultation is
surely advisable ...

From my humble point of view, what has usually worked best in OOo
land is some iterative approach to change; which in this case & my
opinion would mean cleaning up makefiles one by one, either using a
declarative DSL directly that could later be mapped to gnu make or
whatever tool we see fit, or - using a meta-language like automake
cmake, or something homegrown, *still* use dmake for the while, and
then, after some critical mass has been attained, switch the make
tool wholesale (and adapt the metalang-to-makefile generator).

Additionally, and since you mentioned the desire to have only one
make instance - last time someone tried to have gnu make hold all of
OOo's dependency tree in one process, that guy (Kai Backman) ended
up with absolutely pathetic performance & ridiculous mem usage.

That's why he went for bjam ...

Cheers,

-- Thorsten

attachment0 (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Building OpenOffice.org with GNU make

Björn Michaelsen-2
Am Sun, 6 Dec 2009 22:13:47 +0100
schrieb Thorsten Behrens <[hidden email]>:

> That's not what I meant. The reason to also hand over a specific
> dmake option for multi-processor builds is that sometimes only one
> or two directories have their actual dependencies satisfied & are
> thus buildable. So it would be ~trivial to only hand "-P16" over to
> build.pl, and let it distribute that across the active dmake
> instances.
No, thats not trivial: the current bottlenecks cant really be noticed
by build.pl until its to late (unless build.pl kills runnning
dmake-processes for a directories and restarts them again, which will
hardly improve performance and might trigger additional subtile and hard
to debug bugs in the build system). This is because bottlenecks happen,
when a big module with many dependencies -- like svx -- is still
building and all unbuild modules depend on it directly or indirectly.
However, once build.pl notices that it cant start another dmake because
of deps on svx, the dmakes of svx are already long running (with little
paralellization) and the only way to allow those more paralelization is
to kill and restart those. Its an inherent problem of the current
architecture.

> > >  - what kind of dependency tracking is missing in the current
> > > system?
> > Those that bite you on compatible builds.
> >
> Ah. That's what I thought. So nothing inherently missing in
> dmake/build.pl, but "just" bugs in the makefiles.
Yes, and going to the moon is "just" going up long enough ... ;-)
And its not only the makefiles, the build.lst and d.lst files are far
more evil.

> Sorry, but
> http://hg.services.openoffice.org/hg/cws/gnu_make/raw-file/2518db232510/sw/prj/target_lib_msword.mk
> then leaves a lot to be desired.
Like, what?
> There's still loads of redundancy -
I cannot see a lot of redundancy there, unless one is willing to
reorganize quite a bit of the files in the source tree:
- clean up the weird include paths in sw
- for each shared library, keep all files in one directory
That would allow to collect the source files implicitly (still,
collecting source files dynamically might be a performance issue for
complete (re-)builds). I wanted the prototype to be able to work
without major refactorings on the source itself, which is actually
_harder_ to archive than when one allows the new build system to
completely reorder files in the source tree. That does not mean we
should not do such bigger changes per se, just that we do not _have_ to.

> Yes. And? It's still significantly lowering the barrier of entry.
> Loads of other projects do it (with the same limitation).
An digression beforehand: I guess we are talking about Windows here
mostly, makefiles are the "native build system" on pretty much all
*nix-systems. On Windows, anyone getting all the prerequisites setup
right will not even notice any difficulty living without read-only
project files.</digression>

Other than that, I really like some release and QA engineers opinions on
this, because I am only guessing on their opinion. We already have more
than enough issues with (non-)reproducible builds (weather by rebuilds,
that slightly differ from a complete build, platform specific stuff or
other reasons). When I talked with release engineers and QA engineers, I
got the feeling they where not interested in asking back on every issue,
which build environment the dev used to make a build (or worse: QA waves
through a cws, because the tested builds look fine, but when building
the "offical" way in releng, subtile isssues show up on the master).

Another issue with using an external project generator is versioning.
If for example we would use cmake to generate Visual Studio project
files, we might find different versions creating different project
files (maybe even in best faith by bugfixes) and thus causing subtle
bugs by updating the project generator. Also an external project
generator using a abstraction as high level as cmake does might develop
in a way that diverges from what we would like to do. Of course, we
could require only an old version to be used or fork -- but then we are
no better of than we currently are with dmake.

So a generated project file might introduce subtle different builds,
is dependent on the version of the generator and is read-only. Since you
can "generate a project from existing code" trivially in NetBeans,
Visual Studio and others and just as well kick of a makefile-based
build in all modern IDEs, what exactly is gained by generated project
files? I dont at all see how this is lowering the barrier to entry as
it just introduces another concept to learn for a newcomer, but it does
not make life easier in any relevant way. Nothing more confusing to a
newcomer than leaky abstractions(1).

> So stepping back a bit, I should probably mention (again) that I
> find the general idea really great - the make system is  truly
> arcane & leaves a lot to desire. But despite your initial request for
> input, plans & thoughts, I cannot but have the impression you're
> already quite determined to follow the outlined route - sadly the
> build system has seen quite a few attempts for change; and survived
> all of them ~unmodified, thus some extra thought & consultation is
> surely advisable ...
Well, you wont wake up tomorrow and have OOo use a new build system.
The work that was done with gnu_make is a prototype. There was
certainly a lot learned while creating it. Still "extra thought and
consultation" is of course needed and we are in no hurry, but in the
end there will be a point were -- as Linus said -- it comes down to:
"Talk is cheap. Show me the code." ;-).

> From my humble point of view, what has usually worked best in OOo
> land is some iterative approach to change; which in this case & my
> opinion would mean cleaning up makefiles one by one, either using a
> declarative DSL directly that could later be mapped to gnu make or
> whatever tool we see fit, or - using a meta-language like automake
> cmake, or something homegrown, *still* use dmake for the while, and
> then, after some critical mass has been attained, switch the make
> tool wholesale (and adapt the metalang-to-makefile generator).
When discussing possible migration paths, we considered to migrate on a
module-by-module basis: keeping build.pl and replacing dmake in one
module after the other and finally getting rid of build.pl.
 
> Additionally, and since you mentioned the desire to have only one
> make instance - last time someone tried to have gnu make hold all of
> OOo's dependency tree in one process, that guy (Kai Backman) ended
> up with absolutely pathetic performance & ridiculous mem usage.
I did more than a few scalability tests with GNU make. There is a magic
barrier on the number of rules it can handle (above ~10000
scalability grinds to a halt), but rarely one on targets. Unfortunately,
we will only really know in the end (In theory, theory and practice are
same. In practice -- not.). But the four modules in the prototype are
already a significant part of the source files and probably a major
part of the header targets (via #include).

Best Regards,

Bjoern


(1) http://www.joelonsoftware.com/articles/LeakyAbstractions.html


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: Building OpenOffice.org with GNU make

Mathias Bauer
In reply to this post by Thorsten Behrens-3
Thorsten Behrens wrote:

> Björn Michaelsen wrote:
>> >  - regarding parallelization, that's surely fixable with much less
>> >    effort in build.pl, no?
>> Currently we are starting one dmake-process per directory and that
>> dmake process does paralellization the directory. Implementing a
>> recursive jobserver that communicates between dmake and build.pl would
>> not only be ugly, it would also be a major effort.
>>
> That's not what I meant. The reason to also hand over a specific
> dmake option for multi-processor builds is that sometimes only one
> or two directories have their actual dependencies satisfied & are
> thus buildable. So it would be ~trivial to only hand "-P16" over to
> build.pl, and let it distribute that across the active dmake
> instances.

build.pl uses module dependencies, not target dependencies, so it has an
inherent susceptibility to bottlenecks. Basically all of our c++ sources
could be built in parallel (as they don't depend on each other), but
with build.pl we always have to wait until header files are "delivered"
or created. And because the dependency granularity level is the "module"
(not a real target like e.g. a library), we can't use as much
parallelization as possible. This becomes even more painful if you don't
build the whole office, but only some parts of it, e.g. in a split build
or if you rebuild several "modules".

A make system with full dependencies and a single dependency tree only
listing real targets, not virtual ones like "modules" does not have
these defects.

>
>> >  - what kind of dependency tracking is missing in the current system?
>> Those that bite you on compatible builds.
>>
> Ah. That's what I thought. So nothing inherently missing in
> dmake/build.pl, but "just" bugs in the makefiles.

No, not in the make file. The bugs are in the notorious "build.lst"
files. As you surely know, our makefiles don't have useful rependencies
as this would require not only spcifying prerequisites but also rules.
If you link a library against another one, there's nothing in our build
system that tells how to create it in case it doesn't exist. Instead of
that, you have to maintain another pseudo-makefile, the build.lst, that
tells build.pl to "visit" other modules before, so that the case
"prerequisite does not exist but no rule is defined" does not happen.
This is very error prone, especially if the build.lst is changed later
on. And at least on Windows this is quite time consuming.

I was bitten by that quite often in my recent refactoring activities.
The reason is that mistakes can remain unnoticed for a long time: if you
miss a module dependency in a build.lst, the build might work despite
that because the missing module was built "by luck", because another
module, that either is built before or in parallel, has a dependency on
it. In a single process make you would see the mistake as soon as you do
the first build where the prerequite who's rule you forgot to specify is
not present.

To overcome this and to avoid to have information stored in different
places (we have at least n makefile.mk, one build.lst, one d.lst and one
makefile.pmk per "module") makefiles must be able to include others. Our
current system is not able to do that because all makefiles use the same
target names. This is the most remarkable difference of the makefiles in
Björn's prototype.

> Sorry, but
> http://hg.services.openoffice.org/hg/cws/gnu_make/raw-file/2518db232510/sw/prj/target_lib_msword.mk
> then leaves a lot to be desired. There's still loads of redundancy -
> and actually, when compared to a dmake-style makefile without the
> carried-over cargo-cult contents - quite similar.

It seems that you still did not see the major difference that I have
described above.

So then please tell us the "lot to be desired". That's exactly what this
discussion is about. We hope to get input and facts. I also fail to see
redundancy. Due to its nature of a prototype it doesn't factor out
commonly used defines as much as possible (like e.g. compiler flags),
but I think that you know that. So where else do you see redundancies?
Can you do less in a makefile for a library than specifying the name of
the library, the libraries it links against and the object files it is
thought the be built from? The list of include pathes is just caused by
our current structure (and in a final version surely would be done by a
macro that factors out all commonly used patterns).

>> see my other replies here and on the blog. As a sidenote: project files
>> for common IDEs only give you more trouble, if they are one way (and
>> they currently all are): They are a just minor simplification for
>> newcomers for a simple build without changing anything. But I leave it
>> to you to explain to release engineers, why it is their job to translate
>> the changes made by a new dev in his IDE-project back to the cmake
>> source. They will rightfully refuse that. Thus the newcomer will have
>> to fiddle with the makefiles again manually, winning nothing in the end
>> (other than additional confusion and probably some needless
>> communication on mailing lists).
>>
> Yes. And? It's still significantly lowering the barrier of entry.
> Loads of other projects do it (with the same limitation). And the
> need to add a new file to the project is usually not the first, not
> the second, but the nth thing you do when starting to hack ...

If you think that calling "make" is a barrier, overcoming this is easy.
Many developers have configured their IDE to start the OOo build process
from it. But that's not what I would call an IDE integration.

This would require to make OOo a "project" of the IDE. As Michael Stahl
stated, we have done some first tests, and the results where so
disappointing that we didn't continue. It seems that neither MS Visual
Studio nor NetBeans is able to handle even the single writer project
(writer sources and headers from "solver") with an acceptable
performance. We could do the same test with Eclipse, but I doubt that
any IDE is able to handle larger parts of OOo, let alone the whole
source code. That really would create the "pathetic" performance and the
"ridiculous memory usage" that you are afraid of.

So an IDE can't be the solution for the build system. Of course it's
something that we should keep in mind (and we do) as an addition.
Building smaller, well separated "modules" of OOo in an IDE is surely
possible, and especially being able to build extensions that way is one
of my oldest requirements for our SDK. But this is an addition to a
reliable build system for the whole project, nothing more. I don't see
contradicting, but supplementing requirements and solutions here.

If you think that this is so important, we will be glad to work with you
to get that implemented.

> So stepping back a bit, I should probably mention (again) that I
> find the general idea really great - the make system is  truly
> arcane & leaves a lot to desire. But despite your initial request for
> input, plans & thoughts, I cannot but have the impression you're
> already quite determined to follow the outlined route - sadly the
> build system has seen quite a few attempts for change; and survived
> all of them ~unmodified, thus some extra thought & consultation is
> surely advisable ...

No, really, there's nothing nailed until now. If you or anybody else
knew a better way and(!) offered help and cooperation, there's nothing
that would hold us back from doing it differently. The more people get
involved and the broader the consense, the better. Currently we have
only published our most important requirements and a prototype for how
they could be fulfilled.

> From my humble point of view, what has usually worked best in OOo
> land is some iterative approach to change; which in this case & my
> opinion would mean cleaning up makefiles one by one, either using a
> declarative DSL directly that could later be mapped to gnu make or
> whatever tool we see fit, or - using a meta-language like automake
> cmake, or something homegrown, *still* use dmake for the while, and
> then, after some critical mass has been attained, switch the make
> tool wholesale (and adapt the metalang-to-makefile generator).

That iterative approach is exactly what we want to do also. At least the
GNU make builds fit nicely into the build.pl process, as Björn already
has tested, we can convert each module step by step. Of course the big
benefit will require to do the whole thing at the end.

> Additionally, and since you mentioned the desire to have only one
> make instance - last time someone tried to have gnu make hold all of
> OOo's dependency tree in one process, that guy (Kai Backman) ended
> up with absolutely pathetic performance & ridiculous mem usage.

IIRC Kai didn't use GNU make, but jam (that according to Kay Ramme is
not able to deliver what we need). And what was "ridiculous mem usage"
seven years ago, nowadays is probably just a little bit more than average.

The scalability tests Björn has done for GNU make made us think that
this won't be our problem. Most of our dependencies are header
dependencies. The additional dependencies on other prerequisites are
important (and - as I wrote - are the PITA in our current system) but
not so numerous. So what we have seen in our prototype (where the header
dependencies have been pretty complete already) didn't show "pathetic"
performance.

> That's why he went for bjam ...

Can you explain if bjam is able to fulfill the requirements Björn and I
have mentioned and what else it can do better than GNU make? Or can you
 at least explain why you perhaps prefer it?

Regards,
Mathias

--
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "[hidden email]".
I use it for the OOo lists and only rarely read other mails sent to it.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: Building OpenOffice.org with GNU make

Thorsten Behrens-3
In reply to this post by Björn Michaelsen-2
Björn Michaelsen wrote:

> > That's not what I meant. The reason to also hand over a specific
> > dmake option for multi-processor builds is that sometimes only one
> > or two directories have their actual dependencies satisfied & are
> > thus buildable. So it would be ~trivial to only hand "-P16" over to
> > build.pl, and let it distribute that across the active dmake
> > instances.
> No, thats not trivial: the current bottlenecks cant really be noticed
> by build.pl until its to late (unless build.pl kills runnning
> dmake-processes for a directories and restarts them again, which will
> hardly improve performance and might trigger additional subtile and hard
> to debug bugs in the build system).
>
This is a circular argument. Correct dependencies and the underlying
build/make system used are orthogonal. As an aside, I guess I'm only
questioning the rationale here, not the goal - getting rid of the
build.pl perl hell would be quite appreciated. ;)

> > There's still loads of redundancy -
> I cannot see a lot of redundancy there, unless one is willing to
> reorganize quite a bit of the files in the source tree:
> - clean up the weird include paths in sw
> - for each shared library, keep all files in one directory
> That would allow to collect the source files implicitly (still,
> collecting source files dynamically might be a performance issue for
> complete (re-)builds).
>
Granted, quite some redundancy results out of OOo's inconsistency on
many levels; still, why not encoding that knowledge in one place,
instead of spreading it over umpteen makefiles again? Actually the
current libs.mk does a better job of encapsulating things, compared
to the manual fetch of lib names via OOoLibrary_get*, RTLibrary_get*
etc. - so what I'd ideally like to see is something along this lines
(asking for a DSL again, I guess), instead of target_lib_msword.mk:

 # loads cxxflags, weird sw include setup etc.
 include sw_defaults

 libtarget=msword
 msword_SOURCES= \
     $(listcxx sw/source/filter/rtf) \
     $(listcxx sw/source/filter/ww8)

 msword_linklibs=$(extractdeps $(msword_SOURCES))

The last line may well be a pipe dream for the while, but at least
in theory, one should be able to glean the needed libs from the
#include statements ...

> > Yes. And? It's still significantly lowering the barrier of entry.
> > Loads of other projects do it (with the same limitation).
> An digression beforehand: I guess we are talking about Windows here
> mostly
>
Nope. I'm talking about IDE users in general, who are used to
method/param completion, symbol database etc etc.

> So a generated project file might introduce subtle different builds,
> is dependent on the version of the generator and is read-only. Since you
> can "generate a project from existing code" trivially in NetBeans,
> Visual Studio and others and just as well kick of a makefile-based
> build in all modern IDEs, what exactly is gained by generated project
> files?
>
If that gives the same developer experience - sure. I'd then be
interested in some pointers inside the wiki's build guide. ;)

> > Additionally, and since you mentioned the desire to have only one
> > make instance - last time someone tried to have gnu make hold all of
> > OOo's dependency tree in one process, that guy (Kai Backman) ended
> > up with absolutely pathetic performance & ridiculous mem usage.
> I did more than a few scalability tests with GNU make. There is a magic
> barrier on the number of rules it can handle (above ~10000
> scalability grinds to a halt), but rarely one on targets. Unfortunately,
> we will only really know in the end (In theory, theory and practice are
> same. In practice -- not.). But the four modules in the prototype are
> already a significant part of the source files and probably a major
> part of the header targets (via #include).
>
Would then be interesting to know how implicit rules are treated
inside gnu make (i.e. whether each instantiation counts) - we'd be
in that ballpark easily, with some 11k cxx files & what else comes
on top.

> (1) http://www.joelonsoftware.com/articles/LeakyAbstractions.html
>
Prior art:
http://www2.parc.com/csl/groups/sda/publications/papers/Kiczales-IMSA92/for-web.pdf

And in fact inescapable, ~every implementation will leak under its
abstractions. So I guess you're rather arguing for having only _one_
implementation - which is not obtainable in a cross-platform,
opensource project. ;)

Cheers,

-- Thorsten

attachment0 (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Building OpenOffice.org with GNU make

Michael Stahl-3
In reply to this post by Rene Engelhard-7
On 04/12/2009 23:45, Rene Engelhard wrote:
> Did anyone in this discussion propose libtool? I didn't see it.
> (You can use automake without libtool)
>
> Grüße/Regards,
>
> Rene

>> On 04/12/2009 18:41, Thorsten Behrens wrote:
>>> Hi Bjoern, *,
>>>
>>> In line with that, why not using autotools? It's ugly, it has many
>>> drawbacks, but it's _the_ standard for FLOSS. Plus, it has excellent
>>> cross-build capabilities, something I consider increasingly
>>> important.

so, i always thought that "GNU autotools" is short for "GNU autoconf + GNU
automake + GNU libtool".
am i wrong here? is there an official definition somewhere?

wikipedia says (GNU_build_system):
<quote>
The GNU build system comprises the GNU utility programs Autoconf,
Automake, and Libtool.
</quote>

regards, michael

--
"That's right!" shouted Vroomfondel,
"we demand rigidly defined areas of doubt and uncertainty!"


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: Building OpenOffice.org with GNU make

Jan Holesovsky
In reply to this post by Björn Michaelsen-2
Hi Björn,

On Monday 07 of December 2009, Björn Michaelsen wrote:

> > Additionally, and since you mentioned the desire to have only one
> > make instance - last time someone tried to have gnu make hold all of
> > OOo's dependency tree in one process, that guy (Kai Backman) ended
> > up with absolutely pathetic performance & ridiculous mem usage.
>
> I did more than a few scalability tests with GNU make. There is a magic
> barrier on the number of rules it can handle (above ~10000
> scalability grinds to a halt),

Any chance to profile GNU make in this scenario, please?  May be there is some
stupid mistake there, similar to the one in mkdepend
(http://www.openoffice.org/issues/show_bug.cgi?id=73081 - the complexity of
it grew exponentially)?

Thank you,
Kendy

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: Building OpenOffice.org with GNU make

Björn Michaelsen-2
On Mon, 07 Dec 2009 11:17:30 +0100
Jan Holesovsky <[hidden email]> wrote:

> Any chance to profile GNU make in this scenario, please?  May be
> there is some stupid mistake there, similar to the one in mkdepend
> (http://www.openoffice.org/issues/show_bug.cgi?id=73081 - the
> complexity of it grew exponentially)?
I have not yet considered profiling GNU make, because even with OOo this
will not be an issue when using pattern rules for the most common
targets (C++ sources etc.). In a first attempt, I generated an explicit
(non-pattern) rule for each target, and there it might have come up as
an issue. But using pattern rules (which is WIP and almost finished), we
should rarely end up with more than maybe 30 rules -- everything else is
done via variables.

Best Regards,

Bjoern Michaelsen


--
===========================================================================
 Sitz der Gesellschaft:
 Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
 Amtsgericht Muenchen: HRB 161028
 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel
 Vorsitzender des Aufsichtsrates: Martin Haering
===========================================================================

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Building OpenOffice.org with GNU make

Thorsten Behrens-3
In reply to this post by Mathias Bauer
Hi Mathias,

most of the points you've raised I already replied to in my followup
to Bjoern (including my ideal msword lib makefile) -

Mathias Bauer wrote:

> build.pl uses module dependencies, not target dependencies, so it has an
> inherent susceptibility to bottlenecks. Basically all of our c++ sources
> could be built in parallel (as they don't depend on each other), but
> with build.pl we always have to wait until header files are "delivered"
> or created. And because the dependency granularity level is the "module"
> (not a real target like e.g. a library), we can't use as much
> parallelization as possible. This becomes even more painful if you don't
> build the whole office, but only some parts of it, e.g. in a split build
> or if you rebuild several "modules".
>
Ah interesting - so we're then moving away from the solver concept?

> No, really, there's nothing nailed until now. If you or anybody else
> knew a better way and(!) offered help and cooperation, there's nothing
> that would hold us back from doing it differently.
>
I find this "and(!)" slightly worrying - not that I would not lend a
helping hand; but why are you refusing advise from people just
because they may not have time helping you with coding?

> > That's why he went for bjam ...
>
> Can you explain if bjam is able to fulfill the requirements Björn and I
> have mentioned and what else it can do better than GNU make? Or can you
> at least explain why you perhaps prefer it?
>
I didn't say I'd prefer it. I was just pointing to that project, and
the experiences. Maybe it would help the discussion if more of the
internal findings you mentioned would be public - come to think of
it, maybe it would have been nice to have the whole discussion that
led to this prototype public, in the first place ... ;)
 
Cheers,

-- Thorsten

attachment0 (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Re: Building OpenOffice.org with GNU make

Philipp Lohmann
Thorsten Behrens wrote:
>> No, really, there's nothing nailed until now. If you or anybody else
>> knew a better way and(!) offered help and cooperation, there's nothing
>> that would hold us back from doing it differently.
>>
> I find this "and(!)" slightly worrying - not that I would not lend a
> helping hand; but why are you refusing advise from people just
> because they may not have time helping you with coding?

Because talk is cheap and if we have one thing in much more abundance
than we need it is people with an opinion what others should do ?

Just my 2 cents, pl

--
"One SVN to rule them all, One SVN to check out from,
  One SVN to commit them all and on the harddisks bind them
  In Las Vegas where the server lies."

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: Building OpenOffice.org with GNU make

Björn Michaelsen-2
In reply to this post by Thorsten Behrens-3
On Mon, 07 Dec 2009 11:01:02 +0100
Thorsten Behrens <[hidden email]> wrote:

> This is a circular argument. Correct dependencies and the underlying
> build/make system used are orthogonal. As an aside, I guess I'm only
> questioning the rationale here, not the goal - getting rid of the
> build.pl perl hell would be quite appreciated. ;)
This is not an issue of correctness of dependencies, its about
granularity of build.pl's dependencies. Build.pl dependencies are no
finer than a module -- and the smallest build unit it knows about is a
directory.

> Granted, quite some redundancy results out of OOo's inconsistency on
> many levels;
Jep. In the long run it would be a good idea to get rid of those and not
to work around them in build system.

> still, why not encoding that knowledge in one place,
> instead of spreading it over umpteen makefiles again? Actually the
> current libs.mk does a better job of encapsulating things, compared
> to the manual fetch of lib names via OOoLibrary_get*, RTLibrary_get*
> etc.
That is open to discussion. However, having a centralized library name
registry is feeling just as wrong. (I remember saying that I wanted
ugly things to be ugly in the build system and not do any cosmetics on
them, so that they might be fixed at the root -- once you do cosmetics,
you quickly end up depending on the ugliness and thus will never get
rid of it.)

>  # loads cxxflags, weird sw include setup etc.
>  include sw_defaults
Here you will either need to use dirty tricks or you will clash in a
global namespace, because you would like these defaults to be applied
to msword and others in sw, but not the others. What you could do is
something like this:
-- file inc_sw_defaults.mk
#include guards here
define set_sw_defaults
$$(eval $$(call gb_OOoLibrary_set_include,$(1),...))
...
endef
-- end file sw_defaults
-- file target_lib_msword.mk
include ....inc_sw_defaults.mk
$(eval $(call set_sw_defaults,msword))
....
end file

>  msword_linklibs=$(extractdeps $(msword_SOURCES))
>
> The last line may well be a pipe dream for the while, but at least
> in theory, one should be able to glean the needed libs from the
> #include statements ...
You share that pipe dream with Kay Ramme (and me too). But lets be
realistic -- we will have to learn to crawl before we try running.

> > So a generated project file might introduce subtle different builds,
> > is dependent on the version of the generator and is read-only.
> > Since you can "generate a project from existing code" trivially in
> > NetBeans, Visual Studio and others and just as well kick of a
> > makefile-based build in all modern IDEs, what exactly is gained by
> > generated project files?
> >
> If that gives the same developer experience - sure. I'd then be
> interested in some pointers inside the wiki's build guide. ;)
Will be considered. However, for the bigger modules like sw having just
one module (and headers from solver) in the IDE can be really slow.
Still, for stuff like renaming a method with a hard-to-grep/sed name
(hmmm, like "Update" or "Modify") it might be worth it.

> Would then be interesting to know how implicit rules are treated
> inside gnu make (i.e. whether each instantiation counts) - we'd be
> in that ballpark easily, with some 11k cxx files & what else comes
> on top.
Pattern rules definitely scale different than explicit rules for each
target. One thing I will have to watch out for are variable scopes.
However, we do not need a variable scope per cxx file -- in most cases
only the linking targets (the libraries) have a variable scope and those
are not so many that it would scare me. Still, I will do some
(synthetic) test on those too.

> Prior art:
> http://www2.parc.com/csl/groups/sda/publications/papers/Kiczales-IMSA92/for-web.pdf
Pfft, thats easy. There is always prior art at Xeroc PARC. ;-)

> And in fact inescapable, ~every implementation will leak under its
> abstractions. So I guess you're rather arguing for having only _one_
> implementation - which is not obtainable in a cross-platform,
> opensource project. ;)
No, I am all for (according to the Zen of Python):
"There should be one-- and preferably only one --obvious way to do it."

Best Regards,

Bjoern Michaelsen


--
===========================================================================
 Sitz der Gesellschaft:
 Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
 Amtsgericht Muenchen: HRB 161028
 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel
 Vorsitzender des Aufsichtsrates: Martin Haering
===========================================================================


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: Building OpenOffice.org with GNU make

Thorsten Behrens-3
bjoern michaelsen - Sun Microsystems - Hamburg Germany wrote:
> >  # loads cxxflags, weird sw include setup etc.
> >  include sw_defaults
> Here you will either need to use dirty tricks or you will clash in a
> global namespace, because you would like these defaults to be applied
> to msword and others in sw, but not the others.
>
That's exactly why I wonder if we should have a level of abstraction
above naked gnu makefiles - i.e. a DSL that gets translated into
makefiles.

> > And in fact inescapable, ~every implementation will leak under its
> > abstractions. So I guess you're rather arguing for having only _one_
> > implementation - which is not obtainable in a cross-platform,
> > opensource project. ;)
> No, I am all for (according to the Zen of Python):
> "There should be one-- and preferably only one --obvious way to do it."
>
Zen is nice, Python even more so, but let's face reality - the world
out here is not homogeneous (and not a single version for every used
tool) at all.

Cheers,

-- Thorsten

attachment0 (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Re: Building OpenOffice.org with GNU make

Björn Michaelsen-2
On Mon, 07 Dec 2009 13:46:19 +0100
Thorsten Behrens <[hidden email]> wrote:

> That's exactly why I wonder if we should have a level of abstraction
> above naked gnu makefiles - i.e. a DSL that gets translated into
> makefiles.

Actually, the files describing the actual stuff to build are a kind of
DSL. If you look at target_lib_msword.mk there is no makefile syntax or
logic beyond the $(eval $(call)) statements. What is called by the
eval/call statements is our own high level DSL/API. You could
rather trivially parse and translate that to MSBuild-XML, CMake-Files,
Jam-Files or anything else, should the need arise someday.

The important stuff and the hard part will be to:
a) translate all files into clean declarative statements.
b) keep those files clean and not letting them bit rot.

Best Regards,

Bjoern

--
===========================================================================
 Sitz der Gesellschaft:
 Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
 Amtsgericht Muenchen: HRB 161028
 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel
 Vorsitzender des Aufsichtsrates: Martin Haering
===========================================================================


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: Building OpenOffice.org with GNU make

Mathias Bauer
In reply to this post by Thorsten Behrens-3
Thorsten Behrens wrote:

> Hi Mathias,
>
> most of the points you've raised I already replied to in my followup
> to Bjoern (including my ideal msword lib makefile) -
>
> Mathias Bauer wrote:
>> build.pl uses module dependencies, not target dependencies, so it has an
>> inherent susceptibility to bottlenecks. Basically all of our c++ sources
>> could be built in parallel (as they don't depend on each other), but
>> with build.pl we always have to wait until header files are "delivered"
>> or created. And because the dependency granularity level is the "module"
>> (not a real target like e.g. a library), we can't use as much
>> parallelization as possible. This becomes even more painful if you don't
>> build the whole office, but only some parts of it, e.g. in a split build
>> or if you rebuild several "modules".
>>
> Ah interesting - so we're then moving away from the solver concept?

This is irrelevant for the system in question. With or without solver,
you will have the same problems with our current build system. The only
thing that matters is how many modules you want to build in parallel.

>
>> No, really, there's nothing nailed until now. If you or anybody else
>> knew a better way and(!) offered help and cooperation, there's nothing
>> that would hold us back from doing it differently.
>>
> I find this "and(!)" slightly worrying - not that I would not lend a
> helping hand; but why are you refusing advise from people just
> because they may not have time helping you with coding?

Did I say that we would refuse advise if it clearly showed improvements?
Of course not, why should we? But I wouldn't call "don't use X, Z is
much better" an advise. Or, to say it with Monty Python: "This is not an
argument, this is contradiction." "No, it isn't!" "Yes it is!" etc. etc.

Perhaps I should rephrase my statement: the best I can see is that
people show us that what we want to achieve by using GNU make can be
done even better, simpler, faster etc. in a way we don't know until now
and help us to get that implemented. As far as I'm concerned, the second
part is optional, but of course much desired.

>> > That's why he went for bjam ...
>>
>> Can you explain if bjam is able to fulfill the requirements Björn and I
>> have mentioned and what else it can do better than GNU make? Or can you
>> at least explain why you perhaps prefer it?
>>
> I didn't say I'd prefer it. I was just pointing to that project, and
> the experiences.
Just pointing to a project without giving a hint how that could solve
the problems isn't very helpful ATM (though I appreciate the hint and
surely will have a look when I have some time). So if you could explain
how bjam (or any other make system that someone wants to suggest here)
solves our problems or why the problems that require bjam to be resolved
are even bigger than those we try to fix, we might be able to get
somewhere.

> Maybe it would help the discussion if more of the
> internal findings you mentioned would be public - come to think of
> it, maybe it would have been nice to have the whole discussion that
> led to this prototype public, in the first place ... ;)

You can find most of our findings, discussions etc. in the wiki (I have
posted the link several times) or in Björn's and my blogs. Björn also
will post some more data about GNU make investigations soon. They never
were planned to be "internal findings", but posting them without prior
explanation wouldn't have made sense and even now they don't add
anything to the discussion we wanted to start. The topic is not "can GNU
make do that", but "do we have the right goals" and "GNU make can reach
the goals, which other tools can do it also or perhaps even better".

Regards,
Mathias

--
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "[hidden email]".
I use it for the OOo lists and only rarely read other mails sent to it.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

1234