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. > > > > > > > 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 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 >
