openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From janI <j...@apache.org>
Subject Re: Make x Dmake x Build (Was: Re: [Error] Compile AOO on Debian amd64)
Date Fri, 19 Apr 2013 08:02:15 GMT
On 19 April 2013 07:56, J├╝rgen Schmidt <jogischmidt@gmail.com> wrote:

> On 4/19/13 12:33 AM, Kay Schenk wrote:
> > On Thu, Apr 18, 2013 at 2:11 PM, janI <jani@apache.org> wrote:
> >
> >> On 18 April 2013 22:38, Kay Schenk <kay.schenk@gmail.com> wrote:
> >>
> >>> On Thu, Apr 18, 2013 at 5:17 AM, janI <jani@apache.org> wrote:
> >>>
> >>>> On 18 April 2013 14:08, Claudio Filho <filhocf@gmail.com> wrote:
> >>>>
> >>>>> Hi
> >>>>>
> >>>>> 2013/4/18 Oliver-Rainer Wittmann <orwittmann@googlemail.com>:
> >>>>>> But regarding the removed Slot FN_PROPERTY_WRAP_DLG perform
a clean
> >>>>> build of
> >>>>>> module sw:
> >>>>>> - cd sw
> >>>>>> - make clean
> >>>>>> - build
> >>>>>
> >>>>> Oliver, sorry by my newbie ask, but... we don't use more dmake?
> >>>>>
> >>>>> If i understood correctly, "build" is a perl script that calls all
> >>>>> modules, building in order of dependence, entering in each one,
> >>>>> calling Dmake to compile and delivering all files where need.
> >>>>>
> >>>> correct.
> >>>>
> >>>>
> >>>>>
> >>>>> I saw some "makefile" files and many more "makefile.mk", where i
> >> think
> >>>>> that one is for Make and other is to Dmake. I see it in wiki too,
for
> >>>>> build parts.
> >>>>>
> >>>> again correct.
> >>>>
> >>>> Problem is that some of the modules have been moved away from dmake
to
> >>>> "gbuild", so right now it is a mix (and not a very smart one).
> >>>>
> >>>
> >>> Jan --
> >>>
> >>> This last comment "not a very smart one" is interesting. Do you care to
> >>> elaborate?
> >>>
> >> I have to watch more carefully what I write, someone is actually
> reading it
> >> :-)
> >>
> >
> > yes, we do that sometimes! :)
> >
> >
> >>
> >> I am deep in the building system at the moment with my l10n work, and
> what
> >> we have now in trunk is approx 2/3 orignal dmake (that btw also seem to
> >> have at least 2 generations) and 1/3 gbuild, this combination does a
> good
> >> job of confusing anyone who tries to understand the system. Just to make
> >> things worse, the gbuild part is split in as many files as possible.
> >>
> >> So I should have written "dont try to understand it, just accept it",
> >> actually someone else in here said something similar to me a couple of
> >> month ago.
> >>
> >
>
> Exactly that is the problem, the work on gbuild is not yet finished and
> we have a mix of gnu make and dmake. The gbuild is the outcome of an
> analysis how to improve the build system. I believe it is not bad and
> our friends from LO have more or less finished the work but I also
> believe that it is too complex and can be done much simpler.
>
> It's nearly impossible to debug and not easy to understand. It tried to
> hide the complexity from single makefiles in the modules and introduced
> soe kind of new scripting language based on gnu make. I am not sure if
> that was the best approach.
>
As I wrote earlier, the gbuild team have done a fantastic job analyzing our
system.

I am sure there is something wrong the approach, when you have a chain of 5
makefiles (one include the other)...so to me the structure itself is very
complex.

There is a reason both for the scripting language and the complex
structure. Both dmake and gbuild tries to solve the whole world and cook
coffee at the same time.

What I mean is, there are no separation between a couple of logical steps:
- Clean/create directories and other items needed for the actual make. This
happens on the go and everytime you build. In my world we should have a
"make prepare" that I call ONCE after svn co, and the real build should
assume all directories are present.
- Intermodule dependencies. Every module checks at every build if the
modules it depends has been built. In my world, module makefile should only
do the module, and a makefile in main takes care of the interdependencies.

I have tried the LO gbuild, and it is not particulary fast either.


