incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan iversen <>
Subject Re: [question] build infra structure.
Date Thu, 01 Nov 2012 16:57:16 GMT
See below please.

THANKS for your VERY informative answer, it helped me a lot.

I was of the simple idea, that we pursued a simple build process made up of
gnuMake and an addon to gather for the shortcoming of gnumake in respect of
cascaded makefiles.

I hope to see your presentation on video later, due to personal budget
restriction (dont we all have that) I cannot participate.


On 1 November 2012 17:44, Andre Fischer <> wrote:

> On 31.10.2012 22:20, jan iversen wrote:
>> Hi
>> I have been searching for detailed internal information about how the
>> build
>> process works with build and dmake (gnumake).
>> I have seen the relationship in the single directories (prj/build.lst
>> prj/d.lst and, but I cannot find a central makefile.
>> If I understand life, there should be a central makefile, telling e.g. how
>> .cpp is translated to .o
> Pah, who needs a central makefile if he can have a Perl file instead :-)
> Sorry, I could not resist.  I am currently preparing a talk for ApacheCon
> about the AOO build system and it is somewhat depressing to see how bizarre
> some things are.
It´s quite OK, I learn fast :-) (and being a dane I like that kind of

> If I find the time after ApacheCon then I will turn my talk into a Wiki
> page or one or several blog posts.
> Here is the short version.
> First there is configure and bootstrap.  But I think that you have
> mastered that step already.
> Then comes the actual building.  The central makefile is main/solenv/bin/
>, yes, a Perl script.  It reads <module>/prj/build.lst files to
> a) determine the dependency between modules and     (just the first line)
> b) find the directories inside each module that have to be built.
>  (all other lines)
> starts at main/instsetoo_native/prj/buil** <> and follows
the dependency to other modules.
> can handle multi process builds and uses the module dependency
> graph to build modules in the right order.
> It can do partial builds:
>   build --all --from <module>  ignores all modules before <module> when
> building AOO (in the linearization of the dependency graph)
>   build --all   called in another module than instsetoo_native builds all
> dependencies and stops when the current module is built.
> calls dmake for every module, regardless of whether they are
> dmake or gbuild modules.
> - For dmake modules it calls dmake for all directories listed in
> prj/build.lst
> - For gbuild modules it does the same but prj/build.lst only contains one
> entry which points to util/
>   This util/ then chains GNU make for <module>/Makefile
>   gbuild modules have all their makefiles in their top level directory.
>  One makefile per library or other main targets.
Why dont we just use dmake/gnumake, have a makefile in each directory which
includes a master makefile ?

> Both dmake and gbuild distinguish between data and build logic.  The
> modules usually contain only descriptions of which source files have to be
> compiled and which libraries are to be linked.  How that is done, on all
> the different platforms, compilers, environment variables is handled by
> makefiles in
>    solenv/inc            for dmake
>    solenv/gbuild      for gbuild
A  I wrong in saying that the bulid list and  delivery list could just as
easily have been expressed as a target in ???

Please forgive me, I am (as one who looks at the process with new eyes)
just floating ideas ?

> The last part of the build process is the creation of installation sets.
>  It is triggered by instsetoo_native/util/makefile**.mk<>which
basically just calls solenv/bin/
> with a cleverly selected bunch of parameters.
> uses a larger number of Perl modules under
> solenv/bin/modules/installer which then do the actual work of collecting
> the relevant files, copying them into a temporary directory into a runnable
> office, and finally packing them into a package that fits the target
> platform.
> I am aware that the above is still very terse.  I am happy to answer any
> questions (if I know the answer).
Thanks again, you actually helped me a lot !!!!

> Regards,
> Andre
>> Can somebody please point me in the direction, or tell me if it done in a
>> different way ?
>> My reason for asking is that I need to add  a set of new standard rules
>> for
>> localization (.xhlp -> .po ....)
>> Thanks in advance.
>> Jan

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message