I switch between so many projects and IDEs a lot. They run each project with default options of IDE. For example
g++ test.cpp
I know make file can solve the problem. But it is not IDE friendly way. I am thinking if there is any way to impose option
-std=c++11
In the code rather than in calling g++.
The same problem with linker. I want to tell the linker in the code that I want to link to armadillo library
-larmadillo
Maybe setting a prepossessing command could solve the problem. Is there any solution for it?
Have you tried CMake? With this you can create compiler and IDE independent makefiles and then generate the makefiles/project files for the environment of your choise. You can freely script it so you can set certin swithces for gcc and other for vc++ or clang.
You can also use it if you want to create different build configurations.
Related
I'm using ortools in c++ to model a vehicle routing problem. I was wondering whether there was a way to compile the code using my own Makefile by including the proper flags for the compiler, so that I don't have to use
make build SOURCE=/path/to/my/program
I have compiled ortools from source on Debian 10, making sure to follow the proper instructions on the guide (make third-party then make cc then make install_cc). make test_cc runs and finished without problems, so I don't think there is any issues with the installation.
The only clue that I found about this topic was someone writing they used
g++ -std=c++11 -o my_program my_program.cc -I/usr/local/include/or-tools -lortools
to compile their program, but upon trying that, I have a lot of undefined references. I have read somewhere that one should use -std=c++17 instead of -std=c++11 but either way it does not work.
Please let me know if you need more details.
All binary packages comes with a supplied makefile.
You can see the source here: https://github.com/google/or-tools/blob/stable/tools/Makefile.cc.java.dotnet
If you run make detect_cc. It will print out all compiling and linking options for your platform.
Since ortools is a shared library, you will have to specify its path using the environment variable LD_LIBRARY_PATH in addition to specifying the path using the -L flag.
export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:<path-to-lib>.
You can put the export command above in the .bashrc file or run it every time your run the code. Also, you will have to used C++17.
I've been using a .bat file to build my applications for years. Recently, switched to CMake for it's elegancy and I ran into a situation where I had to guess the flags that I should put into CMake's add_link_options and add_compile_options
Example flags that I've used in my BAT file,
-s WASM=1 --bind -s MODULARIZE=1
And, In CMake this flags have become (After trial and error),
add_compile_options("SHELL: -s WASM=1")
add_link_options("SHELL: --bind")
add_link_options("SHELL: -s MODULARIZE=1")
Honestly, I can't find any information regards flags that add_link_options and add_compile_options supports.
I know what is a linker is but lost when it comes to add_link_options or linker flags.
I'm used to compile everything in single line and now in CMake everything appear to be involve separate steps.
I am not sure what your problem is, but here is a full working sample from a Wasm project that sets project-wide strict mode and disabling of exception support:
if (EMSCRIPTEN)
add_compile_options(-fno-exceptions "SHELL:-s STRICT=1")
add_link_options("SHELL:-s STRICT=1")
endif()
Note in particular that, as it has a [compile+link] marker in the emscripten settings, -s STRICT=1 has to be used both for compiling and for linking, thus it appears in each.
The if(EMSCRIPTEN) around is there because this project can also be built for Windows and Linux.
The options you can pass to the compiler or linker depends on which compiler or linker you use. For example if you fork GCC and add a -Wstackoverflow-copy-pasta option, you can pass that option to add_compile_options(), but other people using standard GCC cannot.
So the answer to your question seems to be, read your compiler and linker documentation.
I just installed YCM on CentOS 7. I am now at the step of generating a ".ycm_extra_conf.py" equivalent of the file for my project, which is a nested directory of c++ files, uses Scons build system and g++ (with -std=c++98) to compile the c++ files.
I have few questions:
Are the contents of the "flags" variable in ".ycm_extra_conf.py"
file the flags that are passed to the project compiler, in my case
the g++ compiler by the scons build system?
If answer to question 1 is yes, are these same flags then passed to
clang when YCM compiles the files? If so, is YCM compiling or more
technically processing the c++ files in the project to use for
semantic completion?
If answer to question 2 is yes, then I am guessing the flags I state in
the "flags" variable will not work for clang, as they are applicable to
g++. Should I do a conversion/mapping of the flags to clang?
Does YCM use clang to only front-end compile the files to produce the
AST to use for semantic completion?
Sorry about the naive questions, I am very new to YCM. Any help/guidance would be very appreciated.
Regards and thank you,
Ahmed.
The easiest way to get autocompletion working in vim with ycm is bear:
https://github.com/rizsotto/Bear
Install it and then just run:
bear scons
and you'll get your compilation database that makes ycm happy.
I have a code on my computer uses Petsc which depends on mpi. On my computer it works well. I put it on cluster, exported paths of gcc, Petsc and openmpi (although I was using mpich on my computer I hope openmpi will also work) to LD_LIBRARY_PATH and PATH. I also changed paths in makefile. Petsc, gcc, openmpi were all available on cluster so I did not configure anything. When I did make, compiler gave error:
fatal error: mpi.h: No such file or directory
I know I did not give complete information but I can tell more if needed. How can I make the Petsc to know where is mpi.h?
Typically, you should use mpicc (or mpicxx for C++) to compile instead of gcc (or g++ for C++). These commands are simple wrappers around gcc and g++ that simply add in the appropriate -I/path/to/mpi/includes and -L/path/to/mpi/libs automatically and should be included with your openmpi install. In the absence of that, simply add -I/path/to/mpi/includes in your command to compile the appropriate files. This tells the compiler where to look for the appropriate header files.
To answer the question. To prevent a C/C++ editor from showing errors as you tyoe in the "special code" just use:
#include </usr/include/mpi/mpi.h>
which seems to be a link -- but doing that turns off the errors in Netbeans editor so I can code without distraction.
Note: Using Ubuntu 18.04 Desktop as editing machine -- and testing run machine -- but I compile manually using mpic as noted previously.
sudo mpicc c_pi.c -o c_pi
and then...
mpiexec ./c_pi
hth
I've been working on adding functionality to a C++ library. The library is compiled by using CMake. It has a complex set of dependencies. I have a C++ test file that runs code relating to the library. Let the compiled file be test.cpp, its executable test.
So far, I've been debugging by adding "cout" statements to the library files. I frequently get segmentation faults, but can usually figure it out by inspection. Obviously, this is inefficient. I want to see where the code fails, by using gdb. Via this stackoverflow post, I tried adding debug flags to my cmake, but when I run gdb on test and do bt, I don't get comprehensive info. I simply get the name of the function in the library where the code fails, not the exact line.
Anyone know how to get the gdb information?
While adding the respective compiler flags manually will work, it is not the most convenient way of doing so. As suggested by #ruslo, you should use the following command line instead for getting debug support:
cmake -DCMAKE_BUILD_TYPE=Debug <path_to_source>
There are several reasons for this:
Compiler flags are not portable. -g -O0 will work on gcc, but what about other compilers? One of CMake's main strengths is to make portability easy, so you should not throw it out of the window easily.
Multi-configuration generators (like most IDE generators) allow to use multiple profiles at once. You would not want to force users of those IDEs to compile without optimizations even though they selected a Release profile, would you?
Changes to CMAKE_CXX_FLAGS are global. This becomes especially nasty once you have to compose multiple projects together. If you absolutely need to manually give compiler flags, use target_compile_options for this purpose.
Last but not least: Setting CMAKE_BUILD_TYPE is the idiomatic solution to this problem. It is the one right tool for solving it and people familiar with CMake (granted, there are not too many around of those...) will be surprised if you solve it using a non-idiomatic workaround.
I've figured it out. They key is to add the "-g" flag to
SET (CMAKE_C_FLAGS ...
and
SET(CMAKE_CXX_FLAGS ...
to the CMakeLists.txt file.