> >
> >>
> >>
> >>>
> >>> I saw all this mixture too in my build experience, and well...couldn't
> >>> figure out why. It seems historically dmake was used to speed things
> >> along,
> >>> but, well...I'm not sure how/why it's being used now exactly.
> >>>
> >> Actually the wiki/gbuild have a pretty good description. The people who
> >> started gbuild did a real good job of analyzing the dmake build and an
> even
> >> better job of documenting their findings.
> >>
> >> I am right now (slowly) in the progress of writing a document, with
> demands
> >> to a solid, easy to understand build system, based on my experience
> from a
> >> system about 4-5 times bigger than AOO.
> >>
> >
> > Great! I look forward to it! Although I have *used* make systems a lot
> > throughout my career, I've never ever constructed one, so much of this
> is a
> > mystery to me.
>
> Me too and we can can benefit from something that we understand better
> and that is potentially not so generic but where makefiles are readable.
>
 +2

>
> >
> >
> >>>
> >>> And, yes, I saw the gbuild branch was basically inactive and tried to
> >> tract
> >>> down some info on that, but couldn't find much discussion about it.
> >>>
> >>> We do indeed need to devote discussion time to our build process after
> >>> 4.0.   I would hope we could at least make things simpler for folks
> >> wanting
> >>> to partial builds of areas.
> >>>
> >>
> >> In my world, we can make it VERY simple...but even though gbuild is
> pretty
> >> new, it uses the same philosofy as dmake, so it does not really change
> >> things. I have a couple of ideas, admitted a bit radical, but they would
> >> allow us to use standard make. My intention is to take the discussion,
> when
> >> I have something to present, instead of starting the discussion with a
> >> piece of blank paper.
>
> I am looking forward to hear, read or see more
>
> >>
> >> Another thing we need to discuss is packaging, would it not be ideal if
> >> people could just make writer, when working on that. I would like to
> see a
> >> download page, where the user select which parts of AOO he/she wants to
> >> download.
> >>
> >> I hope you like to appetizer :-)
> >>
> >
> > So far, what you say makes very good sense to me.  I'm happy you've
> started
> > in this direction.
>
> of course it make sense and is not really a new idea. But when you look
> closer you will see that the difference in the end is not really huge.
>
No not really...I am afraid though that we might need a couple of code
changes, and maybe also subdivide main in svn.

>
> But a simplified packaging process would be highly appreciated. I
> believe there is a lot of room for improvements, especially when we
> remove all the special cases that we no longer need.
> This would probably help us to provide a good working patch mechanism.
>
> The idea of dynamic packaging is an interesting one especially when I
> think about localized version. Most of the stuff is the same and only
> the localized string are different. It would be nice to have a process
> in place where we could package the final downloadable dynamic. But it
> becomes more complex when we take signing into account.
>
As far as I know you can have multiple packages in one download each with a
separate signature. At least that is what happens with visual studio.

>
> In the end our users want an easy to install end user product, that
> means one download and a one click installation, maybe with minor options.
>
> Or we need a minimal base installer that downloads the rest on demand.
> Fine for many locations but not so good for regions where the internet
> connections are still not goo enough or not existent at all.
>
I agree, we have many "small" languages, meaning aoo is often downloaded in
areas with bad connections, so the one-click philosofy is good.

rgds
jan I.

>
> Many ideas where we can start thinking ...
>
> Juergen
>
> >
> >
> >> rgds
> >> Jan I.
> >>
> >>>
> >>>
> >>>
> >>>>
> >>>>>
> >>>>> In long term, we will migrate to Make or continue with this hibrid(?)
> >>>>> model?
> >>>>>
> >>>> Yes, at the moment we have a branch called "gbuild" with very little
> >>>> activity. You can find a lot of description on wiki about gbuild.
> >>>>
> >>>> There are also ongoing work, to use standard make and a much simpler
> >>>> structure (no perl build), but this is not something you will see
> until
> >>>> after the 4.0 (and problaly 4.1) release. Once a complete is ready it
> >>> will
> >>>> be published and hopefully discussed on this list.
> >>>>
> >>>> rgds
> >>>> jan I.
> >>>>
> >>>>>
> >>>>> Cheers,
> >>>>> Claudio
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> >>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
> >>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>>
> >>>
> >>
> ----------------------------------------------------------------------------------------
> >>> MzK
> >>>
> >>> "There's no upside in screwing with things you can't explain."
> >>>                         -- Captain Roy Montgomery, "Castle"
> >>>
> >>
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>

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