Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong C standard - GNU extensions enabled in PCH file but disabled in CMake #23

Closed
martinhanzik opened this issue Aug 2, 2018 · 3 comments
Labels

Comments

@martinhanzik
Copy link

On macOS, using brew llvm, it's setting the -std=gnu 17 flag instead of the -std=c 17 flag I use for the rest of the project and I get the following error when it actually uses the pch: 'GNU extensions was enabled in PCH file but is currently disabled'.

@nanoant nanoant changed the title GNU extensions was enabled in PCH file but is currently disabled Wrong C standard - GNU extensions enabled in PCH file but disabled in CMake May 1, 2019
@nanoant nanoant added the bug label May 1, 2019
@nanoant
Copy link
Owner

nanoant commented May 1, 2019

I have spent a while investigating this and this is indeed pretty tricky to carry CXX_STANDARD to PCH target. The problem that current CMake implementation for selecting C standard is pretty complicated and uses combination of CMAKE_CXX??_STANDARD/EXTENSION_COMPILE_OPTION compiler defined variables and custom dedicated code of cmLocalGenerator::AddCompilerRequirementFlag that adds these flags.

I tried to convince CMake to add these for PCH target too adding relevant entries in CMakeCXXPCHCompiler.cmake.in as it check if the compiler has CMAKE_ lang _STANDARD_DEFAULT defined, but it seems to be not enough.

FYI current baked in solution provided by @mick-p1982 simply bakes -std=gnu <STD> rather using the CMakes built-in complicated C standard flags handling. That is why you get wrong standard. For now you can simply replace -std=gnu with -std=c and I believe this should do the job for you.

I am rather short on time for this project and already spend couple of hours yesterday, so any help would be appreciated.

@drizt
Copy link
Contributor

drizt commented May 1, 2019

Hm. I think maybe it is possible to use CMAKE_EXPORT_COMPILE_COMMANDS to get exact compile command? It will work only with Ninja and Unix Makefile generators. I tried it with my project so output:

[
{
  "directory": "/home/taurus/develop/torrent-file-editor/release-qt5",
  "command": "/usr/lib64/ccache/g    -DHAVE_QT5 -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NO_CAST_FROM_ASCII -DQT_NO_DEBUG -DQT_WIDGETS_LIB -I../ -I. -isystem /usr/include/qt5 -isystem /usr/include/qt5/QtCore -isystem /usr/lib64/qt5/mkspecs/linux-g   -isystem /usr/include/qt5/QtGui -isystem /usr/include/qt5/QtWidgets   -std=c  11 -Wall -Wextra -pedantic -Werror -Wno-error=cpp -O2 -DNDEBUG   -fPIC -std=gnu  11 -o CMakeFiles/torrent-file-editor.dir/application.cpp.o -c /home/taurus/develop/torrent-file-editor/application.cpp",
  "file": "/home/taurus/develop/torrent-file-editor/application.cpp"
}
]

@m-7761
Copy link
Contributor

m-7761 commented May 1, 2019

If there is no way to detect it with CMake then there has to be a parameter added to module's commands.

I should add that C XX should be a subset of gnu XX. The module is supposed to just give your what you need to do PCH with CMake for popular platforms. If switching to gnu standard is a bridge too far, then you don't really require PCH for your project!

@nanoant nanoant closed this as completed in e17969b May 3, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants