GNOME Bugzilla – Bug 502970
Jhbuild should support building/running on windows
Last modified: 2021-05-17 15:49:20 UTC
If would be good for testing gtk+/glib if jhbuild supported building the stack on windows. The attached patches are the first attempt at getting this to work using the msys/mingw toolchain and environment
Created attachment 100734 [details] [review] Allow jhbuild to install on windows The attached patch lets jhbuild install using make -f Makefile.plain install. It is necessary because msys does not hav sys/wait.h for install-check
Created attachment 100735 [details] [review] Lets jhbuild download and unpack a tarfile This patch replaces use of wget with python's build in urllib library to download patches, modulesets and tarfiles. Also adds an option to disable the tray icon and various fixes to work around win32 limitations
Shouldn't the tray icon be forcefully disabled if it causes problems ?
Also, I would prefer sth like if sys.platform.startswith('win') instead of handling the AttributeError exception in defaults.jhbuildrc.
Created attachment 100827 [details] [review] w32 support patch v1 Combined patch, supercedes other patches and Alberto Ruiz native unpack patch. This is a diff against head generated from my bzr branch. More information can be found here http://www.johnstowers.co.nz/blog/index.php/2007/12/11/jhbuild-adventures-on-windows/ http://www.johnstowers.co.nz/blog/index.php/2007/12/13/jhbuild-and-windows-we-meet-again/
bzr Branch (because I didnt generate the patch correctly) http://www.gnome.org/~jstowers/bzr/jhbuild-win32
Could this be separated in different patches, with proper ChangeLog entry for each of them ? It would be much easier for me to apply them that way, and better for long term history.
Absolutely, I will generate a propper patch series from my bzr branch when I am more confident that this approack can actually solve the problem.
Updated status report here: http://www.johnstowers.co.nz/blog/index.php/2007/12/16/jhbuild-anything-on-windows-in-12-steps/
Hello! I've been working on this problem off and on for a while because I have been using jhbuild to manage my app's numerous dependencies on Win32. Recently I've decided to reintegrate all of these hacks into some proper branches in git so my branch can track master more easily. So far I have some of John Stower's code in gitorious: http://gitorious.org/jhbuild/jhbuild/commits/win32-fixes This is enough for all the unit tests to pass but not a lot else. I'm posting this ramble to find out how likely it is for any of this stuff to be merged into mainline jhbuild, because if it's going to be a seperate branch for ever I can be a bit lazier :) Basically what's I've got is: * general win32 fixes, including John Stowers' work etc. * bootstrap-win32 moduleset, which involves a *lot* of ugly hacks, and some supporting patches * the infamous binary module type, and a few other features which make jhbuild useful as a mini package-tracker .. of course binary modules are managed by the system on a sane OS but it's not a huge effort for jhbuild to emulate this on windows. * patch state tracking, so tarballs are rebuilt if you change patches for them and useful things like that (mostly helpful to me while I was patching all sorts of things to make them work on win32, but I don't see why it's not useful generally) Almost all of this is still in my stale bzr branch and it will be some work to pull it all into git. Like I said I'm just after a general idea of if it's worth my time filing bugs/patches/pull requests for any of these (I understand some are quite major) or if you want to keep gnome.org/jhbuild purely as something builds GNOME and related things on *NIX. I'm happy to maintain a fork if necessary, but if I am going to be maintaining a fork there are various extra liberties I can take with the code, so it would be nice to know ... Sorry if this wasn't really appropriate as a bugzilla comment, I couldn't find a relevant mailing list :) Thanks for reading!
It sure is appropriate; as I noted in an earlier comment, having separate feature patches is the best way to get them in. > Basically what's I've got is: > * general win32 fixes, including John Stowers' work etc. I believe I already incorporated many (using Python modules for downloading and unzipping comes to mind), anything of that nature could go in. > * bootstrap-win32 moduleset, which involves a *lot* of ugly hacks, and some > supporting patches Modulesets (and associated patches) can live out of jhbuild tree (as it is already the case for gstreamer, sugar, moblin); especially when there are ugly hacks within :) > * the infamous binary module type, and a few other features which make jhbuild > useful as a mini package-tracker .. of course binary modules are managed by the > system on a sane OS but it's not a huge effort for jhbuild to emulate this on > windows. I am still very reluctant about this, especially when used for modules that are normally built from sources. > * patch state tracking, so tarballs are rebuilt if you change patches for > them and useful things like that (mostly helpful to me while I was patching > all sorts of things to make them work on win32, but I don't see why it's not > useful generally) This could certainly go in.
I was going to file bugs for each patch but most of these patches are trivial. I have filed two new bugs: one before I realised there was no point and another because it's a big patch. Other three patches are attached below.
Created attachment 135101 [details] [review] patch for use of 'uname' on win32 Wraps call to 'uname' in try..except block, because uname doesn't exist on win32
Created attachment 135102 [details] [review] disables tray icon on win32 Adds 'notrayicon' config option, and makes nonotify and notrayicon default to True on windows.
Created attachment 135103 [details] [review] prevents c:/.. moduleset paths being treated as URI's uri's of the form x:/ are treated as paths on win32.
Created attachment 135108 [details] [review] fixes use of /dev/null in tests.py uses 'NUL' instead of '/dev/null' when tests are running on win32
> patch for use of 'uname' on win32 Applied mostly as is (0298a7696a50054b7723e16fb1dd455368c4ba69) > disables tray icon on win32 Applied after obvious fix (config was not passed to TrayIcon) (bb60bd49f50cdbe83ef1db67adcc4d3bc5bb8262) > prevents c:/.. moduleset paths being treated as URI's Rewritten (6a8797506b8f8f3d92669cc0063b2d9818a3b9a0) so it works for all callers of httpcache.laod(), please test it. > fixes use of /dev/null in tests.py Applied as is (08d2dd26466498cc1b0a8272c531c8ca17acbbb8)
Good to see someone come along and continue working on this! Personally I still believe the binary module stuff was one of the most useful things I did. Building on windows through cygwin is so painfully snow (sh's fault IIRC) the binary module stuff made it bearable.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/jhbuild/-/issues/94.