Who's cross-compiling gnucash for Windows ?

John Ralls jralls at ceridwen.us
Fri Sep 6 10:17:33 EDT 2013


On Sep 6, 2013, at 5:05 AM, Christian Stimming <christian at cstimming.de> wrote:

>> On Sep 5, 2013, at 2:07 PM, Geert Janssens <janssens-geert at telenet.be> wrote:
>>> mingw-get is not compatible with a cross-compilation environment
>>> however. So I was wondering how many people are actually building
>>> gnucash for Windows via a cross-compiler ?
>>> 
>>> My current impression is that the cross-compilation set up has slowly
>>> been gathering dust. I may be wrong though. Hence the query...
> 
> I've been running a gnucash cross-compile on my Linux box from time to time, but not for reaching an actual distribution package. The point is (or: was) that running the gnucash build cross-compile on a Linux host is significantly faster than running it natively with mingw on a windows host. In numbers: Running "install.sh" cross-compile with a Linux host (ubuntu, mingw32 tools from apt-get) takes approx. 2-3 minutes with building everything (!) from scratch, including libgoffice, aqbanking, and whatever. On Windows this takes several hours.
> 
> But I didn't use the result for anything else except verifying that there a no mingw compiler errors.
> 
>> Great! It would be nice to get it working with more recent versions of MinGW.
>> 
>> Cross-compilation implies that it's on a system with working Python, so one could
>> use jhbuild... in which case, why use the rather clunky shell scripts?
> 
> Are you volunteering to write jhbuild configuration files for a whole build of gnucash? This sounds like a lot of work to me. If you're up to it, don't hesitate to do it, though :-)

https://github.com/jralls/gnucash-on-osx/modulesets ;-)

Writing modules is actually *really* easy, and 99% of them are already provided by https://git.gnome.org/browse/jhbuild/tree/modulesets  and https://git.gnome.org/browse/gnome-modulesets/

> 
>> BTW, while trying to build on Win7 the last couple of days I noticed that the versions
>> of the various packages are scattered about along with their download URLs. I think
>> it would be nicer if they were in their own block near the top of defaults.sh.
> 
> No, I don't think this would be an improvement for all cases. In the majority of URLs, some part of the version number appears as well. Examples:
> 
>> set_default GCONF_URL  "$GNOME_WIN32_URL/GConf/2.22/GConf_${GCONF_VERSION}-3_win32.zip"
>> set_default GTK_URL    "$GNOME_WIN32_URL/gtk+/2.24/gtk+_${GTK_VERSION}-1_win32.zip"
>> set_default LIBGSF_URL "$GNOME_MIRROR/sources/libgsf/1.14/libgsf-${LIBGSF_VERSION}.tar.bz2"
>> set_default LIBSOUP_URL "$GNOME_WIN32_URL/libsoup/2.26/libsoup-${LIBSOUP_VERSION}-1_win32.zip"
> 
> For all those cases, the URL and the VERSION variable need to be kept together, otherwise you'll end up changing only the VERSION without paying attention to the URL that might need changes as well. Hence, I'd rather prefer to have the VERSION variables right next to the URL, as it is now.


That's a "magic number". For those packages there should be two variables, FOO_VERSION and FOO_BUILD, so the URI looks like:
"$GNOME_WIN32_URL/GConf/2.22/GConf_${GCONF_VERSION}-${GCONF_BUILD}_win32.zip"

Regards,
John Ralls




More information about the gnucash-devel mailing list