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
pgp1ToyAHALCx.pgp
Description: PGP signature
