I'm trying to set up a toolchain for CMake and have made some progress (it's getting the right compiler and all), but I've run into a problem with the -I (include directories directive).
The compiler I'm using doesn't understand -I, it understands -i. What I don't understand is where to change this so that CMake builds the makefile with the -i rather than the -I.
Any help would be greatly apprecaited
Somewhere in your CMakeLists.txt file, you should add the following line:
set(CMAKE_INCLUDE_FLAG_C "-i")
This will change your include flag from the default of -I to -i. Do CMAKE_INCLUDE_FLAG_CXX for C++.
I say this with the caveat that you might want to wrap this in a if that only does this for the Cosmic compiler.
CMake sets this to -I by default in the file CMakeGenericSystem.cmake... search your cmake install dir this file and you will see the CMake defaults for several settings inside. If a compiler has to modify this, it will be in the Compiler folder in the same dir as CMakeGenericSystem.cmake. I'm willing to bet that there is nothing implemented in the Compiler folder for the Cosmic compiler.
Related
I'm using CMake with the GNU Make generator on a project of mine, and then want to build it - verbosely.
I'm interested in lines which actually produce things, and not interested in lines such as:
gmake[2]: Entering directory '/some/where'
gmake[2]: Leaving directory '/some/other/place'
nor the lines saying:
cd /some/where && /path/to/cmake/bin/cmake -E cmake_link_script CMakeFiles/some.dir/link.txt --verbose=1
as those are "wrapping" the actual work that will happen when cmake runs that script (e.g. calls a linker executable such as gcc).
I don't mind very much the percentage headers such as:
[ 97%] Building CXX object /path/to/proj/CMakeFiles/something.dir/foo.o
i.e. if your solution removes them, then fine, if it keeps them - also fine.
I've read answers and comments on this question: Using CMake with GNU Make: How can I see the exact commands?, and the best I've come up with so far is:
MAKEFLAGS="$MAKEFLAGS --no-print-dir" cmake --build build_dir/ --verbose
The --verbose gives you maximum (?) verbosity, with everything you don't want. Then, the --no-print-dir is picked up by GNU Make, making it avoid the Entering/Leaving Directory messages.
Can I do better, and actually avoid the cd and the cmake -E commands?
Notes:
I realize I can use maximum verbosity, then filter using grep. That's not what I want - I want the lines not to be emitted in the first place.
Nothing may be hard-coded into the CMakeLists.txt file; everything must be done via the command-line, after CMake configuration.
You can discover for yourself that there is no way to do what you want.
Since cmake is just generating makefiles, and it's make that is actually running the recipes and printing the output, you need to look at the makefile and see how the rules are constructed. If you find a sample rule for a link line for example you will see it looks like this:
myexecutable: ...
#$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --green --bold --progress-dir=/mydir/CMakeFiles --progress-num=$(CMAKE_PROGRESS_2) "Linking CXX executable myexecutable"
cd /mydir && $(CMAKE_COMMAND) -E cmake_link_script CMakeFiles/myexecutable.dir/link.txt --verbose=$(VERBOSE)
Note that there is no special variable, or token, or anything appearing in this recipe before the cd /mydir ... text.
So, there is absolutely no way to control how this particular recipe is printed, separately from how all the other recipes are printed. You either get them all, or you get none of them.
This answer to a former question on CMake shows this command line:
cmake -H. -Bbuild -G "MSYS Makefiles"
What task does the -H. option perform here? cmake --help says that -H prints the help...
I am using CMake 3.2.3.
As mentioned in the linked answer, it is an undocumented option, but looking at the source code reveals its effect:
In cmake::SetArgs():
if(arg.find("-H",0) == 0)
{
directoriesSet = true;
std::string path = arg.substr(2);
path = cmSystemTools::CollapseFullPath(path);
cmSystemTools::ConvertToUnixSlashes(path);
this->SetHomeDirectory(path);
The last call, SetHomeDirectory actually sets the source directory for the project. The -B option (also undocumented) in turn sets the binary directory.
If these options are not set, the binary directory will be the current folder where cmake is executed, and the source directory can be given as a positional argument (if not found, the source folder will also be the current working directory).
The Hitchhiker’s Guide to the CMake explains both, the legacy and new in CMake 3.13 options:
-H
This internal option is not documented but widely used by community.
and
Has been replaced in 3.13 with the official source directory flag of -S.
-B
Starting with CMake 3.13, -B is an officially supported flag,
can handle spaces correctly and can be used independently of the -S or -H options.
I have a makefile of this kind:
program: \
a/a.o \
b/b.o
$(CXX) $(CXXFLAGS) -o program \
a/a.o \
b/b.o
a.o: \
a/a.cpp \
a/a.h
$(CXX) $(CXXFLAGS) -c a/a.cpp
b.o: \
b/b.cpp \
b/b.h
$(CXX) $(CXXFLAGS) -c b/b.cpp
So in the directory of the makefile I have two subdirectories a and b
that contain respectively a.h, a.cpp and b.h, b.cpp.
The problem is that if I modify a .cpp file, issuing a make rebuilds the target program
but if I modify an .h file make do not rebuilds anything but says
make: `program' is up to date.
I can't understand why, because the .h files are in the prerequisites line
along with the .cpp files.
Interestingly, if I issue a make on an object file target like
$ make a.o
instead, the modifications to a/a.h
are detected and the target a/a.o is rebuild.
Where is the problem?
The subdirectories that you added to the question later are causing the problem indeed. The target program depends on a/a.o and b/b.o, but there are no explicit rules to make those to .o files -- only the targets a.o and b.o are present but those are not in the subdirectories.
Therefore, make will look for implicit rules to build a/a.o and b/b.o. That rule does exist, you will see it being found when you run make -d. That implicit rule depends on a/file_a.cpp only, not on a/file_a.h. Therefore, changing a/file_a.cpp will make a/a.o out of date according to that implicit rule, whereas a/file_a.h will not.
For your reference, the make User's Manual has a section Catalogue of Implicit Rules. That also explains that you can use the argument --no-builtin-rules to avoid that implicit behavior. If you use that, you will see that make can not find any rules to make a/a.o and b/b.o.
Finally, running make a.o will run the recipe for the target a.o as defined in your makefile. That target does have a/a.h as its prerequisite so any change to that file will result in a recompile. But essentially, that has nothing to do with the target program, which has different prerequisites.
all of a sudden I have started seeing this cmake doohickey. Great, one more thing to learn now that I'm used to configure/ make / make install
how does it work and what is the equivalent of configure --help with cmake, to show the build options of a particular source code? thanks
http://dev.mysql.com/doc/internals/en/autotools-to-cmake.html
You can run CMake in interactive mode to get useful information about (and the ability to set) each cache variable in the current CMakeLists.txt:
cmake -i <path-to-source>
If you just want to list all the non-advanced cached variables, run:
cmake -L <path-to-source>
For any of these which are documented CMake variables (e.g. CMAKE_INSTALL_PREFIX), you can get further info by running:
cmake --help-variable CMAKE_INSTALL_PREFIX
Here is a little problem that cannot be resolved by me such a Linux program newbie.
Now I have a main.cpp program which need to be compiled, there is a
#include "Down.h"
in the front of file.
Actually, this header file exist in the other directory, which locates at
../../../include
directory. Besides, some other header files needed by Down.h also locate at this ../../../include directory.
Here is the problem, I compile main.cpp with command
g++ -I /../../../include main.cpp
However, it gives lots of error info which means it is not correct to be done like this.
Should I also change the include declaration into this one?
#include "../../../include/DownConvert.h"
May you please leave me with some advice? Thanks.
Edit:
After using g++ -I ../../../include main.cpp, I get the following errors:
$ g++ -I ../../../include main.cpp
In file included from ../../../include/DownConvert.h:98,
from main.cpp:92: ../../../include/ResizeParameters.h:4:22: error:
TypeDefs.h: No such file or directory
In file included from /usr/include/c++/4.4/bits/stl_algo.h:61,
from /usr/include/c++/4.4/algorithm:62,
from ../../../include/H2
g++ -I /../../../include main.cpp
See that leading slash after the -I? That's an absolute path.
Change it to a relative path (shown below) and it'll work OK.
g++ -I ../../../include main.cpp
g++ -I ../../../include main.cpp
ought to work
Try to use -v option:
g++ -v -I ../../../include main.cpp
And check that list of directories to search for include files contains your folder and there is no complains that this folder is absent. If there is this sort of complains correct the path that you give after -I