Caolan,
Caolán McNamara wrote:
On Thu, 2009-04-30 at 10:29 +0200, Kay Ramme wrote:
- Add missing/useful configuration switches (e.g. for headless support).
FWIW vcl headless support is always just built at the moment, so not
sure of its role an example of a missing/useful configuration switch.
... may be not the best example, agreed ...
This "build helper" may be compared to the Linux kernels menuconfig /
xconfig, first configure it extensively, ideally in a graphical way,
than build it.
I'm not particularly against all this stuff, but it seems like a lot of
work for very little gain. I mean "./configure; make" should be the
goal. All the rest of the fiddly --with-this, --with-that, --the-other"
shouldn't really be encouraged to be used unless necessary.
I should have been more precise - what I mean is not only to add more
enable/disable switches, but to add/change switches to support something
as build/pre-build/disabled.
Later on we may
- rework SCP to configure the sources more dynamically,
- provide pre-build intermediates to reduce build times for many,
- disentangle the OOo applications, and
- do even more ...
FWIW, for me the ideal build-modularization goal is something along the
modular X model, where a similar single build-system that created a
gadzillion programs and libraries was split up where each target could
be checked out individually and built separately from scratch linking
against previously installed headers/libraries from previously built
targets.
This is amongst the things behind this effort, utilize the "build
helper" to select the parts you want to develop on, only things
dependent on these may need to be build, everything else may be
pre-build / abandoned.
e.g. to build vcl "standalone" you can nearly do that, checkout just
vcl, use the sdk configuration mechanism of setsdkenv_unix, and build
against headers from the existing sdk headers + headers from comphelper,
i18npool, psprint (gone now), svtools, tools & vos (should go away) and
link against the existing libraries from the matching ure packages and
matching installed OOo. I think that there's better prototypes in
ooo-build, especially to address splitting scp2 up into the individual
projects, etc. to make a more serious stab at it.
To simplify things, I'd like to select what needs to be build at
configuration time (comparable to the Moz stuff). Obviously this is very
static, later on we may be able to introduce some more dynamics, e.g.
pre-build packages etc.
i.e. the use case is:
linux developer has OOo installed, sees a little bug, grabs the distro
source package for the little piece of OOo which has the bug, rebuilds
it in 40 nano-seconds because he doesn't have to rebuild the rest of it.
Fixes bug, is delighted with himself, becomes amazing OOo contributor.
This is what I want!
I know that I'd never have ever build X because of the long build-time
of the old tree, I just wasn't that interested. But with the modular
stuff, I can grab my distros libICE or whatever and see if those
valgrind warnings really are bugs or not rather than just whacking them
with a supressions file.
Just let's start simple, let's take care of prerequisites, 3rd party
stuff etc. followed by more in an iterative fashion ...
Only what has been identified as a "module" (AKA can been "configured"),
may become something pre-build respectively an "extension" or be left
out, to enable focusing on the relevant parts.
C.
Best regards
Kay
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
