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 .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
Jan Holesovsky 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. 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. > 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. 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". > 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. :-) 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
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 Jan, Jan Holesovsky 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). Agreed, being able to fully build the packages independently is a requirement. [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).] Understood and agreed to. 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 see ... though this sounds like the module approach being more feasible ;-) 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? I keep thinking (and working :-) on this, the moment my picture becomes clearer I am going to share it with you :-) Regards, Jan Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOo source split
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. C. - 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 /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 /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 it just
Re: [tools-dev] OOo source split
Matthias Klose wrote: Stephan Bergmann schrieb: Jan Holesovsky wrote: Keep in mind that the current situation is that some 3rdparty stuff checked into OOo is either/both: - accompanied by patch files to adapt to OOo requirements, - required by OOo in specific versions. So, in general, without cleanup, replacing 3rdparty stuff checked into OOo with 3rdparty stuff available in the environment is just not working. patches may be obsoleted by new upstream versions. I currently don't see why the patch for zlib is needed with the recent upstream version. So maybe an update would help? Generally it would be nice that every patch applied to 3rdparty stuff can at least be found in the 3rdparty upstream bug tracker and the 3rdparty development sources so that it can be dropped when importing a new upstream version into OOo. So please make it work. At least "upstreaming patches" stuff to "upstream" is expected by distributions to the "OOo upstream" as well, so why shouldn't OOo do the same? I am not at all against doing what you say (on the contrary). I just wanted to make clear what the current state of affairs is. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOo source split
Stephan Bergmann schrieb: > Jan Holesovsky wrote: > Keep in mind that the current situation is that some 3rdparty stuff > checked into OOo is either/both: > > - accompanied by patch files to adapt to OOo requirements, > > - required by OOo in specific versions. > > So, in general, without cleanup, replacing 3rdparty stuff checked into > OOo with 3rdparty stuff available in the environment is just not working. patches may be obsoleted by new upstream versions. I currently don't see why the patch for zlib is needed with the recent upstream version. So maybe an update would help? Generally it would be nice that every patch applied to 3rdparty stuff can at least be found in the 3rdparty upstream bug tracker and the 3rdparty development sources so that it can be dropped when importing a new upstream version into OOo. So please make it work. At least "upstreaming patches" stuff to "upstream" is expected by distributions to the "OOo upstream" as well, so why shouldn't OOo do the same? Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOo source split
Hi Stephan, On Thursday 01 of November 2007, Stephan Bergmann wrote: > > My vision is that on modern Linux distros, you won't need > > ooo-libs-3rdparty at all, because you will have all the packages in the > > distro already, and you'll be able to install them from there (most > > probably with the corresponding -devel packages). But for the Win32 > > builders, searching for the dependencies could be too expensive - that's > > why I propose the 'super-source-package' ;-) Of course, we can go the way > > of ooo-3rdparty-dictionaries, ooo-3rdparty-epm, ooo-3rdparty-hsqldb, etc. > > but I'm not sure if it helps in the end... > > Keep in mind that the current situation is that some 3rdparty stuff > checked into OOo is either/both: > > - accompanied by patch files to adapt to OOo requirements, > > - required by OOo in specific versions. > > So, in general, without cleanup, replacing 3rdparty stuff checked into > OOo with 3rdparty stuff available in the environment is just not working. Yes, that's why I named it a 'vision' ;-) - I hope that we agree that we would like to up-stream the OOo-specific patches to the appropriate 3rd party projects [which even happened in some cases from what I know]. So - I hope the cleanup will take place. Regards, Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOo source split
Jan Holesovsky wrote: Hi Martin, On Friday 12 October 2007 12:37, Martin Hollmichel 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. Yes, this is very tricky :-( For every module from ooo-libs-3rdparty we could have a single package, but I'm afraid it would make the granularity too fine. My vision is that on modern Linux distros, you won't need ooo-libs-3rdparty at all, because you will have all the packages in the distro already, and you'll be able to install them from there (most probably with the corresponding -devel packages). But for the Win32 builders, searching for the dependencies could be too expensive - that's why I propose the 'super-source-package' ;-) Of course, we can go the way of ooo-3rdparty-dictionaries, ooo-3rdparty-epm, ooo-3rdparty-hsqldb, etc. but I'm not sure if it helps in the end... Keep in mind that the current situation is that some 3rdparty stuff checked into OOo is either/both: - accompanied by patch files to adapt to OOo requirements, - required by OOo in specific versions. So, in general, without cleanup, replacing 3rdparty stuff checked into OOo with 3rdparty stuff available in the environment is just not working. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOo source split
Hi Mathias, On Tuesday 16 October 2007 10:12, Mathias Bauer wrote: > As we are currently talking about splitting up the source I think it > makes most sense to have separate builds for each extension. Again I am a bit afraid of too fine granularity in the case 1 extension = one tarball. But we can think of having ooo-extensions-writer, ooo-extensions-calc, ooo-extensions-core (crashreporter, etc.), ooo-extensions-base, what do you think? Maybe even rename ooo-filters to ooo-extensions-filters? > So there > would be a package/tarball containing the jfreereport binaries and the > reportdesign sources. At least that's as I understood Martin and thus my > "+1". If he was aiming for something else of course that would turn into > a "-1". But I hope that I understood him right. > > > 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 think 3rd party stuff used in extensions should be separated from 3rd > party stuff used for the "core" code base. I would even like to keep > java libs separated from C(++) libs. Right, that might make sense. So instead of ooo-libs-3rdparty, we could have ooo-libs-3rdparty-c++, ooo-libs-3rdparty-java and ooo-libs-3rdparty-extensions. That would be OK for me :-) 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
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
Laurent Godard wrote: > Hi Mathias, Hi Martin > >>> 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. :-) > > If an optional product, I would say yes > > But if delivered within OOo, the sources have to remain in CVS and then > the packaging is easier if all done at build process Of course they should remain in the OOo cvs. The question is: how are they built and packaged. It's a PITA to have to build the whole OOo code base and especially the "instsetoo_native" module to get a single package. As I understood it, the idea is to be able to get particular combinations of modules and build a single package from them without a lot of scp2 and instsetoo magic. OOo as a whole then will be a combination of several packages. That is the goal, not the first step. Now we are discussing what can bring us near to that goal and what might hold us back. > The report design extension is a typical example of what i called a > promoted popular extension > An extension, first has his own life outside OOo > When popular and included in OOo by default, sources come into the CVS > and is built during the whole process 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. 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
Hi Kendy, 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? So let me try to remove the confusion. jfreereport is LGPL without a JCA, yes. So reportdesign is derived work that is distributed as an extension. As the latter is our own code and it is OOo code we committed it to the OOo source code repository and (for convenience reasons) build it together with the "core" code base. As we are currently talking about splitting up the source I think it makes most sense to have separate builds for each extension. So there would be a package/tarball containing the jfreereport binaries and the reportdesign sources. At least that's as I understood Martin and thus my "+1". If he was aiming for something else of course that would turn into a "-1". But I hope that I understood him right. > 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 think 3rd party stuff used in extensions should be separated from 3rd party stuff used for the "core" code base. I would even like to keep java libs separated from C(++) libs. 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
Laurent Godard wrote: Hi Mathias, Hi Martin 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. :-) If an optional product, I would say yes But if delivered within OOo, the sources have to remain in CVS and then the packaging is easier if all done at build process of course all sources need to stay in CVS and there should be one alias to checkout all sources including 3rdparty, extensions and all the other stuff. We're just talking about introducing additional modular packages to allow separate building and packaging. Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOo source split
Jan Holesovsky wrote: > Hi Martin, > > On Monday 15 October 2007 14:11, Martin Hollmichel wrote: > >> > But for the Win32 builders, searching for the dependencies >> > could be too expensive - that's why I propose the 'super-source-package' >> > ;-) Of course, we can go the way of ooo-3rdparty-dictionaries, >> > ooo-3rdparty-epm, ooo-3rdparty-hsqldb, etc. but I'm not sure if it helps >> > in the end... >> >> this was what I was thinking about, just redistributing the 3rdparty >> packages as single one to achive maximum modularity at that level. > > But the maximum modularity is achieved if the developers use the versions > from > their distros. I understand ooo-libs-3rdparty as a fallback for the > developers that don't want to install the pieces; the ./configure would > detect if there are 'system' versions of this or that, and build just the > pieces that are not there. 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? 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
Hi Mathias, Hi Martin 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. :-) If an optional product, I would say yes But if delivered within OOo, the sources have to remain in CVS and then the packaging is easier if all done at build process The report design extension is a typical example of what i called a promoted popular extension An extension, first has his own life outside OOo When popular and included in OOo by default, sources come into the CVS and is built during the whole process Having it an extension has benefits as packaging is easier (because work is already done) and if an update is needed, it can be build outside the OOo proces (eg. security, crash bug aso.) This also allow the extension to join the translation process aso. 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
Hi Martin, On Monday 15 October 2007 14:11, Martin Hollmichel wrote: > > But for the Win32 builders, searching for the dependencies > > could be too expensive - that's why I propose the 'super-source-package' > > ;-) Of course, we can go the way of ooo-3rdparty-dictionaries, > > ooo-3rdparty-epm, ooo-3rdparty-hsqldb, etc. but I'm not sure if it helps > > in the end... > > this was what I was thinking about, just redistributing the 3rdparty > packages as single one to achive maximum modularity at that level. But the maximum modularity is achieved if the developers use the versions from their distros. I understand ooo-libs-3rdparty as a fallback for the developers that don't want to install the pieces; the ./configure would detect if there are 'system' versions of this or that, and build just the pieces that are not there. > If we > target the Windows developer I'd vote for a one click download again > (one really super tarball), otherwise people will go into an several > hour lasting "configure - missing dependency - download" circle. Well, considering that the binary compatibility of ooo-libs-3rdparty changes ~once in a year, I think it is worth having split even in the Win32 case. Regards, Jan - 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
Hi Martin, On Friday 12 October 2007 12:37, Martin Hollmichel 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. Yes, this is very tricky :-( For every module from ooo-libs-3rdparty we could have a single package, but I'm afraid it would make the granularity too fine. My vision is that on modern Linux distros, you won't need ooo-libs-3rdparty at all, because you will have all the packages in the distro already, and you'll be able to install them from there (most probably with the corresponding -devel packages). But for the Win32 builders, searching for the dependencies could be too expensive - that's why I propose the 'super-source-package' ;-) Of course, we can go the way of ooo-3rdparty-dictionaries, ooo-3rdparty-epm, ooo-3rdparty-hsqldb, etc. but I'm not sure if it helps in the end... Regards, Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOo source split
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? 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? Regards, Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOo source split
Jan Holesovsky schrieb: > Oh, sure! My original mail contains my suggestion of what belongs where - > please have a look, input is most appreciated. I did few corrections > afterwards (accessibility, bean, crashrep, and package moved to > ooo-apps-extensions, jut moved to ure, rvpapi removed, it's not used any > more). Yes, I already planned to have a look. I wish the day had more than 24 hours ... 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
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
Rüdiger Timm schrieb: > 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. Of course. As I understand it, the idea is to get more and better defined packages and the ability to rebuild only parts of them. Whether the code to build the packages comes from a single repository or not doesn't make a difference, so keeping one repository obviously is fine. But it should be possible to download only parts of the whole OOo source and build only the parts you want. > My feeling is we should first do some work on our code base so that be > really can benefit from a split. Absolutely. There are a few modules where we don't need this but over all the code base will be the limiting factor. 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
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, Martin 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 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] - To unsubscr
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
Hi Mathias, On Wednesday 10 October 2007 21:14, Mathias Bauer 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. Thank you for your support! > 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. Yes, definitely. If the libraries resulting from the split [svx was the most problematic, right?] are going to end up in different packages (eg. one in ooo-libs-core, and the other in ooo-apps-writer), then we have a light version of chicken-egg problem ;-) - split first the library, and then create the packages, or vice versa. OTOH, the split into more source packages is from my point of view easier to achieve, so I'd start there. [...] > 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? Fully agree :-) > 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. ;-) Oh, sure! My original mail contains my suggestion of what belongs where - please have a look, input is most appreciated. I did few corrections afterwards (accessibility, bean, crashrep, and package moved to ooo-apps-extensions, jut moved to ure, rvpapi removed, it's not used any more). As I said, I was able to build using this split (after having created an artifical module in each package containing the list of the packages in prj/build.lst), so... ;-) If you agree, I can setup experimental git repositories with all this so that others can play with it as well. Regards, Jan - 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
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
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]
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=dev&msgNo=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
Hi Ruediger, I am sorry, I missed a part of the mail when I was answering previously :-( 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." > 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. We have o3-build CD now; but our goal should be what the world outside uses - ./configure ; make ; make install, and ideally in each of the modules. ./configure in eg. ooo-apps-calc would just tell you "Sorry, you don't have ure, please build it first" if you don't have it yet. No need to go through tons of documentation to learn such a simple fact. [And of course - in the future it might very well happen that the user already has a sufficient version of URE in the system anyway ;-)] > > So - what do you think? ;-) ooo-l10n in the current proposal contains > > (in > > Personally, I do not like spitting up sources at all. But that's my very > personal opinion. I wonder why? ;-) We (OpenOffice.org) already distribute the sources split to binfilter, sdk, system, l10n and core, let's make the second step... > Besides this, I do not understand how your proposal could work (see > above). I hope I was clearer in the other mail to you; if not, I'll be happy to explain more. > 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? > > 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? Regards, Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOo source split
Hi Shaun, On Monday 08 October 2007 21:14, Shaun McDonald wrote: > > [...] And of course, the -noarch > > parts like the translations could be built just once for all > > architectures. > > Language packs are currently system specific. Thus building once for > all archs is not currently possible. This would require quite a lot > of rework, which I'd be very happy to see. > > Some info: > http://shaunmcdonald131.blogspot.com/2007/03/openofficeorg-language- > pack-revamp.html Well, I'm talking of _translations_, not language packs with their current OOo meaning. The translations are indeed -noarch, we already ship them in openSUSE 10.3 as such ;-) 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. Regards, Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOo source split
On 8 Oct 2007, at 13:57, Jan Holesovsky wrote: Hi, [...] And of course, the -noarch parts like the translations could be built just once for all architectures. Language packs are currently system specific. Thus building once for all archs is not currently possible. This would require quite a lot of rework, which I'd be very happy to see. Some info: http://shaunmcdonald131.blogspot.com/2007/03/openofficeorg-language- pack-revamp.html Shaun [...] - 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]
Re: [tools-dev] OOo source split
Jan Holesovsky wrote: Hi, Hi Jan, 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. 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 How should that work with your proposal? He would need everything 'below' calc. 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. 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 Personally, I do not like spitting up sources at all. But that's my very personal opinion. 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. 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. Following is the proposal what I think belongs where: [...] Ruediger - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOo source split
On Monday 08 October 2007 14:57, Jan Holesovsky wrote: > 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) Sorry, this contains even the filesystem overhead. Without it (counting just the file sizes) it's: 52M ure 17M ooo-bootstrap 107Mooo-libs-core 83M ooo-libs-guitoolkit 137Mooo-libs-3rdparty 12M ooo-apps-base 23M ooo-apps-calc 26M ooo-apps-extensions 11M ooo-apps-chart 35M ooo-apps-impress 33M ooo-apps-writer 14M ooo-artwork 83M ooo-filters 863Mooo-l10n 40M ooo-sdk 34M ooo-testing (1.6G total) Regards, Jan - 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]
