I am looking for a way to get the command invoked to compile a specific file inside CMake as a variable. This is the same "command" as it shows up in a compile_commands.json. It is of the form:
%gcc% %bunch of -DSOMETHINGS% %bunch of -Isome/files% -o %cpp files% ... etc.
The project I am in the process of porting to CMake makes a note of the invoked compiler command inside a file, which I am changing to use the configure_file cmake mechanism. The configured file is needed prior to compiling a specific object.
While searching, I found this answer that is pretty much the same question: cmake - get the used commandline flags "-D". However, it is more than 3 years old, and only concerns retrieving a list of the "-D" flags, which the user solved by manually keeping track. I consider this suboptimal. If this command is written into compile_commands.json, I should be able to access this somehow, right? When exactly is compile_commands.json written? Any change I can get this to write that file for like, a non-functional dummy target or something, then access it and use it to configure my file in the real project?
I know this is kind of against the ethos of CMake, and I love the fact that I don't ever have to manually manage the flags myself, however I find it hard to believe there is no way to get them for a specific file, am I overlooking something?
I have looked at CMake properties on source files, and retrieving them using get_property, however I don't believe I can reconstruct the whole command from these.
I am currently generating Unix makefiles, although the mechanism should optimally also work when generating MSVC project files, which I know CMAKE_EXPORT_COMPILE_COMMANDS does not.
Any thoughts and input on this is greatly appreciated!
Related
i got stuck with a problem which has to do with a managed c++ Project.
Currently we have a working Build and we are about to use CMake to generate our Solution Files in the future.
In our solution we have some Managed C++ Project and C# Projects. I tried to generate/build the Managed C++ Projects and it works. But there is one key thing that is different which atually breaks the build.
In our working build the managed C++ Project has the Xml Tag <TargetFrameworkVersion> but when I use CMake to configure/generate the Project I end up having <TargetFramework> and this breaks the build ( I confirmed by manually changing the Tag).
I got stuck with this Problem for 2 days and the following things I already tried:
I tried setting VS_DOTNET_TARGET_FRAMEWORK_VERSION which actually is deprecated but makes sense because of the name. I ended up having in the Project file.
I also tried the newer Variables DOTNET_TARGET_FRAMEWORK, DOTNET_TARGET_FRAMEWORK_VERSION but I ended up again with in the Project file.
I thought to myself I could change the Project file after I configure/generate but thats pretty hacky (but works)
There is a second solution which actually works but is not what I really want. I can tell cmake.exe to pass some options to the native MsBuild tool to build the managed C++ target. This works but I would prefer to some how tell the CMakeLists.txt to do this or even better have the right Xml tag when generating the Proect files because we don't want to use the command line when building our projects.
The approach looks like this (Target Name is NotifierLib and .NET Framework Version is 4.7.2)
cmake --build . --target NotifierLib -- /p:TargetFrameworkVersion=v4.7.2
Did anyone came across this exact issue? Or maybe has an idea how to solve this via CMakeLists.txt?
Thanks in advance.
I finally came to a pretty Solution which was there initially.
This post helped my to get on the right Track:
How can cmake add custom entry in a project's vcxproj PropertyGroup?
Basically I don't need to iterate over the .xml File myself to edit the Tag.
I can tell CMake to set it for me as a global option with:
set_target_properties(NotifierLib PROPERTIES VS_GLOBAL_TargetFrameworkVersion "v4.7.2")
This way the initial <TargetFramework> Tag is still in the .xml File but it does not bother because it is not being used.
I'd like to do some property-based testing in a C++ library I'm working on, and was thinking of going with RapidCheck unless somebody has a better idea. (I will need, for example, to generate arbitrary std::set<int>, and if I can place bounds on the range of int in the sets and the size of the sets, all the better.)
All this being said, I'm still a bit of a cmake newb. There appear to be no instructions in RapidCheck except to include it as part of the source code (although downloading it would be better). I have gotten to the point where I can include the headers for RapidCheck in my code, but when I try to build any app using RapidCheck, I'm told that there are symbols from RapidCheck missing or that the rapidcheck library is missing.
I'm assuming that I have to build RapidCheck itself as part of the project to generate the library, but I'm not entirely sure how to do this and it seems difficult to find any examples where this is done.
Does anyone have any suggestions of examples where such things are done so that I can see the string of commands necessary to build a 3rd party API and include the library when building the executables, or - even better - an example of a project using RapidCheck that does exactly this? The lack of documentation on how to set this up is discouraging.
I hope this is not overly vague. To summarize, what I'd like to do from cmake:
Preferably download RapidTest (although including the files directly from the RapidTest project would be fine as well).
Run the required commands and set up the necessary variables to have my test code (in ${PROJECT_SOURCE_DIR}/test) be able to access RapidTest headers.
Generate (if necessary) the RapidTest library and make it so that I can link it to the tests I'm running.
Thanks in advance for any help you might be able to offer!
This is probably not the right way to do this, but maybe it will help:
I was able to get this working by doing the following:
# from within the root of the rapidcheck repo:
$ cmake -DBUILD_SHARED_LIBS=true -G "Unix Makefiles" -DCMAKE_BUILD_TYPE=Debug .
# Leave off the BUILD_SHARED_LIBS flag if you don't need an SO.
$ make
That built: librapidcheck.so and librapidcheck.a, which you can then copy / install as needed.
You'll also need the include directory with the headers for rapidcheck, but that's just in the source tree.
Add the include path to your compile commands using whatever build tool you want, and link with the compiled libraries (the .so and .a)
My question is the following:
Is there a way to tell CMakeFiles where to generate it's makefiles, such as cmake_install.cmake, CMakeCache.txt etc.?
More specifically, is there a way to set some commands in the CMakeFiles that specifies where to output these generated files? I have tried to search around the web to find some answers, and most people say there's no explicit way of doing this, while others say I might be able to, using custom commands. Sadly, I'm not very strong in cmake, so I couldn't figure this out.
I'm currently using the CLion IDE and there you can specifically set the output path through the settings, but for flexibility reasons I would like as much as possible to be done through the CMakeFiles such that compiling from different computers isn't that big of a hassle.
I would also like to avoid explicitly adding additional command line arguments etc.
I hope someone might have an answer for me, thanks in advance!
You can't (easily) do this and you shouldn't try to do it.
The build tree is CMake's territory. It allows you some tiny amount of customization there (for instance you can specify where the final build artifacts will be placed through the *_OUTPUT_DIRECTORY target properties), but it does not give you any direct control over where intermediate files, like object files or internal make scripts used for bookkeeping are being placed.
This is a feature. You have no idea how all the build systems supported by CMake work internally. Maybe you can move that internal file to a different location in your build process, which is based on Unix Makefiles. But maybe that will also horribly break my build process, which is using Visual Studio. The bottom line is: You shouldn't have to care about this. CMake should take care of it, and by taking some freedom away from you, it ensures that it can actually do that job on all supported build toolchains.
But this might still be an unsatisfactory answer to you. You're the developer, shouldn't you be in full control of the results produced by your build? Of course you should, which is why CMake again grants you full control over what goes into the install tree. That is, whatever ends up in the install directory when you call make install (or whatever is the equivalent of installing in your build toolchain) is again under your control.
So you do control everything that matters: The source tree, the install tree, and that tiny portion of the build tree where the final build artifacts go. The rest of the build tree is off-limits for you and for good reasons.
At the company I'm currently working for, several IDEs are being used (they develop firmware for different embedded platforms).
All their C projects use a Makefile, so we decided to also add rules to their default Makefile to run static code analysis tools.
One of the IDEs they use is Eclipse.
Here we have added additional targets to the Make Target view, that triggers the lint target from the Makefile, for example.
Since we use multiple IDEs we can tell the tools called by the Makefile to generate specific output for the IDE being used.
For Eclipse we do this by adjusting the Build Command and adding something like IDE_ENV=eclipse to the end.
This works just fine.
Recently one of the engineers mentioned that it would be really helpful if he could run the tools, as defined in the Makefile, for a single file.
So, I updated the Makefile and it now accepts a variable SOURCE_FILE with the path of the file that needs to be checked.
In Eclipse I tried adding SOURCE_FILE=${selected_resource_loc} and just SOURCE_FILE=${resource_loc}, but these variable do not seem to work when running a Make Target.
I also tried to use $(selected_resource_loc) and $(resource_loc) directly in the Makefile, but without any luck.
Can somebody tell me how I can pass the current selected file to Make when running a target from the Make Target view?
Some Eclipse special variables can be not recognized in a build configuration. Instead of running build procedure try to use External Tools Configuration.
Similar problem was described here: Custom command for Eclipse on current file .
I'm considering reimplementing our build system (currently based on GNU Make) in CMake.
Disclaimer: this is more of a theoretical and "best practices" question. I don't know CMake in-depth. Also, please feel free to migrate the question to programmers if it's more on-topic there.
As far as I understand, the standard workflow for CMake is
cmake .
make
I suspect there may be problems of de-synchronization of CMake files and Makefiles.
So, during usual development process you're supposed to run make to avoid unnecessary rebuilds of CMakeCache and Makefiles and generally make the process more straight-forward. But then, if you add, say, a new source file to CMakeLists and run make, it'll be using old CMakeCache and Makefiles and will not regenerate them automatically. I think it may cause major problems when used at scale, since in case something is not building as it should, you'll have to try to perform make clean, then, if it doesn't help, you'll need to remove CMakeCache and regenerate everything (manually!).
If I'm not right about something of the above, please correct me.
I'd like to just do
awesome-cmake
and have it update everything what needs updating and build the project.
So, the question: is there a way to make "atomic build" with CMake so that it tracks all the required information and abstracts away the usage of make?
I think you have a couple of incorrect ideas here:
I suspect there may be problems of de-synchronization of CMake files and Makefiles.
Ultimately, CMake is all about producing correct Makefiles (or Visual Studio solution files, or XCode project files, or whatever). Unless you modify a generated Makefile by hand, there can be no synchronisation issue between CMake and the Makefile since CMake generates the Makefile.
But then, if you add, say, a new source file to CMakeLists and run make, it'll be using old CMakeCache and Makefiles and will not regenerate them automatically.
Actually, the opposite is true: if you modify the CMakeLists.txt (e.g. adding a new source, changing a compiler flag, adding a new dependency) then running make will trigger a rerun of CMake automatically. CMake will read in its previously cached values (which includes any command line args previously given to CMake) and generate an updated Makefile.
in case something is not building as it should, you'll have to try to perform make clean, then, if it doesn't help, you'll need to remove CMakeCache and regenerate everything (manually!).
Yes, this would be a pretty normal workflow if something has gone wrong. However, things don't often get that bad in my experience.
So, the question: is there a way to make "atomic build" with CMake so that it tracks all the required information and abstracts away the usage of make?
Given that running make will cause CMake to "do the right thing", i.e. rerun if required, I guess that using make is as close to an "atomic build" as possible.
One thing to beware of here is the use of file(GLOB ...) or similar to generate a list of source files. From the docs:
We do not recommend using GLOB to collect a list of source files from your source tree. If no CMakeLists.txt file changes when a source is added or removed then the generated build system cannot know when to ask CMake to regenerate.
In other words, if you do use file(GLOB ...) to gather a list of sources, you need to get into the habit of rerunning CMake after adding/removing a file from your source tree; running make won't trigger a rerun of CMake in this situation.
The standard workflow for CMake is an out of source build
mkdir build
cd build
cmake ..
make