On 14.10.2013 23:40, janI wrote:
On 14 October 2013 23:34, Kay Schenk <kay.sch...@gmail.com> wrote:
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.
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.
I think build.pl is the smallest problem in our build problem. As Jan
already said, it basically just calls dmake or GNU make for all projects
and in the right order.
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.
Some time ago I have written a Perl script that basically what Jan has
outlined. It reads the build.lst files and creates one Makefile that
calls dmake and GNU make for the projects.
The only problem with this aproach, and the reason why I did not
finalized this experiment, is that build.pl has a lot of other features
and options besides the regular build. Understanding these and
replicating them is the hard part.
-Andre
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 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 work
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.
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 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
