Who's cross-compiling gnucash for Windows ?

[Christian Stimming]

Am Freitag, 6. September 2013, 07:17:33 schrieb John Ralls:
> >> 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/

Ok, I'm interested how they look like for gnucash :-)

> >> 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. 
>
> > 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.zi
> p"

I don't think your comment touched the actual point I was trying to make. My 
point was that the URL contains the "2.22" sub-directory, which of course is 
valid only for 2.22.x versions, but not for 2.24.x or others. The build 
number, on the other hand, is completely uninteresting in the rest of the 
build scripts, which is why I just hard-coded it into the URL. Only the 
version number itself is used later for verification of the correctly 
installed library. If the build number should appear as a variable, it can be 
done, but surely this doesn't make things much clearer compared to right now. 
But my point was about the directory paths, which contain part of the version 
number in the mentioned cases.

Regards,

Christian