openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andre Fischer <>
Subject Re: [question] build infra structure.
Date Thu, 01 Nov 2012 17:18:36 GMT
On 01.11.2012 17:57, jan iversen wrote:
> 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.

We are in the process of migrating from dmake to GNU make.
When that is finished then we will have essentially one single 
makefile.  Well, there will be one top level makefile that includes all 
the other makefiles.  But there will not one make process that starts 
other makes in subprocesses.  That would be evil, or so I have been 
told, see

> I hope to see your presentation on video later, due to personal budget
> restriction (dont we all have that) I cannot participate.
Sorry to hear that, I would have liked to meet you.

> Jan.
> 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
> jokes/hints)
>> 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 ?
I guess there are historical reasons for that.  And then there is the 
not-invented-here syndrome.

I have made an experiment a few months ago in which I wrote a Perl 
script that reads all prj/build.lst files and creates one GNU makefile 
that did what build --all does.   Worked like a charm.  It just has not 
many advantages over  Especially when we proceed with the 
dmake to gbuild transition and will have the centeral makefile in a few 

>> 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 ???

Yes, certainly.  But when you use a makefile for inter-module 
dependencies then you get a much finer granularity.  That is one of the 
goals of gbuild.  Change one file in VCL, run build -all in 
instsetoo_native and only the files that directly or indirectly depend 
on the modified files are built.  Today you have to rebuild all modules 
completely that depend on VCL.

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

That is, of course, a good thing.  I am not so differently in that I did 
not know much about the build system when I worked at Sun and later 
Oracle.  Our release engineers took care of it.  It became necessary to 
have a closer look at the build system when OpenOffice was transferred 
to Apache and the build engineers and their knowledge left the project.

>> 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 !!!!

You're welcome.  It is nice to see that I am not the only one who tries 
to understand the build system,  the "boring" part of AOO.


View raw message