On Mon, Oct 14, 2013 at 2:40 PM, janI <j...@apache.org> 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. > > > > > > > > > > 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. >
Jürgen suggested this back in April... and you can see the rest of the thread as well http://markmail.org/message/tl5lsy4cxaa3s6lx Anyway, I did just install the Help Authoring extension for what it's worth. I think we need a new thread to start down this road again. > 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 > > > -- ------------------------------------------------------------------------------------------------- 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
