Globing paths on #cgo directives

[Gustavo Niemeyer]

Hello all,

Some projects use version numbers in include paths. At the moment,
this forces Go packages to use unfortunate settings such as:

// #cgo CPPFLAGS: -I/usr/include/qt5/QtCore/5.0.1/QtCore
// #cgo CPPFLAGS: -I/usr/include/qt5/QtCore/5.0.2/QtCore
// #cgo CPPFLAGS: -I/usr/include/qt5/QtCore/5.1.1/QtCore
// #cgo CPPFLAGS: -I/usr/include/qt5/QtCore/5.2.0/QtCore
// #cgo CPPFLAGS: -I/usr/include/qt5/QtCore/5.2.1/QtCore

Can we add support for something like:

// #cgo CPPFLAGS: -I/usr/include/qt5/QtCore/5.*/QtCore

This would duplicate the given parameter for every match of the glob,
assuming an absolute path is found as a suffix.

How does that sound?


gustavo @ http://niemeyer.net

[Aram Hăvărneanu]

What's wrong with pkg-config?

[Russ Cox]

[again, replying all]

Right now the #cgo extras are passed directly to the command line tools
(the C++ compiler in this case). I would really like to avoid any
interpretation by any of the Go software. This one thing may or may not be
reasonable but it opens the door to many more.

As Aram points out, we do have pkg-config support.

Russ

[Gustavo Niemeyer]

Post by Russ Cox
As Aram points out, we do have pkg-config support.

pkg-config doesn't work in this case, because the path is not part of
the provided flags. The short story is that these headers are
considered private by the project, except not entirely private.
There's no way to create extensions such as Go Qt/QML (or Python
Qt/QML, etc) without including just one or two things from these
headers. Talking to the upstream, they agree it's fine for Go QML to
use these, but they don't want to expand to general applications. So
I'm stuck between Go not supporting including the headers easily, and
Qt not wanting to offer the headers on pkg-config.

For the moment I'll continue to include a long list of includes for
all versions people happen to use in the many distributions, which
isn't great, but at least gets people the out-of-the-box experience.
Would be nice to have a hand from the go tool here.


gustavo @ http://niemeyer.net

[Russ Cox]

Great. I was going to say that the case for changing cmd/go is even weaker
since this is a one-off due to a badly configured project.

[Gustavo Niemeyer]

Reading through the documentation of cpp, the #include directive
allows the included content to be computed, which I wasn't aware of.
So I can do something like this:

#include QT_PRIVATE_INCLUDE(QtCore,qobject_p.h)
#include QT_PRIVATE_INCLUDE(QtCore,qmetaobject_p.h)

And compute the include as such:

https://gist.github.com/niemeyer/b1ed9144a12fcbfd39ca

Works, so it's all good. Thanks and sorry for the noise.

Post by Gustavo Niemeyer

Post by Russ Cox
As Aram points out, we do have pkg-config support.

pkg-config doesn't work in this case, because the path is not part of
the provided flags. The short story is that these headers are
considered private by the project, except not entirely private.
There's no way to create extensions such as Go Qt/QML (or Python
Qt/QML, etc) without including just one or two things from these
headers. Talking to the upstream, they agree it's fine for Go QML to
use these, but they don't want to expand to general applications. So
I'm stuck between Go not supporting including the headers easily, and
Qt not wanting to offer the headers on pkg-config.
For the moment I'll continue to include a long list of includes for
all versions people happen to use in the many distributions, which
isn't great, but at least gets people the out-of-the-box experience.
Would be nice to have a hand from the go tool here.