On Thu, May 21, 2009 at 20:28, Bernie Innocenti <ber...@codewiz.org> wrote: > On 05/21/09 10:03, Tomeu Vizoso wrote: >>> 1) Stop checking out random unstable versions of external projects. >>> They break very often, and we cannot fix them. Let's instead upgrade >>> manually every once in a while after some testing. >> >> We are supposed to be doing this already, which modules are not >> following this rule? > > I'm looking at the glucose-external.modules, and I see these modules > being checked out from the tip of the master branch: > > - squeak > - hulahop > - hippo-canvas > > >>> 2) Do not build C modules that is already available (and recent enough) >>> in popular distros. Specifically: abiword, matchbox, hippocanvas... >> >> About abiword, we have been depending lately on modifications not >> released on a tarball, but 2.7.0 was released recently and it should >> contain all we need for now. If during 0.85 we need to hack further on >> it, we may need to create unstable tarballs ourselves. Also, not all >> distros are building it a way it can be used by Sugar, we should >> check. > > And besides, abiword 2.7.0 is not yet in F11 nor Jaunty. > > >> About hippo, we are the only users, so it can be considered as any >> other Sugar module. > > Ok, but it's already packaged in all the distros we target, so why make > people spend precious time building it from source?
As with any other sugar module, people want to run the latest code because it will contain bugfixes, etc. I see hulahop in the same way. >> About xulrunner, we often want to test with the version that is going >> to ship on the next distro releases, plus some distros still don't >> package it in a way usable by Sugar (we should fix this). > > xulrunner now fails to build with gcc 4.4 (in F11) because of a tiny > error in an #elif directive. Is there a way in jhbuild to apply patches > to sources? Yeah, we may be doing it still in some modules. > xulrunner is also one of the worst compile time hog we have. If we > could only build it on distros that require it, it would save a lot of > trouble to a lot of developers. > > I'd vote for disabling it now and lazily wait to see if someone > complains before actually adding a workaround. No need to do that for all users, we can do it distro by distro. I think that each distro in jhbuild should have its maintainer, as Sascha cannot run all of them. >>> 3) Let's move etoys away from the base set of components: the repository >>> is often offline, building it breaks very often, and it takes a lot of >>> time. You don't need it in order to test Sugar, the same way you don't >>> need TamTam and TurtleArt. >> >> I guess this makes sense, though would be good to hear people who hack >> on eToys in Sugar. > > Ok, although this shouldn't impair them in any way. We just move etoys > to a module that regular users don't have to build by default. Fine with me. >>> 4) We could check for prerequisites before starting the build. Some >>> configure scripts are stupid enough to fail tests silently and proceed >>> anyway using "no" as a command name in make :-) >> >> We are supposed to be doing this already. If it's not working then we >> should fix it. > > It's definitely not working, because we had to manually find out what > was missing along the way. Do you have any idea where I should look? Grep for depscheck, though it's an expensive process and may not be fun to have it run at every jhbuild invocation. >>> If there's consensus on implementing one or more of these points, I can >>> provide patches (or just go on and commit them). >> >> Totally, Sascha is the maintainer so coordinate with him. > > OK. Also, maybe what we need is better documentation rather than big changes that bring new problems? Regards, Tomeu > -- > // Bernie Innocenti - http://codewiz.org/ > \X/ Sugar Labs - http://sugarlabs.org/ > _______________________________________________ Sugar-devel mailing list Sugarfirstname.lastname@example.org http://lists.sugarlabs.org/listinfo/sugar-devel