GNOME Bugzilla – Bug 131296
Allow separate build directory from checkout directory
Last modified: 2005-10-24 07:16:32 UTC
This is a simple RFE for jhbuild. I tend to keep my Gnome checkout on a partition of 2GB, which doesn't have too much room to spare. Besides, I prefer to keep the checkout clean, since I am a Gnome translator, and do checkins throughout, so this reduces the risk of messing something up with my local (possibly hacked) copies. The following patch adds buildroot parameter, but it's incomplete (it does so only for the CVSModule class, not for other Package-derived classes), and it lacks a bit (a lot?) of polish. It works for me, though I'm not quite positive about the "cp" command I used (the idea is to follow symlinks, and overwrite everything in the build directory with newer stuff; perhaps one should do "rm" prior to that). The idea is to add another state: STATE_COPY. This simplifies code in some other places (do_start, do_checkout) because they share the same code which is now in do_copy. Of course, I could have done something simpler (just inserting verbatim cp and doing a chdir by hand), but my goal is to get this into jhbuild, so I don't have to worry about keeping up patches. Of course, if idea is accepted, I'd work on extending patch to work for MozillaModule, tarballs, etc. Any other suggestions are welcome as well.
Created attachment 23293 [details] [review] Add "buildroot" parameter where build is actually performed instead of in checkoutroot (only for CVSModule atm)
When you first mentioned this, I thought you were talking about doing srcdir!=builddir builds. This entails something like this: mkdir foo /path/to/checkout/foo/configure ... Which might give a pristine srcdir, if it works :) What reasons are there for a copy instead of this?
autogen.sh must be done in the real checkout dir, which conflicts with the goal of keeping them clean -- you can't even do a "make distclean" there, because you don't have Makefile. Yes, I thought of calling configure from someplace else, but it doesn't what it takes. And btw, how would one run "./configure" in a separate directory, without modifying autogen.sh first (or gnome-autogen.sh from, I think, gnome-common), which defaults to running it itself: this would mean making jhbuild know about aclocal, automake, autoconf, and all the other stuff. Also, some modules don't use gnome-autogen.sh, so there should be more per-module changes. Another btw, lot of modules do not build, or pass configure stage at the very least, if this approach is used. (I know my build system sucks somewhat, but) I get problems with certain Makefile.in's not being found if I try it this way (I tried with gedit and gtksourceview). I remember I have tried this earlier by hand, and didn't have too much luck if package was not specifically advertised to be buildable from another directory (like, Emacs). So, those are the reasons for a copy instead of that ;) In fact, it's easier to do what you propose, because one would have to change only couple of lines in do_configure, do_build to os.chdir to some other directory, and use correct path for the directory, so if you feel like trying (my build system is based around Slackware 8.0, with automake, autoconf, libtool all updated by hand to latest versions, so that may be the problem I'm having with that approach), and it works, that would be great as well.
Created attachment 24436 [details] [review] Updated patch for reorganized jhbuild; supports tarballs (tested) and Mozilla builds (untested) as well
Sorry for not getting back to you earlier. For most of the packages in CVS, you can do a srcdir!=builddir simply by running autogen.sh in a different directory. For example: cd gtk+ mkdir build cd build ../autogen.sh --prefix=/opt/gnome ...
James, I'm aware of what you're thinking about (autoconf features), but this doesn't always work (it's easy to use relative or absolute paths in eg. Makefile.am, which don't reference top_srcdir or something, what sometimes makes building outside real srcdir fail). The good side of that approach would be that we'd find out which packages have problems with that way of building, so we might fix them. So, I'll provide later much simpler patch that will work that way (I hope to get to that tommorow morning). Also, it doesn't completely follow the rule of "don't touch real srcdir": automake --add-missing adds all the links to mkinstalldir, install-sh and similar in the source dir, instead of the build dir. Likewise, autoconf creates "configure" script in the real source directory (obviously, since we're talking about autoconf feature here, and it's usable only once "configure" is there); intltoolize adds intltool-*.in scripts. (All these are reasons why I opted for copying, instead of this simpler [to implement] approach: building a copy works if it worked otherwise; it's simple to "prove formally" that it doesn't touch anything at all in CVS checkout ;)
This probably won't be implemented. We support the standard form of srcdir!=builddir builds, which is enough.