Hi Kay,
I missed you reply I believe; please CC me ;-)
On Wed, 2008-07-23 at 12:49 +0200, Kay Ramme - wrote:
> Michael Meeks wrote:
> > I'm currently playing with split source builds: by which I mean that we
> > can slice OO.o into a number of smaller pieces (following kendy's
> > suggested split), having split the source into chunks with the attached
> > src-pack2. I also attach my notes on how we're going about this so far.
>
> I am going to take a look.
So - in fact this now works quite nicely for me; I have a set of RPMs
that build separately & run much of the OO.o.
http://svn.gnome.org/viewvc/ooo-build/trunk/patches/dev300/
the piece-* patches are they, those piece-* can all be JCA'd etc. but
are likely only to be useful as pointers in their current form.
> > Firstly - scp2: - this module is built very late in the build system,
> > but - we need the results from it to install ~all our libraries during
> > the split build. ie. if we build the 'ure' then in order to install the
> > libs in the right place; we need the scp2 to hand.
>
> I know ... ;-)
So - having just banged through make_installer.pl and co. once again -
I'm really beginning to loathe it ;-) Anyhow.
Here is what I suggest we do, as a way ahead: kill several birds with
one stone:
* merge a variant of the above patches
* split the scp2 into the individual modules
!! * kill half of 'deliver.pl'
+ split the solver into two:
+ install-set layout image
+ solver/ layout image
+ make the install-set layout image from the scp2 &
an (accelerated) make_installer.pl
[ this is effectively what I do ]
This has a number of rather obvious benefits:
+ we can easily split the code any-way we like later
+ we have a "run-able" OO.o even in all-the-way through
OO.o: should save space, and pain for developers.
+ we can trivially build pieces against an
installed OO.o
Failing that, it's necessary to take something like the piece-*
patches, but re-work each of them, and add a lot of conditionals to make
them work both in all-the-way-through mode and also in built-vs-system
mode - which is pain, complexity and so on.
So - the question is: is there any good reason why we would not want
the 'live' half of the solver to look like an install set ? in the
abstract - if we wanted it to look like something else of course it
should be easy enough to do that just by tweaking the include paths in
foootherproduct.lst such that make_installer.pl can build that too.
HTH,
Michael.
--
[EMAIL PROTECTED] <><, Pseudo Engineer, itinerant idiot
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
