I use the conan_cmake_run() macro for CMake. When I add two libs with the same external dep. it results in an error message.
Example:
conan_cmake_run(REQUIRES boost/1.74.0 BASIC_SETUP CMAKE_TARGETS)
conan_cmake_run(REQUIRES hdf5/1.10.6 BASIC_SETUP CMAKE_TARGETS)
Boost and HDF5 will add zlib as an external dep. due to that, this results in the following error message during CMake configure.
CMake Error at build/conanbuildinfo_multi.cmake:152 (add_library):
add_library cannot create imported target "CONAN_PKG::zlib" because another
target with the same name already exists.
Call Stack (most recent call first):
build/conanbuildinfo_multi.cmake:286 (conan_define_targets)
cmake/modules/conan.cmake:515 (conan_basic_setup)
CMakeLists.txt:104 (conan_cmake_run)
Is there a way to explicitly not add the "CONAN_PKG::zlib" for boost/1.74.0 or hdf5/1.10.6?
Thanks a lot in advance!
Best,
It is very important not to run twice the cmake_conan_run, but just once with multiple parameters, something like:
conan_cmake_run(REQUIRES boost/1.74.0 hdf5/1.10.6 BASIC_SETUP CMAKE_TARGETS)
Doing separate runs, the second one will overwrite the results from the previous one. Furthermore, in the installation there could be conflicts (like boost/1.74 depending on zlib/1.2.8 and hdf5/1.10.6 depending on zlib/1.2.11) that would be unnoticed. When installing the dependencies of a project, a single conan install, or a single conan_cmake_run() should be done.
Related
I have python script that is run through add_custom_command in my project, this script analyzes target sources and generate additional one for the target.
get_target_property(TARGET_SOURCES ${target} SOURCES)
add_custom_command(
OUTPUT ${CMAKE_BINARY_DIR}/static_init/generated/${target}/static_init.cpp
COMMAND ${Python3_EXECUTABLE} myscript.py
DEPENDS ${TARGET_SOURCES}
VERBATIM)
target_sources( "${target}" PRIVATE "${CMAKE_BINARY_DIR}/static_init/generated/${target}/static_init.cpp" )
I need my script to rerun when one of sources becomes "dirty" (e.g. one of included headers is changed, probably this file is in another target and it is not guaranteed that another target will be rebuild on header change). As we use Ninja, IMPLICIT_DEPENDS isn't available for us, so it looks DEPFILE property is the way to do it, but I cannot understand, how can I get one for all ${TARGET_SOURCES}?
It doesn't seem to me that ninja will generate something like that automatically, I cannot write it by hands, as it will require to recursively analyze all includes during cmake run. Or maybe there is another way to solve this problem?
To get dependencies of a source you have to compile it. Just depend on the target. I would do:
add_custom_target(target_objects OBJECT all_source_files_for_your_target)
add_custom_command(
OUTPUT ${CMAKE_BINARY_DIR}/static_init/generated/${target}/static_init.cpp
COMMAND ${Python3_EXECUTABLE} myscript.py
DEPENDS $<TARGET_OBJECTS:target_objects>
VERBATIM
)
add_custom_library/executable("${target}" PRIVATE
${CMAKE_BINARY_DIR}/static_init/generated/${target}/static_init.cpp
)
link_target_libraries("${target}" PRIVATE target_objects)
That way the dependencies are linear.
I’m running cmake version 3.23.0-rc1, on ubuntu 20.04.
I built vtk-8.2 from source; cmake, make, then ‘make install’. Now I am trying to find the VTK package for my own application, using cmake’s find_package(VTK). The application’s CMakeLists.txt contains this:
find_package(VTK)
message("VTK_FOUND: ${VTK_FOUND}")
message("VTK_INCLUDE_DIRS: ${VTK_INCLUDE_DIRS}")
message("VTK_LIBRARIES: ${VTK_LIBRARIES}")
Result is that VTK_FOUND=1, VTK_LIBRARIES contains many entries, but VTK_INCLUDE_DIRS is blank/empty. Why would this be?
I do see file /usr/local/lib/cmake/vtk-8.2, which contains many *.cmake files. But I don’t see a corresponding /usr/local/include/cmake directory, despite the presence of /usr/local/include/vtk-8.2. Is that expected? Here is the output:
VTK_FOUND: 1
VTK_INCLUDE_DIRS:
VTK_LIBRARIES: VTK::WrappingTools;VTK::ViewsQt;VTK::ViewsInfovis;VTK::CommonColor;VTK::ViewsContext2D;VTK::loguru;VTK::TestingRendering;VTK::TestingCore;VTK::vtksys;VTK::RenderingQt;VTK::PythonContext2D;VTK::RenderingVolumeOpenGL2;VTK::RenderingOpenGL2;VTK::glew;VTK::opengl;VTK::PythonInterpreter;VTK::Python;VTK::RenderingLabel;VTK::octree;VTK::RenderingLOD;VTK::RenderingImage;VTK::RenderingContextOpenGL2;VTK::IOVeraOut;VTK::hdf5;VTK::IOTecplotTable;VTK::IOSegY;VTK::IOParallelXML;VTK::IOPLY;VTK::IOOggTheora;VTK::theora;VTK::ogg;VTK::IONetCDF;VTK::netcdf;VTK::IOMotionFX;VTK::pegtl;VTK::IOParallel;VTK::jsoncpp;VTK::IOMINC;VTK::IOLSDyna;VTK::IOInfovis;VTK::libxml2;VTK::zlib;VTK::IOImport;VTK::IOGeometry;VTK::IOVideo;VTK::IOMovie;VTK::IOExportPDF;VTK::libharu;VTK::IOExportGL2PS;VTK::RenderingGL2PSOpenGL2;VTK::gl2ps;VTK::png;VTK::IOExport;VTK::RenderingVtkJS;VTK::RenderingSceneGraph;VTK::IOExodus;VTK::exodusII;VTK::IOEnSight;VTK::IOCityGML;VTK::pugixml;VTK::IOAsynchronous;VTK::IOAMR;VTK::InteractionImage;VTK::ImagingStencil;VTK::ImagingStatistics;VTK::ImagingMorphological;VTK::ImagingMath;VTK::GUISupportQtSQL;VTK::IOSQL;VTK::sqlite;VTK::GUISupportQt;VTK::GeovisCore;VTK::libproj;VTK::InfovisLayout;VTK::ViewsCore;VTK::InteractionWidgets;VTK::RenderingVolume;VTK::RenderingAnnotation;VTK::ImagingHybrid;VTK::ImagingColor;VTK::InteractionStyle;VTK::FiltersTopology;VTK::FiltersSelection;VTK::FiltersSMP;VTK::FiltersPython;VTK::FiltersProgrammable;VTK::FiltersPoints;VTK::FiltersVerdict;VTK::verdict;VTK::FiltersParallelImaging;VTK::FiltersImaging;VTK::ImagingGeneral;VTK::FiltersHyperTree;VTK::FiltersGeneric;VTK::FiltersFlowPaths;VTK::FiltersAMR;VTK::FiltersParallel;VTK::FiltersTexture;VTK::FiltersModeling;VTK::FiltersHybrid;VTK::RenderingUI;VTK::DomainsChemistry;VTK::CommonPython;VTK::WrappingPythonCore;VTK::ChartsCore;VTK::InfovisCore;VTK::FiltersExtraction;VTK::ParallelDIY;VTK::diy2;VTK::IOXML;VTK::IOXMLParser;VTK::expat;VTK::ParallelCore;VTK::IOLegacy;VTK::IOCore;VTK::doubleconversion;VTK::lz4;VTK::lzma;VTK::utf8;VTK::FiltersStatistics;VTK::eigen;VTK::ImagingFourier;VTK::ImagingSources;VTK::IOImage;VTK::DICOMParser;VTK::jpeg;VTK::metaio;VTK::tiff;VTK::RenderingContext2D;VTK::RenderingFreeType;VTK::freetype;VTK::kwiml;VTK::RenderingCore;VTK::FiltersSources;VTK::ImagingCore;VTK::FiltersGeometry;VTK::FiltersGeneral;VTK::CommonComputationalGeometry;VTK::FiltersCore;VTK::CommonExecutionModel;VTK::CommonDataModel;VTK::CommonSystem;VTK::CommonMisc;VTK::CommonTransforms;VTK::CommonMath;VTK::CommonCore
find_package(VTK) no longer sets VTK_INCLUDE_DIRS variable. If you look into description part of vtk-config.cmake (script CMake/vtk-config.cmake.in contains template of that file), then you find no note about VTK_INCLUDE_DIRS.
Since VTK_LIBRARIES variable contains IMPORTED targets (in form of VTK::foo), linking with the content of that variable using target_link_libraries will automatically provide include directories.
I have a list of vars definedinside a cmake which is called using from main CMakeLists.txt:
add_custom_target(gen_a
COMMAND ${CMAKE_COMMAND} -P "gen_sigs.cmake"
)
add_dependencies(${PROJECT_NAME} gen_a)
My gen_sigs.cmake:
set(SIG_LIST SIGNAL_A=0 SIGNAL_B=1 SIGNAL_C=0 )
I want to use this list to add preprocessor definitions to the compiler command line like (in main CMakeLists.txt):
add_compile_definitions(
SIGNAL_A=0
SIGNAL_B=1
SIGNAL_C=0
)
I tried using the following but it does not work (in main CMakeLists.txt):
add_compile_definitions(
${SIG_LIST}
)
I am new to cmake so any suggestions on how to make this work will be helpful. Also the add_custom_target is defined before the add_compile_definitions() still it doesn't help. My guess is there is some problem with the order of execution because the ${SIG_LIST} has no value when I am printing it in cmakelists.txt. Is there a way to add dependency to add_compile_definitions so that my add_custom_target command gets forcibly executed before the add_compiler_definitions()?
Your question is not very clear, but from what you've shown, the following should work:
include("${CMAKE_CURRENT_SOURCE_DIR}/gen_sigs.cmake")
target_compile_definitions(main_target PRIVATE ${SIG_LIST})
Adding a custom target defers processing until build time, but what you (appear to) want to do is fundamentally a configure/generation time thing. include() will cause the external script to be executed in the same scope as the call, immediately.
Disclaimer: I'm aware of this question. However, The OP's needs are different to mine: what he actually wants is to port an app to Linux and therefore the answers go in that line, not answering what I want to know: the reasons of the error.
I'm trying to create a dropdown list in CMake GUI following the instructions in here and here
So I have this very simple CMakeLists.txt:
cmake_minimum_required(VERSION 3.6)
project(datasetprograms)
set(CMAKE_CXX_STANDARD 11)
#LINES TO MAKE THE GUI DROP-DOWN:
set(TARGET_ARCHITECTURE “arm” CACHE STRING “Architecture to compile to”)
set_property(CACHE TARGET_ARCHITECTURE PROPERTY STRINGS arm x86)
#Add subdirectories for each project
add_subdirectory(helloworld)
Basically I just copied and pasted, following the instructions. However, instead of having a nice drop-down in the CMake GUI, I got the following error:
CMake Error at CMakeLists.txt:9 (set_property): set_property could
not find CACHE variable TARGET_ARCHITECTURE. Perhaps it has not yet
been created
Question: What I'm doing wrong?
You may check value of variable TARGET_ARCHITECTURE using message() and you will found CACHE is a part of that value.
This is because you use in set() command double quotes which are not common ones (") but language-specific (“). So CMake treats set() command as not CACHE'd one. That is a reason of the error message.
This question is subsequent to my previous one: How to integrate such kind of source generator into CMake build chain?
Currently, the C source file is generated from XS in this way:
set_source_files_properties(${CMAKE_CURRENT_BINARY_DIR}/${file_src_by_xs} PROPERTIES GENERATED 1)
add_custom_target(${file_src_by_xs}
COMMAND ${XSUBPP_EXECUTABLE} ${XSUBPP_EXTRA_OPTIONS} ${lang_args} ${typemap_args} ${file_xs} >${CMAKE_CURRENT_BINARY_DIR}/${file_src_by_xs}
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
DEPENDS ${file_xs} ${files_xsh} ${_XSUBPP_TYPEMAP_FILES}
COMMENT "generating source from XS file ${file_xs}"
)
The GENERATED property let cmake don't check the existence of this source file at configure time, and add_custom_target let the xsubpp always re-run at each compile. The reason for always rerun is because xsubpp will generate an incomplete source file even if it fails, so there are possibility that the whole compiling continues with an incomplete source file.
I found it is time consuming to always re-run source generator and recompile it. So I want to have it re-run only when dependent XS files are modified. However, if I do so, the incomplete generated source file must be deleted.
So my question is: is there any way to remove the generated file, only when the program exit abnormally at compile time?
Or more generic: is there any way to run a command depending on another command's exit status at compile time?
You can always write a wrapper script in your favorite language, e.g. Perl or Ruby, that runs xsubpp and deletes the output file if the command failed. That way you can be sure that if it exists, it is correct.
In addition, I would suggest that you use the OUTPUT keyword of add_custom_command to tell CMake that the file is a result of executing the command. (And, if you do that, you don't have to set the GENERATED property manually.)
Inspired by #Lindydancer's answer, I achieved the purpose by multiple COMMANDs in one target, and it don't need to write an external wrapper script.
set(source_file_ok ${source_file}.ok)
add_custom_command(
OUTPUT ${source_file} ${source_file_ok}
DEPENDS ${xs_file} ${xsh_files}
COMMAND rm -f ${source_file_ok}
COMMAND xsubpp ...... >${source_file}
COMMAND touch ${source_file_ok}
)
add_library(${xs_lib} ${source_file})
add_dependencies(${xs_lib} ${source_file} ${source_file_ok})
The custom target has 3 commands. The OK file only exists when xsubpp is success, and this file is added as a dependency of the library. When xsubpp is not success, the dependency on the OK file will force the custom command to be run again.
The only flaw is cross-platform: not all OS have touch and rm, so the name of these two commands should be decided according to OS type.