Mailing-List: contact dev-help@openoffice.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openoffice.apache.org
Received-SPF: pass (athena.apache.org: domain of kay.schenk@gmail.com
 designates 209.85.160.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAK2iWdTewAehmS_QNbkHCtcqhyAwPjDN+8Veydu6Jk_+i+Nn1g@mail.gmail.com>
References: 
 <CAK2iWdRi6j2_e9tRehnD9zvBvvXLucFMNM500feNLUr2N0+Ncg@mail.gmail.com>
	<525B9F85.9030701@googlemail.com>
	<CAGj3217QGpQ1aCHdrhdA=uGyyYXJMTEWAVR1T8=pJdEVzMHHvQ@mail.gmail.com>
	<CAK2iWdS-HN32efARYQhC=HJSiEKb7sfMCSn4DkKFhCHRqTe4CA@mail.gmail.com>
	<CAGj3216SceEPhTfTmXgn_RJcua9NpihCojrKz4qJCh8PezD49w@mail.gmail.com>
	<CAK2iWdTewAehmS_QNbkHCtcqhyAwPjDN+8Veydu6Jk_+i+Nn1g@mail.gmail.com>
Date: Tue, 15 Oct 2013 16:08:59 -0700
Message-ID: 
 <CAGj3214OC=Sw5wygtgRBvds=pbUT8szAN5UcJMjL9t-Npj32NA@mail.gmail.com>
Subject: Re: Mentor a new build system.
From: Kay Schenk <kay.schenk@gmail.com>
To: devAOO <dev@openoffice.apache.org>
Content-Type: multipart/alternative; boundary=047d7b15b0e778d5ed04e8cfabea

--047d7b15b0e778d5ed04e8cfabea
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Oct 14, 2013 at 2:40 PM, janI <jani@apache.org> wrote:

> On 14 October 2013 23:34, Kay Schenk <kay.schenk@gmail.com> wrote:
>
> > On Mon, Oct 14, 2013 at 2:02 PM, janI <jani@apache.org> wrote:
> >
> > > On 14 October 2013 19:44, Kay Schenk <kay.schenk@gmail.com> wrote:
> > >
> > > > On Mon, Oct 14, 2013 at 12:38 AM, Andre Fischer <awf.aoo@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 OS=
U
> > > > >> capstone.
> > > > >>
> > > > >> The project has been selected, so we will have 4 students workin=
g
> > 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=3D16
> > <
> > > > http://eecs.oregonstate.edu/capstone/viewproposal2013.php?id=3D16>
> > > > >>
> > > > >> extract from above:
> > > > >>
> > > > >> motivation:
> > > > >> "Apache OpenOffice is the biggest open source office package, wi=
th
> > 65
> > > > >> milllion downloads of our last version. A number of other open
> > source
> > > > >> packages are derived from OpenOffice, and incorporates patches a=
nd
> > > > >> 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 ha=
s
> > > 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 ea=
sy
> > 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 i=
t
> > 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.
> >
>
> it maybe ignorance, I call it "interest", and to me all input are welcome=
 !
>
> >
> >
> >
> > >
> > >
> > >
> > > >
> > > > 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 ca=
ll
> > > dmake to do the rest.
> > >
> > > Ditching build.pl (which I have done experimental for helpcontent2 an=
d
> > > 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 buil=
d
> 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 ou=
r
> > inline help content, with minimal fuss. OK, I will play with that this
> > week.
> >
>
> I will be happy to assist, feel free to contact me offlist/onlist. I have
> spent the last week debugging the helpcontent2 build part, to make it wor=
k
> with genLang, and I still have some way to go.
>
> If we had some resources we should take it one step further, and replace
> the current help with standard help methods available. That would make it=
 a
> lot easier for tech. writers.
>

 J=C3=BCrgen suggested this back in April... and you can see the rest of th=
e
thread as well

http://markmail.org/message/tl5lsy4cxaa3s6lx

Anyway, I did just install the Help Authoring extension for what it's
worth. I think we need a new thread to start down this road again.


> rgds
> jan I.
>
>
> >
> > >
> > >
> > > >  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 i=
n
> > > 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 hav=
e
> 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 wou=
ld
> > > 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. Th=
e
> > 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 promise=
d
> 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, i=
f
> > the
> > > > >> result works it cannot be less "nice" than the current system.
> > > > >>
> > > > >
> > > > > I hope that you are right.  But the our second build system prove=
s
> > 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 impro=
ve
> > the
> > > > > build system greatly.
> > > > >
> > > > >
> > > > >
> > > > >> are anybody with knowledge of build.pl etc. interested in helpin=
g
> > > 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-unsubscribe@openoffice.apache.org>
> > > > >
> > > > > For additional commands, e-mail: dev-help@openoffice.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > >
> > > >
> > >
> >
> -------------------------------------------------------------------------=
------------------------
> > > > MzK
> > > >
> > > > "Truth is stranger than fiction, but it is because Fiction is oblig=
ed
> > > >  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
> >
>


--=20
---------------------------------------------------------------------------=
----------------------
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

--047d7b15b0e778d5ed04e8cfabea--