On 19 April 2013 07:56, Jürgen Schmidt <jogischm...@gmail.com> wrote:
> On 4/19/13 12:33 AM, Kay Schenk wrote: > > On Thu, Apr 18, 2013 at 2:11 PM, janI <j...@apache.org> wrote: > > > >> On 18 April 2013 22:38, Kay Schenk <kay.sch...@gmail.com> wrote: > >> > >>> On Thu, Apr 18, 2013 at 5:17 AM, janI <j...@apache.org> wrote: > >>> > >>>> On 18 April 2013 14:08, Claudio Filho <filh...@gmail.com> wrote: > >>>> > >>>>> Hi > >>>>> > >>>>> 2013/4/18 Oliver-Rainer Wittmann <orwittm...@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-unsubscr...@openoffice.apache.org > >>>>> For additional commands, e-mail: dev-h...@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-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
