[CMake] Project not built when I specify exclude_from_default_build in CMake
Hi there
I build an executable A. I have set up another target A_remote that uses a
custom launcher for remote debugging with Visual Studio. What I'm trying to
achieve is that before the A_remote target is run, another target is run that
deploys files to the remote computer. So I add a custom target run_deploy that
runs a batch file, and make A_remote depend on it. As run_deploy also copies
image files which aren't part of the VS solution, I want it to always run
before launching A_remote.
However, when I build the entire solution, I don't want VS to build anything
related to remote debugging, which is why I use EXCLUDE_FROM_DEFAULT_BUILD. But
when I do that, and build A_remote, VS tells me
1>-- Skipped Build: Project: run_deploy, Configuration: Debug x64 --
1>Project not selected to build for this solution configuration
Here's a sample CMakeLists.txt.
cmake_minimum_required(VERSION 3.11.0 FATAL_ERROR)
file(WRITE main.cpp "int main(){return 0;}\n")
file(WRITE deploy.bat "echo Deploying!\n")
add_executable(A main.cpp)
add_executable(A_remote main.cpp)
add_custom_target(run_deploy "${CMAKE_SOURCE_DIR}/deploy.bat")
set_target_properties(run_deploy PROPERTIES EXCLUDE_FROM_DEFAULT_BUILD 1)
add_dependencies(A_remote run_deploy)
The documentation
https://cmake.org/cmake/help/latest/prop_tgt/EXCLUDE_FROM_DEFAULT_BUILD.html
says "Exclude target from Build Solution." This might have been the intention,
but the way it is implemented seems to do more than that.
Anyways, how can I achieve that run_deploy is always built when I build
A_remote, but not when I build the solution or ALL_BUILD? Is that even
possible? Is there a workaround?
Cheers,
Andreas
Follow this link to read our Privacy
Statement<https://www.stryker.com/content/stryker/gb/en/legal/global-policy-statement.html/>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake link order
Hey all,
I face a similar problem when constructing a correct (and predictable)
link order for Linux and Cygwin. It would be of great help, if there is
some documentation.
In particular, I would raise two question
1) when does the link order change?
2) when does a clean up happen and in which way?
I did also some experiments on linux with cmake 3.13.4 and ended up with
the appended (nearly) minimal example. The example consists of:
* two "fake"-libraries A and B, whose paths are stored in two
variables libA and libB respectively. (they serve just for
demonstration, no real linking is required)
* two interface libraries interfaceA and interfaceB. Each links to the
corresponding fake library.
* two imported libraries impA and impB, each has the location to the
corresponding fake library.
Now I construct some combinations:
1. An interface library interfaceA_B_vA, which links against the
interface libraries "interfaceA interfaceB ${libA}" and an
executable, which links only against interfaceA_B_vA. For that
executable, I get the link order "B A"
2. Suppose one tries to correct that and link explicitly against with
the variable. Such an executable which links as "${libA}
interfaceA_B_vA". In that case, I got the link order "A A B". So we
have a changed order compared to the previous experiment.
3. If I use the imported libraries instead of the variables from
experiment 1, I get the link order A B A, as expected.
From these experiments, I got the impression, that
1. linking through variables remains a nightmare. That is nothing new.
2. interface libraries might change their order
3. imported libraries lead to a more stable link order?
I hope somebody could shed some light in this behavior.
Best regards,
Andreas
Am 18.10.19 um 18:24 schrieb Fred Baksik:
On Fri, Oct 18, 2019, at 11:55 AM, Fred Baksik wrote:
In target_link_libraries it states that "The library dependency graph
is normally acyclic (a DAG)". I recall from my own experience that
the DAG is not always created the same way when generating the
project. It has to do with the way with this part of CMake is
implemented (C++ containers and that sort of thing) so while all the
inputs are the same the order is Not the same so it produces a
different DAG which changed the ordering of the components build
order which also altered the link order.
For the GHS Generator to ensure that the exact same project files are
output we sorted the components by name into a vector first (instead
of just using a set) before supplying it to this algorithm. Then the
results were always the same.
Sorry, I wanted to clarify this a bit. The DAG is correct. For
example lets say A depends on B and C and then C on D. This DAG
always comes out the same. But when you try to extract the dependents
of A it sometimes returns something that will give you B then C or C
then B when accessing them in a linear order. So there were
differences if you inspected these items with the debugger.
When I ran across these kinds of things with the GHS Generator we sort
things in lexicographical order to produce the same results every time.
Best regards,
Fred
project(testLinkOrder)
cmake_minimum_required(VERSION 3.5)
file(WRITE "simpleProg.cc" "int main() { return 0; }")
set(libA "${CMAKE_BINARY_DIR}/A.a")
file(WRITE "${libA}" "i am not a library")
set(libB "${CMAKE_BINARY_DIR}/B.a")
file(WRITE "${libB}" "i am not a library")
add_library(impA IMPORTED STATIC)
set_target_properties(impA PROPERTIES IMPORTED_LOCATION ${libA})
add_library(impB IMPORTED STATIC)
set_target_properties(impB PROPERTIES IMPORTED_LOCATION ${libB})
add_library(interfaceA INTERFACE)
target_link_libraries(interfaceA INTERFACE ${libA})
add_library(interfaceB INTERFACE)
target_link_libraries(interfaceB INTERFACE ${libB})
#target_link_libraries(interfaceA INTERFACE ${libB})
add_library(interface_A_B_vA INTERFACE)
target_link_libraries(interface_A_B_vA INTERFACE interfaceA interfaceB ${libA})
add_executable(linkInterface_A_B_vA simpleProg.cc)
target_link_libraries(linkInterface_A_B_vA interface_A_B_vA)
add_executable(linkvA_IABAVA simpleProg.cc)
target_link_libraries(linkvA_IABAVA ${libA} interface_A_B_vA)
add_library(interface_impA_impB_vA INTERFACE)
target_link_libraries(interface_impA_impB_vA INTERFACE impA impB ${libA})
add_executable(linkInterface_impA_impB_vA simpleProg.cc)
target_link_libraries(linkInterface_impA_impB_vA interface_impA_impB_vA)
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting
Re: [CMake] How to specify Redhat Developer Toolset compiler?
You could set the environment variables CXX and CC such that they point to your toolset compiler Am 20.06.19 um 17:39 schrieb David Aldrich: My Centos 7.6 machine has CMake 3.13.5 and g++ 4.8.5 installed: $ /usr/bin/x86_64-redhat-linux-g++ --version x86_64-redhat-linux-g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36) I have a very simple CMakeLists.txt: cmake_minimum_required(VERSION 3.5 FATAL_ERROR) project(hello_world LANGUAGES CXX) add_executable(hello_world "") target_sources(hello_world PRIVATE main.cpp Message.hpp Message.cpp) I also have Redhat Developer Toolset 7 installed which I can enable in my bash shell: $ scl enable devtoolset-7 bash $ which g++ /opt/rh/devtoolset-7/root/usr/bin/g++ $ g++ --version g++ (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5) How can I get CMake to use the later version of g++ instead of 4.8.5? -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] How can I automatically optionally build a submodule?
For me, this sounds more like foo is an independent thing and not a subdirectory. In this case, I think about two solutions: 1) Use a macro/function "check_yada", which sets a variable "yada_usable". If you extract this logic in an extra .cmake file, you can reuse it in your yada CMakelists.txt 2) Use foo as an external project. But thats looks like a major change in the project structure. Am 27.03.19 um 20:05 schrieb Steve Keller: "Albrecht Schlosser" wrote: If you want yadda to be optional then don't use REQUIRED. find_package(yadda) if (yadda_FOUND) message(STATUS "found yadda, building bar ...") # add your code to build bar here endif () This should do what you want - unless I misunderstood your question. This will roughly do what I want, but I think it does not correctly express things. For the sub-project, yadda is not optional, and if I call cmake in that sub-project's directory, it should fail. What I think would be appropriate would be a command add_subdirectory_optional(...) or add_subdirectory_and_ignore_errors(...) or something similar. Steve -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Correct Boost version found, linked against wrong one
orrect files, i.e., 1.66? Or is the "DSO missing from command line" another problem? All I found about that is that boost_system should be added, but that's already the case. cmake version is 3.5.2 Can you run make with VERBOSE=1 and give as the output please? To me it looks like, that cmake discards the library directory and links with -lboost_filesystem instead of the fullpath. This happened in my environment whenever the environment variable LIBRARY_DIR contains the boost library directory. Nevertheless, you should unset LIBRARY_DIR with cmake. Otherwise, the compiler gcc will treat the folders in this variable as system folders. Thanks, Florian Hth, Andreas -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about functions
Am 18.02.19 um 20:43 schrieb workbe...@gmx.at:
Hi everyone,
i have a function like:
FUNCTION(checksyste_64Bit arg1)
IF(CMAKE_SIZEOF_VOID_P EQUAL 8)
SET(${arg1} TRUE PARENT_SCOPE)
ENDFUNCTION()
but when i call it with an INTERNAL variable i've set before with
SET(SYSTEM_64BIT FALSE CACHE INTERNAL)
checksystem_64bit(${SYSTEM_64BIT})
the ${SYSTE_64BIT} variable stays the same, i thought when i use
PARENT_SCOPE on a variable i can change it's value from inside the
function ?
best regards!
You should call your function without dollar and braces around the
variable, i.e.
checksystem_64bit(SYSTEM_64BIT)
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Re: [CMake] fixup-bundle usability
Thank you very much for your explaination. At the moment, I link only to
boost and some in-house libraries. When experimenting with CMake and
reading the docs, I got the same impression as you described. And I
hoped to miss something obvious.
When I understand you correctly, one have to set the directories from
hand. Furthermore there are additional variables (in case of VTK), which
contain the library directories. But modern CMake works with targets and
properties and let the dependencies propagate.
To test the idea a little bit, I startet with the following function
function(setBundle targetName dest)
install(TARGETS ${targetName} DESTINATION ${dest})
get_target_property(targtDeps ${targetName} LINK_LIBRARIES)
file(TO_CMAKE_PATH "${CMAKE_INSTALL_PREFIX}" instPref)
set(depDirs )
foreach(t IN LISTS targtDeps)
#disable the INTERFACE target due to error later.
if(TARGET ${t} AND NOT ("${t}" STREQUAL "Boost::disable_autolinking"))
get_target_property(isImported ${t} IMPORTED)
if(isImported)
get_target_property(depFile ${t} IMPORTED_LOCATION_DEBUG)
if(depFile)
get_filename_component(cdepDir ${depFile} DIRECTORY)
list(APPEND depDirs ${cdepDir})
endif()
endif()
endif()
endforeach()
install(CODE "include(BundleUtilities)
fixup_bundle(\"${instPref}/${dest}/$\"
\"\" \"${depDirs}\")")
endfunction()
It is far away from optimal and has some drawbacks, especially the
detection of interface libraries and the location of the imported target
should be more fail proof.
How can I ask for feature requests on gitlab? I found the issue tracker,
but nothing in regard for a feature or improvement.
Andreas
Am 18.02.19 um 15:56 schrieb Francis Giraldeau:
You are right, the fixup bundle is difficult to use. Here are some
undocumented tips:
Put the install(CODE) with the fixup_bundle() call in a CMakeLists.txt
in its own directory. In your main CMakeLists.txt file, add this
directory with add_subdirectory() last. This install(CODE) will run
after all the other install directive, otherwise the fixup_bundle()
might run before other targets are installed.
The main thing is to build the library path variable. Yes, this
information can be recovered from the target itself, but
fixup_bundle() won't gather that info for you. Here is an example with
Qt:
get_target_property(QT_CORE_LIBQt5::CoreLOCATION)
get_filename_component(QT_RUNTIME_DIR"${QT_CORE_LIB}"DIRECTORY)
list(APPENDLIBS_PATH"${QT_RUNTIME_DIR}")
If you are using VTK, there is already a variable:
list(APPENDLIBS_PATH"${VTK_RUNTIME_LIBRARY_DIRS}")
You might as well run windeployqt (and similar tool for other
platforms) inside install(CODE) script if you have a Qt app, such that
the styles and the plugins and other stuff gets copied.
execute_process(COMMANDwindeployqt.exe--release\"\${MAIN_APP}\")
Workaround wrong tool detection using MinGW on Windows:
if(WIN32ANDNOTMSVC)
set(GP_TOOL"objdump")
endif()
install(CODE "\
...
include(BundleUtilities)
set(gp_tool\"${GP_TOOL}\")
fixup_bundle(\"\${MAIN_APP}\"\"\"\"${LIBS_PATH}\")
...
And there is the escaping... You have to escape quotes inside
the script. Escape the '$' sign if you want to refer to the
variable at install time. Remember that you don't have access
to configure-time variables at install time. Unescaped '$' prefix
will be replaced by its value at configure time, somewhat like
a macro or a template.
To see the generated script, look into ${CMAKE_BINARY_DIR} with
the directory name corresponding to the CMakeLists.txt containing
the install(CODE). Example:
${CMAKE_SOURCE_DIR}/cmake/bundle/CMakeLists.txt
-> ${CMAKE_BINARY_DIR}/cmake/bundle/cmake_install.cmake
You can check the generated script, its very
handy when things go wrong.
Also, it is easier to put all libraries and binaries in their
own directory. I have this near the begining of my project's
CMakeLists.
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY${CMAKE_BINARY_DIR}/lib)
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY${CMAKE_BINARY_DIR}/lib)
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY${CMAKE_BINARY_DIR}/bin)
If you have some library that you don't want in your bundle,
you might want to disable install for it, for instance,
google test:
add_subdirectory(3rdparty/googletest/EXCLUDE_FROM_ALL)
I'm using "ntldd.exe -R" on Windows to check the dependencies manually
(its very much like ldd on Linux). It is much more handy than
dependency walker.
Fixup_bundle is not magical either. The library dependencies must be
known beforehand. It means that if you do some dlopen() tricks at
runtime, fixup_bundle() cannot know that and you will have to install
these libraries manually yourself. One notable example of this is
Intel MKL using the Single Dynamic Library (mkl_rt). Using this
library entry point simp
Re: [CMake] Question about set
Hey, I would introduce a list with the allowed values and introduce a macro "checked_set", which tests the setting or aborts. Regards, Andreas Am 18.02.19 um 15:06 schrieb workbe...@gmx.at: Hi everyone, i've looked the web but found no result. I need a string variable that allows only certain values, like bool variables only allow true/false my string should be either "A" or "B" ... best regards! -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Static libraries depending on libraries: only on headers/options/defines
Hi Paul, I understand the relationship between libraries as strict, such that you always build all dependent libraries before. In your use case I thought about splitting the libraries in the actual target and the interface one. For example, you could create an interface library foo_interface add_library(foo_interface INTERFACE ) set the properties and then link foo and bar to this interface library using target_link_libraries. But be aware, that now every executable, which links against bar must manually link against foo. If your project is large, this seems not really desirable. But I think you could also split the library bar in two bar_withoutFoo and bar. The library bar_withoutFoo would link against foo_interface and compile the sources, whereas bar is an interface library which depends on bar_withoutFoo and foo. The developer could than build bar completely independent from foo and you could transport the transitive dependencies to the executable. I don't know if this doubled structure using pure interfaces libraries and the actual libraries is maintainable. Hope that helps a bit, Andreas Am 16.02.19 um 20:20 schrieb Paul Smith: Hi all; I'm working on modernizing our large complex CMake environment. It builds a number of different binaries from an even larger number of static libraries, and these libraries depend on each other as well, in that they need to include headers and, sometimes, -D options etc. I've used straightforward target_link_libraries() to declare the relationship between these libraries; for example: add_library(foo STATIC ...) target_include_directories(foo PUBLIC ...) target_compile_definitions(foo PUBLIC ...) target_compile_options(foo PUBLIC ...) add_library(bar STATIC ...) target_link_libraries(bar PUBLIC foo) add_executable(one ...) target_link_libraries(one PRIVATE bar) This works, in that everything builds properly but it has a side-effect we want to avoid. Because the source tree is large many developers have a habit of testing compilation of subsets of the code using something like: make -jX bar and expect it to just build the static library bar. Because it's a static library you don't need to actually build "foo" until link time. But we do need all the include directories, compile definitions, and compile options to be inherited from "foo" into "bar". However with the above formulation, building "bar" also forces the compilation of "foo", which we don't need or want. I've played around with the different values of PUBLIC, PRIVATE, and INTERFACE but there doesn't seem to be a straightforward way to say, "take the interface values for includes, definitions, and options, but don't depend on the generated target". I can write a function to do this myself but this seems like the most common way someone would want to treat static libraries referencing other static libraries, so I wondered if I was missing something that would allow this in a simpler way. Thanks! -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
[CMake] fixup-bundle usability
Dear CMakers, recently I tried to bundle an application in Windows. From the documentation [1] I see that I should provide the directories to the non-system libraries. But these information should be already in the properties of the targets, arent they? Is there any extension in cmake, that provides these paths? How do other users handle dependencies to external dlls? [1] https://cmake.org/cmake/help/v3.0/module/BundleUtilities.html Regards, Andreas -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] How is ARGN passed to a macro
Hey Torsten,
Am 21.11.18 um 13:15 schrieb Torsten Robitzki:
Hi,
I’ve stumbled over following behavior and now I’m searching for the rules, that
explains that behavior:
test.cmake:
macro(check_argn)
message("in macro check_argn ARGN: ${ARGN}")
if(ARGN)
foreach(item IN LISTS ARGN)
message("ARG: ${item}")
endforeach(item)
message("ARGN: ${ARGN}")
endif()
endmacro()
function(f1 a)
message("in function ARGN: ${ARGN}")
check_argn()
endfunction()
f1(1)
f1(1 2)
This will yield the following output:
$ cmake -P ./test.cmake
in function ARGN:
in macro check_argn ARGN:
in function ARGN: 2
in macro check_argn ARGN:
ARG: 2
ARGN:
I would expect ARGN to behave exactly the same in the macro, as in the
function, but apparently there is a difference. Can someone of you explain that
to me?
I think the behavior is explained in [1] and [2]. In particular the
second section of [2] states that the parameter " [...] such as ARGN are
not variables in the usual CMake sense. They are string replacements
[...]". And the example at the end of [2] seems to match your test
perfectly.
Hope that helps a bit,
Andreas
[1] https://cmake.org/cmake/help/latest/command/function.html
[2] https://cmake.org/cmake/help/latest/command/macro.html
TIA and kind regards,
Torsten
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
[CMake] Bundling Qt5 with CMake on Linux
Hi, I'm currently trying to find a good approach to bundling Qt5 with my application on Linux using CMake (and CPack to create tar.gz). It appears this topic isn't covered very well - or I'm using the wrong search keywords. What I have right now is copying the different plugins that are needed by the application into the install directory, then run fixup_bundle over the executable passing the Qt library directory and the plugins in the install location. In addition to that a qt.conf is written. Now this has a few problems: - BundleUtilities decides to put the qt libraries into the bin/ folder where the executable is, that requires a more complicated qt.conf since the location of plugins and libraries relative to one another is not the same as in the Qt installation directory - BundleUtilities decides to strip rpath and runpath from the copied libraries, this is a major problem since the Qt libraries depend on icu-libraries which are not found anymore without the runpath they have originally ($ORIGIN) It appears both of these are not configurable which makes me wonder if anybody here is using BundleUtilities at all on Linux for bundling Qt5. If not, what are you using instead? I could live with the libraries in the bin/ folder instead of the lib/ folder but the second point is a problem. I shortly looked at the linuxdeployqt project (https://github.com/probonopd/linuxdeployqt) but that only helps when wanting to ship an AppImage or AppDir, but since I'm looking at creating a package from a couple of binaries all using Qt that's not an option either. Andreas -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Moving static library to separate project
Dear Chris, you have several ways to cope with that. First, you should write a MyLogConfig.cmake-File [2], which imports your static library as import library [1] and sets the include path. The same file also defines the dependency on pthread via target_link_library. Your project with the executable then uses find_package(MyLog ) to insert the library into the project. The second way uses the install(Export ...) directive to create export files. These files contain the transitivie dependencies and the include paths at once. In this case, your executable project has to use the export-File via find_file / input. Hope that helps a little bit, Andreas [1] https://cmake.org/cmake/help/v3.5/command/add_library.html [2] https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html Am 25.09.2018 um 23:58 schrieb Christopher E Robison: I've got a situation I've searched for answers on, and though I've found similar questions, I've found no generally-applicable answers, or at least ones I can use. Apologies in advance for a beginner-level question. I have a group of applications that all use some common functionality I've located in a static library (for logging in this case). we'll call it libmylog here. Libmylog is pretty simple, but at some point I wanted to solve some thread safety situations, so I included some synchronization features that now require me to link with pthreads. Easy enough, "target_link_libraries(mylog pthread)" takes care of it. I've recently begun developing a separate application which doesn't belong in the same tree, and so I've put it in its own new project. I've decided I'd like this new application to use libmylog as well, and so now I've moved mylog into its own separate project too. I've added install directives and the library (libmylog.a) and its header file end up in the correct spots in /usr/local when I do a "make install". Looks good so far. The problem is when I compile any of my executables, the link fails with undefined reference errors since after removing libmylog from the same build tree every application I've written that uses it must now link with libpthread as well. This is an odd thing to have to specify for small utilities that don't have threads and shouldn't need to care about them. I look at libmylog.a with nm and all the references to pthreads symbols are undefined. More critically, it seems that since the build process for libmylog doesn't generate an executable, the "target_link_libraries(mylog pthread) line is now _silently ignored_. What is the Right Way of dealing with this in CMake? I'd like a way to tell the linker to force the inclusion of the relevant code in the static library, but if there's a more canonical approach I'd appreciate the advice. (For example, do I need to [learn how to] create a CMake "package" for my libmylog installation -- would this help propagate the -lpthread requirement to the build for the executables?) Thanks! Chris -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Beginners Guide to Cmake and Modern Cmake
Dear space & and the rest of the cmake world :) i just googled for "modern cmake" and came up with at least two interesting talks from cppcon and boostcon: https://www.youtube.com/watch?v=bsXLMQ6WgIk=youtu.be=37m15s https://www.youtube.com/watch?v=eC9-iRN2b04 Their slides can be found at https://github.com/CppCon/CppCon2017/blob/master/Tutorials/Using%20Modern%20CMake%20Patterns%20to%20Enforce%20a%20Good%20Modular%20Design/Using%20Modern%20CMake%20Patterns%20to%20Enforce%20a%20Good%20Modular%20Design%20-%20Mathieu%20Ropert%20-%20CppCon%202017.pdf https://github.com/boostcon/cppnow_presentations_2017/blob/master/05-19-2017_friday/effective_cmake__daniel_pfeifer__cppnow_05-19-2017.pdf I just slipped through them, but they look like the right way. Another nice summary is at https://gist.github.com/mbinna/c61dbb39bca0e4fb7d1f73b0d66a4fd1#file-effective_modern_cmake-md Wish you a nice weekend, Andreas Am 27.07.2018 um 01:54 schrieb Space: Dear Cmake world, I am wanting to learn how to use Cmake correctly and I would like to implement Modern Cmake (the latest version and techniques). Currently I have a project that was intended for use on windows machine but I want to run/develop it on Mac and am also interested to make it overall cross platform. On Mac I'll use Visual Studio Code and Xcode (preferably VSC). Here is a link to the GitHub for the current project of interest: https://github.com/AcademyOfInteractiveEntertainment/aieBootstrap Dependencies are: glfw glm imgui stb openGL (gl_core_4_4.c/h) I have visited the cmake.org site and looked at the tutorials, they teach old cmake 2.8 but shouldn't there be material that teaches the Modern way. I know about the documentation that has made an effort to show some of the modern practices but to a person, new to cmake, my brain just shuts down to the reference styled documents, and yes, but thats what the documentation is; a reference list. I then found the webinars, but much disappoint, they are dated back to March 2012 ( a great effort for its time but left me confused; not modern). We are now end of July 2018. It would be great to see a webinar completely refreshed, which is directed at the complete beginner and makes an effort to teach Modern Cmake in todays world. It would also be nice to understand how to bridge the gap between old 2.8 cmake and the latest cmake. For example: Making proper use of find_package etc... I hope this is an interesting topic to be reviewed, regards, Space -- Sent from: http://cmake.3232098.n2.nabble.com/ -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] conditions and included subprojects
I think, I missunderstood some parts. In particular, why should the user have to change the CMakeLists.txt? He/she can set the value at the commandline or in the cmake-gui and your CMakelist sees the value of your option and can react to that. Gesendet: Montag, 11. Juni 2018 um 10:55 Uhr Von: "Cornelis Bockemühl" An: "Andreas Naumann" , cmake@cmake.org Betreff: Re: [CMake] conditions and included subprojects Thanks for your proposals! Actually my problem is basically that I want to keep up with some minimum good practice, but I am seeing myself throwing it over board constantly if I do not find a logical solution after one or two hours of struggling... Your second option is close to what I am currently implementing - basically just hard-code the option into the sub-project and let the user adapt the CMakeLists.txt before starting cmake. A bit "brute force", not nice, certainly not "good practice" - but works! However, what I imagine is rather like this - from a user perspective: - if the user goes into the main project with cmake-gui, he will see THAT_OPTION with a default value and of course the option to change it. In this case, the sub-project should be built without further bothering the user with options - just take it from the main project. The point is that the option will have an effect for both the main and the sub project, but it has to be the same in both. - if the user goes directly into the sub project with cmake-gui, he should also see THAT_OPTION, but now it would come from the CMakeLists.txt of the sub project. Again with a default value and the option to change it. My guess is that I would need an additional "flag" variable that tells the sub project whether it is now being built within the main project or standalone. Again not so nice, but besides the "brute force solution" (hardcoded) the only one that I can see to do it more nicely... Regards, Cornelis Am Montag, den 11.06.2018, 10:44 +0200 schrieb Andreas Naumann: Dear Cornelis, your description looks to me like having a three valued option: ON, OFF, UNDEFINED. But an option in cmake language has only two values: ON or OFF. To solve your problem with the connection between your sub-project and the main project, you should forget about the main project and concentrate on the sub project only. Than, you have two possibilities: 1) Keep the three state variable "THAT_OPTION". Set it to undefined at the very beginning and check later with if(DEFINED THAT_OPTION) With this variant, you can handle the "I forgot to set it"-case. But your user will not see it as an option in the cmake gui. Your main project will set it, as desired. 2) Use an initial value for the option. Now, it is always defined, there is no need to check for the source. It is the responsibility of the user to set the option appropriately. I think, the second version is the easiest way. Regards, Andreas Gesendet: Montag, 11. Juni 2018 um 10:20 Uhr Von: "Cornelis Bockemühl" An: cmake@cmake.org Betreff: [CMake] conditions and included subprojects Dear CMake users, Maybe my question is trivial for most, but still I do not find an answer on my own! If you have a project and some sub-project (or module or whatever the jargon is) that are both managed with CMake, they should be in separate directories (directory trees), and each of them have a CMakeLists.txt in the root directory, where the sub-project is "included" into the main project with an ADD_DIRECTORY() etc. So far so clear. But then I learned that it is good practice to ensure that the sub-project would also be "buildable" with cmake separately. My problem is about how to pass options from the main to the sub project in such a way that this is working properly, i.e.: - if the sub project is part of the main project it would simply take over the option from the main project level - but if the sub project is being built standalone, the option is not defined and should be set e.g. in cmake-gui If I write now in the sub project IF(THAT_OPTION) ... this will be true if THAT_OPTION was set to ON in the main project. So far so good. But the _expression_ is now so "clever" that it cannot distinguish between THAT_OPTION being set to OFF in the main project, or THAT_OPTION not being defined at all - like in a standalone build! One way would be to have an additional option or variable BUILDING_MAINPROJECT which is set to ON or TRUE in the main project and can be checked. However, I have so far not seen any CMakeLists.txt with such a code, so ... what are the experts doing in such a case? Thanks and regards, Cornelis -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake commu
Re: [CMake] conditions and included subprojects
Dear Cornelis, your description looks to me like having a three valued option: ON, OFF, UNDEFINED. But an option in cmake language has only two values: ON or OFF. To solve your problem with the connection between your sub-project and the main project, you should forget about the main project and concentrate on the sub project only. Than, you have two possibilities: 1) Keep the three state variable "THAT_OPTION". Set it to undefined at the very beginning and check later with if(DEFINED THAT_OPTION) With this variant, you can handle the "I forgot to set it"-case. But your user will not see it as an option in the cmake gui. Your main project will set it, as desired. 2) Use an initial value for the option. Now, it is always defined, there is no need to check for the source. It is the responsibility of the user to set the option appropriately. I think, the second version is the easiest way. Regards, Andreas Gesendet: Montag, 11. Juni 2018 um 10:20 Uhr Von: "Cornelis Bockemühl" An: cmake@cmake.org Betreff: [CMake] conditions and included subprojects Dear CMake users, Maybe my question is trivial for most, but still I do not find an answer on my own! If you have a project and some sub-project (or module or whatever the jargon is) that are both managed with CMake, they should be in separate directories (directory trees), and each of them have a CMakeLists.txt in the root directory, where the sub-project is "included" into the main project with an ADD_DIRECTORY() etc. So far so clear. But then I learned that it is good practice to ensure that the sub-project would also be "buildable" with cmake separately. My problem is about how to pass options from the main to the sub project in such a way that this is working properly, i.e.: - if the sub project is part of the main project it would simply take over the option from the main project level - but if the sub project is being built standalone, the option is not defined and should be set e.g. in cmake-gui If I write now in the sub project IF(THAT_OPTION) ... this will be true if THAT_OPTION was set to ON in the main project. So far so good. But the _expression_ is now so "clever" that it cannot distinguish between THAT_OPTION being set to OFF in the main project, or THAT_OPTION not being defined at all - like in a standalone build! One way would be to have an additional option or variable BUILDING_MAINPROJECT which is set to ON or TRUE in the main project and can be checked. However, I have so far not seen any CMakeLists.txt with such a code, so ... what are the experts doing in such a case? Thanks and regards, Cornelis -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] problem with CMake not including library's path (with pkg-config)
Dear Francesco,
I use the pkg-config module with IPopt and had the same problem.
According to the documentation, the library paths are in
_LIBRARY_DIRS. In your case, you should find the paths in the
variable AGG_LIBRARY_DIRS or all flags in the variable AGG_LDFLAGS .
Regards,
Andreas
Am 24.05.2018 um 18:48 schrieb Francesco Abbate:
Hi all,
I stumbled in a problem with CMake. Everything is working fine except
that, for two libraries that I locate with pkg-config, cmake does not
include during linking the library's path (-L) which is given by
pkg-config.
Here an extract of the CMakeLists.txt:
[...]
include(FindPkgConfig)
pkg_search_module(AGG REQUIRED libagg)
[...]
target_link_libraries(libcanvas ${AGG_LIBRARIES})
target_include_directories(libcanvas PUBLIC
${PROJECT_SOURCE_DIR}/include ${AGG_INCLUDE_DIRS})
[...]
When I run pkg-config everything is correct:
pkg-config --libs libagg
-Lc:/fra/local_msys64/lib -lagg -lm
One can notice that pkg-config provides a non-standard path for the library.
By inspecting CMakeCache.txt I found a trace of the library's path.
See below an extract:
AGG_CFLAGS:INTERNAL=-Ic:/fra/local_msys64/include/agg2
AGG_CFLAGS_I:INTERNAL=
AGG_CFLAGS_OTHER:INTERNAL=
AGG_FOUND:INTERNAL=1
AGG_INCLUDEDIR:INTERNAL=c:/fra/local_msys64/include/agg2
AGG_INCLUDE_DIRS:INTERNAL=c:/fra/local_msys64/include/agg2
AGG_LDFLAGS:INTERNAL=-Lc:/fra/local_msys64/lib;-lagg;-lm
AGG_LDFLAGS_OTHER:INTERNAL=
AGG_LIBDIR:INTERNAL=c:/fra/local_msys64/lib
AGG_LIBRARIES:INTERNAL=agg;m
AGG_LIBRARY_DIRS:INTERNAL=c:/fra/local_msys64/lib
AGG_LIBS:INTERNAL=
AGG_LIBS_L:INTERNAL=
AGG_LIBS_OTHER:INTERNAL=
AGG_LIBS_PATHS:INTERNAL=
AGG_PREFIX:INTERNAL=c:/fra/local_msys64
AGG_STATIC_CFLAGS:INTERNAL=-Ic:/fra/local_msys64/include/agg2
AGG_STATIC_CFLAGS_I:INTERNAL=
AGG_STATIC_CFLAGS_OTHER:INTERNAL=
AGG_STATIC_INCLUDE_DIRS:INTERNAL=c:/fra/local_msys64/include/agg2
AGG_STATIC_LDFLAGS:INTERNAL=-Lc:/fra/local_msys64/lib;-lagg;-lm
AGG_STATIC_LDFLAGS_OTHER:INTERNAL=
AGG_STATIC_LIBDIR:INTERNAL=
AGG_STATIC_LIBRARIES:INTERNAL=agg;m
AGG_STATIC_LIBRARY_DIRS:INTERNAL=c:/fra/local_msys64/lib
AGG_STATIC_LIBS:INTERNAL=
AGG_STATIC_LIBS_L:INTERNAL=
AGG_STATIC_LIBS_OTHER:INTERNAL=
AGG_STATIC_LIBS_PATHS:INTERNAL=
AGG_VERSION:INTERNAL=2.5.0
AGG_libagg_INCLUDEDIR:INTERNAL=
AGG_libagg_LIBDIR:INTERNAL=
AGG_libagg_PREFIX:INTERNAL=
AGG_libagg_VERSION:INTERNAL=
but in the Ninja build file the library's path is not given (below an extract):
--
#
# Link the executable tests\test-window.exe
build tests/test-window.exe: CXX_EXECUTABLE_LINKER__test-window tests/CMakeFiles
/test-window.dir/test-window.cpp.obj | win32/liblibcanvaswin32.a src/liblibcanva
s.a || src/liblibcanvas.a win32/liblibcanvaswin32.a
LINK_LIBRARIES = win32/liblibcanvaswin32.a src/liblibcanvas.a -lagg
-lm -lfreetype -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32
-lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32
So the behavior of CMake looks wrong to me. Pkg-config is giving
explicitly a non-standard library path but CMake just decided to not
include it in the linker options.
To finish let me report that I'am using CMake 3.11.1 on a Windows
system using MSYS2.
I can also mention that a similar Meson build just works fine but this
is only to make you, CMake guys, jealous.
Ok, just kidding :-)
Thank you in advance for any help.
Kind regards
Francesco
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake on Raspberry Pi
Hi, On Sun, May 20, 2018 at 08:35:31PM -0400, cmake-requ...@cmake.org wrote: > Date: Mon, 21 May 2018 08:11:13 +0800 > From: Shawn G <shawn0...@gmail.com> > Hi there, im having some troubles installing CMake on raspberry pi 3 > running raspbian stretch. > I keep getting this error message when i run the command "sudo apt-get > install build-essential cmake pkg-config" > The error message: > " Reading package lists... Done > Building dependency tree > Reading state information... Done > Package CMake is not available, but is referred to by another package. > This may mean that the package is missing, has been obsoleted, or > is only available from another source > > E: Package 'cmake' has no installation candidate " # apt-cache policy cmake cmake: Installed: 3.7.2-1 Candidate: 3.7.2-1 Version table: *** 3.7.2-1 500 500 http://raspbian.raspberrypi.org/raspbian stretch/main armhf Packages 100 /var/lib/dpkg/status (possibly your /etc/apt/sources* setup does not have working/updated info for stretch/main repo?) HTH, Andreas Mohr -- Das "S" in "IoT" steht für "Security" [Signatur von betateilchen: https://forum.fhem.de/index.php/topic,23008.msg163661.html#msg163661 ] -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake does not find module, though it's in MODULE_PATH
Dear Florian,
please note, that CMake expects the variable CMAKE_MODULE_PATH not as an environment variable, but as a CMake variable. So, you could do something like
set(CMAKE_MODULE_PATH $ENV{CMAKE_MODULE_PATH})
before calling find_package(Eigen3)
But there are other ways, according to stackoverflow https://stackoverflow.com/questions/12249140/find-package-eigen3-for-cmake .
Regards,
Andreas
Gesendet: Montag, 07. Mai 2018 um 11:28 Uhr
Von: "Florian Lindner" <mailingli...@xgm.de>
An: "cmake@cmake.org" <cmake@cmake.org>
Betreff: [CMake] CMake does not find module, though it's in MODULE_PATH
Hello,
my CMake 3.6.2 complains about not finding FindEigen3.cmake
CMake Error at CMakeLists.txt:62 (find_package):
By not providing "FindEigen3.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "Eigen3", but
CMake did not find one.
Could not find a package configuration file provided by "Eigen3" with any
of the following names:
Eigen3Config.cmake
eigen3-config.cmake
Add the installation prefix of "Eigen3" to CMAKE_PREFIX_PATH or set
"Eigen3_DIR" to a directory containing one of the above files. If "Eigen3"
provides a separate development package or SDK, be sure it has been
installed.
However, it's clearly there in ls $CMAKE_MODULE_PATH/FindEigen3.cmake
I try to use it like find_package(Eigen3 REQUIRED)
What else could be wrong there?
Thanks!
Florian
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Re: [CMake] FindMPI & policy CMP0004
Thank you for the hint, and I run in a similiar problem. Building from scratch solved the issue. Sorry for the noise. Am 11.03.2018 um 23:07 schrieb Craig Scott: This could be a case of needing to clear out an old CMake cache. That problem you mentioned was supposed to have been fixed already. You can find the updated discussion of the Mantis issue you linked to in gitlab here <https://gitlab.kitware.com/cmake/cmake/issues/11881> where someone else had a situation that sounds similar to yours. On Mon, Mar 12, 2018 at 7:16 AM, Andreas Naumann <andreas-naum...@gmx.net <mailto:andreas-naum...@gmx.net>> wrote: Dear all, recently, I got a problem with FindMPI on our HPC systems. With cmake 3.10.2, I get an error about policy CMP0004. And I cannot set it to OLD anymore. Is this intended? Exactly the same error, together with a patch, is described in the bugtracker https://public.kitware.com/Bug/view.php?id=11881 <https://public.kitware.com/Bug/view.php?id=11881> I cannot reproduce the error easiliy. On my home system, it works. But on the hpc system, mpicc -showme:link returns -L/lib -lmpi -ldl -lm -lnuma -Wl,--export-dynamic -lrt -lnsl -lutil -lm -ldl so, we have exactly one -Wl, part and libraries otherwise. It looks to me, that the patch from the bugtracker should avoid the problem. Can somebody confirm this finding? The problem gets even worse with newercmake versions. With cmake 3.9, I can set policy cmp0004 to OLD, so FindMPI remains usable. With newer cmake versions, ie. 3.10.2, the policy setting seems to get deprecated. So, the user won't get any way to use newer cmake with such a bug. What is the preferred way to resolve such an issue, when the policy setting is not allowed anymore? Regards, Andreas -- Powered by www.kitware.com <http://www.kitware.com> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ <http://www.cmake.org/Wiki/CMake_FAQ> Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html <http://cmake.org/cmake/help/support.html> CMake Consulting: http://cmake.org/cmake/help/consulting.html <http://cmake.org/cmake/help/consulting.html> CMake Training Courses: http://cmake.org/cmake/help/training.html <http://cmake.org/cmake/help/training.html> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html <http://www.kitware.com/opensource/opensource.html> Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake <https://cmake.org/mailman/listinfo/cmake> -- Craig Scott Melbourne, Australia https://crascit.com -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
[CMake] FindMPI & policy CMP0004
Dear all, recently, I got a problem with FindMPI on our HPC systems. With cmake 3.10.2, I get an error about policy CMP0004. And I cannot set it to OLD anymore. Is this intended? Exactly the same error, together with a patch, is described in the bugtracker https://public.kitware.com/Bug/view.php?id=11881 I cannot reproduce the error easiliy. On my home system, it works. But on the hpc system, mpicc -showme:link returns -L/lib -lmpi -ldl -lm -lnuma -Wl,--export-dynamic -lrt -lnsl -lutil -lm -ldl so, we have exactly one -Wl, part and libraries otherwise. It looks to me, that the patch from the bugtracker should avoid the problem. Can somebody confirm this finding? The problem gets even worse with newercmake versions. With cmake 3.9, I can set policy cmp0004 to OLD, so FindMPI remains usable. With newer cmake versions, ie. 3.10.2, the policy setting seems to get deprecated. So, the user won't get any way to use newer cmake with such a bug. What is the preferred way to resolve such an issue, when the policy setting is not allowed anymore? Regards, Andreas -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] RPATH for pkg-config
What about using a FindPETSC-Module? Some hints are
*http://jacobmerson.com/2016/01/17/cmake-petsc2.html
*http://www.mcs.anl.gov/petsc/documentation/faq.html#cmake
Regards,
Andreas
Am 03.01.2018 um 21:35 schrieb Alexander Neundorf:
On 2018 M01 3, Wed 10:08:09 CET Franck Houssen wrote:
Hello,
How to ask cmake to add a library path (coming from pc file) to rpath ?
I checked this https://cmake.org/Wiki/CMake_RPATH_handling, but still not
working. Can somebody help ?
more main.cpp
#include
int main(int argc, char ** argv) {
PetscInitialize(, , NULL, "");
PetscFinalize();
return 0;
}
more CMakeLists.txt
cmake_minimum_required(VERSION 3.7)
enable_language(CXX)
find_package(MPI REQUIRED)
find_package(PkgConfig REQUIRED) # Get pkg_check_modules.
pkg_check_modules(PETSc REQUIRED PETSc)
project(main)
add_executable(main main.cpp)
target_include_directories(main PUBLIC ${MPI_CXX_INCLUDE_PATH})
target_link_libraries(main PUBLIC ${MPI_CXX_LIBRARIES})
target_include_directories(main PUBLIC ${PETSc_INCLUDE_DIRS})
foreach(lib ${PETSc_LDFLAGS})
target_link_libraries(main PUBLIC ${lib})
endforeach(lib)
How does each ${lib} look like ?
Is it "-lpetsc" or does it have the full path to the libraries ?
You should use the full path to the libraries, otherwise cmake doesn't know
where they are and the RPATH computation will not work.
foreach(dir ${PETSc_LIBRARY_DIRS})
link_directories(main PUBLIC ${dir}) # Not sure: is this needed ?
endforeach(dir)
no, link_directories() in general should not be used.
# use, i.e. don't skip the full RPATH for the build tree
SET(CMAKE_SKIP_BUILD_RPATH FALSE)
# when building, don't use the install RPATH already
# (but later on when installing)
SET(CMAKE_BUILD_WITH_INSTALL_RPATH FALSE)
SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")
If the automatic computation fails, you could add the petsc lib dir here as
INSTALL_RPATH
Alex
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
[CMake] cmake-server, path length for pipe
Hey cmakers, I use visual studio code with the extension "vscode-cmake-tools" [1]. This extension uses the cmake-server functionality, Recently, I have encountered the strange error message [cmake-server] CMake Error: Internal Error with /release/.cmserver.18775: EADDRINUSE where the length of longPath is 101 characters. The same error is also discussed in the issue 197 in [2]. After that, I did two small tests using the cmake server. Starting from the longPath above, I tried cmake -E server --experimental --pipe=`pwd`/release/foo and cmake -E server --experimental --pipe=./release/foo The first test led to the error, whereas the second one worked. Is there a path length restriction for the cmake server? And there is an error in the cmake-server manpage. The pipe argument is "--pipe= " instead of "--pipe " I used cmake version 3.9.5. Regards, Andreas [1] https://github.com/vector-of-bool/vscode-cmake-tools/ [2] https://github.com/vector-of-bool/vscode-cmake-tools/issues/197 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] absolute library path, sorry for the question
your problem is hard to analyse. If you have a "minimal" example, which shows this behavior, we could test it. In your last mail, you wrote about building and installing libtiff using your own libjpeg. But than you write about a later build. So something must happen in the "later build". Interesting enough, you said, that with newer systems, you do not have this problem. Do these old systems use a different cmake version? Seasons Greetings, Andreas Am 22.12.2017 um 17:42 schrieb Mario Emmenlauer: Can anyone help to force cmake use absolute paths? On 13.12.2017 11:45, Mario Emmenlauer wrote: Thank you for your reply!! Your explanation is very helpful for writing my own CMakeLists.txt. But in my case, I use the standard CMakeLists.txt that comes with the libraries. For example libtiff, turbojpeg, thrift, and many others... As an example, I build libtiff in the following way: cmake ../$TIFFVERSION \ -Wno-dev \ -G"Unix Makefiles" \ -DCMAKE_PREFIX_PATH="$THIRDPARTYTARGETDIR" \ -DCMAKE_INSTALL_PREFIX="$THIRDPARTYTARGETDIR" \ -DCMAKE_BUILD_TYPE="Release" \ -DBUILD_SHARED_LIBS="ON" \ -Djpeg="ON" \ -DJPEG_INCLUDE_DIR="$THIRDPARTYTARGETDIR/include" \ -DJPEG_LIBRARY="$THIRDPARTYTARGETDIR/lib/libjpeg.so" && \ make VERBOSE="1" && make install In the build log, I can see that cmake detects the jpeg library to be '$THIRDPARTYTARGETDIR/lib/libjpeg.so'. However, in the later build, the Makefile links with '-ljpeg' instead of '$THIRDPARTYTARGETDIR/lib/libjpeg.so'. And this in turn will make 'ld' use '/usr/lib/x86_64-linux-gnu/libjpeg.so' instead of my thirdparty libjpeg. So at some point between FindJPEG.cmake and the final Makefile, cmake changed the JPEG_LIBRARIES variable from absolute to relative. And I can not understand why or when this happens. The documentation also does not help me, because it explains that this should happen 'if the full path is not know or if the full path is one of the system library dirs' (see https://cmake.org/pipermail/cmake/2015-September/061462.html). In my case, I override to use jpeg with a known, existing path that is not a system library. All the best, Mario On 13.12.2017 11:12, Bo Zhou wrote: Hi CMAKE_SKIP_RPATH usually is used for the shared module which might want to have the customized distributed path such as within the application. According personal experience on POSIX systems (Linux, UNIX, OSX), always enable CMAKE_SKIP_RPATH for the all local shared dependencies, and to the final distribution, (if needed) put shared libraries into the lib folder of distribution. According your description, I'm not sure how did you pick up your library into the application from CMake, usually we have to make sure the CMake always chooses the libraries from 3rd-party directory not system or another places. In our system, it has a variable THIRDPARTY_DIR for command FIND_PATH() to locate the folder which contains the all built libraries, then use HINTS and NAMES in the command FIND_PATH() and FIND_LIBRARY() to locate the correct paths for the pre-built libraries, so the linking should be okay. If everything has no error, but just the application always picks up the system's library not the 3rd-party libraries we prepared, one solution would add another loader script for the application, from the loader script it appends the local lib folder to LD_LIBRARY_PATH, then launch the actual application executable file. A lot of commercial application on Linux solve the similar issue by this way. Wish my reply is helpful. Thank you very much. On Wed, Dec 13, 2017 at 6:06 PM, Mario Emmenlauer <ma...@emmenlauer.de <mailto:ma...@emmenlauer.de>> wrote: Dear cmake users, I have found good documentation on the cmake wiki about RPATH and its different variables, and also on the mailing lists. But somehow it still does not add up for me. Can you please help? I use cmake 3.9.5 on different platforms, CentOS 6 and Ubuntu 14.04 amongst others. I build many standard libraries (like tiff and jpeg) into my own thirdparty directory, and set CMAKE_PREFIX_PATH to find them there. On newer Linux and Windows, cmake uses always the absolute path to those libraries, and everything works fine. But on older Linux like Ubuntu 14.04 and CentOS 6 it does not. cmake will first find the library in the correct absolute thirdparty directory, and I can confirm this by printing the 'XXX_LIBRARIES' variable in the find script. But later the Makefile will link with '-lxxx' instead of the full path. This makes 'ld' use the system library instead! I completely fail to understand at what point cmake changes XXX_LIBRARIES from an absolute path to
Re: [CMake] Please update the documentation for execute_process
Am 25.08.2017 um 16:12 schrieb Jeffrey Walton:
Below is a typical case for us
(https://github.com/weidai11/cryptopp/blob/master/CMakeLists.txt). If
it looks pretty shitty, it probably is. That's the best we have been
able to come up with based on the documentation.
Below is the example code. We don't know whether it should be:
set(SHELL_CMD sh)
set(SHELL_ARGS -c)
set(GREP_CMD egrep)
set(GREP_ARGS -i -c)
execute_process(COMMAND ${SHELL_CMD} ${SHELL_ARGS}
"${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} ${GREP_ARGS} "amd64"
OUTPUT_VARIABLE CRYPTOPP_AMD64
OUTPUT_STRIP_TRAILING_WHITESPACE)
Or:
COMMAND "${SHELL_CMD}", "${CMAKE_CXX_COMPILER}", "-dumpmachine", "2>&1"
Or:
COMMAND "${SHELL_CMD}" "${CMAKE_CXX_COMPILER}" "-dumpmachine" "2>&1"
Or:
set(SHELL_CMD sh)
set(GREP_CMD egrep)
execute_process(COMMAND ${SHELL_CMD} "-c" "${CMAKE_CXX_COMPILER}
"-dumpmachine" "2>&1"
COMMAND ${GREP_CMD} ${GREP_ARGS} "-i" "-c" "amd64"
OUTPUT_VARIABLE CRYPTOPP_AMD64
OUTPUT_STRIP_TRAILING_WHITESPACE)
And we certainly don't know what to do with "2>&1" because there is no example.
The documentation states
"If OUTPUT_VARIABLE or ERROR_VARIABLE are given the variable named will
be set with the contents of the standard output and standard error pipes
respectively. If the same variable is named for both pipes their output
will be merged in the order produced
so I would suspect to use something like
execute_process(COMMAND "${CMAKE_CXX_COMPILER}"
"-dumpmachine" OUTPUT_VARIABLE output_dump ERROR_VARIABLE output_dump)
and then use a
if( output_dump MATCHES "amd64" )
..
endif()
block
Does that work?
Jeff
**
set(SHELL_CMD sh -c)
set(GREP_CMD egrep -i -c)
execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} "amd64"
OUTPUT_VARIABLE CRYPTOPP_AMD64
OUTPUT_STRIP_TRAILING_WHITESPACE)
execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} "x86_64"
OUTPUT_VARIABLE CRYPTOPP_X86_64
OUTPUT_STRIP_TRAILING_WHITESPACE)
execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} "i.86"
OUTPUT_VARIABLE CRYPTOPP_I386
OUTPUT_STRIP_TRAILING_WHITESPACE)
# http://github.com/weidai11/cryptopp/issues/466
execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} "mingw32"
OUTPUT_VARIABLE CRYPTOPP_MINGW32
OUTPUT_STRIP_TRAILING_WHITESPACE)
# http://github.com/weidai11/cryptopp/issues/466
execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} "w64-mingw32"
OUTPUT_VARIABLE CRYPTOPP_MINGW64
OUTPUT_STRIP_TRAILING_WHITESPACE)
execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} "x32"
OUTPUT_VARIABLE CRYPTOPP_X32
OUTPUT_STRIP_TRAILING_WHITESPACE)
execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} "Aarch32"
OUTPUT_VARIABLE CRYPTOPP_AARCH32
OUTPUT_STRIP_TRAILING_WHITESPACE)
execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} "Aarch64"
OUTPUT_VARIABLE CRYPTOPP_AARCH64
OUTPUT_STRIP_TRAILING_WHITESPACE)
# http://stackoverflow.com/q/12515462/608639
execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} "\\"
OUTPUT_VARIABLE CRYPTOPP_ARM
OUTPUT_STRIP_TRAILING_WHITESPACE)
execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} "ARMHF"
OUTPUT_VARIABLE CRYPTOPP_ARMHF
OUTPUT_STRIP_TRAILING_WHITESPACE)
execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} "ARM7L"
OUTPUT_VARIABLE CRYPTOPP_ARM7L
OUTPUT_STRIP_TRAILING_WHITESPACE)
# Fixup?
if ("${CRYPTOPP_MINGW64}" STREQUAL "1")
unset(CRYPTOPP_MINGW32)
endif()
# MinGW32
if ("${CRYPTOPP_MINGW32}" STREQUAL "1")
set(CRYPTOPP_I386 "1")
endif()
# OpenBSD and MinGW64
if ("${CRYPTOPP_X86_64}" STREQUAL "1" OR "${CRYPTOPP_MINGW64}" STREQUAL "1")
set(CRYPTOPP_AMD64 "1")
endif()
# arm7l is another 32-bit hard float machine. RPI-3 is arm7l on 64-bit hardware
if ("${CRYPTOPP_ARM}" STREQUAL "1" OR "${CRYPTOPP_ARM7L}" STREQUAL "1")
set(CRYPTOPP_ARMHF "1")
endif()
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] /path/to/libpng.so automatic conversion to -lpng ?
Dear Rene,
cmake instrospects your compiler and asks for system directories. Only
these system directories will be removed and the corresponding libraries
will be linked by -l<...>. So, you should check your compiler and the
environment. I had several problems years ago with the environment
variable LIBRARY_PATH, which leads to such a behavior.
Regards,
Andreas
Am 12.07.2017 um 13:38 schrieb René J.V. Bertin:
Hi,
I have a target_link_libraries command that uses ${PNG_LIBRARIES} and thus
*should* add something like `/path/to/libpng.so /path/to/libz.so` to the linker
command. Instead, I am getting a linker command line that has `-lpng -lz`,
which fails for me because the `/path/to` in question isn't on the standard
library search path.
Is there a cmake feature that does this automatic conversion, and if so how can
I turn it off?
Thanks,
René
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [cmake-developers] Response files with IAR compiler on windows
Thanks, Daniel. I opened a pull request for the issue. Best regards, Andreas On 5/22/2017 9:10 AM, Daniel Pfeifer wrote: Hi Andreas, could you please make a pull request on Gitlab? See here for the preferred way for contributions: https://gitlab.kitware.com/cmake/cmake/blob/master/CONTRIBUTING.rst Cheers, Daniel On Sun, May 21, 2017 at 11:52 PM, Andreas Weis <der_ghul...@ghulbus-inc.de <mailto:der_ghul...@ghulbus-inc.de>> wrote: Hi, We are using the IAR toolchain for cross-compiling parts of our builds and encountered a problem when we recently enabled response files for our Windows builds. It seems that the syntax used for the response file flags on the IAR compilers is wrong, we needed to insert a space after the '-f' to make it work. I attached a patch that fixes the problem in our environment. We are building with the 'Unix Makefiles' generator from a Cygwin shell in Windows. Can someone confirm that this is a proper fix for our issues and whether it would make sense to have the patch merged into the CMake trunk? Thanks & best regards, Andreas -- Powered by www.kitware.com <http://www.kitware.com> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ <http://www.cmake.org/Wiki/CMake_FAQ> Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html <http://cmake.org/cmake/help/support.html> CMake Consulting: http://cmake.org/cmake/help/consulting.html <http://cmake.org/cmake/help/consulting.html> CMake Training Courses: http://cmake.org/cmake/help/training.html <http://cmake.org/cmake/help/training.html> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html <http://www.kitware.com/opensource/opensource.html> Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers <http://public.kitware.com/mailman/listinfo/cmake-developers> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] Response files with IAR compiler on windows
Hi,
We are using the IAR toolchain for cross-compiling parts of our builds
and encountered a problem when we recently enabled response files for
our Windows builds. It seems that the syntax used for the response file
flags on the IAR compilers is wrong, we needed to insert a space after
the '-f' to make it work.
I attached a patch that fixes the problem in our environment.
We are building with the 'Unix Makefiles' generator from a Cygwin shell
in Windows. Can someone confirm that this is a proper fix for our issues
and whether it would make sense to have the patch merged into the CMake
trunk?
Thanks & best regards,
Andreas
Index: share/cmake-3.8/Modules/Compiler/IAR-C.cmake
===
--- share/cmake-3.8/Modules/Compiler/IAR-C.cmake(revision 15921)
+++ share/cmake-3.8/Modules/Compiler/IAR-C.cmake(working copy)
@@ -7,7 +7,7 @@
set(CMAKE_C_CREATE_PREPROCESSED_SOURCE "
--preprocess=cnl ")
set(CMAKE_C_CREATE_ASSEMBLY_SOURCE "
-lAH -o .dummy")
-set(CMAKE_C_RESPONSE_FILE_LINK_FLAG "-f")
+set(CMAKE_C_RESPONSE_FILE_LINK_FLAG "-f ")
set(CMAKE_DEPFILE_FLAGS_C "--dependencies=ns ")
# The toolchains for ARM and AVR are quite different:
Index: share/cmake-3.8/Modules/Compiler/IAR-CXX.cmake
===
--- share/cmake-3.8/Modules/Compiler/IAR-CXX.cmake (revision 15921)
+++ share/cmake-3.8/Modules/Compiler/IAR-CXX.cmake (working copy)
@@ -7,7 +7,7 @@
set(CMAKE_CXX_CREATE_PREPROCESSED_SOURCE "
--preprocess=cnl ")
set(CMAKE_CXX_CREATE_ASSEMBLY_SOURCE "
-lAH -o .dummy")
-set(CMAKE_CXX_RESPONSE_FILE_LINK_FLAG "-f")
+set(CMAKE_CXX_RESPONSE_FILE_LINK_FLAG "-f ")
set(CMAKE_DEPFILE_FLAGS_CXX "--dependencies=ns ")
if("${IAR_TARGET_ARCHITECTURE}" STREQUAL "ARM")
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [CMake] Cross project include/link pathing?
Dear Chris, your description looks like the perfect example for ExternalProject_add. Than, every library would be a project. Inside each library, it looks for its dependency using find_package() and exports the dependency chain. Your CMakeLists.txt of the application than has two possibilities: a) simply assume, that the library is installed in a (known) location -> use find_package as described above and proceed as is. b) build the library as an external project. In this case, your application has to be an external project with dependency to the external project of the library. Hope that helps you and describes at least the idea, Andreas Am 09.02.2017 um 22:26 schrieb Chris Johnson: We've been using CMake for a couple of years for C++ application building. We effectively set up our CMake project structure once, and mostly only change it to add new source files, etc. Currently, all C++ source is checked out of our SVN repository into one large tree. This tree actually contains multiple applications. Many, but not all, depend on libraries which are also in this same source tree checkout. Executables are statically linked to the libraries. Our source tree has grown to the point where this arrangement really does not make sense, and is quite far from best practices. We want to move to a more project-oriented structure, where there will be multiple projects, but where the libraries are still shared. How do I go about this? In particular, how do I structure each project to find the common, shared (but statically linked) libraries? I would assume that each library itself or the collection of libraries would be a project, with a top-level CMakeLists.txt file. Note that each project could be installed in its own unique location in its deployed VM or container, so placing the libraries into, say, hard-coded /usr/local/lib is not a feasible solution for us. Pictorially (use fixed width font for best results): = Current single source tree layout - . |-- CMakeLists.txt |-- application_1/ | `-- CMakeLists.txt |-- application_2/ | |-- CMakeLists.txt | |-- util_1/ | | `-- CMakeLists.txt | |-- util_2/ | | `-- CMakeLists.txt | `-- util_3/ | `-- CMakeLists.txt `-- lib/ |-- CMakeLists.txt |-- lib_1/ | `-- CMakeLists.txt `-- lib_2/ `-- CMakeLists.txt Desired project-oriented layout --- [Application 1 Project] . `-- CMakeLists.txt [Application 2 Project] . |-- CMakeLists.txt |-- util_1/ | `-- CMakeLists.txt |-- util_2/ | `-- CMakeLists.txt `-- util_3/ `-- CMakeLists.txt [Libraries Project] . |-- CMakeLists.txt |-- lib_1/ | `-- CMakeLists.txt `-- lib_2/ `-- CMakeLists.txt Presently, all of the applications know where to find the library header files, because they are all in the same tree. When we run "cmake ." at the root of the source checkout, CMake knows where everything is, and correctly provides the include paths to C++ compiler. Similarly, at link time, CMake has automatically determined where the compiled static libraries are, and our CMakeLists.txt files only need mention them by name. CMake has been brilliant at making this kind of stuff simple. But how do I make CMake generate the correct include and link paths when "cmake ." is run on some individual project's source code, when those paths will be outside the current tree, i.e. elsewhere? ..chris -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Platform-independent config package
Dear Ghis, the easiest long-term fix would be an own glmConfig.cmake file. The command write_basic_package_version_file uses a template with those pointer checks. The glm-developers could simply copy the template to their source directory, remove the unneeded lines and run the configure_file command themself on the changed template. The short solution for debian would be a patch file,which just uncomments the last 5 lines. Regards, Andreas Am 10.01.2017 um 19:52 schrieb Ghislain Vaillant: Dear all, I am currently hit by an issue with the CMake detection of a header-only library [1]. The library is built on a 64-bit machine and packaged for all other architectures supported by Debian. However, CMake detection fails on 32-bit platforms with the following error: ``` Any attempt to call `find_package(glm REQUIRED)` produces the following error: ``` Could not find a configuration file for package "glm" that is compatible with requested version "". The following configuration files were considered but not accepted: /usr/lib/cmake/glm/glmConfig.cmake, version: 0.9.8 (64bit) ``` How can this be effectively solved? Can the bit-ness detection be dropped somehow? It should not be needed for a header-only target. Cheers, Ghis [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850277 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Find Vulkan on 32 bit builds
Hello,
Am 08.01.2017 um 07:22 schrieb Saad Khattak:
Hello,
When I run "find_package(VULKAN)" in a CMakeLists for a Visual Studio
2015 32-bit project, the ${Vulkan_LIBRARY} and ${Vulkan_LIBRARIES}
variables both point to the "Bin" folder for the Vulkan installation
instead of the "Bin32" folder.
I looked at the FindVulkan.cmake module and even put MESSAGE(STATUS
...) on the "elseif(CMAKE_SIZEOF_VOID_P EQUAL 4)" to see if I made a
mistake setting up. The message does indeed print confirming that my
pointer size is 4 and thus the current toolchain selected is 32 bit.
What's perplexing is that when I do a MESSAGE(STATUS
${Vulkan_LIBRARY}) the path is:
D:/VulkanSDK/1.0.37.0/Bin/vulkan-1.lib <http://1.0.37.0/Bin/vulkan-1.lib>
instead of
D:/VulkanSDK/1.0.37.0/Bin32/vulkan-1.lib
<http://1.0.37.0/Bin32/vulkan-1.lib>
It makes no sense. Line 47 of FindVulkan.cmake has Bin32. Why is CMake
ignoring 32?
You should think the other way around: Why should cmake look in a
special directory, when it finds a library with an appropriate name
before this one?
This decision should be in the corresponding FindVulkan.cmake, i.e. the
corresponding find_library call should be constrained to
${VULKAN_DIR}/Bin32 in the 32bit case.
Regards,
Andreas
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] target_link_libraries is using relative path of library
Hello,
on Linux cmake treats system directorys specially, i.e. those libraries
are linked without any path.
Furthermore there are environment variables, whose content is added to
the set of system directories.
I do not work on Windows, but your problem looks like a smiliar problem.
Does some of the environment variables (except path) contain your
directory?
Hope that helps,
Andreas
Am 08.01.2017 um 04:01 schrieb Saad Khattak:
Hello,
This is a very strange behavior I am encountering. I am using CMake
3.7.1 with Visual Studio 2015. I have the following as part of a
CMakeLists file:
find_library(glfw_LIB_D glfw3_d ${glfw_LIBRARIES})
find_library(glfw_LIBglfw3 ${glfw_LIBRARIES})
When I do "message(STATUS ${glfw_LIB_D})" I get the full absolute
path. However, when I add an executable that depends on the library:
add_executable(vk_test src/vulkan_test.cpp )
target_link_libraries(vk_test ${glfw_LIB_D})
CMake puts the relative path when I look at my project's project
properties:
..\install\glfw\lib\glfw_d.lib
I also tried the following:
target_link_libraries(vk_test
"${CMAKE_SOURCE_DIR}/install/glfw/lib/glfw_d.lib")
And it's still a relative path. Because of this issue, my project will
not compile as Visual Studio is looking for the library in the
incorrect folder.
I even set the following, thinking that somehow relative paths got set:
set(${CMAKE_USE_RELATIVE_PATHS} FALSE FORCE)
I still got the same relative path. What is going on?
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] CMake 3.7.1 gui fails to launch
Hi,
On Fri, Jan 6, 2017 at 6:41 PM, <da...@daryllee.com> wrote:
> As it turns out, no, I can't use Qt5. In fact, I'd love to hear from anyone
> who actually has. I find this in Modules/FindQt.make:
That module is specifically only for applications wanting to support
Qt3 and Qt4 at the same time.
> ===
> if (Qt_FIND_VERSION)
> if (Qt_FIND_VERSION MATCHES "^([34])(\\.[0-9]+.*)?$")
> set(DESIRED_QT_VERSION ${CMAKE_MATCH_1})
> else ()
> message(FATAL_ERROR "FindQt was called with invalid version
> '${Qt_FIND_VERSION}'. Only Qt major versions 3 or 4 are supported. If you do
> not need to support both Qt3 and Qt4 in your source consider calling
> find_package(Qt3) or find_package(Qt4) instead of find_package(Qt)
> instead.")
> endif ()
> endif ()
> ===
>
> So I re-installed Qt4, rebuilt CMake (./bootstrap --qt-gui, make, sudo make
> install) and still got the same runtime failure.
Well, Qt5 isn't found through a find-module but rather through the
module-mode (or whatever it was called). Qt5 ships with cmake-specific
files that allow cmake to find it as long as its installed in a common
prefix (like /usr) or the installation directory is specified via
CMAKE_PREFIX_PATH. I suspect if you look at the CMakeLists.txt file
you'll see some logic to lookup Qt5 with something like
find_package(Qt5 MODULES QtCore QtGui QtWidgets) and a fallback for
finding with FindQt4 like find_package(Qt4 MODULES QtCore QtGui
QtWidgets). I don't think you'll find usage of the FindQt module in
the cmake sources as the code likely won't build with Qt3.
Andreas
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] CMake 3.7.1 gui fails to launch
Hi, On Fri, Jan 6, 2017 at 4:41 PM, <da...@daryllee.com> wrote: > CMake suite maintained and supported by Kitware (kitware.com/cmake). > daryl@eve-ldb:~/cmake/cmake-3.7.1$ cmake-gui > cmake-gui: symbol lookup error: cmake-gui: undefined symbol: > _ZN9QListData11detach_growEPii > == > > That looks like a Qt linkage error. Any suggestions on resolving this? Right, in particular it means that cmake-gui uses that symbol but none of the libraries loaded into the executable have it. I'd start with checking what ldd says is being loaded for your cmake-gui executable. Maybe there's another Qt installation in LD_LIBRARY_PATH that is being used for running cmake-gui even though its been built against the Qt in /usr/. The other common cause could be the inverse of that, its trying to run against your system Qt but the build process has picked up a Qt from elsewhere compiled with different flags that change the symbols name. Andreas -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[cmake-developers] Native C# support in CMake
Hi, i was wondering if you plan to support C# as language. Currently we are using a custom tailored set of command lines for building but it becomes more and more difficult when complexer requirements surface. Regards, Andreas Roth Development Engineer FAST Protect GmbH Siemensstrasse 16/1 88048 Friedrichshafen Germany -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [CMake] CMAKE_C++_CREATE_SHARED_LIBRARY missing
Hi, On Sun, Jul 10, 2016 at 12:00:02PM -0400, cmake-requ...@cmake.org wrote: > Message: 1 > Date: Sun, 10 Jul 2016 05:04:35 + > From: Dvir Yitzchaki <dvir.yitzch...@ceva-dsp.com> > To: "'cmake@cmake.org'" <cmake@cmake.org> > Subject: [CMake] CMAKE_C++_CREATE_SHARED_LIBRARY missing > Message-ID: > <71350f7ed6ebb54aa2d182b26086a1b60114ac5...@ilmail1.corp.local> > Content-Type: text/plain; charset="us-ascii" > > Hi. > > I use cmake 3.3.1 on Red-Hat 5 and 6. > When I generate a project I get the following error: > > CMake Error: Error required internal CMake variable not set, cmake may be not > be built correctly. > Missing variable is: > CMAKE_C++_CREATE_SHARED_LIBRARY > > However, after the error the generation succeeds and I can build the project > successfully. > The same project is generated without errors on Windows 7 with Visual Studio > generators and other projects are also generated without errors on the same > Linux machine. > > Does anyone knows the source of that error? Rimshot idea: Quite possibly someone did a project(foo C C++) rather than using the (IIRC - no docs here ATM) correct CXX. HTH, Andreas Mohr -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Modifying the FindBoost.cmake module
Hey,
if you would use the FindBoost.cmake module from cmake itself, you could
set the environment variable BOOST_ROOT to the second path.
Regards,
Andreas
Am 28.06.2016 um 01:21 schrieb Sambeet Panigrahi:
Hi,
I am using Cmake to build Orocos RTT. There is a FindBoost.cmake
module available in the config directory which the project uses.Now I
have got two boost installations one in
1)/usr/include/boost
2)~/NewRockPort/x86/Install/boost
The second installation is the one I want to use .However The
find_package command always goes on to find the first installation.
There is a section in the file
SET(_boost_INCLUDE_SEARCH_DIRS
"$ENV{INSTALL_PREFIX}/boost/include/"
C:/boost/include
C:/boost
"$ENV{ProgramFiles}/boost/include"
"$ENV{ProgramFiles}/boost"
/sw/local/include
in which I have tried to set the second installation's address, but it
always points to the first.I have also tried to set the second
installation from environment but somehow it always detects the first
installation.
What can I do to include the second installation in my project?
Regards
Sambeet
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] subversion
The discussion is interesting and ends with the question, whether the macro "Subversion_IS_WC" is usable. As I understand the other arguments are *leave the FATAL_ERROR as default for backwards compatibility *the suggested patch hides the error message if error_quite is set . *calling svn info twice is felt to be a waste, if the result is desired anyway. So, I would suggest to extend Erik Johanssons patch from http://www.mail-archive.com/cmake@cmake.org/msg26817.html by storingto the error message and svn error code in an extra variable. Than, we have the ability to ignore errors due to "wrong" working directories and to analyze the error, if the user is interested in the error. In my opinion, a hard fail is annoying, because the user is not able to recover from the error. Regards, Andreas Am 27.06.2016 um 12:57 schrieb Marcel Loose: See also https://cmake.org/Bug/view.php?id=10200 Cheers, Marcel Loose. On 27/06/16 09:23, Andreas Naumann wrote: Thanks for the 6 year old hint. But obviously, the patch is not in any recent cmake version. Therefore, I could use it in my own project and ship my own FindSubversion.cmake.. which is quite ugly. *Gesendet:* Montag, 27. Juni 2016 um 03:11 Uhr *Von:* Nagger <nag...@gmx.de> *An:* cmake@cmake.org *Betreff:* Re: [CMake] subversion Am 24.06.2016 um 19:48 schrieb Andreas Naumann: > At the moment, I check, if my directory is a working copy and if it is > not, the version variable is not defined. In my oppinion, it would be > better, if the macro from the subversion module would simply define a > variable "is_working_directory" instead of failing hard. See https://cmake.org/pipermail/cmake/2010-January/034862.html -- Powered by www.kitware.com <http://www.kitware.com> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] subversion
Thanks for the 6 year old hint. But obviously, the patch is not in any recent cmake version. Therefore, I could use it in my own project and ship my own FindSubversion.cmake.. which is quite ugly. Gesendet: Montag, 27. Juni 2016 um 03:11 Uhr Von: Nagger <nag...@gmx.de> An: cmake@cmake.org Betreff: Re: [CMake] subversion Am 24.06.2016 um 19:48 schrieb Andreas Naumann: > At the moment, I check, if my directory is a working copy and if it is > not, the version variable is not defined. In my oppinion, it would be > better, if the macro from the subversion module would simply define a > variable "is_working_directory" instead of failing hard. See https://cmake.org/pipermail/cmake/2010-January/034862.html -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[CMake] subversion
Dear cmake users, I have a question if, and how, you use the Subversion module of cmake. The module provides the macro Subversion_WC_INFO, which extracts information of a working copy. I use this information, to generate a sub minor revision number of my project. If I checkout my project using svn, it works. But if I export it, the modules failes with a fatal error. At the moment, I check, if my directory is a working copy and if it is not, the version variable is not defined. In my oppinion, it would be better, if the macro from the subversion module would simply define a variable "is_working_directory" instead of failing hard. What do you think about this idea? How do you use the subversion module? The patch would be easy, and I would send one to the developer mailing list, if desired. Regards, Andreas -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [cmake-developers] Imported Locations in FindBoost.cmake
On 6/19/2016 9:17 PM, Mike Gelfand wrote: > > The suggested way to deal with this seems to be to use > MAP_IMPORTED_CONFIG_ target properties, but I suppose it should > only (?) be used when imported target (or target it's being linked to) > has non-standard configurations, which isn't so in this case. > Alternatively, maybe it makes sense for FindBoost to simply set all configurations explicitly? By iterating over CMAKE_CONFIGURATION_TYPES (or inspecting CMAKE_BUILD_TYPE for single-config generators) and using the global property DEBUG_CONFIGURATIONS to determine whether a given configuration needs the debug or the release binaries. I'm still unsure what to make of the current fallback-to-first-configuration behavior. I did not find this mentioned anywhere in the docs, so I guess it's not a behavior one should rely upon? I was wondering whether it would make sense to properly define what CMake does in such a case. In particular since, as you mentioned, package configuration files might already rely on some assumptions there. Best regards, Andreas -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] Imported Locations in FindBoost.cmake
Hi there,
I ran into a small issue with the new imported target interface of
FindBoost.cmake.
Just like the old variable-based interface, the script only detects
Debug and Release configurations of installed Boost binaries.
In the old interface, the debug binaries where used only for debug
builds (care of the debug keyword in the classic target_link_libraries
function), while the release binaries were used for all other
configurations (optimized keyword).
It seems that with the new interface, this was inverted. On MSVC for
instance, the RelWithDebInfo and MinSizeRel configurations use the debug
binaries of Boost. This is not desirable and can even break those
configurations on MSVC due to inconsistent use of the debug runtime and
STL debug iterators.
After fiddling around with the issue, I found that reversing the order
in which the IMPORTED_LOCATION_* fields on the imported target are being
set resolves the issue. It seems that the first configuration that's
added here will be used as a default for the not explicitly added
configurations?
I attached a small patch to demonstrate what I mean, but I am unsure if
this is a proper fix for the issue.
Thanks and regards,
Andreas
From c201749b494c5aa44d7cc6c9139d8c71db849cf2 Mon Sep 17 00:00:00 2001
From: Andreas Weis <git...@ghulbus-inc.de>
Date: Sun, 19 Jun 2016 12:44:29 +0200
Subject: [PATCH] Switched order of adding locations to imported target
FindBoost only detects Debug and Release configurations; All other
configurations will fall back to whichever IMPORTED_LOCATION_ was
added *first*. This change makes sure that that is the Release
configuration. Adding Debug first is likely to cause conflicts on MSVC,
where the Debug runtime is not to be used for RelWithDebInfo and
MinSizeRel builds.
---
Modules/FindBoost.cmake | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/Modules/FindBoost.cmake b/Modules/FindBoost.cmake
index 6bf6401..2560459 100644
--- a/Modules/FindBoost.cmake
+++ b/Modules/FindBoost.cmake
@@ -1734,13 +1734,6 @@ if(Boost_FOUND)
IMPORTED_LINK_INTERFACE_LANGUAGES "CXX"
IMPORTED_LOCATION "${Boost_${UPPERCOMPONENT}_LIBRARY}")
endif()
-if(EXISTS "${Boost_${UPPERCOMPONENT}_LIBRARY_DEBUG}")
- set_property(TARGET Boost::${COMPONENT} APPEND PROPERTY
-IMPORTED_CONFIGURATIONS DEBUG)
- set_target_properties(Boost::${COMPONENT} PROPERTIES
-IMPORTED_LINK_INTERFACE_LANGUAGES_DEBUG "CXX"
-IMPORTED_LOCATION_DEBUG "${Boost_${UPPERCOMPONENT}_LIBRARY_DEBUG}")
-endif()
if(EXISTS "${Boost_${UPPERCOMPONENT}_LIBRARY_RELEASE}")
set_property(TARGET Boost::${COMPONENT} APPEND PROPERTY
IMPORTED_CONFIGURATIONS RELEASE)
@@ -1748,6 +1741,13 @@ if(Boost_FOUND)
IMPORTED_LINK_INTERFACE_LANGUAGES_RELEASE "CXX"
IMPORTED_LOCATION_RELEASE
"${Boost_${UPPERCOMPONENT}_LIBRARY_RELEASE}")
endif()
+if(EXISTS "${Boost_${UPPERCOMPONENT}_LIBRARY_DEBUG}")
+ set_property(TARGET Boost::${COMPONENT} APPEND PROPERTY
+IMPORTED_CONFIGURATIONS DEBUG)
+ set_target_properties(Boost::${COMPONENT} PROPERTIES
+IMPORTED_LINK_INTERFACE_LANGUAGES_DEBUG "CXX"
+IMPORTED_LOCATION_DEBUG "${Boost_${UPPERCOMPONENT}_LIBRARY_DEBUG}")
+endif()
if(_Boost_${UPPERCOMPONENT}_DEPENDENCIES)
unset(_Boost_${UPPERCOMPONENT}_TARGET_DEPENDENCIES)
foreach(dep ${_Boost_${UPPERCOMPONENT}_DEPENDENCIES})
--
2.5.0.windows.1
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [CMake] Freetype on linux systems in non-standard directories
Hey Kristian,
as the documentation
https://github.com/Kitware/CMake/blob/master/Modules/FindFreetype.cmake
at line 21 states, FREETYPE_DIR is an environment variable.
So, if you change your line
set(FREETYPE_DIR "/home/kristian/Documents/freetype/freetype")
to
set(ENV{FREETYPE_DIR} "/home/kristian/Documents/freetype/freetype")
I would assume, your script will work.
Hth,
Andreas
Am 07.06.2016 um 22:47 schrieb Kristian:
Hey guys,
I wanted to try something out with CMake and latest version of
freetype (2.6.3). So I downloaded freetype, compiled it with the commands
> ./configure --prefix=/home/kristian/Documents/freetype/freetype
> make
> make install
After that, I created a small C++-file and a CMakeLists.txt. The
C++-file depends on freetype, so my CMakeLists.txt looks like this:
=
> cmake_minimum_required(VERSION 3.5)
> project(freetype_ex)
>
> set(FREETYPE_DIR "/home/kristian/Documents/freetype/freetype")
> find_package(Freetype)
>
> set(SOURCES main.cpp)
>
> include_directories(${FREETYPE_INCLUDE_DIRS})
>
> add_executable(${PROJECT_NAME} ${SOURCES})
> target_link_libraries(${PROJECT_NAME} ${FREETYPE_LIBRARIES})
=
But when calling cmake, I am getting this error:
=
> -- Could NOT find Freetype (missing: FREETYPE_LIBRARY
FREETYPE_INCLUDE_DIRS)
> 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:
> FREETYPE_LIBRARY (ADVANCED)
> linked by target "freetype_ex" in directory
/home/kristian/Documents/freetype/cmake
>
> -- Configuring incomplete, errors occurred!
> See also
"/home/kristian/Documents/freetype/cmake/CMakeFiles/CMakeOutput.log".
=
This sort of error seems for me to be a bug, because I would assume,
that when I set the variable FREETYPE_DIR, then CMake would also look
at this dir.
I looked at the FindFreetype.cmake file
(https://github.com/Kitware/CMake/blob/master/Modules/FindFreetype.cmake)
and my first assumption is, that it would help, to add something like
${FREETYPE_DIR} the the find_path calls.
What do you think of this? Another idea is, to add another variable
instead of FREETYPE_DIR, e.g. FREETYPE_ROOT_DIR...
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [cmake-developers] Review request: FindTBB module
Hi all, I also came across these FindTBB modules while in need for one. As the more recent one from the OGRE project did not support MSVS 2015 yet, and also does not create import targets for a more convenient and “modern” CMake use of the TBB library targets, I wrote my own module. Features: - Makes use of COMPONENTS argument of find_package to look for the different TBB libraries. - Adds IMPORTED library targets with IMPORTED_* and INTERFACE_* properties set appropriately. - Considers TBB_ROOT as user hint and bases library search on root derived from TBB_INCLUDE_DIR otherwise. - Uses PATH_SUFFIXES instead of full search paths as done by OGRE FindTBB module to take advantage of CMake’s default search paths. - Checks TBB_VERSION against VERSION argument of find_package using find_package_handle_standard_args. This module is part of my CMake BASIS project which, among other things, consists of custom CMake functions and modules which attempt to standardise and reduce the CMake code needed by most projects (in research). These CMake BASIS Modules can be found on GitHub: https://github.com/schuhschuh/cmake-basis-modules. Would be great if someone could review the FindTBB module at https://github.com/schuhschuh/cmake-basis-modules/blob/develop/FindTBB.cmake and provide some feedback about what needs to be modified before it can be added to the official CMake Modules. Best, Andreas > On 12 Mar 2015, at 00:04, Klaim - Joël Lamotte <mjkl...@gmail.com> wrote: > > > Hi, > > did you manage to improve over the DaxToolkit FindTBB module? > > Thanks for your time. > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [CMake] Cmake cannot locate header file that exists on my system
You have to add the directory /usr/include/trilinos to the c++ include directories. The fastest workaround would be, to add the directory to the CMAKE_CXX_FLAGS using ccmake or cmake-gui. The better solution is to look for any hint regarding trilinos in the CMakeLists.txt of dakota and check, why the corresponding include directory is not added. Regards, Andreas Am 17.03.2016 um 14:32 schrieb Chris Coutinho: I’m attempting to install Dakota 6.3.0 using cmake 3.5.0 on a 64-bit Linux box from source (to link python and MATLAB), and Dakota is having trouble finding some dependencies. I’ve been able to install and use Dakota successfully on my previous machine (64-bit, OpenSUSE 13.2, cmake 3.3.0) without any problems. Now that I upgraded to the more recent version of OpenSUSE (Opensuse Leap 42.1) and cmake (3.5.0), I’m not able to get past this error. I am using cmake to build the source and create a makefile. Configuring cmake is fine; however, when running ‘make’ I get an error at around 5% of compiling: /[ 5%] Building CXX object packages/OPTPP/src/CMakeFiles/optpp.dir/globals.C.o/ /In file included from /opt/dakota/dakota-6.3.0.src/packages/OPTPP/src/globals.C:4:0:/ //opt/dakota/dakota-6.3.0.src/packages/OPTPP/include/globals.h:22:41: fatal error: Teuchos_SerialDenseMatrix.hpp: No such file or directory/ /#include "Teuchos_SerialDenseMatrix.hpp"/ /^/ /compilation terminated./ I looked for the missing file ‘Teuchos_SerialDenseMatrix.hpp’, and see that I have two copies on my computer from installing trilinos 11.4.3 through the package manager. One is located under ‘/usr/include/trilinos’, and the other is located ‘/usr/lib64/mpi/gcc/openmpi/include/trilinos’. I’m not sure why I have two copies… I added both of those directories to LD_LIBRARY_PATH in ~/.bashrc, but the error keeps coming up that Dakota isn’t able to find the file. Can anyone help me with this installation issue? Kind regards, *Chris Coutinho,* EIT R Engineer REDstack, B.V. Pieter Zeemanstraat 6 8606 JR Sneek, The Netherlands work: +31 6 5785 mobile: +31 6 1689 0287 www.redstack.nl De informatie verzonden middels deze e-mail is uitsluitend bestemd voor de geadresseerde. Gebruik door anderen is niet toegestaan. Openbaarmaking, verspreiding en/of verstrekking van deze informatie aan derden is niet toegestaan. A.Hak staat niet in voor een juiste en volledige overbrenging van de inhoud, alsmede de tijdige ontvangst daarvan. The information contained in this communication, including files, is confidential and legally privileged. It is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking any action in reliance to the contents of this information, is strictly prohibited and may be unlawful. A.Hak is not liable for the proper, complete and timely transmission of the information contained in this communication. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[cmake-developers] Fwd: [CMake 0016022]: GenerateExportHeader DEFINE_NO_DEPRECATED define conflicts
Hi, regarding this issue report, I’ve just attached a patch <https://cmake.org/Bug/file_download.php?file_id=5646=bug> for the current HEAD of the master branch that fixes the issue. Please have a look and it would be great if somebody could apply it. It currently causes problems in particular for projects using VTK, which may need this patch to be applied as well, given that it ships its own copy of the GenerateExportHeader module. Cheers, Andreas > Begin forwarded message: > > From: Mantis Bug Tracker <man...@public.kitware.com> > Subject: [cmake-developers] [CMake 0016022]: GenerateExportHeader > DEFINE_NO_DEPRECATED define conflicts > Date: 16 March 2016 at 21:28:00 GMT > To: cmake-developers@cmake.org > > > The following issue has been SUBMITTED. > == > https://cmake.org/Bug/view.php?id=16022 > ====== > Reported By:Andreas Schuh > Assigned To: > == > Project:CMake > Issue ID: 16022 > Category: Modules > Reproducibility:always > Severity: minor > Priority: normal > Status: new > == > Date Submitted: 2016-03-16 17:27 EDT > Last Modified: 2016-03-16 17:28 EDT > == > Summary:GenerateExportHeader DEFINE_NO_DEPRECATED define > conflicts > Description: > The header file generated by generate_export_header adds a > >#define DEFINE_NO_DEPRECATED 0|1 > > macro which is used to decide whether or not to define the respective macro > with > the desired library prefix and base name. But this macro has the same name for > all libraries and is not undefined when it is no longer needed. In my project, > this for example created a conflict with the VTK library which uses such > generated header file which must of course be included in the public header > files. > > To solve this conflict, I am using now (temporarily) a custom > exportheader.cmake.in template file by changing the > _GENERATE_EXPORT_HEADER_MODULE_DIR path to a directory in my project after > including the GenerateExportHeader module. Find the modified template file > attached. > > There is certainly a better fix for this bug. > == > > Issue History > Date ModifiedUsername FieldChange > == > 2016-03-16 17:27 Andreas Schuh New Issue > 2016-03-16 17:28 Andreas Schuh File Added: exportheader.cmake.in > > > == > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [CMake] Compile shared library and call it's functions
Hi,
On Mon, Mar 7, 2016 at 9:29 PM, Ivan <i...@sleepyiora.pw> wrote:
> Hello!
>
> Here is my CMakeLists.txt:
>
> cmake_minimum_required(VERSION 3.3)
> project(untitled19)
>
> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
>
> set(LIBRARY_SRC library.cpp)
>
> add_library(libra SHARED ${LIBRARY_SRC})
>
> set(SOURCE_FILES main.cpp)
> add_executable(untitled19 ${SOURCE_FILES})
> target_link_libraries(untitled19 libra)
>
>
> This works and both library and executable are compiled. Unfortunately
> library seems to be linked into the executable: ‘nm’ command shows that the
> executable itself exports needed functions!
>
>
I do not think your interpreting the nm output correctly, but its hard to
say without seeing it ;)
Note that nm will show the functions exported by the library in the output
for the executable, because the executable uses those functions. It will
also indicate however that these functions are not defined inside the
executable in the corresponding column with an upper-case U. When you run
nm on the library itself you will notice that the same symbols have a
different type in the corresponding column. In addition you can verify that
the executable actually links against the library using the otool
commandline tool: otool -L executable.
Andreas
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] globs case sensitivity depends on platform
Hi Jan, On Thu, Jan 28, 2016 at 2:35 PM, Jan Hegewald <jan.hegew...@awi.de> wrote: > Hi Nils, > > > On 28.01.2016, at 13:39, Nils Gladitz <nilsglad...@gmail.com> wrote: > > > > You might already be aware but CMake discourages using GLOB for source > files > > yes, I read the docs before posting (: > Avoiding glob would be a workaround to my problem. But anyway I think that > glob is broken if it produces different results on different platforms. > I can't find any docs on cmake.org about what a globbing-expression is exactly, but the docs for file(glob) at least don't say anything about this function producing the same results on different platforms. In fact I'd be surprised if the behavior of the file(glob) function is different than using the same wildcards with ls/dir on a terminal. The only bug that I can see from your description is that the behavior is inconsistent with different types of FS on OSX, that is definetly not matching above mentioned expectation. Anyway, the right place to report bugs/problems is https://public.kitware.com/Bug/my_view_page.php Andreas -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] globs case sensitivity depends on platform
Hi Jan, On Thu, Jan 28, 2016 at 4:52 PM, Jan Hegewald <jan.hegew...@awi.de> wrote: > Hi Andreas, > > > On 28.01.2016, at 16:43, Andreas Pakulat <ap...@gmx.de> wrote: > > > > Hi Jan, > > > > On Thu, Jan 28, 2016 at 2:35 PM, Jan Hegewald <jan.hegew...@awi.de> > wrote: > > Hi Nils, > > > > > On 28.01.2016, at 13:39, Nils Gladitz <nilsglad...@gmail.com> wrote: > > > > > > You might already be aware but CMake discourages using GLOB for source > files > > > > yes, I read the docs before posting (: > > Avoiding glob would be a workaround to my problem. But anyway I think > that glob is broken if it produces different results on different platforms. > > > > I can't find any docs on cmake.org about what a globbing-expression is > exactly, but the docs for file(glob) at least don't say anything about this > function producing the same results on different platforms. In fact I'd be > surprised if the behavior of the file(glob) function is different than > using the same wildcards with ls/dir on a terminal. > > the cmake glob is different from the results of a terminal ls On the Mac apparently (based on your first mail) > The only bug that I can see from your description is that the behavior is > inconsistent with different types of FS on OSX, that is definetly not > matching above mentioned expectation. > > Maybe I was unclear about this, but cmake glob ignores the case regardless > of the FS being case sensitive or not. > Now that contradicts your initial mail, you said there that on OSX you get F* and f* files for a case-insensitive filesystem, but on Linux you get only F*. But you also said that a case-sensitive filesystem on OSX still gives you F* and f* files, which in my eyes is a bug in the implementation. I also just checked the CMake sources quickly and it seems that the glob-support is completely 'inhouse', meaning it does not call out to platform-specific functions (I guess that would explain the discrepancy on OSX). So I guess asking for the same behavior across platforms is just as reasonable (given the logics are fully under CMake's control) as asking for it to reflect what a ls/dir would do on the corresponding platform. I think a bugreport is the correct next step, even if it merely leads to a clarification of the behavior in the documentation. Andreas -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [cmake-developers] [PATCH] Get the PYTHON_SITELIB directory in FindPythonLibs
On Thursday 17 December 2015 11:12:13 Brad King wrote:
> On 12/16/2015 05:04 AM, Andreas Schneider wrote:
> > similar to what I implemented in FindPerlLibs.cmake some years ago, I've
> > added PYTHON_SITELIB to FindPythonLibs. With PYTHON_SITELIB you have the
> > location where to install the python modules you built with cmake.
> >
> > Example:
> >
> > find_package(PythonInterp)
> > find_package(PythonLibs)
> >
> > python_add_module(my_py my_py.c)
> > install(TARGETS my_py DESTINATION
> > ${CMAKE_INSTALL_PREFIX}/${PYTHON_SITELIB})
> One of the goals of FindPythonLibs is to work when cross-compiling such
> that one cannot run the interpreter natively. That is one reason we
> don't just ask the interpreter where to get the libraries. There has
> been some discussion about doing such lookups conditionally when we
> can run the interpreter but also having a fallback.
If you look at the code, my changes to the code are inside an already existing
if (PYTHON_EXECUTABLE)
...
So if you don't call find_package(PythonInterp) before
find_package(PythonLibs) it will not get the PATH information for
PYTHON_SITELIB.
The behavior of the module doesn't not change with this addition!
As it seems you did not look with enough context at the patch you can view the
changes with more context (40 lines) here:
https://git.cryptomilk.org/users/asn/cmake.git/commit/?h=asn_pythonlibs=e414ea43caedeffeb27bb367b5f6c41e6238052a=40=0=0
Cheers,
-- andreas
--
Andreas Schneider GPG-ID: CC014E3D
www.cryptomilk.orga...@cryptomilk.org
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [CMake] Fwd: Re: cmake needs 2 runs to find boost
Did boost change the naming convention? The documentation says, it should be named with vc. And therefore, cmake cannot find the library... Even the boost header files rely on the names in Visual studio. So, I would assume, your boost installation to be broken? Regards, Andreas Am 09.11.2015 um 11:36 schrieb Boudewijn Rempt: I'm actually hitting a similar problem -- I know I've got boost_system installed in c:\dev2\i\lib\boost_system-vc-mt-1_55.dll c:\dev2\i\lib\boost_system-vc-mt-1_55.lib I run cmake like this: cmake ..\krita -G"Visual Studio 14 Win64" -DBoost_DEBUG=ON -DBoost_FIND_QUIETLY=FALSE -DBOOST_INCLUDEDIR=c:\dev2\i\include -DBOOST_ROOT=c:\dev2\i -DBOOST_LIBRARYDIR=c:\dev2\i\lib -DCMAKE_INSTALL_PREFIX=c:\dev2\i -DCMAKE_PREFIX_PATH=c:\dev2\i -DCMAKE_BUILD_TYPE=Release And the output is that boost_system isn't found, because it's looking for vc140, instead of vc, it seems: -- [ C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:515 ] _boost_TEST_VERSIONS = 1.58.0;1.58;1.57.0;1.57;1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0; 1.53;1.52.0;1.52;1.51.0;1.51;1.50.0;1.50;1.49.0;1.49;1.48.0;1.48;1.47.0;1.47;1.46.1;1.46.0;1.46;1.45.0;1.45;1.44.0;1.44;1.43.0;1.43;1.42.0;1.42;1.41.0;1.41;1.40.0;1.40;1. 39.0;1.39;1.38.0;1.38;1.37.0;1.37;1.36.1;1.36.0;1.36;1.35.1;1.35.0;1.35;1.34.1;1.34.0;1.34;1.33.1;1.33.0;1.33 -- [ C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:517 ] Boost_USE_MULTITHREADED = TRUE -- [ C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:519 ] Boost_USE_STATIC_LIBS = -- [ C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:521 ] Boost_USE_STATIC_RUNTIME = -- [ C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:523 ] Boost_ADDITIONAL_VERSIONS = -- [ C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:525 ] Boost_NO_SYSTEM_PATHS = -- [ C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:577 ] Declared as CMake or Environmental Variables: -- [ C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:579 ] BOOST_ROOT = c:\dev2\i -- [ C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:581 ] BOOST_INCLUDEDIR = c:\dev2\i\include -- [ C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:583 ] BOOST_LIBRARYDIR = c:\dev2\i\lib -- [ C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:585 ] _boost_TEST_VERSIONS = 1.58.0;1.58;1.57.0;1.57;1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0; 1.53;1.52.0;1.52;1.51.0;1.51;1.50.0;1.50;1.49.0;1.49;1.48.0;1.48;1.47.0;1.47;1.46.1;1.46.0;1.46;1.45.0;1.45;1.44.0;1.44;1.43.0;1.43;1.42.0;1.42;1.41.0;1.41;1.40.0;1.40;1. 39.0;1.39;1.38.0;1.38;1.37.0;1.37;1.36.1;1.36.0;1.36;1.35.1;1.35.0;1.35;1.34.1;1.34.0;1.34;1.33.1;1.33.0;1.33 -- [ C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:654 ] Include debugging info: -- [ C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:656 ] _boost_INCLUDE_SEARCH_DIRS = c:\dev2\i\include;c:\dev2\i/include;c:\dev2\i;PATHS;C:/boos t/include;C:/boost;/sw/local/include -- [ C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindBoost.cmake:658 ] _boost_PATH_SUFFIXES = boost-1_58_0;boost_1_58_0;boost/boost-1_58_0;boost/boost_1_58_0;b oost-1_58;boost_1_58;boost/boost-1_58;boost/boost_1_58;boost-1_57_0;boost_1_57_0;boost/boost-1_57_0;boost/boost_1_57_0;boost-1_57;boost_1_57;boost/boost-1_57;boost/boost_ 1_57;boost-1_56_0;boost_1_56_0;boost/boost-1_56_0;boost/boost_1_56_0;boost-1_56;boost_1_56;boost/boost-1_56;boost/boost_1_56;boost-1_55_0;boost_1_55_0;boost/boost-1_55_0; boost/boost_1_55_0;boost-1_55;boost_1_55;boost/boost-1_55;boost/boost_1_55;boost-1_54_0;boost_1_54_0;boost/boost-1_54_0;boost/boost_1_54_0;boost-1_54;boost_1_54;boost/boo st-1_54;boost/boost_1_54;boost-1_53_0;boost_1_53_0;boost/boost-1_53_0;boost/boost_1_53_0;boost-1_53;boost_1_53;boost/boost-1_53;boost/boost_1_53;boost-1_52_0;boost_1_52_0 ;boost/boost-1_52_0;boost/boost_1_52_0;boost-1_52;boost_1_52;boost/boost-1_52;boost/boost_1_52;boost-1_51_0;boost_1_51_0;boost/boost-1_51_0;boost/boost_1_51_0;boost-1_51; boost_1_51;boost/boost-1_51;boost/boost_1_51;boost-1_50_0;boost_1_50_0;boost/boost-1_50_0;boost/boost_1_50_0;boost-1_50;boost_1_50;boost/boost-1_50;boost/boost_1_50;boost -1_49_0;boost_1_49_0;boost/boost-1_49_0;boost/boost_1_49_0;boost-1_49;boost_1_49;boost/boost-1_49;boost/boost_1_49;boost-1_48_0;boost_1_48_0;boost/boost-1_48_0;boost/boos t_1_48_0;boost-1_48;boost_1_48;boost/boost-1_48;boost/boost_1_48;boost-1_47_0;boost_1_47_0;boost/boost-1_47_0;boost/boost_1_47_0;boost-1_47;boost_1_47;boost/boost-1_47;bo ost/boost_1_47;boost-1_46_1;boost_1_46_1;boost/boost-1_46_1;boost/boost_1_46_1;boost-1_46_0;boost_1_46_0;boost/boost-1_46_0;boost/boost_1_46_0;boost-1_46;boost_1_46;boost /boost-1_46;boost/boost_1_46;boost-1_45_0;boost_1_45_0;boost/boost-1_45_0;boost/boost_1_45_0;
Re: [CMake] getting the rpath right on osx
Hi,
On Mon, Nov 2, 2015 at 10:26 AM, Boudewijn Rempt <b...@valdyas.org> wrote:
> I checked the manual and the blog post about rpath on osx, but I'm still
> confused, and still not getting it right...
>
> I build and installed Qt 5.6 alpha like this:
>
> ./configure -prefix /Users/boudewijnrempt/kf5/i
>
> Then I made a small test project, consisting of nothing but a main that
> links to QtCore.
>
> If I build that with qmake, with this .pro file:
>
> QT += core
> QT -= gui
> TARGET = rpathqmake
> CONFIG += console
> CONFIG -= app_bundle
> TEMPLATE = app
> SOURCES += main.cpp
>
> The r-path is set:
>
> Boudewijns-Mac-mini:test boudewijnrempt$ otool -L rpathqmake
> rpathqmake:
> @rpath/QtCore.framework/Versions/5/QtCore (compatibility version
> 5.6.0, current version 5.6.0)
>
> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
> (compatibility version 1.0.0, current version 1.0.0)
> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
> (compatibility version 1.0.0, current version 275.0.0)
> /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version
> 120.0.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 1213.0.0)
>
> Boudewijns-Mac-mini:test boudewijnrempt$ otool -L rpathqmake | grep -i
> rpath
> rpathqmake:
> @rpath/QtCore.framework/Versions/5/QtCore (compatibility version
> 5.6.0, current version 5.6.0
>
Thats not the rpath in your executable, thats just the install name of the
QtCore library. And the install name indicates that you need to set an
rpath in your executable that points to the installation directory of Qt.
In order to see the rpath entries of your executable you'll need to check
for the LC_RPATH command in the output of this:
otool -l rpathqmake
It will show the absolute path to the Qt installation on your system.
> If I try a minimal cmakelists.txt, the rpath isn't set, I tried with and
> without all those RPATH related lines,
> they don't seem to make a difference. I'm using cmake 3.3.2.
>
> cmake_minimum_required(VERSION 2.8.12)
> cmake_policy(SET CMP0042 NEW)
> set(CMAKE_MACOSX_RPATH ON)
> SET(CMAKE_SKIP_BUILD_RPATH TRUE)
> SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
> SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
> set(REQUIRED_QT_VERSION 5.3.0)
> find_package(Qt5 ${REQUIRED_QT_VERSION} CONFIG REQUIRED Core)
> add_executable(rpathcmake main.cpp)
> target_link_libraries(rpathcmake Qt5::Core)
> install(TARGETS rpathcmake DESTINATION /Users/boudewijnrempt/kf5/i/bin)
>
> Only adding something like this makes it work:
>
> set_target_properties(rpathcmake PROPERTIES INSTALL_RPATH
> "/Users/boudewijnrempt/kf5/i/lib")
>
I guess thats where your Qt is installed to? Then yes, that is exactly what
you want since thats where Qt is and the Qt libraries require an rpath to
be set to be found since 5.5 on OSX. You just don't want to hardcode this,
but rather calculate it off of the path of the QtCore library. Or even
better would be if the Qt5 cmake modules would provide some provision to
add the necessary linker commandline argument to inject the rpath during
linking into the executable. Thats how qmake makes things 'work out of the
box', it knows Qt has been built with the rpath-flag (default since 5.5)
and then adds something like -Wl,-rpath, to the linker
commandline of the generated Makefile.
I think the idea of using @rpath as install name of the Qt libraries is
geared towards the usecase of shipping Qt within the application bundle of
the application. In that case all you need is set the rpath
@executable_path/../Frameworks or so in the executable and thus the
app-bundle is relocatable. In order to get that with CMake you'll likely
need to use the BundleUtilities, though its been so long since I used those
I don't know if they can handle this scenario out of the box.
Andreas
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] getting the rpath right on osx
Hi, On Mon, Nov 2, 2015 at 2:49 PM, Boudewijn Rempt <b...@valdyas.org> wrote: > On Mon, 2 Nov 2015, Andreas Pakulat wrote: > > I think the idea of using @rpath as install name of the Qt libraries is >> geared towards the usecase >> of shipping Qt within the application bundle of the application. In that >> case all you need is set >> the rpath @executable_path/../Frameworks or so in the executable and thus >> the app-bundle is >> relocatable. In order to get that with CMake you'll likely need to use >> the BundleUtilities, though >> its been so long since I used those I don't know if they can handle this >> scenario out of the box. >> >> > Yes, that's what I'm trying to do -- well, I'm trying to do two > things. One is setup a build environment where kde apps like desktoptojson > can run, the other is creating a bundle, preferably using the same > Qt. I got quite far by manually fixing up the applications built as part > of kcoreaddons That would be fixed in kcoreaddons by extending the linker flags to include the mentioned -Wl,-rpath,. There's no provisioning for this inside CMake afaik since its hard for it to guess what the intention is. My understanding (not a OSX expert yet here) is also that having the install name of a framework on OSX be something like @rpath is quite unusual. Thats usually something that users are 'patching' when they bundle their application via install_name_tool. And thats what CMake supports doing via the BundleUtilities module. > and then manually patching up the executable inside the > bundle to have the @executable_path/../Frameworks rpath added. But I'm > still not sure why with a really simple example things don't work out > of the box: I guess I had better build Qt with -norpath. See above, I think the way the Qt frameworks are setup when using -rpath is simply not expected/anticipated so far by CMake (or the people maintaining the qt5 cmake modules inside Qt). However I never tried to use BundleUtilities with such a framework, maybe they do manage to 'fixup' things for that as well. For a Qt4-based project I'm using INSTALL_QT4_EXECUTABLE which eventually forwards to fixup_bundle from BundleUtilities, so may be worth a try to avoid the manual steps. Even a Qt built with -norpath would require doing some 'manual' things to get a all-in-one app bundle for the application (or use of BundleUtilities), to copy things around and adjust the install and link names in all the frameworks and executables to be related and thus make the application relocatable. Andreas -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] getting the rpath right on osx
Hi, On Mon, Nov 2, 2015 at 4:26 PM, Clinton Stimpson <clin...@elemtech.com> wrote: > On Monday, November 02, 2015 04:08:55 PM Andreas Pakulat wrote: > > Hi, > > > > On Mon, Nov 2, 2015 at 2:49 PM, Boudewijn Rempt <b...@valdyas.org> > wrote: > > > On Mon, 2 Nov 2015, Andreas Pakulat wrote: > > > > > > I think the idea of using @rpath as install name of the Qt libraries is > > > > > >> geared towards the usecase > > >> of shipping Qt within the application bundle of the application. In > that > > >> case all you need is set > > >> the rpath @executable_path/../Frameworks or so in the executable and > thus > > >> the app-bundle is > > >> relocatable. In order to get that with CMake you'll likely need to use > > >> the BundleUtilities, though > > >> its been so long since I used those I don't know if they can handle > this > > >> scenario out of the box. > > > > > > Yes, that's what I'm trying to do -- well, I'm trying to do two > > > things. One is setup a build environment where kde apps like > desktoptojson > > > can run, the other is creating a bundle, preferably using the same > > > Qt. I got quite far by manually fixing up the applications built as > part > > > of kcoreaddons > > > > That would be fixed in kcoreaddons by extending the linker flags to > include > > the mentioned -Wl,-rpath,. There's no provisioning for this > > inside CMake afaik since its hard for it to guess what the intention is. > > CMake does automatically handle this. If a library being linked has @rpath > for its install ID, then CMake will insert the linker flag. This takes > care of > the build time rpath. And works for any library in target_link_libraries() > where CMake knows its full path. A -L/-l approach does not work, but that > is > usually done for system libraries, in which case we normally don't care > about > rpaths. > > This kind of thing isn't handled automatically at install time, and > requires > the INSTALL_RPATH property to be set. Thanks for correcting me - didn't see your first mail until now either. It seems I'm really out of touch with CMake these days :) So I guess KDE frameworks that generate development-tools lack the INSTALL_RPATH - at least that would explain the necessity to manually patch them. A relative path like you mentioned should work as long as Qt is installed in the same prefix as those tools - which is likely the common case. An end-user application then can either decide to be installed in the same way or it wants an app-bundle, then it could use an INSTALL_RPATH like @executable/../Frameworks and bunlde the Qt frameworks inside that subdirectory. Andreas -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] CMAKE_BUILD_TYPE and exact control of compiler options
Hi, On Mon, Oct 12, 2015 at 10:39 AM, René J. V. <rjvber...@gmail.com> wrote: > Hello, > > I'm using cmake in conjunction with a packaging/distribution system that > aims to > control the compiler and linker flags, a priori via the usual environment > variables. (We're talking about MacPorts.) > > Using one of the CMAKE_BUILD_TYPE presets, the value of those env. > variables > appears at most to be added in front of the preset options, which means > user > options can be overridden. That may be intended behaviour, but not ideal > for my > use case. > > Working with Debian and Ubuntu systems, I deduced that using a > non-pre-defined > BUILD_TYPE make cmake use the values of CFLAGS, CXXFLAGS etc, through > CMAKE_C_FLAGS, CMAKE_CXX_FLAGS etc (instead of CMAKE_C*_FLAGS_RELEASE, for > instance). > > Experimenting with -DCMAKE_BUILD_TYPE=MacPorts in the toplevel control file > (cmake PortGroup), that appeared indeed to work, but I appear to have been > mistaken. Adding -DCMAKE_C*_FLAGS_MACPORTS definitions has no effect, nor > has > setting CMAKE_C*_FLAGS from the CMake command line. > > Which leads me to the following questions: > - Is it indeed possible to get CMake to take all compiler and linker flags > from > the environment, and if so, how? - If not, what is the best/official way to get exact control over the > compiler > and linker options used? No this is not possible in general. A CMakeLists.txt file can always just set their own compiler/linker flags. However if I understand you correctly (in what kind of flags you want to change), then this could be doable with a toolchain file. These are usually used to teach CMake specialities about compilers/linkers that it does not support itself and behave sufficiently different from one it does know. That is for example gcc builds for doing cross-compilation to some specialized hardware may not work with certain flags CMake uses by default for gcc builds. The toolchain files are just cmake scripts, you can see some examples in the Modules/Platform directory of your cmake install. They set certain special variables that CMake will read out again when creating compiler/linker commandlines. The variables are explained in the documentation of CMake IIRC. > - Out of curiosity, what's special about the CMAKE_BUILD_TYPE=Debian build > type? > There's no such build type in CMake, see the Compilers and Tools section here: https://cmake.org/Wiki/CMake_Useful_Variables#Various_Options that details the built-in types in CMake. Andreas -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [cmake-developers] Allow ALIAS of IMPORTED targets
Hi,
Being able to alias imported targets would be a great feature. Just an
addition to the exports discussion, I also don't think it is necessary.
Besides the EXPORT_NAME property I was not aware of either, I would instead
expect to see an
add_library (old_name ALIAS new_name)
in the ProjectConfig.cmake(.in) file after importing the new_name library
target. This would make it more clear that it is just an alias for the
actual new exported/imported target. Also no need to maintain copies of
identical imported target properties. I would find this more appealing than
exporting the same target twice but with different name. I would think this
was just done before because of the missing ability to alias an imported
target.
Andreas
On 15 Sep 2015 21:36, "Tamás Kenéz" <tamas.ke...@gmail.com> wrote:
> Thank you, I was not aware of the EXPORT_NAME target property.
> Tamas
>
> On Tue, Sep 15, 2015 at 7:36 PM, Stephen Kelly <steve...@gmail.com> wrote:
>
>> Tamás Kenéz wrote:
>>
>> >> For example, if an ALIAS can be IMPORTED, does it makes sense that it
>> can
>> > be
>> >> exported with export() and install(EXPORT)?
>> >
>> > Yes: couple of months ago I was adding install(EXPORT) to an existing
>> > CMakeList. The name of the library target which I had to export was not
>> > correct as export target name but I was not able change the library
>> target
>> > name because of backward compatibility. Being able to export an alias
>> > would have helped.
>>
>> I still think exporting should be a follow up to allowing IMPORTED ALIAS.
>> Just too keep the branch and discussion as short as possible.
>>
>> Nevertheless, I think you wouldn't need ALIAS targets for your use-case.
>> They are more than you need. You don't need the aliases anywhere except
>> for
>> exporting. So, we could design something which allows you to export
>> aliases,
>> but be completely separate from ALIAS targets.
>>
>> For example,
>>
>> add_library(foo ${foo_SRCS})
>> set_target_property(foo EXPORT_NAMES foo foo_old_name)
>>
>> ...
>>
>> install(EXPORT ...)
>>
>> resulting in a generated file containing
>>
>> add_library(foo IMPORTED)
>> ...
>>
>> add_library(foo_old_name IMPORTED)
>> ...
>>
>> where each of the generated targets get the same target properties.
>>
>> Note that there is already an EXPORT_NAME target property
>>
>> http://www.cmake.org/cmake/help/v3.3/prop_tgt/EXPORT_NAME.html
>>
>> but it is not a list, so the task would probably be to deprecate that one
>> and add EXPORT_NAMES.
>>
>> I filed
>>
>> http://public.kitware.com/Bug/view.php?id=15745
>>
>> Thanks,
>>
>> Steve.
>>
>>
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake-developers
>>
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Python extension to FindProtobuf
Sorry, found a stashed change, that I missed. With that it works. -Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: Montag, 14. September 2015 16:12 To: Andreas Bergmeier Cc: Rolf Eike Beer; cmake-developers@cmake.org Subject: Re: [cmake-developers] Python extension to FindProtobuf On 09/14/2015 03:42 AM, Andreas Bergmeier wrote: > I now added documentation, removed ARGS and GENERATED property. Thanks. Applied with minor wording tweaks: FindProtobuf: Add protobuf_generate_python function http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=143579c3 -Brad Diese E-mail enthält VERTRAULICHE UND PERSÖNLICHE INFORMATIONEN und/oder PRIVILEGIERTE UND VERTRAULICHE MITTEILUNGEN, die ausschließlich für die angesprochenen Empfänger bestimmt sind. Ohne ausdrückliche schriftliche Zustimmung des Absenders dürfen diese Informationen und Mitteilungen nicht an irgendeinen Dritten außerhalb der Organisation des Empfängers weitergeleitet oder zur Kenntnis gebracht werden. Wenn Sie diese E-mail versehentlich empfangen haben, teilen Sie dies bitte dem Absender umgehend telefonisch oder durch Rücksendung dieser E-mail mit, und zerstören Sie die Mail sowie Ihre evtl. Rückmail bitte anschließend, ohne eine Kopie zu erstellen. Koch Media übernimmt keinerlei Verantwortung für mögliche Verluste oder Beschädigungen, resultierend aus virus-infizierten E-mails bzw. Viren in Anhängen. This e-mail may contain CONFIDENTIAL AND PROPRIETARY INFORMATION and/or PRIVILEGED AND CONFIDENTIAL COMMUNICATION intended solely for the recipient and, therefore, may not be retransmitted to any party outside of the recipient's organization without the prior written consent of the sender. If you have received this e-mail in error please notify the sender immediately by telephone or reply e-mail and destroy the original message without making a copy. Koch Media accepts no liability for any losses or damages resulting from infected e-mail transmissions and viruses in e-mail attachment. commit-ddb5ae6 Description: commit-ddb5ae6 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Python extension to FindProtobuf
I now added documentation, removed ARGS and GENERATED property.
-Original Message-
From: Brad King [mailto:brad.k...@kitware.com]
Sent: Freitag, 11. September 2015 20:33
To: Andreas Bergmeier
Cc: Rolf Eike Beer; cmake-developers@cmake.org
Subject: Re: [cmake-developers] Python extension to FindProtobuf
On 09/11/2015 11:11 AM, Andreas Bergmeier wrote:
> Here is the commit.
Thanks. Please revise the patch to also update the documentation of the module
to mention the new API.
> +list(APPEND ${SRCS} "${CMAKE_CURRENT_BINARY_DIR}/${FIL_WE}.pb.py")
> +add_custom_command(
> + OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/${FIL_WE}.pb.py"
> + COMMAND ${PROTOBUF_PROTOC_EXECUTABLE}
> + ARGS --python_out ${CMAKE_CURRENT_BINARY_DIR}
> + ${_protobuf_include_path} ${ABS_FIL}
The ARGS option can be dropped. It is silently ignored anyway.
The arguments after it will be collected by COMMAND already.
> + DEPENDS ${ABS_FIL} ${PROTOBUF_PROTOC_EXECUTABLE}
> + COMMENT "Running Python protocol buffer compiler on ${FIL}"
> + VERBATIM )
> + endforeach()
> +
> + set_source_files_properties(${${SRCS}} PROPERTIES GENERATED TRUE)
We do not need to explicitly set the GENERATED property. That convention has
been outdated for years. The add_custom_command call automatically sets this
on the OUTPUT.
Thanks,
-Brad
Diese E-mail enthält VERTRAULICHE UND PERSÖNLICHE INFORMATIONEN und/oder
PRIVILEGIERTE UND VERTRAULICHE MITTEILUNGEN, die ausschließlich für die
angesprochenen Empfänger bestimmt sind. Ohne ausdrückliche schriftliche
Zustimmung des Absenders dürfen diese Informationen und Mitteilungen nicht an
irgendeinen Dritten außerhalb der Organisation des Empfängers weitergeleitet
oder zur Kenntnis gebracht werden. Wenn Sie diese E-mail versehentlich
empfangen haben, teilen Sie dies bitte dem Absender umgehend telefonisch oder
durch Rücksendung dieser E-mail mit, und zerstören Sie die Mail sowie Ihre
evtl. Rückmail bitte anschließend, ohne eine Kopie zu erstellen. Koch Media
übernimmt keinerlei Verantwortung für mögliche Verluste oder Beschädigungen,
resultierend aus virus-infizierten E-mails bzw. Viren in Anhängen.
This e-mail may contain CONFIDENTIAL AND PROPRIETARY INFORMATION and/or
PRIVILEGED AND CONFIDENTIAL COMMUNICATION intended solely for the recipient
and, therefore, may not be retransmitted to any party outside of the
recipient's organization without the prior written consent of the sender. If
you have received this e-mail in error please notify the sender immediately by
telephone or reply e-mail and destroy the original message without making a
copy. Koch Media accepts no liability for any losses or damages resulting from
infected e-mail transmissions and viruses in e-mail attachment.
commit-226ffb3
Description: commit-226ffb3
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] Python extension to FindProtobuf
Since beneath generating cpp and h files we often also want python bindings to be generated, I would like to have the following extension to FindProtobuf added. This adds protobuf_generate_python function. Diese E-mail enthält VERTRAULICHE UND PERSÖNLICHE INFORMATIONEN und/oder PRIVILEGIERTE UND VERTRAULICHE MITTEILUNGEN, die ausschließlich für die angesprochenen Empfänger bestimmt sind. Ohne ausdrückliche schriftliche Zustimmung des Absenders dürfen diese Informationen und Mitteilungen nicht an irgendeinen Dritten außerhalb der Organisation des Empfängers weitergeleitet oder zur Kenntnis gebracht werden. Wenn Sie diese E-mail versehentlich empfangen haben, teilen Sie dies bitte dem Absender umgehend telefonisch oder durch Rücksendung dieser E-mail mit, und zerstören Sie die Mail sowie Ihre evtl. Rückmail bitte anschließend, ohne eine Kopie zu erstellen. Koch Media übernimmt keinerlei Verantwortung für mögliche Verluste oder Beschädigungen, resultierend aus virus-infizierten E-mails bzw. Viren in Anhängen. This e-mail may contain CONFIDENTIAL AND PROPRIETARY INFORMATION and/or PRIVILEGED AND CONFIDENTIAL COMMUNICATION intended solely for the recipient and, therefore, may not be retransmitted to any party outside of the recipient's organization without the prior written consent of the sender. If you have received this e-mail in error please notify the sender immediately by telephone or reply e-mail and destroy the original message without making a copy. Koch Media accepts no liability for any losses or damages resulting from infected e-mail transmissions and viruses in e-mail attachment. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Python extension to FindProtobuf
Blindly trusting Outlook D was a bad idea ;) Here is the commit. (Sorry the footer is company policy) -Original Message- From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of Rolf Eike Beer Sent: Freitag, 11. September 2015 17:07 To: cmake-developers@cmake.org Subject: Re: [cmake-developers] Python extension to FindProtobuf Am Freitag, 11. September 2015, 14:44:21 schrieb Andreas Bergmeier: > Since beneath generating cpp and h files we often also want python > bindings to be generated, I would like to have the following extension > to FindProtobuf added. This adds protobuf_generate_python function. Forgot to add patch? > > Diese E-mail enthält VERTRAULICHE UND PERSÖNLICHE INFORMATIONEN > und/oder […] Argh! Eike -- Diese E-mail enthält VERTRAULICHE UND PERSÖNLICHE INFORMATIONEN und/oder PRIVILEGIERTE UND VERTRAULICHE MITTEILUNGEN, die ausschließlich für die angesprochenen Empfänger bestimmt sind. Ohne ausdrückliche schriftliche Zustimmung des Absenders dürfen diese Informationen und Mitteilungen nicht an irgendeinen Dritten außerhalb der Organisation des Empfängers weitergeleitet oder zur Kenntnis gebracht werden. Wenn Sie diese E-mail versehentlich empfangen haben, teilen Sie dies bitte dem Absender umgehend telefonisch oder durch Rücksendung dieser E-mail mit, und zerstören Sie die Mail sowie Ihre evtl. Rückmail bitte anschließend, ohne eine Kopie zu erstellen. Koch Media übernimmt keinerlei Verantwortung für mögliche Verluste oder Beschädigungen, resultierend aus virus-infizierten E-mails bzw. Viren in Anhängen. This e-mail may contain CONFIDENTIAL AND PROPRIETARY INFORMATION and/or PRIVILEGED AND CONFIDENTIAL COMMUNICATION intended solely for the recipient and, therefore, may not be retransmitted to any party outside of the recipient's organization without the prior written consent of the sender. If you have received this e-mail in error please notify the sender immediately by telephone or reply e-mail and destroy the original message without making a copy. Koch Media accepts no liability for any losses or damages resulting from infected e-mail transmissions and viruses in e-mail attachment. commit-2c9f168 Description: commit-2c9f168 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [CMake] CMake + MPI
Hi Nico, I just use find_package(MPI REQUIRED) and use the given MPI_CXX_LIBRARIES and MPI_CXX_INCLUDE_PATH. Recent mpi wrappers should support support interspection. Regards, Andreas Am 08.09.2015 um 13:01 schrieb Nico Schlömer: Hi everyone, When it comes to compiling and linking, the MPI world is quite a mess. Sometimes, vendors make you link and include certain libraries/directories, sometimes you are supposed to simply use a compiler wrapper, often both. What's the recommended way of dealing with MPI in CMake? Do you `find_package(MPI REQUIRED)` and set LINK_LIBRARIES and INCLUDE_DIRS? Do you select a compiler wrapper from within the CMake file? From outside? Cheers, Nico -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Prefix header for Makefiles
Hi, On Wed, Aug 26, 2015 at 3:10 PM, Jakob van Bethlehem jsvanbethle...@gmail.com wrote: Hej Andrew, CMake does never scan source files (as far as I know), as it is not a compiler. From your question it almost seem you are making this assumption, so I just wanted to make sure to mention at least this. Thats wrong, CMake has to parse the source files you add to a target to be able to determine its dependencies (recursively) so it can generate makefile rules that ensure that if one of the (indirectly) included headers changes the source file is recompiled. You can see this in cmDependsC.cxx in the CMake sources for C (and possibly C++) source files. It of course does not parse the C/C++ code, it merely finds lines that start with #include or #import and figures out the absolute path of the mentioned header file based on the targets include directories. Of course you can help CMake here by specifying all headers in the add_executable/add_library call, but that easily ends up being a maintenance nightmare for files outside of your actual project (system headers, third-party libraries etc.). Andreas -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] CMake Error at build/modules/add_boost.cmake:156 (message):
Hey, at the first sight, it seems to me an error in their build system. But the error message is surrounded by an if-clause. Your error message does not show any error or output, so I assume, there was no error with bootstrap, but the (executable? file?) b2 was not found. To test it, you could print the result of the find_program call in their file add_boost.cmake just after the line 154. Good luck, Andreas Am 13.08.2015 um 20:19 schrieb Sonya Blade: Dear All, I'm attempting to build the open license manager from that location .https://github.com/open-license-manager As can be seen, there is not much info what needs to be done to configure and compile it, I'm not even sure that it is been configured to work with GCC 4.7.1 and Code Blocks. Anyway if attempt to run the configuration with CMake-GUI then I receive the following error, AFAIU this library requires the boost library and Cmake-GUI downloads the boost automatically but at th middle of configuration throws the following error how am I supposed further procedd on that? CMake Error at build/modules/add_boost.cmake:156 (message): Failed running ./bootstrap.sh;--with-toolset=gcc: Call Stack (most recent call first): CMakeLists.txt:73 (add_boost) Regards, -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[CMake] Packaging debug symbol files on Windows
Hi, I'm trying to generate a zip file (on Windows) for a shared library including the generated debug symbols in pdb files with CPack. Unfortunately CPack does not seem to pick up the pdb files all by itself and after cross-reading the cpack docs in the cmake wiki I didn't see any switch to enable such behavior. Did somebody already do this and if so how? Andreas -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Packaging debug symbol files on Windows
Hi Nils, On Mon, Jul 27, 2015 at 3:12 PM, Nils Gladitz nilsglad...@gmail.com wrote: On 07/27/2015 02:25 PM, Andreas Pakulat wrote: Hi, I'm trying to generate a zip file (on Windows) for a shared library including the generated debug symbols in pdb files with CPack. Unfortunately CPack does not seem to pick up the pdb files all by itself and after cross-reading the cpack docs in the cmake wiki I didn't see any switch to enable such behavior. Did somebody already do this and if so how? What gets installed is decided by install() commands in your project rather than by CPack. You can use the $TARGET_PDB_FILE:tgt [1] generator expression to install pdb files. e.g. install(FILES $TARGET_PDB_FILE:my_target DESTINATION bin) Ah, interesting. I would've thought that an install() would automatically include the pdb files, after all those are usually useful after the build process and the builddir is often gone once a library is being used. I've meanwhile also noticed that the default compiler flags that CMake uses include the debug information in the dll itself (dll size is doubled), so for now don't even have to have the separate pdb files packaged anymore (in this case the pdb info is small enough to just keep in the dll). Thanks for the pointer. Andreas -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Packaging debug symbol files on Windows
Hi Nils, On Mon, Jul 27, 2015 at 3:58 PM, Nils Gladitz nilsglad...@gmail.com wrote: On 07/27/2015 03:46 PM, Andreas Pakulat wrote: I've meanwhile also noticed that the default compiler flags that CMake uses include the debug information in the dll itself (dll size is doubled), so for now don't even have to have the separate pdb files packaged anymore (in this case the pdb info is small enough to just keep in the dll). I am not entirely sure what you mean but CMake's default flags for the Visual Studio compiler when building Debug or RelWithDebInfo use /Zi (debug information in external pdb) rather than /Z7 (embedded debug information; no pdb is generated). Maybe your project replaces the default flags? No Z7 or Zi anywhere in the CMake files and the generated makefiles include /Zi. So I don't know why the dll's would be bigger and generate proper backtrace information when analyzing a dump file but so it is and thats fine with me for now. Andreas -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Where do all the extra clang flags come from in Xcode?
Hi Paul, On Mon, May 18, 2015 at 3:20 PM, Paul Smith p...@mad-scientist.net wrote: On Mon, 2015-05-18 at 12:32 +0200, Ruslan Baratov via CMake wrote: This table tells you what attribute you need to set to disable/enable specific warning. I see, so these are CMake attributes? That wasn't clear to me. I thought they were attributes of Xcode. I guess my basic question is, why are all these extra flags to disable and enable various warnings set in the Xcode generator? I expected it would work like the makefile generator, where if you don't set any flags in CMakeLists.txt then you don't get any warnings enabled (or explicitly disabled). It surprises me that when I take the same CMakeLists.txt file and use a Makefile generator and an Xcode generator, I get very different compile lines. If you look at the foo.xcodeproj contents of a very simple CMake project (hello-world style) you'll notice just 1 file and there are not a lot of -W words inside that file either. I see 3 warnings being added by CMake when generating this file. That suggests anything else is added by Xcode itself because thats what its default settings are. Xcode (and xcodebuild) has a lot more logics builtin that make. Make is essentially just a dependency-tracking and execution tool and thus cannot make any assumptions about what is being executed when a target is to be 'made'. It cannot add any compile flags that the make-developers deem useful, since the action executed for a target may not be a compile run at all. Xcode on the other hand with its more structured project file has a very clear idea of what is a compile action and what is not and apparently the Apple devs think a certain set of flags are useful for everybody and hence are added to all compiler invocations. You'll also notice this when creating a new project inside xcode and then examine and run it outside, i.e. grep for -W flags in the generated files. There are literally none, but still xcodebuild shows tons of -W flags added to the compiler invocation. And secondarily, is there any way to get the Xcode generator to work like the Makefile generator, where only the warning flags I explicitly defined in my CMakeLists.txt file are added to the compile/link lines and no others? http://cmake.org/cmake/help/consulting.html Given the above, your only options are: propose a patch to cmake (or find someone to do this for you) that enhances the xcode generator to disable all flags that are not explicitly enabled so its closer to the makefile generator. This is however quite a lot of effort upfront and in maintenance since each new xcode version (even just bugfix versions) may need changes to the list. The alternative to that is that you blacklist via the mentioned attributes the warnings you don't want to have enabled, each and every one of them individually. Andreas -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Check whether C++ headers are self-sufficient
Why do you want to use one library per header? I think, it would be sufficient to have one cc-file per header and one library per folder. The library would simply contain all files. Why do you worry about large build directories? Regards, Andreas Am 14.03.2015 um 13:19 schrieb Christoph Grüninger: Dear CMakers, I want to have all my C++ headers self-sufficient (self-contained), i.e., a header can be included without additional includes. This is not only handy but also part of Google's C++ styleguide [2]. It would be great to have a make target (let's call it headercheck), that can check for this, by compiling a simple test.cc file for each current_header.h: #include config.h #include current_header.h #include current_header.h Additionally it would be great to have such a target for every folder (checking all headers recursively) and every header that is explicitly passed as an argument. We tried this with CMake: We generate a test.cc file per header and create a library for every cc file. The problem is, that we get hundreds of additional targets, we generate a lot of folders and files which can increase our build directory size by an order of magnitude and it does not work properly on a per file or per directory basis. What do you think, is there a good way to have such a target headercheck with CMake? Or would it be better to include it as a CTest? Or better as an external (bash) script as proposed in [1]? If it can be done in a good way with CMake, would it be of interest to include it as a feature in CMake? Or as an external project similar to UseLATEX.cmake? Bye Christoph [1] http://stackoverflow.com/questions/1892043/self-sufficient-header-files-in-c-c [2] http://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Self_contained_Headers -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Unexpected use of ld on Windows
Hi, On Wed, Feb 11, 2015 at 3:16 PM, Arjen Markus arjen.mar...@deltares.nl wrote: Hello, I am trying to build the Fortran interface to NetCDF4 on Windows, using the Intel Fortran compiler and Nmake Makefiles as the generator (see http://www.unidata.ucar.edu/downloads/netcdf/index.jsp). I had some trouble getting the first part to build, but that is solved (small issues with the code). The second part, which is supposed to build a C library that can be called from Fortran, presents a more serious problem: for some reason CMake picks parts of another toolchain to build this: The Makefile contains these lines to compile the sources: cd D:\netcdf\netcdf-build-fortran\libsrc C:\PROGRA~2\MICROS~3.0\VC\bin\amd64\cl.exe @ /nologo $(C_FLAGS) $(C_DEFINES) /FoCMakeFiles\ncfortran.dir\fort-attio.c.obj /FdD:\netcdf\netcdf-build-fortran\libsrc\ncfortran.pdb -c D:\netcdf\netcdf-fortran-4.4.1\libsrc\fort-attio.c But to build the library it contains: libsrc\ncfortran.dll: d:\netcdf\netcdf-build\liblib\netcdf.lib libsrc\ncfortran.dll: libsrc\CMakeFiles\ncfortran.dir\objects1.rsp @$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --red --bold Linking C shared library ncfortran.dll cd D:\netcdf\netcdf-build-fortran\libsrc d:\CMake2.8.10.2\bin\cmake.exe -E vs_link_dll C:\PROGRA~2\HASKEL~1\201320~1.0\mingw\bin\ld.exe /nologo @CMakeFiles\ncfortran.dir\objects1.rsp @ /out:ncfortran.dll /implib:ncfortran.lib /pdb:D:\netcdf\netcdf-build-fortran\libsrc\ncfortran.pdb /dll /version:0.0 /STACK:1000 /INCREMENTAL:YES /machine:x64 /debug d:\netcdf\netcdf-build\liblib\netcdf.lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib As you can see, it has picked up a linker (ld.exe) belonging to a completely different compiler/package for this step. I have no idea where this is coming from and how to fix this. Does anyone have any suggestions? Seeing the path to that ld.exe I'm reminded of a problem a colleague recently had. He has Haskell installed on his system and either haskell itself or some haskell library came with mingw and his PATH ended up including the bin dir of that mingw installation. Even if that entry is after the VS compiler CMake apparently chooses to pick up the mingw toolchain (or parts of it), so one has to make sure that there's no MinGW compiler or linker or other part of the toolchain in any of the directories in PATH. At least thats how he resolved the issue. Andreas -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Tweak CMake project to include non-buildable files in the CodeBlocks project file
Hi,
On Sun, Jan 11, 2015 at 10:55 PM, Dario Oliveri oliveridari...@gmail.com
wrote:
It is very simple for each of the files you want to include in the build
(I use txt example so that you know it can work for arbitrary types):
---
set_source_files_properties( comment.txt PROPERTIES HEADER_FILE_ONLY true)
---
then you can include that file in the build to let it shows up in the IDE
file
---
#example when adding a static library (works the same also for executables)
add_library( ${arg1} STATIC
${sourcefiles} #files you need to REALLY BUILD
comment.txt#this file would be added, but not builded
)
---
Ah, that works. Its a little ugly in the CMake files but I guess I can live
with that. Ideally I was hoping to simply have a 'complete' list including
actual sources and sources for other platforms and hand that to a special
function - without passing the source-for-other-platform to the actual
target. Oh well, I have to stop dreaming :)
Andreas
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Tweak CMake project to include non-buildable files in the CodeBlocks project file
Hi Nils, On Mon, Jan 12, 2015 at 11:50 AM, Nils Gladitz nilsglad...@gmail.com wrote: On 01/12/2015 11:40 AM, Andreas Pakulat wrote: Ah, that works. Its a little ugly in the CMake files but I guess I can live with that. Ideally I was hoping to simply have a 'complete' list including actual sources and sources for other platforms and hand that to a special function - without passing the source-for-other-platform to the actual target. Oh well, I have to stop dreaming :) You can also use add_custom_target(my_new_target SOURCES src1.cpp src2.cpp). That will list the given sources in the IDE without adding build semantics to them. Since this lists the sources as part of a new target rather than an existing target this will be visually distinct from the other approach in some IDEs but should afaik make no difference in QtCreator. Thanks for that idea, having a dedicated target wouldn't be so bad even if its visible. With a bit of restructuring of the cmakelists.txt this may actually make the file quite a bit more 'declarative' and less convoluted. Andreas -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[CMake] Tweak CMake project to include non-buildable files in the CodeBlocks project file
Hi, I'm using QtCreator with CMake and have several files that are included in targets depending on the platform on which I build. Files that are not enabled on the current platform will not be included by CMake in the CodeBlocks file which in turn is used by QtCreator. Since QtCreator only picks up files listed in the CodeBlocks project file for its project view I cannot easily open certain files using QtCreator. I'm wondering wether CMake has a mechanism that would make these files show up in the CodeBlocks project file without them being actually compiled by the project build (I'm using Ninja for that part)? I was thinking of something similar to what can be used to create groups etc. for VS projects. Andreas -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Problems with CMP0037
Hi Alan,
with cmake 2.8.12.1 I can confirm this behavior at least for Makefile
generator on Linux, see the attached small CMakeLists.txt. But what
would be a better behavior? Changing the target name would change the
output at end. So the user would have to figure out, what changed why.
At this point, I would prefer the current behavior, because cmake does
at least with the Makefile generator, the same thing as the user writes.
So the warning is appropriate.
Andreas
Am 02.11.2014 18:30, schrieb Alan W. Irwin:
Eike said:
Because you can't create files or directories with that name, you
would end up getting one directory tests and a file/directory
win32_test*. And
creating both with one API call isn't possible, so this may work if
there is a directory tests before because of some other reason, but
it will not reliably work.
Hi Eike:
I just want to confirm something about your answer. The OP
was getting complaints about a _target_ with a slash in the name. At
the CMake level there is a huge distinction between targets and files.
Are you saying that at least for some generators a target eventually
ends up as a filename (e.g., at the configured Makefile level) with
exactly the same name as the target so a slash propagates to that
filename? I
agree if that were the case, it could cause issues on Unix platforms
if the directory portion of the filename was not independently
created first.
If this is actually the case, I am somewhat surprised that CMake
exposes such implementation details at the CMake level. For example,
it should be possible to use a unique hash of target names when
creating the corresponding configured filename such that the filename
does not include any characters such as / that have special meaning
at the file level on some platforms.
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and
Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__
Linux-powered Science
__
project(testSlash)
cmake_minimum_required(VERSION 2.8)
file(WRITE main.c int main() { return 0; })
add_executable(testDir/TestExe main.c)
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] TARGET_LINK_LIBRARIES with full path libraries
Am 17.09.2014 22:00, schrieb Alexander Neundorf: On Wednesday, September 17, 2014 14:50:40 Volker Pilipp wrote: ... I suppose it is the line LIBRARY_PATH=/opt/XXX/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/:/opt/XXX/lib/g cc/x86_64-unknown-linux-gnu/4.8.2/../../../../lib64/:/lib/../lib64/:/usr/lib /../lib64/:/opt/XXX/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../:/lib/:/ usr/lib/ yes, cmake checks $LIBRARY_PATH and uses -l for the libraries located in these directories. I stumbled about that behaviour last year or so, I guess it's a feature. Alex It less a feature of cmake, much more a feature of gcc. It interprets every directory in LIBRARY_PATH as system directory and reports this to cmake, so it assumes, that those directories are system directories. Andreas -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Incorrect object file name on cmake compilation
Hi, Date: Thu, 11 Sep 2014 07:49:23 + From: Ravi Raman ravi.ra...@xoriant.com Hi, Thanks Petr for your reply. By incorrect I meant instead of the conventional main.obj, we get main.cpp.obj. I understood what you are saying. We have found a solution for this in our cmake code. Good, so you've found a solution - to which, umm, I dare ask... problem exactly? :) We have explicitly set the /Fo compiler flag for main.cpp. With that it creates main.obj for main.cpp and also main.res for main.rc Why does this need some manual effort (and of manually adding a very specific compiler flag syntax, in fact!) when it ideally/normally/usually shouldn't, one would want to ask. Perhaps this issue is indicative of an asymmetric/incomplete mechanism or configuration in CMake or this specific CMake environment, which one might want to discover and fix, in order to have the need for any manual tweaking (in all sufficiently standard cases) avoided in all future deployments... Thanks, Andreas Mohr -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Incorrect object file name on cmake compilation
On Thu, Sep 11, 2014 at 08:25:27AM +, Ravi Raman wrote: Actually, in our project, the names of the object files matter because these object files go as an input to a object file comparison tool that compares object file names. So, there are 2 sets of object files, one coming from cmake build and one from Visual Studio build. The set coming from cmake build was having this object file naming with extension .cpp.obj. That was the reason for looking into this issue. Ah, so that means we're talking about this issue having come up due to expectations about object naming being somewhat usual (as opposed to CMake-configured naming), of an *external tool*, rather than due to uneasiness/issues detected within the CMake workflow itself. So, that means: - CMake handling likely *is* consistent (at least in regard to this aspect) - the external tool does not like it :) - a manual specific compiler flag setting was configured to fall back to previously usual object naming So, my thoughts on this are that it would be best to have the external tool offer an option to support custom object file naming patterns, since naming of internally generated object files may easily differ in various build systems. Manually adding a very specific /Fo option *can* be done, but: - this manual tweak might then cause incompatibilities with internal CMake assumptions (quite possibly there are CMake configuration variables/mechanisms to generically switch this naming pattern though) - it's extremely compiler-specific (read: not environment-generic) So, I would recommend going the improve external tool support route instead (or resort to figuring out CMake config mechanisms to generically switch object naming). Andreas Mohr -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[CMake] Merge VS: Use full path to sources to allow deeper trees with VS = 10 fix to release
Hi CMakers, I was running into a using to long path issue with CMake. Here some short notes about my setup: OS: Windows 7 Dev: MS Visual Studio 10 CMake: 2.8.12 (tested it also with 3.0.1) In our project (it is based on the CIAO/TAO framework) some files will be generated automatically through an IDL compiler. Through that process the root of the project will be based on those generated files. Additional source files, placed in a complete other folder, will be referenced through relative paths to the project folder. The project itself consists of several subfolders and the length of the paths can go up to 100 letters (which should still be ok for CMake and Visual Studio) but through adding some file into another folder, the relative path description can grow up to more then 250 letters: (e.g. c:\path\to\current\dir\..\..\..\relative\path\to\source.c) As the project is already quite big, and the concept on how we store our files is not a thing we can change quite easily, I was looking if it is possible that CMake will generate always absolute paths. By default, CMake was not able to generate absolute paths, also the CMAKE_USE_RELATIVE_PATHES flag had no effect on my project. After some investigations I found out, that a solution was already submitted by the CMake dev team through the following change: http://cmake.org/gitweb?p=cmake.git;a=commit;h=0d048384694b7285ef739153757b57791d4ebb93 But it seems, that it did not make it into the release branches. My question is now, is there any reason why that fix, besides serval other changes to the cmVisualStudio10TargetGenerator.cxx did not made it into a new CMake release? After I found out, that a solution is already available I downloaded the nightly build binaries form the 1st of september and voila it worked. In addition CMake will print out a warning, that informs me that we have a path that is too long. Thats why I wanna ask you guys here, how I should proceed. Should I add a bug although a solution already exists? Kind regards, Andreas Bitte überlegen Sie, ob Sie diese Nachricht wirklich ausdrucken müssen/ before printing, think about environmental responsibility. Hydrometer GmbH, Industriestraße 13, 91522 Ansbach Telefon + 49 981 1806 0, Telefax +49 981 1806 615 Sitz der Gesellschaft: Ansbach, Registergericht: Ansbach HRB 69 Geschäftsführer: Frank Gutzeit (Sprecher), Dr.-Ing. Robert Westphal, Thomas Gastner, Adam Mechel Der Inhalt der vorstehenden E-Mail ist nicht rechtlich bindend. Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Informieren Sie uns bitte, wenn Sie diese E-Mail fälschlicherweise erhalten haben. Bitte löschen Sie in diesem Fall die Nachricht. Jede unerlaubte Form der Reproduktion, Bekanntgabe, Änderung, Verteilung und/oder Publikation dieser E-Mail ist strengstens untersagt. The contents of the above mentioned e-mail is not legally binding. This e-mail contains confidential and/or legally protected information. Please inform us if you have received this e-mail by mistake and delete it in such a case. Each unauthorized reproduction, disclosure, alteration, distribution and/or publication of this e-mail is strictly prohibited. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] CFLAGS disables link directories?
Hello Alexander,
your problem is not a problem of CFlags, it is much more a problem
of the compiler and what you are setting with --sysroot=/sysroot.
Here you tell the compiler, that it should treat /sysroot as
system library directory, so that cmake removes it from the link
line, because it is part of the system. The same applies with gcc
for the environment variable LIBRARY_DIR.
I hope, that helps you.
Andreas
Am 28.08.2014 18:21, schrieb Alexander Shashkevych:
Hi all,
I did't found info how cmake internally handles CFLAGS environment
variable, but I know that cmake picks it up from environment and seems this
removes link directories from linking flags added by link_directories()
command.
For example. I'm using custom sysroot, to build my app and I run cmake with
following command:
export CFLAGS="--sysroot=/sysroot/"
cmake ..
My cmake file is:
# GStreamer_LIBRARY_DIRS is set by pkg_check_modules()
link_directories(${GStreamer_LIBRARY_DIRS})
get_directory_property(LINK_DIRS LINK_DIRECTORIES)
message("LINK_DIRS: ${LINK_DIRS}")
add_executable(myapp main.c)
target_link_libraries(myapp ${GStreamer_LIBRARIES})
When CFLAGS isn't specified, then file src/CMakeFiles/myapp.dir/link.txt
contains -L/sysroot/usr/lib and -Wl,-rpath,/sysroot/usr/lib flags as
expected, but when I add CFLAGS to environment, then -L and -Wl,-rpath are
disappearing from linker options.
Could someone to confirm, is this expected behavior?
PS: Regardless of CFLAGS specified in command line or not, message() always
prints: LINK_DIRS: /sysroot/usr/lib, so internally cmake sets this property.
Thanks!
Alexander
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] make target export file follow symlinks (or something better?)
Hi,
On Sat, Aug 23, 2014 at 8:12 AM, Nico Schlömer nico.schloe...@gmail.com
wrote:
Hi all,
I'm linking my shared library against
```
/usr/lib/x86_64-linux-gnu/libhdf5.so - libhdf5.so.7.0.0
/usr/lib/x86_64-linux-gnu/libhdf5.so.7 - libhdf5.so.7.0.0
/usr/lib/x86_64-linux-gnu/libhdf5.so.7.0.0
```
resulting in the dynamic dependency
```
$ ldd mylib.so.1.0.0 | grep hdf5
libhdf5.so.7 = /usr/lib/x86_64-linux-gnu/libhdf5.so.7 (0x7f50179e2000)
```
The export file `mylibTargets.cmake` however lists
```
set_target_properties(mylib PROPERTIES
INTERFACE_INCLUDE_DIRECTORIES ${_IMPORT_PREFIX}/include
INTERFACE_LINK_LIBRARIES /usr/lib/x86_64-linux-gnu/libhdf5.so
)
```
(without the so-version). This is not good since this symlink might
not be present when I configure a project against mylib. And it
doesn't have to be either:
Actually it does have to be there (or rather it will be there).
All I need is
`/usr/lib/x86_64-linux-gnu/libhdf5.so.7` as specified by `ldd`.
No, what you also need are the headers of that library, i.e. the
'development' part of the library installation. Since those development
parts are usually mutually exclusively installable between different
versions there's going to be only 1 installed. So the .so symlink will be
there and hence the linking will work. If the symlink links to a different
so-version the linker will abort when trying to link against mylib.
The only exception would be if your mylib does not expose any of the API
that hdf5 provides and a user of mylib does not need to know or care that
you're using hdf5. In that case you should drop that library from your
public link interface. That'll automatically drop the imported target in
the export file, as the linker does not need to know what mylib links
against when linking an app against mylib. (at least for shared libraries).
Andreas
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
[CMake] How to replace get_target_property(LOCATION)?
Hello,
with cmake 2.8.12 get_target_property(LOCATION) isn't allowed anymore. I find
the documentation for CMP0026 really confusing. Maybe someone can tell me what
the way is how to do it.
I have:
src/CMakeLists.txt:
add_library(nss_wrapper SHARED nss_wrapper.c)
get_target_property(NWRAP_LOCATION nss_wrapper LOCATION)
set(NSS_WRAPPER_LOCATION ${NWRAP_LOCATION} PARENT_SCOPE)
tests/CMakeLists.txt:
set(TEST_ENVIRONMENT LD_PRELOAD=${NSS_WRAPPER_LOCATION})
So how do I get and set the location of the library with cmake 2.8.12 now?
Thanks,
-- andreas
--
Andreas Schneider GPG-ID: CC014E3D
www.cryptomilk.orga...@cryptomilk.org
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Mac bundled application with multiple executables.
Hi Bill, On Sun, Feb 9, 2014 at 8:45 PM, Bill Somerville b...@classdesign.comwrote: Hi, noob here so firstly thanks for the great build tools! I'm struggling with shoehorning a Win32/Linux Qt GUI application into CMake for those targets and for OS-X. At the moment the Mac build is manually transformed into an OS-X app bundle. I am making some progress getting it to install (and package, for deployment) directly into a bundle format. Using MACOSX_BUNDLE on the main GUI executable target plus the required CMake variable declarations. What I am stuck with is how to include another executable in the app bundle. It is a console type program that is spawned from the GUI to do some background work. Although it can be run standalone from the console, its purpose is to be run by the GUI program. Therefore it belongs in the bundle. What incantation do I need to give CMake to get this executable into the bundle installation. It is built as a target by the same CMake script as the GUI executable. This is how CMake itself is shipped on MacOSX (the bundle starts the qt gui and contains the console gui as well as the various cli tools like cmake, ctest etc. So you may want to look into CMake's own buildsystem files for that, IIRC the cmake buildsystem wasn't that hard to understand and follow. Andreas -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to read and compile dynamically-generated list of cpp files
Hi, On Mon, Feb 03, 2014 at 12:00:02PM -0500, cmake-requ...@cmake.org wrote: Date: Mon, 3 Feb 2014 16:44:28 + From: gimmeamilk gimmeamilk gimmeamilkb...@googlemail.com Hi all, I have a custom tool that processes a given list of IDL files and produces a number of .cpp and .h files as output. I want to add those files to the list of things to compile in my CMakeLists, and also model the dependencies those files have on the IDL. To keep things simple, I will state that any change to any of the IDL files should trigger a regeneration of all cpp/h. I have a custom command that takes care of running the generator tool and listing all the IDL files as dependencies. My issue is getting the subsequent list of cpp/h files into cmake at build-time. It is not possible to infer from the name of the IDL files what cpp files will be generated. My generator tool will, however, output the list of generated files to a text file. So my question is: how do I instruct cmake to read from this text file and add the contents as extra source and header files to be compiled, also bearing in mind that the said text file only exists during a certain point of the build? Judging from my (in?)sufficient amounts of CMake experience, I'd say that's not possible, since we'd be talking build-time (IOW, generator-type-specific) injection of dependencies into the generated build system. But then CMake does have some amounts of interesting features, so I might end up staying corrected (the only feasible mechanism might be to configure the IDL user side as an ExternalProject, to have its configure-time activity - and thus its analysis of the generated text file - happen during build-time execution of the main project). I've been spending quite some time integrating (M?)IDL support into my vcproj2cmake converter, so I know that several IDL compilers have options for specifying specific files (IID header, proxy header, etc.). And I'd expect such a capability to be required anyway, since it's *fixed source files* content which thus has no choice but to #include *specifically-named* files, thus the build process would *have to* be able to custom-name such output file names. Plus, I can report that on .vc[x]proj files there are rather liberal possibilities for custom-named patterns of IDL-related output filenames. So I'm mildly astonished that one would have a setup where this is NOT the case. BTW, it might be very worthwhile to provide an actual CMake LANGUAGE configuration for your IDL compiler mechanism, for pretty automatic specification of IDL files etc. (but perhaps it's wise to choose a language identifier other than a plain IDL, since CMake might choose to provide generic IDL support on its own eventually). HTH (got milk?), Andreas Mohr -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Announcing CMake BASIS, a set of CMake based project interoperability and automation tools
On Jan 24, 2014, at 12:49 PM, Stephen Kelly steve...@gmail.com wrote: Roger Leigh wrote: On Thu, Jan 23, 2014 at 10:40:54AM +0100, Stephen Kelly wrote: Andreas Schuh wrote: On a side note, just today a co-worker asked me why the compiler cannot find the header files when they were provided as additional arguments to the add_executable command. Indeed this was a reasonable assumption, I think. Why the need for an additional include_directories when I already specified where the header files are located ? This is not something BASIS is taking care of yet either, but would certainly be one of the things I would consider adding. This is the kind of concrete feedback *about cmake* that I'm looking for in this discussion. It's self contained, refers to existing cmake functionality, it's easy to imagine the 'user story' and what the user code would look like etc. I don't have any comment about the viability of adding such functionality to cmake add_* commands though. I'm not sure this can ever be viable because it makes assumptions that are guaranteed to break for different use cases. If I add a header, cmake can have no knowledge of how the sources use the header. Is it an absolute or relative include? Does the relative include also include a path? Exactly. That sounds all viable to me for having the separate mechanisms. But does CMake not already parse the C++ module files in order to determine the dependencies on header files ? I was in the believe that you do not actually need to specify the header files when calling add_executable because it would find out which are included by each specified .cpp file and add the appropriate file dependencies. If so, it would actually be able to determine the correct paths to add to the include search path. But I also see one problem left here. That for some projects the location of header files can differ between source/build tree and installation. I still would assume that in most cases the correct relative path can be deduced from the build configuration and dependency analysis of .cpp modules. See also http://cmake.3232098.n2.nabble.com/Query-regarding-header-files-in-CMakeLists-txt-td7581689.html I think the general sentiment that having add_executable remove a redundant include_directories statement is a good one. I'm just unconvinced that this is doable in practice. My thoughts exactly. Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Announcing CMake BASIS, a set of CMake based project interoperability and automation tools
On Jan 24, 2014, at 10:49 AM, Stephen Kelly steve...@gmail.com wrote: There seems to be some mailing list problems going on (maybe Andrew didn't subscribe before posting... :/ Always subscribe to a mailing list before posting...), and my reply was rejected. I had one rejected post because I was yet subscribed with “googlemail.com” instead of the new “gmail.com” domain which is only since a few years legally allowed to be used by Google in Germany now. Updated my subscription then. Breaking threading to respond. On 01/23/2014 07:32 PM, Andrew Hundt wrote: Allow me to rephrase, could you send a link or other reference such as a summary posted on a mailing list where I can learn about the KDE situation and how it was resolved? Essentially, I would appreciate any additional information you could give me that would help me apply your experience to my own project. However, I suspect the reasons, design, purpose, and goal of kde4_add_executable and basis_add_executable may have been significantly different but I would like to learn more. Yes, I expect so too, actually. I actually don’t think so. The main difference is likely that KDE is a C++ only project with some JavaScript for the Qt-based UIs. The purpose of basis_add_executable and basis_add_library is to be able to cope with just any programming language supported by BASIS. In particular MATLAB was of interest at the time of its development. This is unlikely a functionality that will ever make it into CMake’s add_executable or add_library commands and therefore the need for these custom BASIS functions. I don't think there's a good entry point for this. http://community.kde.org/Frameworks/Epics/CMake tracks some of the changes. http://quickgit.kde.org/?p=kdelibs.gita=commitdiffh=41986d0829d2 and http://quickgit.kde.org/?p=kdelibs.gita=commitdiffh=1fe778bca and other commits removed reasons for kde4_add_library to exist. http://www.cmake.org/cmake/help/git-master/manual/cmake-packages.7.html http://www.cmake.org/cmake/help/git-master/manual/cmake-buildsystem.7.html How does one browse to these sphinx docs from the cmake website? I've never come across them before and I generally use the main cmake docs. When there is a new release from the master branch, the sphinx docs will show up there. Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Announcing CMake BASIS, a set of CMake based project interoperability and automation tools
Find one minor correction to my previous post below. On Jan 23, 2014, at 1:11 PM, Andreas Schuh andreas.schuh...@gmail.com wrote: For example, in case of Python, you can “wrap” the script and have it act as both Windows NT Script and Python script by adding the following line at the top @setlocal enableextensions /path/to/required/python/version -x %~f0 %* goto :EOF % Any Python code goes below this line Python will ignore the first line. In case of Perl, however, you need to do a bit more: @goto = START_OF_BATCH” ; @goto = (); % Any Perl code goes in between these lines __END__: “START_OF_BATCH @“/path/to/required/perl -w -S %~f0 %* As this modified Perl script is no longer valid Perl Actually the neat thing about this added code is that it is both, valid Perl and valid Windows NT Script syntax. It is thus mostly about wrapping scripts automatically as well as replacing the path to the found interpreter executable. Andreas-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Announcing CMake BASIS, a set of CMake based project interoperability and automation tools
On Jan 23, 2014, at 9:40 AM, Stephen Kelly steve...@gmail.com wrote: Andreas Schuh wrote: How often have you seen CMake code as the following add_executable(foo foo.cpp) ? I see executables with a single source file only in dummy test code, and even then add_executable(foo main.cpp) is more common. I presume that’s because you mostly worked on larger, mainly C++ or other compiled language, based projects. At least in research software you will find these quite frequently, where there are dozens of executables implemented in single .cpp modules. These may just link to libraries which are build from a multiple .cpp modules (that is why obviously add_library would not support such short notation), but yet, the executable itself does (and IMHO should) only consist of a single .cpp module which defines the entry point (main). If you name all these main.cpp, you are not giving away what binary file this .cpp module relates to and further have to have them all in different subdirectories… Isn’t it nicer to have them all in one directory with meaningful names ? I believe program logic should go into libraries so it could be reused by other executables or packages if there need be. The basis_add_executable supports this use case as well, but additionally the shorter notation (not counting the basis_ prefix ;) ) basis_add_executable(foo.cpp) Yes, that's what I was referring to. I see why you have it. I'm not convinced it should be upstreamed. I guess most people can live with defining a CMake macro for it if they want to. is intended to bridge both, make the use of globbing expressions convenient and safe at the same time. I would like to see investigation into what can be done upstream to benefit cmake users who do not use BASIS. Another example: You have code for adding scripts as executables. What are the generic (non-BASIS related) use cases for that? You can define dependencies among them or to modules written in the same scripting language. Can you say why this is useful? Is it only useful in cases where the buildsystem creates a particular/modified script from an input, such as by replacing @VAR@? You can have find_package calls to find installed modules and declare that your script depends on them. Why is this useful? If my script depends on something external I require the find_package. Can you be more specific on what BASIS does in addition here? An installation rule for the script may ensure that the modules get installed as well. I can imagine that defining, say, a python library as such for packaging and installation purposes could be generically useful, but I'm not sure that that is what you are saying. I'm trying to find descriptions of things in BASIS that should be in cmake, that show gaps in cmake functionality etc. Think of script modules the same way you think about shared libraries in case of binary code. If you have multiple versions of a library installed, you have to specify the LD_LIBRARY_PATH or presumably better set the RPATH of the executable properly. Most scripting languages have something similar as the LD_LIBRARY_PATH and it is possible to adjust the search path within the script. To automatically generate code that does the latter to avoid the problem of having to set the module search path right, especially considering users not familiar enough with these concepts and in cases where this is not trivial due to different scripts requiring different versions of a module and thus a change of the environment, you need the information about which modules a particular script depends on along with the imported locations of the used modules. This you can get with CMake via the import targets and the dependency graph among scripts and modules. Not sure if you would like such functionality in a tool such as CMake, but for the purposes of BASIS it worked out well. At the top of each executable script, BASIS inserts the appropriate code to prepend the default “RPATH” of the scripts to the search path. Relative paths where appropriate to maintain relocate-abilitiy as much as possible, absolute paths otherwise. Yet, if an installation would be relocated, using the other means of setting the environment variables can possibly fix any potentially broken search paths. But that is also what you get with the RPATH of binary executables. Installations are generally not meant to be moved around. The higher priority is ensuring that scripts use the right version of the modules they were “linked” to. When wrapping scripts in Windows Command files to mimic the she-bang directive of Unix, calling such script becomes just as convenient as it is on Unix from the command line without having to specify the interpreter executable explicitly. I'm not familiar with Windows, but this comment doesn't seem to relate to cmake? Maybe not to CMake, but whatever is taking care
Re: [CMake] Announcing CMake BASIS, a set of CMake based project interoperability and automation tools
On Jan 23, 2014, at 1:11 PM, Andreas Schuh andreas.schuh...@gmail.com wrote: On Jan 23, 2014, at 9:40 AM, Stephen Kelly steve...@gmail.com wrote: Another example: You have code for adding scripts as executables. What are the generic (non-BASIS related) use cases for that? You can define dependencies among them or to modules written in the same scripting language. Can you say why this is useful? Let me give just one more example, if you could define that a script depends on another executable target (e.g., build from C++), when I rebuild only the script, the other executable will be recompiled and linked if it has changed since the last build as well. This is not possible at the moment without custom build commands/targets, but often (Shell) scripts are indeed calling other executables of your package. Then if you just want to test the changes made to the script, you can simply run “make myscript” and all dependencies will be updated as well.-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Announcing CMake BASIS, a set of CMake based project interoperability and automation tools
On Jan 23, 2014, at 4:17 PM, Stephen Kelly steve...@gmail.com wrote: Andreas Schuh wrote: On Jan 23, 2014, at 1:11 PM, Andreas Schuh andreas.schuh...@gmail.com wrote: On Jan 23, 2014, at 9:40 AM, Stephen Kelly steve...@gmail.com wrote: Another example: You have code for adding scripts as executables. What are the generic (non-BASIS related) use cases for that? You can define dependencies among them or to modules written in the same scripting language. Can you say why this is useful? Let me give just one more example, if you could define that a script depends on another executable target (e.g., build from C++), when I rebuild only the script, the other executable will be recompiled and linked if it has changed since the last build as well. This is not possible at the moment without custom build commands/targets, but often (Shell) scripts are indeed calling other executables of your package. Then if you just want to test the changes made to the script, you can simply run “make myscript” and all dependencies will be updated as well. This looks like something that might be worth supporting better, but I can't imagine how the cmake code would look or work. With the current CMake commands, you could actually do the following: add_executable(myutil main.cpp) add_custom_target(myscript SOURCES myscript.sh) add_dependencies(myscript myutil) My goal with BASIS was, however, to reduce the number of different commands needed as in add_executable(myutil.cpp) add_executable(myscript.sh) add_dependencies(myscript myutil) and to establish an understanding of scripts to be just another kind of executables and modules being just another kind of shared library. Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] custom command with non-zero exit code?
Hi, I have a custom command to copy over some javascript files from the source to the build tree and along with that run them through a javascript lint tool. The main point of the lint is to catch syntax errors and the like early on. Unfortunately the lint tool also reports all kinds of warnings it detects and if there's any warning will generate a non-zero exit code. This behaviour is not configurable in any way. This creates a problem since the commands for add_custom_command seem to be required to generate a 0 exit code, understandably. My current solution to that is a cmake script that uses execute_process along with message( FATAL_ERROR ) if the exit code indicates actual errors in the javascript files. This is then called from add_custom_command. I'm wondering if anybody has come across such a situation and wether I'm maybe overlooking a more lightweight/easier to understand/simpler solution to the issue? Andreas -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Announcing CMake BASIS, a set of CMake based project interoperability and automation tools
Hi Steve and all, On Jan 23, 2014, at 12:47 AM, Andrew Hundt athu...@gmail.com wrote: On Wed, Jan 22, 2014 at 5:44 PM, Stephen Kelly steve...@gmail.com wrote: Andrew Hundt wrote: CMake BASIS is a set of utilities and standards created with the goal of making CMake projects and libraries very easy to create, share, and reuse. Hello, There seems to be several years of development behind this already. Is it newly public, or newly publicized? I've never heard of it before. The about page and the 3.0 release on github explains the history reasonably well. Previously it was public but not publicized. For the v3.0 release we moved it to github, redesigned and rewrote much of the documentation, added custom project templates, and made everything else configurable. For example we needed take out previously hard coded items such as University of Pennsylvania logo (I'm at Carnegie Mellon). I’ve been developing BASIS mainly to establish some software development and distribution practices in the research lab I was working and to reduce the repetition of CMake code across (the various small) projects. It has been public, but I mainly used within this lab. Since then, however, I changed position and took the project with me with the hope to make it more generally useful and to offer it as a resource for various CMake and other auxiliary functions. The main goal of BASIS was to set a certain “standard” for project organization and everything related to it for researchers who are not very familiar with common practices and especially not with the many possibilities and features of the whole CMake suite. Further we wanted to unify the look and feel of research software developed by individuals and yet distributed as open source by one lab, namely SBIA at Penn. It has been thus far only used by myself to repackage the research software that was developed at this lab while I was employed there. But it clearly has potential to be extended and used also by more experienced developers. Website: http://opensource.andreasschuh.com/cmake-basis/index.html GitHub: https://github.com/schuhschuh/cmake-basis/ The repo is surprisingly large (67 mb) for something like this. I consider such large files in a git repo to be bad practice. This is just the first thing I noticed... Commit: [...] Hmm, I hadn't noticed the size before. There are a few powerpoint presentations and a PDF manual that probably contribute to the size, there are also a couple of small external libraries that are directly committed into the tree. The zip version of the release is 2.7 MB which is not quite as bad. I'm not well versed with the guts of git but are there any good ways to do some cleanup? My bad. The PowerPoint presentations were only on an internal Wiki server at the beginning, but having them within the repo which is supposed to document a standard (rather than being software alone) seemed to be the right place. Of course I would prefer now a different format than PowerPoint slides to create this kind of documentation. The PDF manual can be created from the reST source files and I was considering removing it again from version control for that very reason. Also, if any CMake developers are interested in bringing any of this functionality upstream into CMake itself we would also love to hear from you. I read some of the docs and some of the code (TargetTools.cmake). My understanding my not be complete or correct. 1) BASIS seems to be doing lots of things. Can you identify what parts of BASIS or what concepts are most valuable/most useful/most missing from CMake etc? I think you could know better than we can. I would suggest many of the items from the BASIS CMake modules, specifically the section labeled BASIS Modules. Some of the specific useful items include: basis_add_doc() - built in support of documentation tools Additional support for other languages, such as MATLAB and Python Automated packaging and installation of libraries Support for doxygen documentation of CMake Code I'm sure there is more but those are some of the most obvious items that I can think of off the top of my head. For example, do you consider add_executable(myexe.cpp) to be good user interface for creating a target called 'myexe', and something that CMake should do? It seems like it would be pretty straightforward and easy to use. I've seen that functionality implemented independently on more than one occasion. How often have you seen CMake code as the following add_executable(foo foo.cpp) ? The basis_add_executable supports this use case as well, but additionally the shorter notation (not counting the basis_ prefix ;) ) basis_add_executable(foo.cpp) Should CMake automatically create installation rules for it? I think this would be excellent if there was a reasonable default, plus more advanced configuration for when it is
[CMake] [BUG] [INFRASTRUCTURE] Wiki editing broken?
Hi,
I just tried to edit
http://www.cmake.org/Wiki/index.php?title=CMakeaction=submit
after a seemingly successfully legitimate login,
and all I got was:
Internal error
Detected bug in an extension! Hook ReCaptcha::confirmEdit failed to return a
value; should return true to continue hook processing or false to abort.
Backtrace:
#0 /mounts/raid/projects/KitwareWeb/PublicWiki/includes/EditPage.php(802):
wfRunHooks('EditFilter', Array)
#1 /mounts/raid/projects/KitwareWeb/PublicWiki/includes/EditPage.php(2552):
EditPage-internalAttemptSave(false, false)
#2 /mounts/raid/projects/KitwareWeb/PublicWiki/includes/EditPage.php(389):
EditPage-attemptSave()
#3 /mounts/raid/projects/KitwareWeb/PublicWiki/includes/EditPage.php(271):
EditPage-edit()
#4 /mounts/raid/projects/KitwareWeb/PublicWiki/includes/Wiki.php(553):
EditPage-submit()
#5 /mounts/raid/projects/KitwareWeb/PublicWiki/includes/Wiki.php(70):
MediaWiki-performAction(Object(OutputPage), Object(Article), Object(Title),
Object(User), Object(WebRequest))
#6 /mounts/raid/projects/KitwareWeb/PublicWiki/index.php(117):
MediaWiki-performRequestForTitle(Object(Title), Object(Article),
Object(OutputPage), Object(User), Object(WebRequest))
#7 {main}
and my changes have been verified to NOT have been saved.
There also was the hint
Note: This page has been locked so that only registered users can edit it. The
latest log entry is provided below for reference:
16:51, 16 May 2011 WikiSysop (Talk | contribs) protected CMake
[edit=autoconfirmed] (indefinite) [move=autoconfirmed] (indefinite) (hist)
on that page, but a valid-logon user ought to have no issues with that right?
Logout and re-login didn't manage to rectify it either.
Tested editing on aptosid live, Iceweasel 10.0.12 (whoops).
Hmm?
Thanks,
Andreas Mohr
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] boostrap error - borked cmConfigure.h [v2.8.12.1]
Hi, On Fri, Jan 10, 2014 at 2:16 PM, Szilárd Páll pszil...@kth.se wrote: Found a workaround: $ find /tmp/cmake-2.8.12.1 -type f | xargs dos2unix This must be a bug, should I file a report? Did you use the .zip file of the CMake sources? That one is intended to be used for Windows and hence contains Windows lineendings. Thus its not surprising that you have to convert that to unix first, not all *nix tools can handle windows lineendings. Alternatively you can use the *.tar.* download of the CMake sources. Andreas -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] boostrap error - borked cmConfigure.h [v2.8.12.1]
Hi, On Fri, Jan 10, 2014 at 9:42 PM, Szilárd Páll pszil...@kth.se wrote: Indeed, I did (accidentally) download the .zip package. I was rather annoyed that the bootstrap script did not have executable permission set, but it did not ring a bell... Thanks guys! Just for curiosity: - what *nix tool does not support CR+LF? As your error shows they got transported literally from an end of line into a c++ header. Which part in the build process would need to be fixed I don't know, I'd start searching where the cmake-2.8 value is supposed to come from and who generates the numbers. - the cross-platform codes I work on use LF newlines but build without problem on Windows (msvc, intel, gcc). Why does CMake need two separate packages with different newlines? The problem is not so much the compilers (though there could be older versions which choke on just lf), but some editors still require crlf for line breaks (try opening a unix-file with Windows' notepad). Andreas -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Provide 64bit Linux binaries
Hi, I know this has been raised in the past, but I don't think the arguments for not providing the binaries are strong enough to warrant the hassle a cmake user has to go through to run the 32bit binaries on a 64bit Linux distribution. I think requiring users to figure out how to install 32bit compat libraries and keeping a copy of at least libc on the machine for no other purpose than running cmake does not really fit the intention of providing binaries in the first place. As far as I understand the idea was to make it easier for people who cannot upgrade a package-manager-provided CMake (for whatever reason) to use a newer CMake. Requiring those people to build from source does not really make it easy and not all distributions install 32bit compat libraries out of the box (let alone older machines which have no such compat libs at all) So can we please get 64bit Linux binaries for the next CMake release? Andreas -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Provide 64bit Linux binaries
Hi, On Wed, Jan 8, 2014 at 10:07 PM, Magnus Therning mag...@therning.orgwrote: On Wed, Jan 08, 2014 at 01:56:22PM +0100, Andreas Pakulat wrote: Hi, I know this has been raised in the past, but I don't think the arguments for not providing the binaries are strong enough to warrant the hassle a cmake user has to go through to run the 32bit binaries on a 64bit Linux distribution. I think requiring users to figure out how to install 32bit compat libraries and keeping a copy of at least libc on the machine for no other purpose than running cmake does not really fit the intention of providing binaries in the first place. As far as I understand the idea was to make it easier for people who cannot upgrade a package-manager-provided CMake (for whatever reason) to use a newer CMake. Requiring those people to build from source does not really make it easy and not all distributions install 32bit compat libraries out of the box (let alone older machines which have no such compat libs at all) So can we please get 64bit Linux binaries for the next CMake release? What 64-bit Linux distribution, that doesn't package CMake, do you use? I did not say there is no CMake package, the point I'm trying to make is that if someone wants or needs a newer CMake release than his Distro provides this is not as easy as it should be for a 64Bit Linux system (that does not yet have 32bit compat libs installed). Andreas -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cannot set CMP0022 to OLD
Hi, On Sat, Dec 14, 2013 at 2:58 PM, Stephen Kelly steve...@gmail.com wrote: Andreas Pakulat wrote: Anyway, I've now stripped it down as much as I can (without diving into the wilderness of FindKDE4Internal) and also added the observations I've made while stripping it. So its definetly somewhat related to the magics that the KDE4 module does. It's related to the scope of the policy and the context of the macro, which is a bit counterintuitive. Your options are: 1) Set the policy in KDE4Internal.cmake, like the rest of the policies. 2) Apply a patch equivalent to: diff --git a/CMakeLists.txt b/CMakeLists.txt index b93f190..134181c 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -5,6 +5,7 @@ cmake_minimum_required(VERSION 2.8) project(KDevPlatform) cmake_policy(SET CMP0022 OLD) find_package(KDE4 4.7.0 REQUIRED) +include(KDE4Macros NO_POLICY_SCOPE) Thanks for taking the time to analyze this and enlighten me about the options. I'll see what the KDevelop team prefers. Andreas -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Cannot set CMP0022 to OLD
Hi, I've been quite annoyed by the warnings from CMP0022 in a project I use ( http://quickgit.kde.org/?p=kdevplatform.git) and wanted to set the policy to OLD to hide the warnings (porting the code is not an option as that would require to enforce CMake 2.8.11 which is too new for this project). Unfortunately no matter where I put either a cmake_policy(VERSION 2.8.6) or even cmake_policy(SET CMP0022 OLD) I still get the warnings all the time. I'm using CMake 2.8.12.1 here and was wondering wether anybody else run into this already? I've tried to come up with a small example, but can't seem to get it to trigger the CMP warning at all. Andreas -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Proper behaviour and use of CMAKE_INSTALL_* variables
Hi, On Mon, Dec 9, 2013 at 3:50 PM, Mojca Miklavec mojca.miklavec.li...@gmail.com wrote: Dear list members, I often like or need to install two versions of the same software. Ideally the software should put its files by default to $prefix/include/$NAME/*.h $prefix/lib/$NAME/*.dylib ... ($prefix = $CMAKE_INSTALL_PREFIX) and in order to be able to install multiple versions side-by-side I would like to be able to specify something like -DCMAKE_INSTALL_INCLUDEDIR=include/$NAME/$VERSION -DCMAKE_INSTALL_LIBDIR=lib/$NAME/$VERSION to end up with $prefix/include/$NAME/$VERSION/*.h $prefix/lib/$NAME/$VERSION/*.dylib instead of default paths. Do you have any reasons that speak against using separate prefixes for each version of that software? In particular since such a setup will make your life harder when you want to use the installed software in some cmake-based project. In that case you'd have to manually specify include-dir and lib-dir when configuring the project since many find-modules simply expect a 'standard' unix-like layout below the prefix under which they should search for a given software. So they don't look into include/version or lib/version so you'd need to specify that manually. Compared with the ease of just specifying CMAKE_PREFIX_PATH to the installation directory for the version you want thats a lot more effort each time you setup a build directory. Andreas -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] TARGET property LOCATION
Hi,
On Tue, Nov 26, 2013 at 12:00:10PM -0500, cmake-requ...@cmake.org wrote:
Date: Tue, 26 Nov 2013 12:13:16 +0100
From: Marcel Loose lo...@astron.nl
Subject: [CMake] TARGET property LOCATION
Hi all,
According to the CMake documentation, the TARGET property LOCATION for a
non-imported target is provided for compatibility with CMake 2.4 and
below. My question is: are there any plans to deprecate this property? I
want to know, because AFAIK, the only way to determine the full path to
a built target is to use this property.
Yeah, a very good question. Especially since for somewhat older
(I assume that these already were a bit newer than the LOCATION deprecation
event though!)
CMake versions I have a need for the following conditional code
(or similar to it - not 100% sure whether LOCATION is the only way to handle
it):
# CMake add_test() has a plain signature and additionally a NAME/COMMAND
signature
# in newer versions.
# Since I somehow managed to completely miss this,
# I filed a CMake bug report (#12589).
# Let's thus use the newer signature whenever it's supported.
set(cmake_add_test_command_signature_supported_ false)
set(cmake_version_add_test_command_signature_not_supported_last 2.7.0) #
FIXME which version?
set(cmake_version_add_test_supports_command_signature_check
${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION}.${CMAKE_PATCH_VERSION})
if(${cmake_version_add_test_supports_command_signature_check} VERSION_GREATER
${cmake_version_add_test_command_signature_not_supported_last})
set(cmake_add_test_command_signature_supported_ true)
endif(${cmake_version_add_test_supports_command_signature_check}
VERSION_GREATER
${cmake_version_add_test_command_signature_not_supported_last})
if(cmake_add_test_command_signature_supported_)
function(_ctest_add_test_sanitized _target)
set(testname_ ${_target})
set(testexe_ ${_target})
add_test(NAME ${testname_} COMMAND ${testexe_})
endfunction(_ctest_add_test_sanitized _target)
else(cmake_add_test_command_signature_supported_)
function(_ctest_add_test_sanitized _target)
set(testname_ ${_target})
# Work around incapable add_test(), by using a property which
# is said to be deprecated... (*** SIGH ***).
get_property(test_location_ TARGET ${_target} PROPERTY LOCATION)
set(testexe_ ${test_location_})
add_test(${testname_} ${testexe_})
endfunction(_ctest_add_test_sanitized _target)
endif(cmake_add_test_command_signature_supported_)
Best regards,
Marcel Loose.
Andreas Mohr
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Qt4 QT_INSTALL_LIBS
Hi, On Thu, Nov 14, 2013 at 11:45 AM, Lars Lars laasu...@hotmail.com wrote: Using CMake 2.8.10 on Windows 7. We have a working project that finds QT liket this: FIND_PACKAGE(Qt4 4.7.1 COMPONENTS QtCore QtGui) Now we would like to update Qt library, so changed it to: FIND_PACKAGE(Qt4 4.8.4 COMPONENTS QtCore QtGui) This however fails because FindQt4.cmake execute qmake -query QT_INSTALL_LIBS which returns the path where the Qt library was built. We however store Qt in another location in our development setup. How can is solved this issue without rebuilding the Qt library in the same path as the development setup? Your Qt won't work from that place as it is either. Qt is not relocatable, the path to the install location is hardcoded into the tools. If you build a Qt project with qmake it'll also generate compiler commands that point to the non-existing install location. You can make the Qt installation relocatable by adding a qt.conf file and qmake will pick this up as well, see the Qt docs for more information: http://qt-project.org/doc/qt-4.8/qt-conf.html. What is the rational behind querying qmake for the the location of the libs? Because qmake knows best where the libs are. There are various ways of customizing the structure and the structure can be different across platform. Andreas -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
