db-browser-for-sqlite blacklists clang < 800

[ryandesign (Ryan Carsten Schmidt)]

db-browser-for-sqlite blacklists clang < 800 with this remark:

# Qt's C++11 test seems more stringent than MacPorts ??
# /opt/local/libexec/qt5/lib/QtCore.framework/Headers/qcompilerdetection.h:562:6:
#    error: Qt requires a C++11 compiler and yours does not seem to be that.
compiler.blacklist-append {clang < 800}

I don't think this is necessary. Think the real problem is that that particular invocation of the compiler has neglected to specify -std=c++11 so the compiler has used its older default C++ mode. The solution would be to specify -std=c++11 everywhere. Ideally the developers would fix this problem in their build system but until they do it should be solvable by adding configure.cxxflags-append -std=c++11 to the portfile instead of blacklisting older clang. Then the compiler_blacklist_versions portgroup can be removed from the portfile as well.

[cjones051073 (Chris Jones)]

The above suggestion is not enough as it appears that appending to the cxxflags flags does not propagate to the options used by the build. See the attached log, which I created testing the patch in

​https://github.com/macports/macports-ports/pull/7217

on my 10.9 VM. i.e. it still gives

:info:build /opt/local/libexec/qt5/lib/QtCore.framework/Headers/qcompilerdetection.h:562:6: error: Qt requires a C++11 compiler and yours does not seem to be that.
:info:build #    error Qt requires a C++11 compiler and yours does not seem to be that.
:info:build      ^

Also note, later on there are warnings like

:info:build ld: warning: directory not found for option '-L/usr/local/opt/sqlite/lib'
:info:build ld: warning: directory not found for option '-L/usr/local/lib'

the references to /usr/local are problematic, and should be purged from the build configuration.

[cjones051073 (Chris Jones)]

Just FYI, failing build command is

:info:build /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -c -pipe -stdlib=libc++ -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk -mmacosx-version-min=10.9  -Os -fPIC -Wall -W -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -I. -I. -I/opt/local/libexec/qt5/lib/QtGui.framework/Headers -I/opt/local/libexec/qt5/lib/QtCore.framework/Headers -Irelease -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/OpenGL.framework/Headers -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/AGL.framework/Headers -I/opt/local/libexec/qt5/mkspecs/macx-clang -F/opt/local/libexec/qt5/lib -o release/TreeParser.o src/TreeParser.cpp

you need to arrange for -std=c++11 to be used there.

[cjones051073 (Chris Jones)]

Note the qmake5 PG has a lot going on in it w.r.t. build settings, and specifically cxx11. See

​https://github.com/macports/macports-ports/blob/master/_resources/port1.0/group/qmake5-1.0.tcl

you probably need to do something specific for Qt5 to address this. I'm not an expert on Qt5 builds, so cannot really help much. Maybe ask on the mailing lists if you need help.

( I do wonder if just blacklisting compilers that don't have c++11 enabled by default isn't the easiest way out, but up to you .... )

[kencu (Ken)]

adding flags to qt4 and qt5 builds generally requires a patch to the build file, using some trickily-named qt env vars.

qt5 generally ignores our flags set in the portfile, possibly because we use the cache file mechanism to control the build.

I've done a few of these; Marcus, hundreds...

[kencu (Ken)]

Replying to cjones051073:

( I do wonder if just blacklisting compilers that don't have c++11 enabled by default isn't the easiest way out, but up to you .... )

Ryan and I have had this conversation many times.

It is better to fix the build, but overall easier to make the older systems look like new ones with compiler defaulting in base.

If the older systems used their ancient clang only to bootstrap to clang-9.0, and then used that for the main compiler, life would be easier but the fix less pure.

[i0ntempest]

QT5_CFLAGS might be the flag that needs to be changed, we need to somehow append -std=c++11 to it. In bind9 portfile I did this by setting the whole QT5_CFLAGS variable again. Is there a better way to append something to a env variable without re-setting it?

[kencu (Ken)]

you patch the pro/pri file like this:

+MY_WACKY_QT_VARIABLE_NAME_ALWAYS_HARD_TO_FIND += -std=c++11

[kencu (Ken)]

It certainly won't be "CFLAGS", as it's a C++ variable. Look for something that has "CXX" in it.

[cjones051073 (Chris Jones)]

"If the older systems used their ancient clang only to bootstrap to clang-9.0, and then used that for the main compiler, life would be easier but the fix less pure."

Personally, I don't view this as really as a 'less pure fix', just a pragmatic acceptance of the reality of the situation, which is projects increasingly assume c++11 (or newer) is enabled by default. If we simply arranged to do this by default (maybe always, maybe only when 2011 standard is specified), we would save ourselves a lot of hassle in MacPorts, that is just going to get more and more common the more upstream just assumes this is the default. So yes, I would do something like this.

[i0ntempest]

Will try to look into it. It’s weird changing that variable in bind9 fixed the exact same problem...

EDIT: I meant avahi, not bind9. Sorry

[kencu (Ken)]

Replying to cjones051073:

So yes, I would do something like this.

All the compiler.cxx_standard 20XY stuff would just disappear, along with a lot of other shenanigans we do to make the older compilers behave like new ones. I do set my default_compilers in macports.conf to accomplish this sometimes when I just want to get a bunch of things built.

But it's not a popular opinion, and I have come to learn the beauty of purity. However, MacPorts is severely understaffed, and the pragmatic approach in the end might be the only one available.

[cjones051073 (Chris Jones)]

I wouldn't suggest going quite that far, at least not yet. For now if a port sets the compiler.cxx_standard to 2011, instead of just blacklisting compilers that can *in principle* implement that standard, blacklist any compiler that does not implement this as its default standard. Whether we do the same for 2014 and/or 2017 is another discussion, but at least for 2011 (which is 9 years old now) for me it would make sense.

[kencu (Ken)]

from another project:

QMAKE_CXXFLAGS += -std=c++11

[i0ntempest]

I did a bit more digging on avahi, it's configure script seems to be a mess: Qt5 compile test doesnt use CXXFLAGS and CPPFLAGS got used in a C test. So back on this, Chris can you try if adding QMAKE_CXXFLAGS += -std=c++11 to the pro file fixes the build?

[cjones051073 (Chris Jones)]

I don't know what you mean by 'pro file' ??

Please just update the GitHub PR with your suggestion, and then I will try it.

[i0ntempest]

Okay, just updated it

[cjones051073 (Chris Jones)]

OK, that worked.

[ryandesign (Ryan Carsten Schmidt)]

Replying to cjones051073:

( I do wonder if just blacklisting compilers that don't have c++11 enabled by default isn't the easiest way out, but up to you .... )

Let's move any further discussion of that (as a MacPorts policy pertaining to all ports) to the macports-dev mailing list. I have some views I'd like to express but ticket comments aren't a good place to have discussions.

[i0ntempest]

In a0e2bcb8beea7c73d07618a9369ea3bf3cca7a73/macports-ports (master):

db-browser-for-sqlite: patch project file to use c++11

Closes #60552

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

For future reference, something along the lines of

configure.args-append \
                    CONFIG+=c++11

is a patch-free way of ​ensuring qmake based project use C++11.

This should really be in the .pro file for the sake of older Qt versions.
Perhaps upstream would be willing to make the change?