[gdal-dev] How to build py-gdal using the C++ compiler

[Ryan Schmidt]

On Jun 18, 2020, at 12:09, Chris Marsh wrote:

> I note you commented on the setuptools issue here
> https://github.com/pypa/setuptools/issues/1732
> 
> but there is also this earlier post
> https://github.com/pypa/setuptools/issues/1192

Thanks, I hadn't seen that one.


> From what I can tell, I agree that CXXFLAGS aren't explicitly handled by setuptools and it uses gcc/clang instead of the ++ variants. I see clang++ being used for the link invocation though.
> However, either gcc/g++ can be used to compile c++ as code, as long as with gcc the c++ libraries are linked against (which seems to be done correctly). So other than the CXXFLAGS being ignored, it's perhaps not that big of a problem (ie, it's still a C++ compiler at the end of the day https://gcc.gnu.org/onlinedocs/gcc/Invoking-G_002b_002b.html)
> 
> I'll use the pygdal example (the one I linked above) as it uses setuptools
> 
> If I do 
> CC=clang++ CXXFLAGS='-std=c++11 -stdlib=libc++' pip -v install --force-reinstall  pygdal=="`gdal-config --version`.*"
> 
> it fails to compile due to C++11 not being enabled
> 
> If I do
> CC=clang++ CFLAGS='-std=c++11 -stdlib=libc++' pip -v install --force-reinstall  pygdal=="`gdal-config --version`.*"
> 
> then it works as expected and it uses clang++ throughout in the log file.
> 
> My read is:
> -I don't think this is a GDAL specific problem but a disutils/setuptools quirk. 

That's what I suspect and GDAL is not the only Python extension with which I am seeing this type of problem. But I've been watching the distutils bug report about this problem* for a long time, waiting for it finally to be resolved. Well now it's fifteen years old and apparently will never be resolved. Before I wait another fifteen years for the setuptools developers to get around to deciding whether to fix this, and possibly then telling me that it's not a setuptools bug after all but something the project is doing wrong in its setup files, I thought I'd ask here. But it sounds like nobody here has really thought about it before because it worked well enough for them so I'll go back to waiting for the setuptools developers to respond.

* https://bugs.python.org/issue1222585


> - It seems using CFLAGS=$CXXFLAGS would be sufficient to work around the setuptools/distutils behaviour, but that may not be possible with macports/your build env. 

It's really not satisfactory.

I'm not comfortable modifying the way that MacPorts compiles *all* Python extensions (even those that aren't written in C++) to use the C++ compiler and CXXFLAGS instead of the C compiler and CFLAGS. I'm not sure what consequences that might have. And I'm not very interested in analyzing the thousands of Python extensions in MacPorts to determine which are written in C++ and modifying their Portfiles for this hack manually.

Some extensions are written partly in C and partly in C++. The build system must arrange for the correct compiler and flags to be used when compiling each file. Anything else is madness. One such extension is libsass and its setup scripts do somehow force the use of the C++ compiler instead of the C compiler for all files. This results in warnings when compiling the C files: "clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated [-Wdeprecated]" This signifies to me that the build system is doing something wrong.

If it really is a bug in setuptools, as I suspect it is, the focus should be on getting that fixed, not working around it.