On Sep 6, 2013, at 5:05 AM, Christian Stimming <[email protected]> wrote:
>> On Sep 5, 2013, at 2:07 PM, Geert Janssens <[email protected]> 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 _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
