On 10/15/13 10:45 AM, janI wrote: > On 15 October 2013 10:02, Andre Fischer <awf....@gmail.com> wrote: > >> 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> >>>>>>>> >>>>>>> < >>>> >>>>> 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. >> > > I would not mind having a copy of the script if possible ? > > I think we need a big discussion to whether a new system should support all > options and features of the existing systems. > > As an example, we remove most (if not all) options in configure by having > an option like "--generate_platform=xyz" where xyz is one of our supported > release platforms. The --generate-platform would internally set the same > options we use to generate the releases. > > Going in such a direction will of course limit the build variations, but I > am not sure if that is a bad thing ?
I don't know either but one goal should be to be able to build on a modern unix system and build against the system libs. I believe this is important to be included in Linux distros in the long term which I would like to see ... But having a cleanup configure and having such release or platform switches to simplify things are potentially not a bad idea. Juergen Juergen > > rgds > jan I. > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
