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