Re: [tools-dev] OOo source split
Hi Mathias, On Wednesday 30 of April 2008, Mathias Bauer wrote: Well, my _only_ motivation for the split are the build dependencies - so if we end up with 20 (sub)packages, or 15, I don't really care :-) Also, the names are not that big deal for me (though I personally prefer better describing names, and a kind of structure in them). What is the real problem from my point of view is that currently you cannot take just one of the projects, and (when you have the dependencies installed) self-containly build it. Also, if you look at eg. framework, you see stuff that is essential for the OOo functionality (desktop) as well as one that can be omitted (binfilter). What level of granularity are you aiming at? I think that having separate packages for modules can work for many if we applied the necessary changes to scp2. Of course these changes will be more than some tweaking, it looks like a redesign to me. As I wrote, Why do we need it: It would be great to have the .rpm/.deb/whatever packages in accord with the build dependencies. [and elaborate why it would be so great]. So - take the number of .rpm packages you would be willing to install by hand to get the OOo running, and you get the granularity I'm aiming at. For me, anything between 15 and 20 is OK, anything higher is too much, anything lower is too monolithic again. But there are some libraries/modules that are still very big and very intertwined with others. Making them available as separated packages with a reasobable size would require code changes also - and currently I don't see any activity going on to work on that. That's something I regret but OTOH I know that this is a resource problem. That's the next step from my point of view :-) But the approach of moving the modules between the projects is generally OK for me. Just let's be careful not to end up in arguments like 'X: This module needs to be built in project A, that way we'll have the smallest dependencies. Y: Yes, but people in the project B know most about it.' :-) I don't understand who modules and projects relate here. Kay, in the email from 2008-04-09, you could have seen the relevant parts quoted in my mail. Maybe we should define the terms: projects: The top-level cvs modules [term 'module' used here in the cvs terminology, not the 'module' defined below] - like gsl, graphics, framework, api, ... modules: The one level lower thing - the directories you see top-level when you checkout the OpenOffice2 alias. Examples: vcl, desktop, sal, ... The 'projects' are re-used as project.openoffice.org, and also for the mailing lists, hierarchy (project leads), etc. So - there for sure is a relation, Kay proposed to re-use it, I fear that the current reuse for the hierarchy and for the webpages will be stopping us. Projects are completely irrelevant for modularization - we should use the modules as units for packages and try to bundle some smaller ones into one package so that the number does not become too high. But nobody wants a package filter or utilities. That's either what me (and I belive Kay as well) propose [split the current mega-big-monolithic sources by bundling the modules into packages, and distribute them separately], or I don't understand you, sorry. So - what can we do as the next step? Should I try to merge your and my list to come up with the 'core' dependencies? Or could you, please? As long as the lists are project oriented and not module oriented we won't succeed. As alway, IMHO. :-) And here I don't understand you either. So, you say that a list like Package/project/whatever_is_the_name 1 contains: module_A module_B module_C Package/project/whatever_is_the_name 1 contains: module_D is bad, and we need something like module_A: belongs to Package/project/whatever_is_the_name 1 module_D: belongs to Package/project/whatever_is_the_name 2 ? I don't see the difference... Regards, Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOo source split
Caolan McNamara wrote: On Mon, 2008-04-28 at 20:25 +0200, Jan Holesovsky wrote: Another advantage is that it is also easy for the potential contributors to install just the -devel packages of the dependencies, and start with the development in the package where he/she wants to fix something - eg. you (generally) do not have to build everything up to Writer if you want to fix a Writer bug I don't think I can stress the worth of being able to do that enough btw. I'd never have bothered to even look at a line of xorg code in the pre modularized build days and e.g. just waved away various valgrind errors from x libs, but post-modularization it was a trivial matter to scratch that itch and see was there something in those libs that needed fixing. The build was guaranteed to work first-time without having to read a single how-to-build readme, and was going to be short. Fully agreed, currently contributors need to do a full build to check their changes, this hurdle is too high for many to actually care enough to contribute. C. Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOo source split
Hi Kay, Apparently I missed your mail - sorry for that :-( On Wednesday 09 April 2008 15:35, Kay Ramme - Sun Germany - Hamburg wrote: just wanted to suggest that re-using one or the other already existing structure for package re-organization would have some benefits. Possible candidates IMHO are: -1- projects -2- modules You more or less already ruled out the modules approach, arguing along the line, that it would be too many resulting packages, which I basically agree to. So let's take a look a mirroring the (code) projects into the package structure, we would get: api dba documentation external framework graphics gsl installation l10n oi (obsolet, but still used) porting qa sc script (obsolet, but still used) sw tools ucb udk ui util whiteboard (obsolet, but still used) xml These are slightly more than in your suggestions (19 vs. 16), but still seems to be manageable, the structure is partly similar. Benefits would be: - Known package owner. - No discussions where a new module belongs to etc. - Already defined and established. - Easy to find out where a module belongs too: cat module/CVS/Repository Issues regarding build dependencies might give a hint about wrong module placement and would need to be fixed anyway. Well, my _only_ motivation for the split are the build dependencies - so if we end up with 20 (sub)packages, or 15, I don't really care :-) Also, the names are not that big deal for me (though I personally prefer better describing names, and a kind of structure in them). What is the real problem from my point of view is that currently you cannot take just one of the projects, and (when you have the dependencies installed) self-containly build it. Also, if you look at eg. framework, you see stuff that is essential for the OOo functionality (desktop) as well as one that can be omitted (binfilter). [Why do we need it: It would be great to have the .rpm/.deb/whatever packages in accord with the build dependencies. It then allows us (the Linux distributors) to build the packages in parallel easily. Another advantage is that it is also easy for the potential contributors to install just the -devel packages of the dependencies, and start with the development in the package where he/she wants to fix something - eg. you (generally) do not have to build everything up to Writer if you want to fix a Writer bug... The Linux distros have mechanisms to install such development setups - eg. 'apt-get build-dep', or 'zypper build-deps-install' (to be in openSUSE 11.0).] But the approach of moving the modules between the projects is generally OK for me. Just let's be careful not to end up in arguments like 'X: This module needs to be built in project A, that way we'll have the smallest dependencies. Y: Yes, but people in the project B know most about it.' :-) So - what can we do as the next step? Should I try to merge your and my list to come up with the 'core' dependencies? Or could you, please? Regards, Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOo source split
Hi Jan, just wanted to suggest that re-using one or the other already existing structure for package re-organization would have some benefits. Possible candidates IMHO are: -1- projects -2- modules You more or less already ruled out the modules approach, arguing along the line, that it would be too many resulting packages, which I basically agree to. So let's take a look a mirroring the (code) projects into the package structure, we would get: api dba documentation external framework graphics gsl installation l10n oi (obsolet, but still used) porting qa sc script (obsolet, but still used) sw tools ucb udk ui util whiteboard (obsolet, but still used) xml These are slightly more than in your suggestions (19 vs. 16), but still seems to be manageable, the structure is partly similar. Benefits would be: - Known package owner. - No discussions where a new module belongs to etc. - Already defined and established. - Easy to find out where a module belongs too: cat module/CVS/Repository Issues regarding build dependencies might give a hint about wrong module placement and would need to be fixed anyway. Comments? Kay It follows the module-to-project list: api bean odk offapi offuh oovbaapi sdk_oo udkapi unodevtools dba connectivity dbaccess reportdesign documentation helpcontent2 external MathMLDTD addons addons afms agg apache-commons beanshell berkeleydb boost curl epm expat external_images fondu freetype hsqldb icc icu jfreereport jpeg libegg libtextcat libwpd libxml2 libxmlsec libxslt lpsolve moz msfontextract neon np_sdk openssl psprint_config python regexp rhino sane stlport tomcat twain unixODBC vigra x11_extensions xalan xpdf zlib framework binfilter desktop embeddedobj embedserv filter framework idl scripting sfx2 unoxml graphics animations avmedia basegfx chart2 goodies sd sdext slideshow svx gsl UnoControls accessibility basebmp canvas cppcanvas dtrans forms fpicker padmin psprint rsc shell sysui toolkit vcl installation extras instsetoo_native javainstaller2 packimages postprocess readlicense scp2 setup_native smoketestoo_native wizards l10n i18npool i18nutil transex3 oi sj2 porting crashrep sal qa qadevOOo sc sc scaddins sccomp script basctl basic xmlscript sw hwpfilter linguistic starmath sw swext writerfilter writerperfect tools autodoc config_office contrib cosv dmake solenv soltools testshl2 udm xml2cmp ucb store ucb ucbhelper uui udk bridges cli_ure codemaker cppu cppuhelper cpputools idlc javaunohelper jurt jvmaccess jvmfwk pyuno rdbmaker registry remotebridges ridljar salhelper stoc testtools unoil ure vos ui default_images ooo_custom_images util automation comphelper configmgr eventattacher extensions external fileaccess io jut o3tl officecfg sandbox sot svtools tools unotools xmlhelp whiteboard lingucomponent xml oox package sax xmerge xmloff xmlsecurity Jan Holesovsky wrote: Hi, During the OOoCon, Petr had a presentation about the OOo package splitting. The most important part for a (Linux) package maintainer was to be able to build parts of OpenOffice.org separately; the thing is that with all the localizations, we are unable to get the build times under some 7 hours. But the build could be done nicely in parallel (on the level of machines, not processors) if the sources were split correctly, with correct rpms and -devel rpms [of course, applies to debs as well ;-)]. And of course, the -noarch parts like the translations could be built just once for all architectures. I propose the following split of the sources [the sizes are of the unpacked sources]: 75M ure 25M ooo-bootstrap 141Mooo-libs-core 101Mooo-libs-guitoolkit 142Mooo-libs-3rdparty 17M ooo-apps-base 28M ooo-apps-calc 38M ooo-apps-extensions 14M ooo-apps-chart 40M ooo-apps-impress 40M ooo-apps-writer 59M ooo-artwork 107Mooo-filters 888Mooo-l10n 48M ooo-sdk 72M ooo-testing (1.8G total) (See below the content of these tarballs/archives). I don't want the granularity to be too fine (we would get the modules we have now, but as separate packages), and OTOH the current 5 packages are too few. The build order of these would be: ooo-bootstrap ooo-libs-3rdparty ure ooo-libs-guitoolkit ooo-libs-core [the rest in whatever sequence/in parallel] This would tremendously decrease the learning curve for the new developers as well. Imagine someone who wants to start hacking on Calc. Instead of the monster 1.8G sources, he would have to handle 512MB. Additionally, the goal of the modern Linux distros should be to get rid of the ooo-libs-3rdparty completely - it contains just stuff that is available from other sources anyway [-system stuff], and the distros have packages for them -, thus additional 142M down, doing
Re: [tools-dev] OOo source split
Hi Mathias, On Monday 15 October 2007 17:45, Mathias Bauer wrote: The advantage of one single 3rdparty package is that you either can use it as a make yourself happy with one click package or you don't use it at all and use each library as part of the already available 3rd party packages that can be installed separately. Problem is that we can't cope with permanently updating OOo to the latest and greatest versions of these libraries and so it must be possible to install older versions of them at times. In case that isn't possible individual oo3rdparty packages for each single 3rd party library might come in handy. Are there any other advantages or disadvantages of either concept that I forgot to mention here? From my point of view, a perfect summary, thank you! Regards, Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOo source split
Hi mathias The point is that people want to get rid of the whole process. That doesn't mean that we won't be able to build everything in one step but that shouldn't be the only way to build something that is part of the OOo code base. Thanks for your development laurent -- Laurent Godard [EMAIL PROTECTED] - Ingénierie OpenOffice.org - http://www.indesko.com Nuxeo Enterprise Content Management http://www.nuxeo.com - http://www.nuxeo.org Livre Programmation OpenOffice.org, Eyrolles 2004-2006 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOo source split
Jan Holesovsky wrote: Hi Mathias, On Friday 12 October 2007 20:18, Mathias Bauer wrote: just stumbled about that the report design extension is built during the regular build process, wouldn't it be better at all to create a source tarball include jfreereport and reportdesign modules. Where we already achieved modularization in the sources we should IHMO also do the right packaging of sources, +1! What already is separated shouldn't become munged with the rest. We know how fast the separation can get lost. :-) I am a bit confused here - I thought that jfreereport was not JCA covered [though LGPL], so bundling it together was not what would you want on the source level? yes, two packages would be required. Either way, from my point of view it is plain 3rd party stuff, so I'd like to let it in ooo-libs-3rdparty. To avoid reportdesign intergrowth with Base, maybe ooo-apps-extensions would be the better option for reportdesign, what do you think? I don't understand why you want to create superbundles again, even if a more fine granular packaging is possible. Why should I care about jfreereport if I don't want to build any extension but just the core product ? Regards, Jan Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOo source split
Martin Hollmichel schrieb: Hi, just stumbled about that the report design extension is built during the regular build process, wouldn't it be better at all to create a source tarball include jfreereport and reportdesign modules. Where we already achieved modularization in the sources we should IHMO also do the right packaging of sources, +1! What already is separated shouldn't become munged with the rest. We know how fast the separation can get lost. :-) Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to [EMAIL PROTECTED]. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOo source split
Jan Holesovsky wrote: Eg. the spellchecker (hunspell) itself is in the lingucomponent which I propose to put to ooo-apps-extensions (and thus to ship it together with the application). The dictionaries for it are in ooo-libs-3rdparty/dictionaries - the distros have their own packages, but it still must be possible to build with the internal ones. I'd prefer to treat the dictionaries as an own package and not to bundle them in a super-source-package ooo-libs-3rdparty package again. If we have meaningful smallest possible packages we should go with them. Regards, Jan Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOo source split
Mathias Bauer wrote: Rüdiger Timm wrote: Personally, I do not like spitting up sources at all. But that's my very personal opinion. Splitting up source definitely is a good idea. Maybe not for people building everything anyway but it would be a huge step ahead for the casual developer like volunteers, distro maintainers etc. And no, Solver tarballs are not a replacement for this, they are yet another workaround as I have learned when I had an email conversation with Petr. So I definitely second the approach to split the source. The problem is - as I reported in my presentation in Barcelona - that we have to rework some libraries and even sources to move that forward and to effectively gain anything from this. Currently we can achieve only a small benefit but as always a large journey starts with the first step. Sorry, I was not clear in my statement. I am not against having the possibility to get smaller, logically connected parts of the code base separately. What I do not want (and perhaps that was a misinterpretation of the original posting) is having different parts in different, distinct archives. I am fine with getting parts out of one repository (currently this would easily be possible by introducing smaller aliases than the big OpenOffice2). But I do not want to collect the stuff from a couple of different repositories. And please do it with care. When OOo started our code base got 'splitted' by creating projects containg several modules. I wish we had not done that. Unfortunately that grouping has prooven to be not usefull. Having just plain modules side by side would be by far easier than what we have now. We should not do such things again. Besides this, I do not understand how your proposal could work (see above). So I would propose existing and well tested means to achieve nearly the same goals. F.e., the build tool provides a possibility to build distributed on several computers. You always refer to your always build everything approach. There's more than this. Having a huge monolithic project structure and workarounding this by providing tools to tame the beast is better than nothing but perhaps it's time to improve. The result will not make a big difference for the always everything people but it will help others. You are right, but that's what I've read in Jan's mail. He already answered that I got him partly wrong. So once reasonable packages have been defined we can think about splitting the source also. The first preparations have been done (URE split) or are under work (sdf split as you mentioned yourself). I think there are a lot of reasonale packages that can be identified right now where building them separately will work. I opt for helpcontent, binfilter and all the applications. And the next goal should be getting updated packages by just building the source packages needed, not by always building full installation sets. Can you imagine what a relief it would be not to build and pack everything because you already have the binaries in your OOo installation and only rebuild the Calc package because you only wanted to fix a small bug in Calc? Of course. Of course to be able to gain something from this we also need development packages for the OOo packages. So there's something to do, Yes, that was my concern. Spitting code does not really help as long as we do not provide corresponding binary packages. but why not start? Of course I take it for granted that those suggesting the change will help doing it. ;-) My feeling is we should first do some work on our code base so that be really can benefit from a split. Ciao, Mathias Rüdiger - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOo source split
On Thu, 2007-10-11 at 09:05 +0200, Rüdiger Timm wrote: My feeling is we should first do some work on our code base so that be really can benefit from a split. Perhaps a good case study of such a split is the modular X effort which broke the monolithic x.org build into separately buildable projects. Even as a non x-hacker I found that really helpful, I could now just build e.g. libXau and debug into it to figure out valgrind warnings and usefully patch it to fix them and submit those fixes back. Something I certainly wouldn't bother to have done if it was still a monolithic multi-hour build as it just wouldn't have been worth my while. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOo source split
Jan Holesovsky wrote: Hi Ruediger, I am sorry, I missed a part of the mail when I was answering previously :-( No problem. On Monday 08 October 2007 17:36, Rüdiger Timm wrote: This would tremendously decrease the learning curve for the new developers as well. Imagine someone who wants to start hacking on Calc. Instead of the monster 1.8G sources, he would have to handle 512MB. Additionally, the goal How should that work with your proposal? He would need everything 'below' calc. Yes, but do we provide an easy way to show him/her what _exactly_ is below calc? I was overwhelmed when I saw the number of the modules for the first time [and there was much less of them at that time ;-)]. With the split, everything is much clearer - my ideal newcomer would tell himself/herself OK, here is some bootstrap stuff, I don't care, some libs, maybe, but what I want is to hack on calc, so ooo-apps-calc. If I ever need something below, I'll learn that later. If that really is his desire, nowadays he just needs a wiki page telling that 'calc' basically is module 'sc'. Than check out 'sc' and start hacking. Learning OOo is hard, no doubt. I just do not think that splitting souce code archive would make it any easier. Except he uses, what we provide anyway: download 'solver' tarball and than check out just module 'sc'. That's exactly for the purpose you mention. Well, if the potential contributor has to learn what is that 'solver', we again increase the learning curve. And using it? I tried it once when I started with OOo hacking (as a volunteer), and after having to have the same compiler toolchain that was used for the solver generation, I just gave up and let my computer building for 24 hours. OK, on unix you are right. May be we should restrict providing 'solver' for windows. At least on linux it does not really make sense, as there are so much different toolchains possible. The idea may be good, but in practise ... [...] So I would propose existing and well tested means to achieve nearly the same goals. F.e., the build tool provides a possibility to build distributed on several computers. May I ask for a documentation/wiki pointer, please? http://tools.openoffice.org/servlets/ReadMsg?list=devmsgNo=6214 and replies to that mail. addition to the few modules) all the localize.sdf's - should we split this a bit as well? There already is work in progress on taking localize.sdf files out of the modules and concentrate them in one place. Great, whom to ask about this, please? Ivo (ihi). Ause also is involved, I think. See also http://www.openoffice.org/issues/show_bug.cgi?id=79750 http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=SRC680%2Fl10ncleanup Rüdiger - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOo source split
Rüdiger Timm wrote: Personally, I do not like spitting up sources at all. But that's my very personal opinion. Splitting up source definitely is a good idea. Maybe not for people building everything anyway but it would be a huge step ahead for the casual developer like volunteers, distro maintainers etc. And no, Solver tarballs are not a replacement for this, they are yet another workaround as I have learned when I had an email conversation with Petr. So I definitely second the approach to split the source. The problem is - as I reported in my presentation in Barcelona - that we have to rework some libraries and even sources to move that forward and to effectively gain anything from this. Currently we can achieve only a small benefit but as always a large journey starts with the first step. Besides this, I do not understand how your proposal could work (see above). So I would propose existing and well tested means to achieve nearly the same goals. F.e., the build tool provides a possibility to build distributed on several computers. You always refer to your always build everything approach. There's more than this. Having a huge monolithic project structure and workarounding this by providing tools to tame the beast is better than nothing but perhaps it's time to improve. The result will not make a big difference for the always everything people but it will help others. So once reasonable packages have been defined we can think about splitting the source also. The first preparations have been done (URE split) or are under work (sdf split as you mentioned yourself). I think there are a lot of reasonale packages that can be identified right now where building them separately will work. I opt for helpcontent, binfilter and all the applications. And the next goal should be getting updated packages by just building the source packages needed, not by always building full installation sets. Can you imagine what a relief it would be not to build and pack everything because you already have the binaries in your OOo installation and only rebuild the Calc package because you only wanted to fix a small bug in Calc? Of course to be able to gain something from this we also need development packages for the OOo packages. So there's something to do, but why not start? Of course I take it for granted that those suggesting the change will help doing it. ;-) Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to [EMAIL PROTECTED]. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[tools-dev] OOo source split
Hi, During the OOoCon, Petr had a presentation about the OOo package splitting. The most important part for a (Linux) package maintainer was to be able to build parts of OpenOffice.org separately; the thing is that with all the localizations, we are unable to get the build times under some 7 hours. But the build could be done nicely in parallel (on the level of machines, not processors) if the sources were split correctly, with correct rpms and -devel rpms [of course, applies to debs as well ;-)]. And of course, the -noarch parts like the translations could be built just once for all architectures. I propose the following split of the sources [the sizes are of the unpacked sources]: 75M ure 25M ooo-bootstrap 141Mooo-libs-core 101Mooo-libs-guitoolkit 142Mooo-libs-3rdparty 17M ooo-apps-base 28M ooo-apps-calc 38M ooo-apps-extensions 14M ooo-apps-chart 40M ooo-apps-impress 40M ooo-apps-writer 59M ooo-artwork 107Mooo-filters 888Mooo-l10n 48M ooo-sdk 72M ooo-testing (1.8G total) (See below the content of these tarballs/archives). I don't want the granularity to be too fine (we would get the modules we have now, but as separate packages), and OTOH the current 5 packages are too few. The build order of these would be: ooo-bootstrap ooo-libs-3rdparty ure ooo-libs-guitoolkit ooo-libs-core [the rest in whatever sequence/in parallel] This would tremendously decrease the learning curve for the new developers as well. Imagine someone who wants to start hacking on Calc. Instead of the monster 1.8G sources, he would have to handle 512MB. Additionally, the goal of the modern Linux distros should be to get rid of the ooo-libs-3rdparty completely - it contains just stuff that is available from other sources anyway [-system stuff], and the distros have packages for them -, thus additional 142M down, doing it just 370M. And that is much more pleasant, isn't it? ;-) Of course, this is not finalized etc. - that's why I'm asking for comments. So far I was able to build in this order with few hacks, eg. scp2 should be split so that the file lists are local, the l10n part must be buildable separtately, etc. So - what do you think? ;-) ooo-l10n in the current proposal contains (in addition to the few modules) all the localize.sdf's - should we split this a bit as well? Following is the proposal what I think belongs where: = ure = bridges cli_ure codemaker cppu cppuhelper cpputools idlc io javaunohelper jurt jut jvmaccess jvmfwk offapi offuh pyuno rdbmaker registry remotebridges ridljar sal salhelper stoc store udkapi unoil ure xml2cmp = ooo-apps-base = dbaccess reportdesign = ooo-apps-calc = sc = ooo-apps-extensions = accessibility automation basctl bean crashrep embedserv extensions forms javainstaller2 lingucomponent MathMLDTD package setup_native UnoControls wizards xmlsecurity = ooo-apps-chart = chart2 = ooo-apps-impress = animations sd slideshow = ooo-apps-writer = starmath sw = ooo-artwork = default_images external_images ooo_custom_images = ooo-bootstrap = config_office dmake instsetoo_native postprocess scp2 solenv soltools stlport = ooo-filters = binfilter filter hwpfilter unoxml writerfilter writerperfect xmerge = ooo-libs-core = avmedia basic configmgr connectivity desktop embeddedobj eventattacher fileaccess fpicker framework idl linguistic officecfg oovbaapi sandbox scripting sfx2 shell sj2 so3 svx sysui ucb uui xmlhelp xmloff xmlscript XmlSearch = ooo-libs-guitoolkit = basebmp basegfx canvas comphelper cppcanvas dtrans goodies i18npool i18nutil o3tl padmin psprint psprint_config regexp rsc sax scaddins sot svtools toolkit tools transex3 ucbhelper unotools vcl vos = ooo-libs-3rdparty = afms agg beanshell berkeleydb bitstream_vera_fonts boost curl dictionaries epm expat external fondu freetype hsqldb icu jfreereport jpeg libegg libtextcat libwpd libxml2 libxmlsec libxslt moz msfontextract nas neon np_sdk portaudio python rhino sane sndfile twain unixODBC vigra xalan xt x11_extensions zlib = ooo-l10n = extras helpcontent2 readlicense_oo = ooo-sdk = autodoc cosv odk sdk_oo udm unodevtools = ooo-testing = qadevOOo smoketestoo_native testshl2 testtools Regards, Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOo source split
Hi Ruediger, On Monday 08 October 2007 17:36, Rüdiger Timm wrote: During the OOoCon, Petr had a presentation about the OOo package splitting. The most important part for a (Linux) package maintainer was to be able to build parts of OpenOffice.org separately; the thing is that with all the localizations, we are unable to get the build times under some 7 hours. But the build could be done nicely in parallel (on the level of machines, not processors) if the sources were split correctly, with correct rpms and -devel rpms [of course, applies to debs as well ;-)]. And of course, the -noarch Sorry, I do not understand this. How do you want to build f.e. ooo-bootstrap, ooo-libs-core, and ooo-apps-writer in parrallel? Bootstrap stuff like dmake or solenv is needed everywhere. Building writer needs nearly all lower libraries in place. Sorry, it seems I should have been more verbose. As you can see below, I don't want these particular build in parallel, their order is fixed: ooo-bootstrap ooo-libs-3rdparty ure ooo-libs-guitoolkit ooo-libs-core And from this point: [the rest in whatever sequence/in parallel] It's the ooo-apps-writer, ooo-apps-calc, ... ooo-l10n that could be built in parallel and on different machines. Why don't I want to merge the 'fixed order' ones into one module? Simply 'divide et impera' ;-) They contain stuff that belongs more or less logically together. Eg. I believe we can shrink ooo-libs-core by just making some things better, but it's hard to start when one is overwhelmed by the amount of modules. Regards, Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
