I am trying to compile this project: https://github.com/computationalpathologygroup/ASAP.git from source.
Pugixml is a dependency
I have built pugixml from source and set PugiXML_DIR and PUGIXML_INCLUDE_DIR And it still gives me error: "CMake Error: The following variables are used in this project, but they are set to NOTFOUND."
Things I have tried:
I am doing this on windows, using cmake 3.14 and visual studio 2017.
I have successfully built pugixml from source and included the .lib file as well
I have tried including and excluding combinations of PUGIXML_INCLUDE_DIR, PUGIXML_LIBRARY, PugiXML_DIR.
This is the error I get:
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
cpp/ASAP/annotation/PUGIXML_INCLUDE_DIR
used as include directory in directory
/cpp/ASAP/annotation
cpp/ASAP/multiresolutionimageinterface/PUGIXML_INCLUDE_DIR
used as include directory in directory cpp/ASAP/multiresolutionimageinterface
Other information: setting PugiXML_DIR is mandatory, and the cmake looks for a file named "pugixml-config.cmake" in that directory. And the config cmake file is supposed to point to compiled lib file. But when it wasn't able to find, I simply copied the lib file I compiled to the location pugixml-config.cmake was pointing.
In ASAP versions before 4.04.2019 they play dirty games with extracting include directory from the IMPORTED target. annotation/CMakeLists.txt:30:
get_target_property(PUGIXML_INCLUDE_DIR pugixml INTERFACE_INCLUDE_DIRECTORIES)
In some cases this results in setting PUGIXML_INCLUDE_DIR variable to "-NOTFOUND", thus you got corresponded error message from CMake.
In commit 36d8bd75 they add FindPugiXML.cmake script, which handle find_package(PugiXML) call instead of configuration script shipped with PugiXML. In that find script they obtain include directory with find_path, which looks more natually:
find_path(PugiXML_INCLUDE_DIR pugixml.hpp)
Because in newer ASAP versions the configuration script (pugixml-config.cmake), shipped with PugiXML, is no longer used, one cannot hint about PugiXML location with PugiXML_DIR or PugiXML_ROOT. In case PugiXML is installed into non-system-default location, one may simply set PugiXML_INCLUDE_DIR variable to the PugiXML include directory.
Related
I'm trying to build a visual studio c++ project under windows by cmake, there are two cmakelists.txt file in my source, and they are't parent-child relationship, main cmakelists.txt link library and add executable, the other one is only responsible for collating the dependent path to the global variable and passing to main cmakelists.txt file use.
At the beginning of executing cmake script, i pass the build dir path by command line parameter "-B".
Final i got the output file, but the structure of result direcotry puzzled me.Main-cmakelists.txt generate configuration file to build folder that was specified by earlier. But the other one cmakelists.txt, which generate configuration file outside, and one level heigher than specified build folder, and the folder with same name as the folder where sub-cmakelists.txt located.
I tried to find answer in offical documents and book like cmakecookbook, currently, no relevant entry found.
How can i specify the path for the generator ouput of sub-cmakelists.txt? I want to unify same build root folder for all cmakelists.
Is there have some professional tutorial introduction about correspondence between cmake file and vs project file?
Thanks.
enter image description here
The second parameter of add_subdirectory() command, can specify the binary_dir path to place the output file for sub-cmakelist.
I tries to use FOREACH to generated several pb files. And make two list names PROTO_SRCS & PROTO_HDRS like below.
I can use it in the main CMakeLists. Like add_executable(a SHARED ${PROTO_SRCS} main.cpp).
But I can not use this param in subdirectories to make a library. when I type "cmake .." in main CMakelists build dir. It shown that "Cannot find source file: a.pb.cc".
main CMakeLists.txt
add_library(xxx SHARED ${PROTO_SRCS})
add_subdirectory(${CMAKE_CURRENT_SOURCE_DIR}/src/back back)
in src/back CMakeLists.txt
add_executable(yyy ${PROTO_SRCS})
and I can use message to show ${PROTO_SRCS} in subdir so it pass into successfully.
Please help me to point out the problem. Thx a lot
The issue is that in CMake versions older than 3.20 the GENERATED property of source files is only visible in the directory where it is set. Thus, when you add the protobuf-generated source files to a target defined in a different directory, CMake will no longer know that these are files generated during the build. Consequently, CMake will try to locate these files at configuration time, when they obviously do not exist yet.
Unfortunately, at the time of writing there is only a release candidate for CMake 3.20 and no official release yet. So depending on whether you need to coordinate with other coworkers or whether you're working on this project on your own it might not be feasible to use the release candidate.
If you can't use it, the alternative is to create an object library via add_library(protobuf_objs OBJECT ${PROTO_SRCS}) in the directory where you generate the files and to use target_sources(xxx PRIVATE $<TARGET_OBJECTS:protobuf_objs>) and target_sources(yyy PRIVATE $<TARGET_OBJECTS:protobuf_objs>) instead of adding the ${PROTO_SRCS} as source files to these targets directly.
I am trying to run some code from my university, but when I do "cmake .." inside "build" I get the following error:
CMake Error: The following variables are used in this project, but
they are set to NOTFOUND. Please set them or make sure they are set
and tested correctly in the CMake files: iceutil_lib
linked by target "cppgui" in directory /Users/alej/Desktop/project1
linked by target "project1" in directory /Users/alej/Desktop/project1
-- Configuring incomplete, errors occurred!
Any of my friends are getting errors, can you help me?
CMake tries to find all the libraries necessary to create the library or executable you are trying to build from the code from your university.
The found paths to those libraries are stored in special variables in CMake. By default, those variables carry the value <Library-Name>-NOTFOUND. This NOTFOUND flag is what makes CMake prompt the error message.
In general there are two possible reasons, why CMake can not find the library for you:
The library is not installed on your system
The library is installed somewhere CMake did not search for it. In this case you can help CMake by setting the library installation path into the respective CMake variables. To do this, open the file CMakeCache.txt with a text editor and search for ICEUTIL_LIB. Replace the blabla-NOTFOUND value with the actual (absolute) path of the library. There might be other variables with the ICEUTIL prefix. One of them might be named like ICEUTIL_HEADERS or ICEUTIL_INCLUDE_DIR. Replace the value of this one with the absolute path of where the .h files for ICEUTIL are found. If the include path is not set, CMake might run fine without errors, but later you will run into compiler errors saying include file not found.
I have a problem with CMake's AUTOUIC option in my qt project.
I have a target that has *.ui qt-form files and changed it to use the AUTOUIC option to automatically generate the corresponding ui_*.h files and add their location to the target's include directory.
The problem is, that I inlcude the generated "ui_*.h" file in a header of the target, which is then included in another test-target. The test-target however does not have the directory with the generated files set to its include directories and therefore will not find the ui_*.h file.
So is there any way to get the directory of the generated files so I can add it to the INTERFACE_INCLUDE_DIRECTORIES of my first target. When I do this using hardcoded names It solves my compile errors, but I would rather do this by getting that directory from some target property or so. I failed with that because the AUTOUIC include dirs seem to be added only after processing all the CMakeLists files.
Btw., I am currently using CMake 3.8.2, but updating to 3.9 is an option if the problem has been solved there.
From CMake version 3.9 onwards you can use the following snippet to add the autogenerated headers to a target's build interface include directories:
get_property(_isMultiConfig GLOBAL PROPERTY GENERATOR_IS_MULTI_CONFIG)
if(_isMultiConfig)
set(AUTOGEN_INCLUDE_DIR ${CMAKE_CURRENT_BINARY_DIR}/${TARGET_NAME}_autogen/include_$<CONFIG>)
else()
set(AUTOGEN_INCLUDE_DIR ${CMAKE_CURRENT_BINARY_DIR}/${TARGET_NAME}_autogen/include)
endif()
target_include_directories(${TARGET_NAME} INTERFACE
$<BUILD_INTERFACE:${AUTOGEN_INCLUDE_DIR}>
)
See:
Use GENERATOR_IS_MULTI_CONFIG to detect multi-config generators
AUTOUIC
GENERATOR_IS_MULTI_CONFIG
AUTOGEN_BUILD_DIR
I have the same issue - it looks like a bug in CMAKE (I'm using version 3.10 rc5)
and have opened a bug report to CMAKE here: https://gitlab.kitware.com/cmake/cmake/issues/17456
In the meantime you can copy the autgenerated header files to your project source directory by using the following commands after autouic has been run.
SET(AUTOGEN_BUILD_DIR "${CMAKE_BUILD_DIR}/<project>_autogen/include_${CONFIG}")
file(COPY "${AUTOGEN_BUILD_DIR}/ui_xxxx.h" DESTINATION "${CMAKE_SOURCE_DIR}/headers")
where ${CONFIG} is the type of build (Debug/Release)
I want to exclude some source files from building when not in Windows.
What is wrong in the following CMakeLists.txt cmake file?
aux_source_directory(. SRC_LIST)
# Remove Microsoft specific files
message(${SRC_LIST})
list(REMOVE_ITEM SRC_LIST stdafx.h stdafx.cpp)
message("------------------")
message(${SRC_LIST})
The contents of the messages before and after trying to remove the two files are exactly the same.
What is wrong?
You have to specify the exact name of the element you want to remove.
In your case, aux_source_directory prepends each entry with a ./, so the correct command has to be
list(REMOVE_ITEM SRC_LIST ./stdafx.h ./stdafx.cpp)
Also, please make sure you understand the implications of using manual calls to aux_source_directory for maintaining lists of source files:
It is tempting to use this command to avoid writing the list of source
files for a library or executable target. While this seems to work,
there is no way for CMake to generate a build system that knows when a
new source file has been added. Normally the generated build system
knows when it needs to rerun CMake because the CMakeLists.txt file is
modified to add a new source. When the source is just added to the
directory without modifying this file, one would have to manually
rerun CMake to generate a build system incorporating the new file.
Quoting the documentation for aux_source_directory.