Re: [gtk-osx-users] Error when compiling gobject-introspection on macOS 10.13

[John Ralls <jralls ceridwen us>]

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