In my CMake file I need to use lib.exe in custom command when building on Windows to combine multiple static libraries into one.
I tried to use find_program command to find the executable:
find_program(LIB_EXE NAMES lib.exe)
but it always sets the variable to not found. What is the right way to find lib.exe?
[EDIT] Fixed NAME->NAMES, but the program is still not found
The proper keyword is NAMES which may be omitted. Try adding the S or removing the keyword entirely.
I think you're actually searching for the program NAME
Check the file CMakeCache.txt in your build directory, and search for "lib.exe".
There you can find "lib.exe" can be located by the variable ${CMAKE_AR}.
Related
I am using CMake to link and build my C++ project, and in said project I am using the fstream library to read from a file. However, when passing the path of the file to my code, I am forced to use a long string such as "../../../../folder/folder/folder/file" to properly reference which file I want opened. I presume this is because my .exe that CMake creates is buried deep, "far" away from my source code, which is why I would have to backtrack so much.
I am wondering if there is something I could put in my CMakeLists.txt to potentially allow for the shortening of this inclusion path.
To save myself some time I have not included my file structure as of now, but if it is needed in order for a solution to be formed I certainly can edit and add it in. I do not necessarily need a case-specific solution, rather just a generalized method in which I could go about doing this.
It looks like CMake doesn't provide such functionality , CMake doesn't do much with execution of your application.
So, For solution you have following
can either create a shell script to copy the file into the desired location which can be picked by the executable and shell script can be run while make process
pass it as a commandline argument to your c++ executable.
create a macro with this location and use this macro in the source file : - CMake can help you in this
Using add_compile_definitions( ...)
I have run into an issue when writing find scripts. For some reason, automatic appending of suffixes did not work: only library files with .dylib extension were found, however files with .a extension or no extension at all were not.
Practical experimentation lead me to setting CMAKE_FIND_LIBRARY_SUFFIXES to an empty value and restoring the value afterwards. However, this has following effect:
When cmake is run for the first time, generation fails with "CMake Error: Error required internal CMake variable not set, cmake may not be built correctly. Missing variable is CMAKE_FIND_LIBRARY_SUFFIXES".
When I run cmake second time the same way, generation succeeds.
My guess is, things that were found are saved in cache, and the script for finding them is not run the second time.
My question is, how can I work around that issue and ensure that both my framework (that does not have suffixes) is found and cmake does not stop generation?
I am generating on MacOS, for Xcode.
Not sure what is an "official" way for assign a list of a single empty extension, but you may assign a list of two empty extensions:
set(CMAKE_FIND_LIBRARY_SUFFIXES ";")
Unlike to empty value, this assignment would pass possible sanity checks like if(CMAKE_FIND_LIBRARY_SUFFIXES), which probably exists in CMake code as it reports about "Error required internal CMake variable not set".
I am using cmake and cpack and wix to build and deploy my project. The installer has some properties that user can enter via GUI or MSI-command-line options.
I set default property values in my CMakeLists.txt using:
set(CPACK_WIX_PROPERTY_<PROPERTY> <value>)
The problem is that if I change these values, I should rerun cmake command before cpack command.
I am looking for a way to change default value of these properties without need for rerunning cmake.
I tried adding additional wxs files using CPACK_WIX_EXTRA_SOURCES or patching generated files with additional xml files using CPACK_WIX_PATCH_FILE, but couldn't find the right code to put in wxs or xml files to accomplish my goal.
I tried The SetProperty command and found out its behavior is not easy to control, I gave up when I saw the user provided values don't replace the initial values and suggested solution at https://web.archive.org/web/20180205001358/http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Unable-to-override-SetProperty-value-with-Edit-Control-value-td7591569.html didn't work. I hope there is a simple way, but even a complex answer using SetProperty is allright.
I am looking for a way to change default value of these properties without need for rerunning cmake.
A script specified in CPACK_PROJECT_CONFIG_FILE variable is the one, which affects on CPack, but which changing doesn't require cmake to re-run. So you may place setting of CPACK_WIX_PROPERTY_<PROPERTY> here: Changing this setting would require only to re-run CPack without re-run cmake on the main project.
Also, when the script specified in CPACK_PROJECT_CONFIG_FILE variable is parsed, CPACK_GENERATOR variable contains the exact CPack generator which is currently processed. This opposites to behavior of the variable inside CMakeLists.txt, when it contains a list of generators.
Is there a sensible way to get a CMake variable containing the build command or all the compiler flags that CMake will associate with a target?
It doesn't seem practical to try to gather and maintain a list of all properties that could add flags. Besides, CMake must have this info somewhere, since it has to eventually generate a build system.
From the CMake docs it looks like this feature once existed and was provided by calling build_command() but this was replaced:
Note In CMake versions prior to 3.0 this command returned a command
line that directly invokes the native build tool for the current
generator.
Is there a new command that gives the old behavior of build_command()?
Is there a sensible way to get a CMake variable containing the build command or all the compiler flags that CMake will associate with a target?
The answer is no (CMake 3.23 is latest at time of writing), not during the CMake configure step.
In general, such a thing is ill-defined, which is likely why it was removed from CMake and will likely not be re-added. The complications arising from generator expressions, multi-config generators, generators that don't construct command lines (like VS/msbuild), source-file-specific properties, and the simple fact that after the command is called, relevant state might change, all make such efforts quixotic.
Honestly, this is such an odd thing to want at configure time, I wonder if this isn't an XY problem. It's unlikely that one target depends on another in such a way that the entire eventual command line is needed (rather than a particular property) to create it.
I know this is many years later now, but what were you trying to do?
CMake provides many ways post-generation to get information about the compiler command lines.
There's the CMake File API, meant for IDE integration,
The CMAKE_EXPORT_COMPILE_COMMANDS option that creates a Clang-compatible compile_commands.json, and then there's
The CMAKE_<LANG>_COMPILER_LAUNCHER variables that would let you instrument a full command line with a custom script while the build is running.
One of these might be useful. The latter is commonly used with ccache, but can be (ab)used with any arbitrary program as long as the output file is eventually generated.
Note that the latter two only work with the Makefile and Ninja generators.
If you want the final output of how the source files will actually be compiled you will want to look at the generated files. I don't really know a better way currently:
Example:
Here is an example output from Ninja Multi
build\CMakeFiles\impl-Release.ninja
This file will list all of the compile definitions, compiler flags, include directories, object directory, etc.
Under the path "cmake-build-debug/CMakeFiles/" you'll find a folder named as "TopFolderOfYourProject.dir", where the cmake generates all its build system files, including a file "build.make". In this file you can see something like this:
CMakeFiles/somepath/somesourcefile.c
#$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --green --progress-dir=xxx\cmake-build-debug\CMakeFiles --progress-num=$(CMAKE_PROGRESS_1) "Building C object CMakeFiles/somepath/somesourcefile.c.obj"
Besides this, you can find extra info about the flags in the file "flags.make", it contains all extra compiler flags specified by developers.
And in "includes_C.rsp/includes_CXX.rsp" you can see the including path.
Build flags are, actually, associated with source files, because you can have differrent flags for different files. On the other hand, for the most cases these flags are equivalent.
Anyways, to get all build flags for a source file you can use COMPILE_FLAGS property:
get_source_file_property(RESULT file.cpp COMPILE_FLAGS)
Now I am using Firebreath to development my plugin, and I got an issue to use Firebreath pre-defined configure_template function.
As far as I see now, configure_template will substitute the variables referenced as ${VAR} or #VAR# or the ##foreach loop.
but my configure file (nsis installer file) has its own defined variables as ${VAR}, so I don't want it to be substituted by configure_template.
The reason that I use Firebreath pre-defined configure_template instead of configure_file(inputfile outputfile #ONLY) is that I want to use ##foreach loop in my configure file to interpret a semicolon CMAKE variable.
So, how should I solve this issue? Can I easily modify the exist configure_template so as to ignore ${VAR}, or there are alternative ways to interpret a semicolon CMAKE variable in my configure file?
I just figure out one solution myself.
The existing configure_template function provided by Firebreath can be modified to ignore substitute variables like ${VAR}. The modification is simple, which is just one line,
Change the following code
string(CONFIGURE "${line}" line ESCAPE_QUOTES)
to
string(CONFIGURE "${line}" line ESCAPE_QUOTES #ONLY)
The #ONLY parameter will tell CMAKE to only substitute variables like #VAR#.
Though, this can solve the problem of configuring my own file, but this will broke the Firebreath specific configuration file, as they all use ${VAR}.
So, my final solution is
Copy the Firebreath's configure_template.cmake out, rename and modify.
Use the modified version of my_configure_template to serve my purpose, then it won't affect the existing configure_template behaviors.
Any other solutions are welcomed.