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