I have cmake a custom command and custom target which runs doxygen to generate documentation from the header files.
However Visual Studio doesn't build this target when the build is started from command line. It says "Project not selected to build for this solution configuration". Is there a way make sure this target is selected for the release (or debug) configuration in Visual Studio?
You probably want the add_dependencies command.
After you have defined they doxygen target and an executable or library target, write something like
add_dependencies( my_executable my_custom_doxygen_target )
This will force the doxygen target to be built every time your executable is.
It may also be possible to make it work by turning off the EXCLUDE_FROM_ALL property on your doxygen target. I expected to see EXCLUDE_FROM_ALL mentioned in the description of add_custom_target, but didn't - so it might be different than I remember.
Related
I'm compiling this PCL Library example. For reference, it consists of a simple cpp file that includes some PCL headers and does some basic data manipulation, and a CMakeLists.txt file.
Using the command line, I am able to build it using cmake -> make. I want to build it also using VSCode IDE. When I open this project on VSCode, it detects I'm using cmake, and if I clean/build it using the cmake extension, everything seems to work as expected (including autocompletion by intellisense, etc).
However, this takes some time as it builds the whole project in the same way you would do it from the command line, only from VSCode. I wanted to understand if I can also configure a "default build task" (via the tasks.json file) to build files using Ctrl + Shift + B, and be able to build individual files, and have a more IDE-Like experience (something like the incremental compiler of Eclipse with Java, for example).
If I add a C++ configuration, it fails to find .h files, and errors are highlighted on the open file, until I clean/rebuild via de cmake extension.
My question is, are this two options (cmake extension vs build tasks) compatible or mutually exclusive? Is defining and compiling via a task in fact more agile than building via the cmake extension?
Thanks!
I have a Qt project file (.pro) and a Makefile (self-written).
The project file is simply used for editing the source files in the IDE:
/home/project/
./src/fooApp.pro
TEMPLATE=app
CONFIG-=qt
TARGET=fooApp
SOURCES+=...
HEADERS+=...
./src/main.c
./src/foo.c
./src/foo.h
./build/Makefile
I would like to build the project via IDE QT Creator 3.5.1
Therefore I would like to invoke make on the Makefile.
During the build process I always get the error that no Makefile can be found hence no build was triggered.
The solution is to always invoke qmake first, then make (even if a Makefile is still present and custom setting make -C ../build in /home/project/)
Could someone please explain, why it is not possible ignore qmake and directly invoke make on the already existing Makefile?
(No Qt library is used for the project)
Regards
This is quite easy, I use makefile only project alot because I like qt-creator as an IDE. In the IDE goto the projects tab on the left.
Select the "build" tab near the top of that page, looks like: (build | run).
In the build steps:
remove the qmake build step by press hovering the mouse over that step and clicking the X that appears.
Edit the build directory so that it is the same directory as your makefile.
Note: you will have to click the shadow build check box next to it to enable it.
remove any other steps you don't want (infact just remove them all for now).
Add a new step make step. It will try to use the default make, but you can override that if you want. Also add any arguments like debug or -j4 etc...
Then you are done :)
Next time you hit build it will simply invoke that make command.
Note: You will need to do the same for any other configurations you have (like release, debug, etc...). You can also just add loads more configurations for doing other make options (if you have them) for instance make doxygen or such...
Just remembered you can also either:
I am not sure why, but when I tested it (as OP did) you can't seem to just setup a make step with parameters -C ../, it seems to want to look in the "build directory" first.
I tend to use the build location since its a nice feature of the IDE.
Note an issue with newer versions of Qtcreator as a makefile IDE is that you cant share your build settings with other people (i.e. can't configure control them) because they are locked to your PC profile... long story... but its very sad and I no longer use qt creator for that one reason.
I have a project which uses Makefiles. On a branch, I have CMake based build system. Now some team-members wants the OLD make-files based system intact, when cmake is added. But this is not possible after cmake . command overwrites the old Makefile.
Now I can easily avoid it if I can tell CMake to generate makefiles with some non-standard names e.g. makefile.cmake etc. Is it possible?
I am open to consider other options as well. In any case, old Makefiles must not be touched.
Cmake creates a build system in the working directory. So create any empty directory, and run cmake <path-to-source> from there.
Unfortunately, the name "Makefile" in hard-coded several times, in the sources of CMake. You cannot change it. As Peter has pointed out in the other answer, that change is not necessary, because CMake support out-of-source builds.
Very new to CMake, and so far I'm finding it to be extremely helpful. I have a set of custom libraries that I would like to build for multiple platforms using cross-compilation. The toolchains are installed, and I can hand-create the Makefiles that I need to do so, but I would like to be able to make use of CMake.
Is there a way to tell cmake which toolchain to use, either at the command line or in the CMakeLists.txt file?
Have a look here: basically, you define a "toolchain file" that sets things like the system name, paths to compilers and so on. You then call cmake like so:
cmake /path/to/src -DCMAKE_TOOLCHAIN_FILE=/path/to/toolchain/foo-bar-baz.cmake
To customize the build settings so you don't have to specify the parameter every time:
For Visual Studio - here
For Vusual Studio Code :
Install the Cmake Tools extension if haven't done so already.
In the .vscode/settings.json file set the parameter cmake.configureArgs. You can also set it from Settings -> CMake Tools configuration -> Add Item. Mine looks like this:
{
"cmake.configureArgs": [
"-DCMAKE_TOOLCHAIN_FILE=C:/Users/.../vcpkg/scripts/buildsystems/vcpkg.cmake"
]
}
I develop C/C++ using the Eclipse IDE. Eclipse also generates a makefile which I don't want to edit as it will simply be overwritten.
I want to use that makefile for nightly build within Hudson.
How do I pass #defines which are made in the project file of the IDE to the makefile ? (and why doesn't Eclipse already include them in the generated makefile?)
I actually had this figured out once, then accidentally overwrote it :-( But at least I know that it can be done...
If you are running make from the command line, use
make CPPFLAGS=-DFOO
which will add -DFOO to all compilations. See also CFLAGS, CXXFLAGS, LDFLAGS in the make manual.
You could write a small program to include the headers and write a makefile fragment which you include in the main makefile (requires GNU make).
This is a fairly ugly solution that requires a fair amount of hand hackery. More elegant would be to parse the project file and write the makefile fragment.
For GCC use -D define.
OP commented below that he wants to pass the define into make and have it pass it on to GCC.
Make does not allow this. Typically you just add another make rule to add defines. For instance 'make release' vs 'make debug'. As the makefile creator you make the two rules and have the defines right in the make file. Now if Eclipse is not putting the defines into the makefile for you, I would say Eclipse is broken.
If you're using autotools another options is to have 2 directories 'bin/debug' and 'bin/release'.
# Simple bootstrap script.
# Remove previously generated filed and call autoreconf.
# At the end configure 2 separate builds.
echo "Setting up Debug configuration: bin/debug"
../../configure CXXFLAGS="-g3 -O0 -DDEBUG=1"
echo "Setting up Release configuration: bin/release"
cd bin/release/
../../configure CXXFLAGS="-O2"
Setup Eclipse. Open the project's properties (Project->Properties->C/C++ Build->Builder Settings) and set the Build Location->Build Directory to
${workspace_loc:/helloworld/bin/debug}
Replacing 'helloworld' with your project's directory relative to the workspace (or you can supply an absolute path ${/abs/path/debug}). Do the same thing with the Release config, replacing "/debug" with "release" at the end of the path.
This method seems like a waste of disk space, but a valid alternative to achieve completely separate builds.