Who's cross-compiling gnucash for Windows ?
christian at cstimming.de
Fri Sep 6 08:05:13 EDT 2013
> 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
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 :-)
> 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
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.
> set_default GCONF_URL
> set_default GTK_URL
> set_default LIBGSF_URL
> set_default LIBSOUP_URL
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.
More information about the gnucash-devel