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 http://wiki.openoffice.org/wiki/Build_System_Analysis
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 <awf....@gmail.com> 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 makefile.mk), 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/
build.pl, 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)
build.pl starts at main/instsetoo_native/prj/buil**d.pl <http://build.pl> and
follows the dependency to other modules.
build.pl 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.
build.pl 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/makefile.mk
This util/makefile.mk 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 build.pl. Especially when we proceed with the
dmake to gbuild transition and will have the centeral makefile in a few
months.
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 makefile.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<http://makefile.mk>which basically just
calls solenv/bin/
make_installer.pl with a cleverly selected bunch of parameters.
make_installer.pl 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.
-Andre
