On Mon, Oct 14, 2013 at 2:02 PM, janI <j...@apache.org> wrote:
> On 14 October 2013 19:44, Kay Schenk <kay.sch...@gmail.com> wrote:
>
> > On Mon, Oct 14, 2013 at 12:38 AM, Andre Fischer <awf....@gmail.com>
> wrote:
> >
> > > On 11.10.2013 18:10, janI wrote:
> > >
> > >> Hi.
> > >>
> > >> FYI: as I informed a while ago, I made a project proposal for OSU
> > >> capstone.
> > >>
> > >> The project has been selected, so we will have 4 students working the
> > next
> > >> months to achieve the following:
> > >>
> > >
> > > That is great news. Thank you for pushing this forward.
> > >
> > >
> > >
> > >> http://eecs.oregonstate.edu/**capstone/viewproposal2013.php?**id=16<
> > http://eecs.oregonstate.edu/capstone/viewproposal2013.php?id=16>
> > >>
> > >> extract from above:
> > >>
> > >> motivation:
> > >> "Apache OpenOffice is the biggest open source office package, with 65
> > >> milllion downloads of our last version. A number of other open source
> > >> packages are derived from OpenOffice, and incorporates patches and
> > >> enhancements from AOO.
> > >> The AOO source code is very big, 121 languages, 233 modules and 2933
> > >> makefiles (including sub-makefiles). As programming platform, we use
> C++
> > >> (bulk part), Java, Python, Perl and some special libraries
> > >> The build system is old, a combination of perl and dmake, and has
> grown
> > >> over the years into a non standard, hard to understand non documented
> > >> system.
> > >> At the same time, we want to attract more developers, therefore we
> want
> > to
> > >> make a new build system based on modern technology, which are easy to
> > use
> > >> especially for windows developers."
> > >>
> > >> goal:
> > >> "The goal is to:
> > >> 1) make a build system suitable for use with microsoft visual studio
> > >> 2) make a build system suitable for use on linux (makefiles)
> > >> One of those systems should be the primary one and the other one
> should
> > be
> > >> automatically generated.
> > >>
> > >
> > > I am not happy with that last sentence. When there is one 'primary'
> > > flavor of the build system, then that tends to get much more attention
> > than
> > > the other flavors. This happened with both build system that we have.
> > > They heavily tend to the Unix side and are slow and hard to use on
> > Windows.
> > > I think that we should treat our major platforms (Windows, Linux and
> Mac)
> > > equal.
> >
> >
> >
> > I plead absolute ignorance about Visual Studio 2008, but I thought it
> could
> > use "makefile" specifications -- though maybe this is not well-integrated
> > from what I've been reading.
> >
>
> Makefiles have been integrated since VC 6, but once you start using it you
> soon find the limits, it would never support a setup like ours.
>
OK...like I said, complete ignorance. I have ONLY used *nix builds in the
course of my life.
>
>
>
> >
> > In my mind, it would be great to ditch build.pl if we could, and go
> with a
> > straight makefile setup. We've already worked on this aspect.
> >
>
> To ditch build.pl alone, is a very straight forward task, a real nice task
> for a new developer.
>
> Remember build only controls the <module>/prj directories and then call
> dmake to do the rest.
>
> Ditching build.pl (which I have done experimental for helpcontent2 and
> l10ntools) consist of:
> 1) take the first line of */prj/build.lst and use that to build a Makefile
> in with module dependencies.
> 2) for each module use the remaining lines in */prj/build.lst to build a
> <module>/Makefile that calls dmake for the existing makefiles
> 3) for each mdoule use */prj/deliver.lst to expand <module>/Makefile with a
> target and a set of copy instructions.
>
> It about a little workweek to edit and test the setup.
>
Thanks for these tips. I would REALLY like to disconnect the help building
to try to get tech writers more interested in development/changes of our
inline help content, with minimal fuss. OK, I will play with that this week.
>
>
> > I have not thoroughly investigated the workings of "build.pl", but I'm
> > wondering if it's the mix of what we're trying to build -- e.g. the
> > helpcontent -- that is a bottleneck here. To me, it seems "code"
> components
> > could be built in some standard way and these other aspects built in
> their
> > own environment and plugged in later at some point. Just some thoughts
> I've
> > had, which might not make any sense. ;}
> >
>
> I have because of the genLang integration been deep into build (and still
> are), and e.g. helpcontent2 is solely dmake files, in my ubuntu I have a
> helpcontent2/Makefile that replaces build.pl for the module. postprocess
> or
> instsetoo_native might be a level more difficult, but they are still only
> dmake make files.
>
> I have read the fuzz about having a standard make setup, but I have never
> understood the complexity (unless you want to make it complex). I would
> gladly help someone who has time to edit the Makefiles we need.
>
> rgd
> jan I.
>
>
> >
> > But, I'm happy to see this proposal and I hope it gets accepted. The more
> > eyes we have on the build process, the better.
>
>
> >
> >
> > >
> > >
> > > The team must first understand how the current system works in
> general,
> > >> and
> > >> then build scenarios how a \\\\\\\\\\\\\\\"perfect\\\\\\\**\\\\\\\\"
> > >> system
> > >> would look like.
> > >> Second task is to implement it, in parallel with the existing system
> > >> Third task is to help test it on the different platforms we support. "
> > >>
> > >>
> > >> I will mentor the students, but hope that the community will be behind
> > me
> > >> and help as well. If the students turn out to be motivated they can,
> as
> > >> volunteers and committers, be a real bonus for the project.
> > >>
> > >> Another apache committer who lives close to the OSU have promised to
> > help
> > >> me as well.
> > >>
> > >> I am aware there are very different ideas about how a new build system
> > >> should look like, but lets use this possibility to get moving, if the
> > >> result works it cannot be less "nice" than the current system.
> > >>
> > >
> > > I hope that you are right. But the our second build system proves that
> > > just working does not necessarily result in an improvement. But I don't
> > > want to sound too negative. This project is a great start and I
> believe
> > > that you and the students and our community will be able to improve the
> > > build system greatly.
> > >
> > >
> > >
> > >> are anybody with knowledge of build.pl etc. interested in helping
> out ?
> > >>
> > >
> > > As you know, I have already done some reasearch in this area and I
> would
> > > be glad to help.
> > >
> > > Regards
> > > Andre
> > >
> > >
> ------------------------------**------------------------------**---------
> > > To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<
> > dev-unsubscr...@openoffice.apache.org>
> > >
> > > For additional commands, e-mail: dev-h...@openoffice.apache.org
> > >
> > >
> >
> >
> > --
> >
> >
> -------------------------------------------------------------------------------------------------
> > MzK
> >
> > "Truth is stranger than fiction, but it is because Fiction is obliged
> > to stick to possibilities. Truth isn't."
> > -- "Following the Equator", Mark Twain
> >
>
--
-------------------------------------------------------------------------------------------------
MzK
"Truth is stranger than fiction, but it is because Fiction is obliged
to stick to possibilities. Truth isn't."
-- "Following the Equator", Mark Twain
