I am using cmake generator ninja to build my project.
cmake / ninja adds a compile definition: -DNDEBUG automatically and it breaks the build.
What is the method to get rid of this default specifically and any in general?
This happens also for compile options and linker options.
what is the recommended way to stay in control of those?
-DNDEBUG break your build? This is a standards-defined preprocessor symbol that changes the behavior of the
assert macro. If you really want to remove it, you’ll have to
string(REPLACE) on the
As Ben already said, this is a define from the C Standard which should not break your build.
But if your project was never built as a Release, only for Debugging purposes, then switching the
Thanks Ben / Joseph,
I agree NDEBUG should not break the build but it does and the reason is quite complicated as we are replacing and rebuilding standard libraries taken from another package and this could be challenging of getting into the root cause of the build break.
Can you elaborate a little bit about string(REPLACE) - do you mean resetting CMAKE_<CXX/C>_FLAGS_RELEASE since I could not see that this affects the compile command and its -D options.
Taking back what I said above: setting CMAKE_CXX_FLAGS_RELEASE to -O3 (instead of ‘-O3 -NDEBUG’ which was the default) solved the problem.
I somehow last week tried to do something similar and it did not help.
Probably a mixup.
Thanks for your help,
Excellent question. Tho answer the „should work“ statements: I for example don’t use GNU C so any gnu options are in the way. And yes I have one toolchain file. But the default compiler options are still there.
The defaults depend on the compiler/target environment detected. They differ e.g. for MSVC and GNUC and others.
If you have a specific problem please create your own thread and explain your environment (which compiler, which target) and what specific problem you have.
Well, I have „my own thread“ over on StackOverflow:
It’s an unsupported compiler so I have to use a custom toolchain file. But despite having a toolchain file compiler options pop out of nowhere.
The defaults depend on the compiler/target environment detected.
This is probably the problem. There is nothing useful to detect. CMake should just use what’s in the toolchain file.
I can copy paste the thread over here of you think that would be helpful.
I see at least two problems
- the toolchain file expects
cl65 as assembler, compiler and linker executable, you did use
- the command line arguments are specified as one single argument (e.g. by using a single string where a list was expected): the error message should only contain e.g.
-xc and not the rest
-xc: I don’t think this was added by CMake, can’t find it in the source code.
Perhaps I should resurrect my old cc65 branch which I have lying around.
- Good observation. That was an artefact from some experimenting I made. Reversed it and didn’t make a difference
- Quick test. Correct. I thought that this was just a case of bad english.
- Then it was most likely added by CLion.
Two and three suggest a problem in CLion. Let’s see:
cmake --toolchain Library/cc65-toolchain.cmake -S . -B cmake-build-release
-- The ASM compiler identification is cc65
-- Found assembler: /opt/local/bin/cl65
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - failed
-- Warning: Did not find file Compiler/cc65-ASM
> CMAKE_ASM_COMPILER: /opt/local/bin/cl65
> CMAKE_C_COMPILER: /opt/local/bin/cl65
> CMAKE_AR: /opt/local/bin/ar65
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/Shared/Work/Projects/6502Tutorial/Atari/cmake-build-release
Of course I tried this before and it didn’t work. I guess there were multiple problems some of which I fixed and now all problems left are CLion. Which is annoying as I the only reason I do this is to have CLion support.
I’ll open a forum post at JetBrains. Thanks for the help.