After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 502970 - Jhbuild should support building/running on windows
Jhbuild should support building/running on windows
Status: RESOLVED OBSOLETE
Product: jhbuild
Classification: Infrastructure
Component: general
3.0.x
Other Windows
: Normal enhancement
: ---
Assigned To: Jhbuild maintainers
Jhbuild QA
Depends on: 499497 503679
Blocks:
 
 
Reported: 2007-12-11 02:56 UTC by John Stowers
Modified: 2021-05-17 15:49 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Allow jhbuild to install on windows (1.28 KB, patch)
2007-12-11 02:58 UTC, John Stowers
none Details | Review
Lets jhbuild download and unpack a tarfile (10.70 KB, patch)
2007-12-11 03:00 UTC, John Stowers
none Details | Review
w32 support patch v1 (39.73 KB, patch)
2007-12-12 12:57 UTC, John Stowers
none Details | Review
patch for use of 'uname' on win32 (1.06 KB, patch)
2009-05-21 14:29 UTC, Sam Thursfield
committed Details | Review
disables tray icon on win32 (3.27 KB, patch)
2009-05-21 14:30 UTC, Sam Thursfield
reviewed Details | Review
prevents c:/.. moduleset paths being treated as URI's (926 bytes, patch)
2009-05-21 14:31 UTC, Sam Thursfield
reviewed Details | Review
fixes use of /dev/null in tests.py (526 bytes, patch)
2009-05-21 14:43 UTC, Sam Thursfield
reviewed Details | Review

Description John Stowers 2007-12-11 02:56:43 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
Comment 1 John Stowers 2007-12-11 02:58:34 UTC
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
Comment 2 John Stowers 2007-12-11 03:00:23 UTC
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
Comment 3 Frederic Peters 2007-12-11 14:24:30 UTC
Shouldn't the tray icon be forcefully disabled if it causes problems ?
Comment 4 Frederic Peters 2007-12-11 14:28:56 UTC
Also, I would prefer sth like if sys.platform.startswith('win') instead of handling the AttributeError exception in defaults.jhbuildrc.
Comment 5 John Stowers 2007-12-12 12:57:18 UTC
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/
Comment 6 John Stowers 2007-12-12 12:59:47 UTC
bzr Branch (because I didnt generate the patch correctly)

http://www.gnome.org/~jstowers/bzr/jhbuild-win32
Comment 7 Frederic Peters 2007-12-12 13:02:29 UTC
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.
Comment 8 John Stowers 2007-12-12 13:10:50 UTC
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.
Comment 10 Sam Thursfield 2009-05-20 21:35:23 UTC
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!
Comment 11 Frederic Peters 2009-05-20 21:49:42 UTC
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.
Comment 12 Sam Thursfield 2009-05-21 14:28:03 UTC
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.
Comment 13 Sam Thursfield 2009-05-21 14:29:14 UTC
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
Comment 14 Sam Thursfield 2009-05-21 14:30:29 UTC
Created attachment 135102 [details] [review]
disables tray icon on win32

Adds 'notrayicon' config option, and makes nonotify and notrayicon default to True on windows.
Comment 15 Sam Thursfield 2009-05-21 14:31:43 UTC
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.
Comment 16 Sam Thursfield 2009-05-21 14:43:39 UTC
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
Comment 17 Frederic Peters 2009-05-21 17:51:06 UTC
> 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)
Comment 18 John Stowers 2009-05-25 20:21:05 UTC
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. 
Comment 19 GNOME Infrastructure Team 2021-05-17 15:49:20 UTC
-- 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.