Who's cross-compiling gnucash for Windows ?
jralls at ceridwen.us
Sun Sep 8 17:16:49 EDT 2013
On Sep 8, 2013, at 12:52 PM, Christian Stimming <christian at cstimming.de> wrote:
> 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
> Ok, I'm interested how they look like for gnucash :-)
Did you look? The github url takes you there.
>>>> 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
>>>> 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.
>> That's a "magic number". For those packages there should be two variables,
>> FOO_VERSION and FOO_BUILD, so the URI looks like:
> 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.
Ah, right, so we'd need FOO_VERSION, FOO_REVISION, and FOO_BUILD to make the URL.
That might be overcomplicating it a bit given the needs of the rest of the scripts.
More information about the gnucash-devel