You shouldn't build each module in a separate run of jhbuild, it stops jhbuild from optimizing the dependencies. Just do:
jhbuild bootstrap && jhbuild meta-gtk-osx-bootstrap meta-gtk-osx-core python geany openssl
You don't need to worry about the order of the modules either.
Openssl is in there because the last I checked Apple doesn't provide the openssl headers (they actually use libressl, but the APIs are identical) and so python doesn't build hashlib.
Regards,
John Ralls
> On Jan 26, 2018, at 10:48 AM, Jiří Techet <techet gmail com> wrote:
>
> Hi John,
>
> I'd personally go for the second (simpler) option - building python as part of bootstrapping. I've been using
>
> jhbuild bootstrap && jhbuild build python && jhbuild build meta-gtk-osx-bootstrap && jhbuild build meta-gtk-osx-core
>
> for the last few releases of Geany and it works fine for me. Alternatively it could be documented that users have to run the above but doing it directly in bootstrap is nicer.
>
> Best regards,
>
> Jiri
>
>
>
> On Sun, Jan 14, 2018 at 10:24 PM, John Ralls <jralls ceridwen us> wrote:
>
>
> > On Sep 16, 2017, at 1:04 PM, Jiří Techet <techet gmail com> wrote:
> >
> > Just check the backtrace from the first email - there's no C involved. The error message comes from
> >
> > /System/Library/Frameworks/Python.framework/Versions/2.7/ lib/python2.7/distutils/spawn. py
> >
> > Jiri
> >
> > On Sat, Sep 16, 2017 at 9:53 PM, John Ralls <jralls ceridwen us> wrote:
> >
> > > On Sep 16, 2017, at 12:44 PM, Jiří Techet <techet gmail com> wrote:
> > >
> > > Hi John,
> > >
> > > at least from the backtrace it doesn't seem to happen when linking libpython but rather when running preprocess() from
> > >
> > > https://docs.python.org/2/distutils/apiref.html
> >
> > Huh. That's odd, there's no reason that should care about deployment target. You're sure it's using /usr/bin/python, not linking libpython and calling distutils.preprocess() from C?
>
> Jiri,
>
> Sorry for forgetting about this thread.
>
> We're both wrong, of course. The preprocess function runs cpp, the C preprocessor, on the file. That does everything starting with # in the file: Composes the compilation unit with #include, selects code blocks in #if..#else...#endif, and runs all of the preprocessor macros including MAC_OS_X_MIN_SUPPORTED and MAC_OS_X_MAX_ALLOWED, hence the failure.
>
> But looking through giscanner/ccompiler.py I see that it also has a compile function that does exactly what one would expect. That will also get tripped up by MAC_OS_X_MIN_VERSION/MAX_ALLOWED.
>
> So either work up a generic patch for ccompiler.py that figures out if there's a mismatch between the MACOSX_DEPLOYMENT_TARGET set for building the library and the one used by python or just build python as part of bootstrapping your build environment.
>
> Regards,
> John Ralls
>
>