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 ? rgds jan I. > > -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.**a**pache.org<http://apache.org> >>>>>> < >>>>>> >>>>> 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-unsubscribe@openoffice.**apache.org<dev-unsubscr...@openoffice.apache.org> > > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
