GNOME Bugzilla – Bug 503679
[PATCH] Add binary modtype
Last modified: 2010-07-04 05:25:06 UTC
For the jhbuild on win32 work (#502970) I would like to be able to install 'binary' modules such as Tor's pre-packaged win32 zip files [1] of iconv,gettext and pkg-config (to avoid circular dep build pain). Attached is the 'binary' module type which allows this to be done. Its like a tarball modtype but instead of running ./configure make make install the user can specify their own scripts to run at these stages. Because the binary mod type can also depend/be depended on, it can also provide a way arbitarily execure scripts before/after/on installed modules (because not everything can be solved with a patch file). See #488111 for a discussion on how this approach could be used to install distro dependant packages. Example of use: <binary id="testbin" version="1.2.4"> <source href="http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/expat-2.0.0.zip"/> <configure> <cmd execute="['ls', '-la', '@@SRCDIR@@']"/> </configure> <build> <cmd execute="['ls', '@@PREFIX@@']"/> </build> <install> <cmd execute="['cp', '--recursive', '@@SRCDIR@@/*', '@@PREFIX@@/']"/> </install> <dependencies> <dep package="testscript"/> </dependencies> </binary> <binary id="testscript" version="0.0.9"> <install> <cmd execute="['mkdir', '@@SRCDIR@@/foo']"/> <cmd execute="['touch', '@@SRCDIR@@/foo/bar']"/> </install> </binary> [1] http://www.gimp.org/~tml/gimp/win32/downloads.html
Created attachment 100983 [details] [review] Adds binary modtype
Sorry but I don't like this, JHBuild purpose is building sources, not installing binary packages. If you want to use system packages for some modules, there is support via the "skip" configuration variable.
Sorry, I should have posted this first The full context of this is addressed here http://www.johnstowers.co.nz/blog/index.php/2007/12/16/jhbuild-anything-on-windows-in-12-steps/ Basically its most (only) useful on windows, for mixing in precompiled binaries/developer libs into a build (to save time, and to make it easier for folks) I dont really agree that its the right approach for solving the distro bug, I just thought it was neat that it could be used to do so.
I know about the context, I had read your post before, but it doesn't change my opinion. You may be interested in the suggestion in my comment of bug 488111, this approach would probably also work in your situation.
Oh, I posted that particular post after you closed this bug. Never mind I guess.
Oh I was talking about the general context, I have been following your progress with interested eyes; I don't want to work against your goal, I just believe some things are out of scope for JHBuild (I myself maintain a seperate branch for features such as automatically building Debian packages). Also I really believe you could achieve simplicity through the way described at the bottom of bug 488111. See comment #8 of bug 419879 for an example of module overriding.
Ok, putting the distro packages thing aside for a second, as that wasnt the goal of this patch. I have read all of bug 488111 and understand how "make install calling scripts to do what you want." can achieve the same thing as this. I think that implementation is better for the case of (at least) Tor's and gnuwin32 project zip files because all the knowledge about the layout of a zip file (i.e how it unzips and what files install to where) can be described in the modules file, giving a single place which to maintain them. The alternative implementation described by bug 488111 seems convoluted as it requires; 1) Download the zip file, checkout to a fresh dir (because tors zip files unzip into the current dir). Other zip files have even more random layouts which they unzip to. 2) Download a 'patch' that contains a shell autotools project such that ./configure --prefix writes the correct prefix into a Makefile 2b) It might be possible to instead just download a makefile and pass --prefix=foo to it via makeargs, but I digress. 3) Let the normal make step install the files from the random zip file to the correct jhbuild prefix or 1) Preconvert all the zip files to autotools projects so that the normal ./configure make make install does the right thing. Yes executing arbitary command line actions is ugly, <cmd execute="['cp', '--recursive', '@@SRCDIR@@/*', '@@PREFIX@@/']"/> But it is one line which is maintained in one place, compared with maintaining specialist autofoo/makefiles/patches to make the zips do what I want, and unzip where I want them to. Trust me, I really did try to do this within the tarball/repo framework, but It was just too much work.
bah, should have read "I think that -->this<-- implementation is better...."
Sam Thursfield has continued on this work, using the binary module type to build gtk+ etc on windows; http://afuera.me.uk/jhbuild-windows/