Using Alire, I'm attempting to follow the Scripts API instructions of the `GNATColl 22.0w documentation` Section 3.1.2, `The Python Language` which states that `Python support is optional in GNATColl`.
I can't figure out how to provide `GNATColl` with the optional Python support. Hence my instruction `with GNATCOLL.Scripts.Python;` fails.
No problem with `with GNATCOLL.Scripts;`
Please advise on how to provide `GNATColl` with the optional Python support.

Roger Mc <rogermcm2@gmail.com> writes:

> Using Alire, I'm attempting to follow the Scripts API instructions of
> the `GNATColl 22.0w documentation` Section 3.1.2, `The Python
> Language` which states that `Python support is optional in GNATColl`.
> I can't figure out how to provide `GNATColl` with the optional Python
> support. Hence my instruction `with GNATCOLL.Scripts.Python;` fails.
> No problem with `with GNATCOLL.Scripts;`
> Please advise on how to provide `GNATColl` with the optional Python
> support.

Unfortunately the Python3 binding in Alire doesn't work on macOS (ISTR
you use a Mac? always helpful to say what machine you're using!)

Should work on Debian/Ubuntu/Windows, not that that helps you a lot.

Mac OSX 13.0.1 (22A400)
XCode 14.1
gnat-x86_64-darwin-12.1.0-2

Thanks Simon,
I've just posted a query with gnatcoll_core as
alr get gnatcoll_python3 returns an error message.
I think the gnatcoll documentation is now out of date with respect to changes made by alire.
I've just updated my Mac to Ventura and consequently am fighting battles on many fronts.

Roger Mc <rogermcm2@gmail.com> writes:

> Mac OSX 13.0.1 (22A400)
> XCode 14.1
> gnat-x86_64-darwin-12.1.0-2
>
> Thanks Simon,
> I've just posted a query with gnatcoll_core as
> alr get gnatcoll_python3 returns an error message.
> I think the gnatcoll documentation is now out of date with respect to
> changes made by alire.

The trouble is that Alire hasn't been taught how to deal with
gnatcoll_python3.

The community index has, in gnatcoll_python3-23.0.0.toml,

+++++++++++++++
[environment.'case(distribution)']
"debian|ubuntu" = { C_INCLUDE_PATH.append = "${DISTRIB_ROOT}/usr/include/python3.7/:${DISTRIB_ROOT}/usr/include/python3.8/"}
msys2 = { C_INCLUDE_PATH.append = "${DISTRIB_ROOT}/mingw64/include/python3.10/" }

[available.'case(distribution)']
'debian|ubuntu|msys2' = true
'...' = false

[[depends-on]]
gnatcoll = "~23.0.0"
libpython3dev = "^3.10"
+++++++++++++++

and this has no support for macOS; specifically, the "'...' = false"
under "[available.'case(distribution)']" says it's only available on the
distributions named above.

In libpython3dev-external.toml, there is

+++++++++++++++
[[external]]
kind = "system"
[external.origin."case(distribution)"]
"debian|ubuntu" = ["libpython3-dev"]
msys2 = ["mingw-w64-x86_64-python"]
+++++++++++++++

which says e.g. that, if you're on debian, Alire is to use its package
manager (apt, I think) to check/fetch the package libpython3-dev.

Alire 1.3 will support Homebrew as the package manager for macOS, but
someone has to work out how to upgrade the above two items to use it
(and how to approach include, library paths; the ideal way would
probably be to use pkg-config to determine them, but the simplest way of
doing that would mean running a script from within gprbuild - not going
to happen.

Bear in mind that although Xcode 14 has /usr/bin/python3 it doesn't
support the -dev aspects, i.e. no includes and no libs, and so no
gnatcoll_python3.

> I've just updated my Mac to Ventura and consequently am fighting
> battles on many fronts.

There's an issue with GCC 12.1.0 & Ventura (macOS 13): that release of
GCC doesn't believe in macOS versions greater than 12 :-(

I'm pretty sure that this only affects C (and C++?) compilation.

You could try
export MACOSX_DEPLOYMENT_TARGET=12
- I haven't tried this yet.

The 12.2.0 versions I've just posted don't have _this_ problem!

Thanks Simon,

Thanks Simon,
I've pretty much given up on this until alire has a gnatcoll_python3 release for Mac.
I'm using gnat-x86_64-darwin-12.2.0-1 so don't have the "GCC doesn't believe in macOS versions greater than 12" problem and is also needed for compilation and building to work.
I've also given up on trying to get GNATstudio to work.
I think I've learnt enough now to know when to give up.
GPS 2019 is working fine as a GUI except for the menus which can be negotiated using the keyboard arrow keys.
I notice the X's and UX's in alire searches and have come across the alire list of crate statuses which is quite informative but not very easy to find.

Hi Simon,

I have not used alire myself, but I noticed the following in your message:

> Alire 1.3 will support Homebrew as the package manager for macOS, but
> someone has to work out how to upgrade the above two items to use it
> (and how to approach include, library paths; the ideal way would
> probably be to use pkg-config to determine them, but the simplest way of
> doing that would mean running a script from within gprbuild - not going
> to happen.

Although running external scripts from gprbuild is indeed unlikely, it is definitely in the realms of gprconfig (which is run first to generate the .cgpr config file).
For this one would need to provide some .xml file that explains what command to run, and what to generate in the .cgpr file (likely adding some `-I` compiler
switches for C files).

Emmanuel

Emmanuel Briot <briot.emmanuel@gmail.com> writes:

> I have not used alire myself, but I noticed the following in your message:
>
>> Alire 1.3 will support Homebrew as the package manager for macOS, but
>> someone has to work out how to upgrade the above two items to use it
>> (and how to approach include, library paths; the ideal way would
>> probably be to use pkg-config to determine them, but the simplest way
>> of doing that would mean running a script from within gprbuild - not
>> going to happen.
>
> Although running external scripts from gprbuild is indeed unlikely, it
> is definitely in the realms of gprconfig (which is run first to
> generate the .cgpr config file). For this one would need to provide
> some .xml file that explains what command to run, and what to generate
> in the .cgpr file (likely adding some `-I` compiler switches for C
> files).

Brilliant idea! Thanks, Emmanuel!

On Monday, November 21, 2022 at 8:45:08 AM UTC+1, briot.e...@gmail.com wrote:
> Although running external scripts from gprbuild is indeed unlikely, it is definitely in the realms of gprconfig (which is run first to generate the .cgpr config file).
> For this one would need to provide some .xml file that explains what command to run, and what to generate in the .cgpr file (likely adding some `-I` compiler
> switches for C files).

We are considering adding the feature to Alire directly. In particular an easy way to get relevant info from pkg-config.

Fabien Chouteau <fabien.chouteau@gmail.com> writes:

> We are considering adding the feature to Alire directly. In particular
> an easy way to get relevant info from pkg-config.

In the case of gnatcoll_python3, which already has
GNATCOLL_PYTHON_CFLAGS and GNATCOLL_PYTHON_LIBS environment vars, what
we need *for Homebrew* is to set the first to
pkg-config --cflags-only-I python3-embed
and the second to
pkg-config --libs-only-L python3-embed

Note the python3-embed! python3 on its own gives you no libs on
macOS. As far as I can tell this has been in Python since 3.8.

I did an experiment adding Homebrew to a new
gnatcoll_python3-23.0.1.toml and revised libpython3dev-external.toml,
and it successfully build a simple demo with the above environment
variables set externally.