I have an application that compiles fine with nmake. But it does not compile in debug mode. So I edited .mak file and added /Debug for "link" options and "Zi" for "cl.exe" options. During compilation it looks like this now: cl -I ../../../ -DEXTRACT_ONLY -DNO_READ_FROM_CODER -D_SFX -Gr -c -FoO/ -WX -EHsc -Gy -GR- /Zi -MT -W4 -GS- -Zc:forScope -O1 -Yu"StdAfx.h" -FpO/a.pch abc.cpp
and I get this error:
error C2855: command-line option '/Zi' inconsistent with precompiled header
Q1: Can I simply remove options like -Yu or -Fpo and it will still work ( though take longer to compile because there is no recompiled stuff now)?
Q2. Is there an option of nmake to clean all files generated by it. ( I am using .mak files )
Note: I am in vs2010 world.
Answer to Q1: I removed -Yu and -Fpo and it compiled. Now I am able to debug. Note that Q2 still remain unanswered.
Related
I'm trying to get a custom compiler working in CLion and having a bear of a time. Can anyone help me find out what I'm doing wrong? I have the full code on Github.
What I have
The command line tools are all behind the same executable named mpw. So the C compiler is behind mpw SC, the linker is behind mpw link. There's also a tool named Rez to add some metadata to the executable, but I'm fine if CLion just ignores that.
I'm using a make file to do the actual build.
I've created a custom compiler definition YAML and selected it in CLion's project settings. I tried to follow the Jetbrains docs [1] [2] but couldn't find out what code insight target name to use (It eventually compiles for 68000 CPU, old MacOS, anyone know where I can find a list of allowed clangd target names?).
The Makefile works when I call make clean or make all from command line.
Problem
When I open the folder in CLion, it tries to parse the Makefile and reports:
(x) Analysing makefile
(x) No compilation commands found
Goal
Get CLion to see all my code (including system headers at ~/mpw/Interfaces/CIncludes) so I can use its code navigation to auto-complete code. Refactoring would be nice too.
Get CLion to understand my Makefile so I can build using the "hammer" icon inside CLion.
Custom Compiler Definition
compilers:
- description: "MPW SC"
match-sources: ".*\\.c"
match-language: "C"
match-compiler-exe: "(.*/)?mpw SC"
code-insight-target-name: mpw
include-dirs:
- ${user-home}/mpw/Interfaces/CIncludes
defines-text: "
#define __MRC__ 0x0700
#define OLDROUTINENAMES 1
"
Makefile
SOURCES=SillyBalls.c
RFILES=SillyBalls.r Size.r
EXECUTABLE=SillyBalls
MPW=~/Programming/mpw/build/bin/mpw
RINCLUDES=~/mpw/Interfaces/RIncludes
LDFLAGS =-w -c 'SILB' -t APPL \
-sn STDIO=Main -sn INTENV=Main -sn %A5Init=Main
LIBRARIES={Libraries}Stubs.o \
{Libraries}MacRuntime.o \
{Libraries}IntEnv.o \
{Libraries}Interface.o \
{Libraries}ToolLibs.o \
{CLibraries}StdCLib.o
TOOLBOXFLAGS=-d OLDROUTINENAMES=1 -typecheck relaxed
OBJECTS=$(SOURCES:%.c=obj/%.o)
all: prepass bin/$(EXECUTABLE)
prepass:
mkdir -p obj bin
bin/$(EXECUTABLE): $(OBJECTS)
$(MPW) link $(LDFLAGS) $(OBJECTS) $(LIBRARIES) -o $#
Rez -rd $(RFILES) -o $# -i $(RINCLUDES) -append
obj/%.o : %.c
$(MPW) SC $(TOOLBOXFLAGS) $< -o $#
clean:
rm -rf bin obj
Thanks to #JohnBollinger for getting me on the right track:
CLion is apparently not smart enough to recognize $(MPW) SC as mpw SC. If I change it to
CC="~/Programming/mpw/build/bin/mpw SC"
CLion is happy, but of course there is no file named mpw SC.
So my solution was to create a shell script sc.sh:
#!/bin/zsh
~/Programming/mpw/build/bin/mpw SC $#
and then set
CC=./sc.sh
and
match-compiler-exe: "(.*/)?sc.sh"
and then use ./sc.sh everywhere where I used to have $(MPW) SC
CLion recognizes it, starts indexing the system headers, and the "hammer" icon triggers a build all just as desired.
I am trying to get code coverage in my unit test project in windows system.
Description
After compiling with -fprofile-arcs -ftest-coverage, I found out the execution file is generated and works fine. However there's no any .gcno files in the folder. So I cannot output the coverage report properly by gcovr.
Software version
gcc 8.1.0/gcov 8.1.0/gcovr 5.1/python 3.10.2
Steps
Here's what I've done during the whole process. Please help me if there's something wrong.
There are only .c and .h files in one folder
Compile my project using gcc
gcc -Wall -Wno-unknown-pragmas -fcompare-debug-second -fprofile-arcs -ftest-coverage -DUTEST AllTests.c CuTest.c BZR2.c BZR2_test.c -o beta.exe
Then I got beta.exe in the folder.
After runing beta.exe, there's my test result(All tests are passed.) showing in the command line window. Besides there're .gcda files with the same filename as my .c files.
Then I run gcovr -r ., the result is showing below. I think the reson why gcovr can't show the coverage information is there's no any .gcno files generated after compiling my project. But I don't understand why and how to solve this.
------------------------------------------------------------------------------
GCC Code Coverage Report
Directory: .
------------------------------------------------------------------------------
File Lines Exec Cover Missing
------------------------------------------------------------------------------
------------------------------------------------------------------------------
TOTAL 0 0 --%
------------------------------------------------------------------------------
Thanks for your time!
Remove the -fcompare-debug-second option. It is used for debugging the compiler itself, and causes the compiler
to silence warnings, and omitting other options that would cause the compiler to produce output to files or to standard output as a side effect.
(see: https://gcc.gnu.org/onlinedocs/gcc-8.5.0/gcc/Developer-Options.html)
Creation of gcno files is such a side effect.
General tips:
Instead of -fprofile-arcs -test-coverage you can simply use the --coverage option.
When you compile multiple source files in one go, then GCC tries to figure out file names for intermediate files, and also automatically derives some name for secondary outputs like gcno files. This used to be somewhat unintuitive, at least until reasonable behaviour was implemented in GCC 11.
To compile all of the files individually, we would use the structure:
OPTIONS="-Wall -Wno-unknown-pragmas --coverage -DUTEST"
# compile the individual compilation units
gcc -c $OPTIONS AllTests.c -o AllTests.o
gcc -c $OPTIONS BZR2.c -o BZR2.o
gcc -c $OPTIONS BZR2_test.c -o BZR2_test.o
# we should now have three gcno files
ls *.gcno
# link the final executable
gcc $OPTIONS CuTest.o BZR2.o BZR2_test.o -o beta.exe
At this point, it's typically appropriate to use a build system, for example by writing a Makefile:
CFLAGS += -Wall -Wno-unknown-pragmas --coverage -DUTEST
SOURCES = AllTests.c BZR2.c BZR2_tests.c
OBJECTS = $(SOURCES:.c=.o)
beta.exe: $(OBJECTS)
$(CC) $(CFLAGS) $^ -o $#
I am trying to run Ale as my linter, which in turn uses clang-check to lint my code.
$ clang-check FeatureManager.h
Error while trying to load a compilation database:
Could not auto-detect compilation database for file "FeatureManager.h"
No compilation database found in /home/babbleshack/ or any parent directory
json-compilation-database: Error while opening JSON database: No such file or directory
Running without flags.
/home/babbleshack/FeatureManager.h:6:10: fatal error: 'unordered_map' file not found
#include <unordered_map>
^~~~~~~~~~~~~~~
1 error generated.
Error while processing /home/babbleshack/FeatureManager.h.
Whereas compiling with clang++ returns only a warning.
$ clang++ -std=c++11 -Wall FeatureManager.cxx FeatureManager.h
clang-5.0: warning: treating 'c-header' input as 'c++-header' when in C++ mode, this behavior is deprecated [-Wdeprecated]
There are no flags to clang-check allowing me to set compilation flags.
Took a while to figure this out, but you can do
clang-check file.cxx -- -Wall -std=c++11 -x c++
or if you are using clang-tidy
clang-tidy file.cxx -- -Wall -std=c++11 -x c++
To get both working with ALE, I added the following to my vimrc
let g:ale_cpp_clangtidy_options = '-Wall -std=c++11 -x c++'
let g:ale_cpp_clangcheck_options = '-- -Wall -std=c++11 -x c++'
If you want ALE to work for C as well, you will have to do the same for g:ale_c_clangtidy_options and g:ale_c_clangcheck_options.
I was getting stumped by a similar error message for far too long:
/my/project/src/util.h:4:10: error: 'string' file not found [clang-diagnostic-error]
#include <string>
^
I saw other questions suggesting that I was missing some critical package, but everything already seemed to be installed (and my code built just fine, it was only clang-tidy that was getting upset).
Passing -v showed that my .h file was being handled differently:
$ clang-tidy ... src/*.{h,cc} -- ... -v
...
clang-tool ... -main-file-name util.cc ... -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9 ... -x c++ ... /tmp/copy/src/util_test.cc
...
clang-tool ... -main-file-name util.h ... -x c-header /my/project/src/util.h
...
As Kris notes the key distinction is the -x c-header flag, which is because clang assumes a .h file contains C, not C++, and this in turn means that the system C++ includes weren't being used to process util.h.
But the -main-file-name flag also stood out to me as odd; why would a header file ever be the main file? While digging around I also came across this short but insightful answer that header files shouldn't be directly compiled in the first place! Using src/*.cc instead of src/*.{h,cc} avoids the problem entirely by never asking Clang to try to process a .h on its own in the first place!
This does introduce one more wrinkle, though. Errors in these header files won't be reported by default, since they're not the files you asked clang-tidy to look at. This is where the "Use -header-filter=. to display errors from all non-system headers.*" message clang-tidy prints comes in. If I pass -header-filter=src/.* (to only include my src headers and not any other header files I'm including with -I) I see the expected errors in my header files. Phew!
I'm not sure whether to prefer -x c++ or -header-filter=.* generally. A downside of -header-filter is you have to tune the filter regex, rather than just passing in the files you want to check. But on the other hand processing header files in isolation is essentially wasteful work (that I expect would add up quickly in a larger project).
So I'm trying to add the /DYNAMICBASE option like this:
add_definitions(/DYNAMICBASE)
and the result in MSVC when I look in the project c++ command line options is this:
/D "YNAMICBASE"
How am I supposed to add this flag? I also tried using CMAKE_CXX_FLAGS but the same thing happens.
My comment (Visual Studio specific):
/D is a compiler (cl.exe) flag, while /DYNAMICBASE is a linker (link.exe) one.
is only half of the answer, and that is finding the root cause.
Translating it into something that cmake understands (setting the CMAKE_SHARED_LINKER_FLAGS and CMAKE_EXE_LINKER_FLAGS variables) which is solving the problem is #onqtam's merit.
So, the points should be divided.
I am very new to Cmake and need to generate some files at compile time. once generated i need to compile and link the files. I ve created the cmake makefile to compile the already generated files like
cmake_minimum_required(VERSION 2.6)
project(demo)
set(CMAKE_CXX_FLAGS "-DWITH_COOKIES")
add_library(soapC soapC.cpp soapVimBindingProxy.cpp)
add_library(stdsoap2 /home/abdullah/installs/gsoap-shah_edits/gsoap/stdsoap2.cpp)
add_executable(demo test_file.cc test_app.cc)
target_link_libraries(demo soapC stdsoap2 gsoap++)
This successfully compiles the project. However the files soapC.cpp soapVimBindingProxy.cpp needs to be generated first. And I want to generate these files at runtime using the gsoap tool.
following is the command that needs to be run to generate the header file
wsdl2h -o outfile.h infile.wsdl
This takes an input wsdl file and creates a corresponding outfile.h.
Now I tried doing this in cmake like this
cmake_minimum_required(VERSION 2.6)
add_custom_command(
OUTPUT vsphere.h
COMMAND wsdl2h -o vsphere.h vim25/vim.wsdl
)
But something goes wrong here. No error pops up but no file is created either. Am I missing something ? All help much appreciated.
Thanks.
You've just created a command for producing your header file, so CMake knows just where to get vsphere.h from. I'd recommend using OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/vsphere.h in the add_custom_command() call.
Now you need to create a target:
add_custom_target(vsphere_header ALL DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/vsphere.h)
Finally, make your soapC target depend on it:
add_dependencies(soapC vsphere_header)
Be sure to place add_dependencies() call after soapC target definition.
Thanks arrododger and TobyHijzen for your lighting on this issue.
I use add_custom_command with main_dependency feature for solution for this issue. Following is my CMakeLists.txt for famous calc example of gsoap tutorial.
cmake_minimum_required(VERSION 2.8)
# Proejct name
PROJECT(Calculator)
# Make verbose level on/off
SET(CMAKE_VERBOSE_MAKEFILE ON)
# Varialbes used in cmake
SET(TARGET calc_client)
SET(GSOAP_STATIC_LIB gsoap)
SET(CLIENT_SRC calc_client.c)
SET(WSDL2H_EXEC wsdl2h)
SET(WSDL2H_IN http://www.genivia.com/calc.wsdl)
#SET(WSDL2H_IN calc.wsdl)
SET(WSDL2H_OUT calc.h)
SET(WSDL2H_OPT -c -o)
# command for generating stub and xml serializer code
ADD_CUSTOM_COMMAND(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${WSDL2H_OUT}
COMMAND ${WSDL2H_EXEC} -c -ttypemap.dat -o ${WSDL2H_OUT} ${WSDL2H_IN}
COMMENT "=================== Generating ${WSDL2H_OUT} gSOAP Header file ..."
)
SET(SOAPCPP2_EXEC soapcpp2)
SET(STUB soapClient.c soapC.c)
SET(SOAPCPP2_OUT
${STUB}
calc.add.req.xml
calc.add.res.xml
calc.sub.req.xml
calc.sub.res.xml
calc.mul.req.xml
calc.mul.res.xml
calc.div.res.xml
calc.div.req.xml
calc.pow.res.xml
calc.pow.req.xml
calc.nsmap
soapH.c
soapH.h
soapStub.h
soapClientLib.c
)
# command for generating stub and xml serializer code
ADD_CUSTOM_COMMAND(
OUTPUT ${STUB}
COMMAND ${SOAPCPP2_EXEC} -c -C ${WSDL2H_OUT}
MAIN_DEPENDENCY ${WSDL2H_OUT}
COMMENT "=================== Generating ${STUB} outputs ..."
)
# Exutable files and dependents
ADD_EXECUTABLE(${TARGET} ${CLIENT_SRC} ${STUB})
# libraries for taget : for gcc -l option
TARGET_LINK_LIBRARIES(${TARGET} ${GSOAP_STATIC_LIB})
# Compiler options
ADD_DEFINITIONS(-Wall -O2 -s)