Hi Michael,

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.

        Matthias asked how best Sun could help out with this - and of course,
there are a number of somewhat disruptive changes that are hard for us
to test externally pwrt. Sun's internal build system.
OK

        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 - request 1: can we split the scp2 into each project ? perhaps into
prj/ such that each module can install itself into the system, as it is
built. [ NB. we could perhaps re-use this to make OO.o run-able from the
solver ;-]. For the straight through build, hopefully the scp2 can be
simply re-aggregated later to run make_installer on it.

That is what we have in mind as well ... just give me some more days (I am on vacation the next two weeks :-), I am than going to present what I have in mind with a little prototype.


        Secondly - i18n: multiplying the already large number of lang-packs by
16 or so is not a good idea: all linux distros go to quite some lengths
to re-aggregate separated i18n packages. If we split the source, we need
to re-aggregate all our i18n work. Of course, currently that is
scattered all over the code-base which (for a split) is not ideal.

        So - request 2: can we move to a more centralised i18n system - whereby
we install un-translated src/hrc files to the solver, then run a
complete translation pass later, to build a single i18n package ? That
might have the added benefit that we can build a standalone
translation-pack, to make it (perhaps) simpler to build localisations -
though this is not my area :-)

        As a 3rd request - we need to patch the settings / target pieces fairly
hard to cope with build from (effectively) two solvers - one in the
local module set and one in the system. Comments on & help getting
changes like that up-stream appreciated - we have a number of (on the
face of them trivial) piece-* patches to tweak things there.

I think others are better prepared to comment on your other points :*)

        Thanks,

                Michael.

Kind 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]

Reply via email to