openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan iversen <jancasacon...@gmail.com>
Subject Re: [question] build infra structure.
Date Thu, 01 Nov 2012 17:31:10 GMT
you See below please.


On 1 November 2012 18:18, Andre Fischer <awf.aoo@gmail.com> wrote:

> 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<http://wiki.openoffice.org/wiki/Build_System_Analysis>

I am in the process of changing the l10n process. Currently it runs on one
makefile that searches all directories, I want to change that to a target
in every local makefile (build.lst).

Can I attach myself to your progress, or would you suggest that I attach my
development to the current build process. my timeline is somewhat around
new year.


>
>
>
>> 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.
>
Well if you come to FOSDEM, we can have a long chat. My problem is that I
am currently "only" a contributor so that ticket alone is 600,- EUR.

I am also prepared for google/skype videochats.


>
>
>> Jan.
>>
>> On 1 November 2012 17:44, Andre Fischer <awf.aoo@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 <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
>
>

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