Re: [CMake] building cmake without the bootstrap step
Never mind, this tweak to the bootstrap script should take care of anything not directly obvious. Could do with an automated test of the installed version but the accepted version range is so large that doesn't seem to be the trouble. ``` if [ -x ${cmake_prefix_dir}/bin/cmake ] ;then # use the existing cmake that we'll be replacing. ln -s ${cmake_prefix_dir}/bin/cmake ${cmake_bootstrap_dir}/cmake else # Run make to build bootstrap cmake if [ "x${cmake_parallel_make}" != "x" ]; then ${cmake_make_processor} ${cmake_make_flags} else ${cmake_make_processor} fi RES=$? if [ "${RES}" -ne "0" ]; then cmake_error 9 "Problem while running ${cmake_make_processor}" fi fi cd "${cmake_binary_dir}" ``` R -- Powered by kitware.com/cmake Kitware offers various services to support the CMake community. For more information on each offering, please visit https://cmake.org/services Visit other Kitware open-source projects at https://www.kitware.com/platforms Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake This mailing list is deprecated in favor of https://discourse.cmake.org
Re: [CMake] building cmake without the bootstrap step
On Thursday December 12 2019 09:36:03 Kyle Edwards wrote: >If you want to skip bootstrapping, you can use a pre-existing CMake >binary for your system to build the new CMake. > >This mailing list is deprecated. Please head over to Discourse for >further discussion: OK, thanks. To finish things up here, there is thus nothing in the arguments to the bootstrap script that is crucial and cannot be set via a preexisting cmake command? R. -- Powered by kitware.com/cmake Kitware offers various services to support the CMake community. For more information on each offering, please visit https://cmake.org/services Visit other Kitware open-source projects at https://www.kitware.com/platforms Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake This mailing list is deprecated in favor of https://discourse.cmake.org
[CMake] building cmake without the bootstrap step
Hi, If I understand correctly, configuring CMake for building means bootstrapping a basic version of itself which is then run on the included CMakeLists.txt file. That takes a lot of time (comparatively) which begs the question if there's a more-of-less official way to skip the bootstrap and just use the installed cmake binary? Thanks, René -- Powered by kitware.com/cmake Kitware offers various services to support the CMake community. For more information on each offering, please visit https://cmake.org/services Visit other Kitware open-source projects at https://www.kitware.com/platforms Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake This mailing list is deprecated in favor of https://discourse.cmake.org
[CMake] cmake and high-dpi support on Mac
Hi, CMake had hardcoded default support for high-dpi screens in the applications it generated for Apple's desktop OS at some point, but that was removed very quickly in 286c75f7f034c5fdcd43bcb755da74d09c809642. It is my understanding that you don't actually need to set the high-dpi key explicitly, but that it defaults to on for the desktop OS. IOW, it's enough to set the NSPrincipalClass property to NSApplication. I cannot check this myself, and I have no idea if and how NSPrincipalClass can be set for Apple's other OS variants. But maybe one could use this property in a minimal-change change to enable high-dpi support automatically in applications that do not provide their own Info.plist: add this to the bundle plist template: + NSPrincipalClass + <${MACOSX_BUNDLE_PRINCIPALCLASS}/> If the target OS is known when the MACOSX_BUNDLE_* variables get their default, MACOSX_BUNDLE_PRINCIPALCLASS could default to whatever class is appropriate for the target OS, otherwise it would just be set to NSApplication (and users targetting other OS variants would have to set the property explicitly, which is still less cumbersome than providing a custom template). Thoughts please? Thanks, R. -- 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_AR/NM/RANLIB require full path?!
Hi, I just got some build failures when changes to my build scripts led to configuring with -DCMAKE_AR=ar (RANLIB=ranlib, etc). The documentation isn't explicit on what these parameters expect so I assumed that it should be fine to set them to a command name, as with CMAKE__COMPILER. Wrong! CMake will apparently prepend CMAKE_BINARY_DIR to these commands. If this is intentional, why isn't it documented in the CMAKE_AR (etc) description? Thanks, R. -- 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] support for -fsyntax-only (and generating Qt/KDE's auto-generated content)
Sylvain Joubert wrote: > My use case is for static analysis builds. For example, my CI setup has > multiple of them including cppcheck, clang-tidy and iwyu through the > CMake integration. And since I'd like to keep separate builds for each > of them this requires 3 full build whose results I don't really care. Are you thinking of tools that are invoked instead of the compiler, like clazy- standalone? I thought about mentioning a potential interest of my idea for using such tools (but forgot in the end). Specific support for -fsyntax-only may not be relevant for those tools, but a build mode where the final step of each build product is not taken would probably be useful there, indeed. Such a mode might even create an empty file with the intended name, so that there's something to refer to later during a build. I've been considering to write a little wrapper one could "inject" using CMAKE__COMPILER_LAUNCHER but there is no equivalent for the final product generation step (linker, librarian). > > So if we can achieve a light build mode, that would be great. In my case > I could completely deactivate the build part including the syntax > checking since that's done by the static analysis tools anyway. You'd get that by setting your analysis tool as the compiler. > Anyhow, we can't deactivate all the build. As you said auto-generated > content, custom targets,... would need to stay. And besides, cmake's goal is to create files with which one can build projects. Generating something that doesn't attempt to build at all could well require a lot more implementation effort than pretending the linker/librarian step always succeeds. FWIW, I notice that the link step now takes the form cmake -E cmake_link_script CMakeFiles/.dir/link.txt IOW there are 2 levels where linker errors due to missing objects can be intercepted: in the link.txt script, and in cmake itself. R. -- 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] support for -fsyntax-only (and generating Qt/KDE's auto-generated content)
Hi, Apologies, longish post ahead. I've tried to present my idea and the thought train leading up to it as succinctly as possible. Hope I at least strike a chord! Clang and GCC have long supported an option that makes them stop after the syntax-verification stage: -fsyntax-only . This has the advantage (see below) that it's much faster than a regular build and that no output is generated. The absent output is also a problem and the reason I'm posting about it here: - compiler checking fails because of the missing output. - link and archive (static lib) creation fail because of missing files. The first problem should not be hard to fix (filter out -fsyntax-only from the arguments used to check the compiler). The 2nd problem can be addressed by ignoring the exit code from linking and archiving commands (possible with make, presumably with ninja too). Would it be feasible to implement "something" that makes it possible to run a full pure-syntax-checking "build", either as a special target or as a separate mode of operation or CMAKE_BUILD_TYPE? I think this could be useful in general esp. with larger projects, allowing to check "quickly" if a change (triggering a full rebuild) breaks something. QtWebKit would be an appropriate example: it uses a central header to set the configuration preprocessor tokens so toggling even one of these switches causes *everything* to be rebuilt. Some more observations which outline a context where cmake-level support for a pure syntax-checking run would be beneficial (also the context that made me remember the -fsyntax-only option): - a number of IDEs (can) use CMake as the basis for project definition. - They also provide parsing facilities that also use information from cmake to control the parser. - KDE has long used cmake instead of autoconf (or qmake) and is based on Qt, which means KDE projects depend on auto-generation of files which need to be included in C++ code. - Parsing or even syntax-checking won't work to at least some degree without those auto-generated files. - opening a project in an IDE is not always done with the intention to build it; in absence of such an intention one usually does expect to be able to rely on parsing and syntax checking. - Auto-generation of Qt's automatic content occurs during a full build, when needed. That last observation is the big bottleneck; a full build can be very costly. If there were a dedicated target to generate just all automatic content one could just build that target and there would be no issue left. Whether or not this is impossible is unclear, and at least not entirely a CMake issue. Here too something like -DCMAKE_BUILD_TYPE=SyntaxOnly would be a workable solution. R. -- 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] SOVERSION and Mac library id in shared library made from assembly files
Hi, I have a little project that creates a shared library from a pair of assembly files. I've been trying to follow examples such that the generated library - has versioning (libFastCompression.1.dylib on Mac or libFastCompression.so.1 on Linux) - has the full path as its ID on Mac I get this in the projects I used as example, but not in this particular project. Am I overlooking/forgetting something, or is what I'm looking for not implemented/supported for libraries built exclusively from assembly files? The project: github.com/RJVB/lzvn 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: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] losing CMakeCache.txt after changing the compiler...
Marc CHEVRIER wrote: > If you have multiple compilers or even multiple versions of a compiler, by > managing carefully environment variables (i.e. PATH variable for example) > by using some bash functions, you can easily ensure to use always the > correct compiler for each build environment. That just shouldn't be necessary: to do this properly (in a way to helps avoiding simple mistakes like running cmake with 1 env. setting and then make with a different setting) requires writing something on top of cmake. Not that I already have something like that, but did I say it shouldn't be necessary? -- 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] losing CMakeCache.txt after changing the compiler...
Marc CHEVRIER wrote: > You can easily avoid this bad experience by using different builds > environments : one per compiler ! You mean one build directory per compiler? That can be very disk-expensive, and it doesn't solve the issue (e.g. you clone an environment and then change the compiler - why would that cause certain cached variables to be reset that don't need to be reset). Qt projects using CMake (e.g. KDE) are in a class of their own; Qt's auto- generation applications use a mix of hardcoded absolute and relative paths that can easily go wrong when you update something that invalidates certain paths. Or when you access your build directory in different ways. This is a bit of a different issue, but suppose you have directories: /a/b/c/d/e/f/projectA/work/source /a/b/c/d/e/f/projectA/work/build and a symlink $HOME/projects/projectA -> /a/b/c/d/e/f/projectA Depending on shell and OS you may get surprises when you do things like %> cd $HOME/projects/ %> (cd projectA/work/build ; cmake ../source) %> (cd /a/b/c/d/e/f/projectA/work/build ; make) Qt's auto-generated relative paths (in step 2) will be invalid in step 3 if no path normalisation occurs, because of the different number of levels between the 2 access paths to the same working directory. Linux suffers from this, not the Mac OS. This is a cmake issue only insofar as cmake could prevent it by normalising the working dir always (make should probably do the same). R. -- 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] losing CMakeCache.txt after changing the compiler...
Hi, This happened once too often for me: I apply successive tweaks to a CMakeCache file, reinvoke make (or ninja) and then at some point lose everything because I forgot that changing the compiler is a "lethal" operation. Why does cmake have to throw away the entire cache file when something changes in the compiler path? That seems like a cheap way to implement a "let's keep track of which cached settings depend on the choice of compiler". At the least it wouldn't be much less cheap to rename CMakeCache.txt to CMakeCache.bak instead of deleting it. And FWIW, this is also a situation in which storing the exact CMake invocation in a comment at the top of the cache file could be useful... R. -- 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 not always replacing symlinks in the path used to access a build.dir?!
WTH, apparently this can even happen without regeneration (that I know of, at least): %> CD kdevld-lnx-work/build/plugins/ wmake --MP -w ### /opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/build/plugins ### /home/bertin/script/wmake --MP -w ### Mon Sep 18 11:06:15 CEST 2017 make: Entering directory `/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/build/plugins' cd /home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build && /opt/local/bin/cmake -H/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/kf5-kdevelop-5 -B/home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build --check-build-system CMakeFiles/Makefile.cmake 0 cd /home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build && /opt/local/bin/cmake -E cmake_progress_start /home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build/CMakeFiles /home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build/plugins/CMakeFiles/progress.marks cd /home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build && make -f CMakeFiles/Makefile2 plugins/all make[1]: Entering directory `/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/build' make -f kdevplatform/interfaces/CMakeFiles/KDevPlatformInterfaces_autogen.dir/build.make kdevplatform/interfaces/CMakeFiles/KDevPlatformInterfaces_autogen.dir/depend make[2]: Entering directory `/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/build' cd /home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build && /opt/local/bin/cmake -E cmake_depends "Unix Makefiles" /opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/kf5-kdevelop-5 /opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/kf5-kdevelop-5/kdevplatform/interfaces /home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build /home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build/kdevplatform/interfaces /home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build/kdevplatform/interfaces/CMakeFiles/KDevPlatformInterfaces_autogen.dir/DependInfo.cmake --color= Scanning dependencies of target KDevPlatformInterfaces_autogen make[2]: Leaving directory `/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/build' make -f kdevplatform/interfaces/CMakeFiles/KDevPlatformInterfaces_autogen.dir/build.make kdevplatform/interfaces/CMakeFiles/KDevPlatformInterfaces_autogen.dir/build make[2]: Entering directory `/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/build' [ 0%] Automatic MOC for target KDevPlatformInterfaces cd /home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build/kdevplatform/interfaces && /opt/local/bin/cmake -E cmake_autogen /home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build/kdevplatform/interfaces/CMakeFiles/KDevPlatformInterfaces_autogen.dir MacPorts Generating MOC predefs moc_predefs.h Generating MOC source include/moc_iplugin.cpp Generating MOC source EWIEGA46WW/moc_configpage.cpp Generating MOC source EWIEGA46WW/moc_iassistant.cpp Generating MOC source EWIEGA46WW/moc_icompletionsettings.cpp Generating MOC source EWIEGA46WW/moc_icore.cpp Generating MOC source EWIEGA46WW/moc_idebugcontroller.cpp Generating MOC source EWIEGA46WW/moc_idocumentation.cpp Generating MOC source EWIEGA46WW/moc_idocumentationcontroller.cpp Generating MOC source EWIEGA46WW/moc_idocumentcontroller.cpp Generating MOC source EWIEGA46WW/moc_ilanguagecontroller.cpp Generating MOC source EWIEGA46WW/moc_ipartcontroller.cpp Generating MOC source EWIEGA46WW/moc_iplugincontroller.cpp Generating MOC source EWIEGA46WW/moc_iproject.cpp Generating MOC source EWIEGA46WW/moc_iprojectcontroller.cpp Generating MOC source EWIEGA46WW/moc_iprojectprovider.cpp Generating MOC source EWIEGA46WW/moc_iruncontroller.cpp Generating MOC source EWIEGA46WW/moc_iruntime.cpp Generating MOC source EWIEGA46WW/moc_iruntimecontroller.cpp Generating MOC source EWIEGA46WW/moc_iselectioncontroller.cpp Generating MOC source EWIEGA46WW/moc_isession.cpp Generating MOC source EWIEGA46WW/moc_isourceformatter.cpp Generating MOC source EWIEGA46WW/moc_isourceformattercontroller.cpp Generating MOC source EWIEGA46WW/moc_itestcontroller.cpp Generating MOC source EWIEGA46WW/moc_launchconfigurationpage.cpp Generating MOC source EWIEGA46WW/moc_launchconfigurationtype.cpp make[2]: Leaving directory `/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/build' [ 0%] Built target KDevPlatformInterfaces_autogen make -f kdevplatform/interfaces/CMakeFiles/KDevPlatformInterfaces.dir/build.make kdevplatform/interfaces/CMakeFiles/KDevPlatformInterfaces.dir/depend make[2]: Entering directory `/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/b
[CMake] cmake not always replacing symlinks in the path used to access a build.dir?!
Hi, I'm seeing a weird issue with a large project: KDevelop. It was reorganised recently but I think that's what exposes the issue, rather than causing it. My workflow puts both source and out-of-source build directories rather deep in a dedicated "playground"; for convenience I create symlinks to the parent of both directories in one of my own work directories under my $HOME: %> ls -l kdevd-lnx-work lrwxrwxrwx 1 bertin bertin 92 Sep 5 15:18 kdevld-lnx-work -> /opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work As long as I chdir directly into that "hidden" build.dir, invoke cmake and then make from there things are fine. Problems occur though when I change something in one of the project's CMakeLists.txt files, chdir into the build.dir via the symlink and then issue a make without running cmake by hand. Consider the example below where I tried to do partial rebuild (something that's always worked reliably for me, a feature I really appreciate with cmake!). Evidently make is being executed in the actual directory, as shown by the output from `pwd` just underneath the `CD` line. Somewhere during the snipped part (which I don't have anymore) cmake was called automaticallyand that's where the symlink must have found its way into the Notice how the failing build of iplugin.cpp uses search paths that include the link that don't work with the relative include paths generated by the moc compiler. How can happen, for all I can tell cmake has no way of knowing about the symlink?! FWIW, it's not something I can reproduce easily. %> where CD CD is aliased to (cd !:^ ; !:2*) %> CD kdevld-lnx-work/build/plugins/ wmake ### now in /opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/build/plugins ### make -w ### Sun Sep 17 20:32:06 CEST 2017 make: Entering directory `/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/build/plugins' [ 0%] Building CXX object kdevplatform/interfaces/CMakeFiles/KDevPlatformInterfaces.dir/iplugin.cpp.o cd /home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build/kdevplatform/interfaces && /opt/local/bin/ccache /opt/local/bin/clang++-mp-4.0 -DKCOREADDONS_LIB -DKDevPlatformInterfaces_EXPORTS -DQT_CORE_LIB -DQT_DBUS_LIB -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x050500 -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_NO_SIGNALS_SLOTS_KEYWORDS -DQT_NO_URL_CAST_FROM_STRING -DQT_STRICT_ITERATORS -DQT_USE_QSTRINGBUILDER -DQT_WIDGETS_LIB -DQT_XML_LIB -DTRANSLATION_DOMAIN=\"kdevplatform\" -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I/home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build/kdevplatform/interfaces -I/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/kf5-kdevelop-5/kdevplatform/interfaces -I/home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build/kdevplatform/interfaces/KDevPlatformInterfaces_autogen/include -I/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/kf5-kdevelop-5 -I /home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build -I/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/kf5-kdevelop-5/kdevplatform -I/home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build/kdevplatform -isystem /opt/local/include/KF5/KParts -isystem /opt/local/include/KF5 -isystem /opt/local/include/KF5/KIOWidgets -isystem /opt/local/include/KF5/KIOCore -isystem /opt/local/include/KF5/KCoreAddons -isystem /opt/local/include/qt5 -isystem /opt/local/include/qt5/QtCore -isystem /opt/local/share/qt5/mkspecs/linux-g++-64 -isystem /opt/local/include/KF5/KService -isystem /opt/local/include/KF5/KConfigCore -isystem /opt/local/include/KF5/KJobWidgets -isystem /opt/local/include/qt5/QtWidgets -isystem /opt/local/include/qt5/QtGui -isystem /opt/local/include/qt5/QtNetwork -isystem /opt/local/include/KF5/KCompletion -isystem /opt/local/include/KF5/KWidgetsAddons -isystem /opt/local/include/KF5/KXmlGui -isystem /opt/local/include/qt5/QtDBu s -isystem /opt/local/include/qt5/QtXml -isystem /opt/local/include/KF5/KConfigWidgets -isystem /opt/local/include/KF5/KCodecs -isystem /opt/local/include/KF5/KConfigGui -isystem /opt/local/include/KF5/KAuth -isystem /opt/local/include/KF5/KTextWidgets -isystem /opt/local/include/KF5/SonnetUi -isystem /opt/local/include/KF5/KI18n -isystem /opt/local/include/KF5/KTextEditor -Ofast -g -DNDEBUG -std=c++11 -m64 -std=c++0x -fno-operator-names -fno-exceptions -DQT_NO_EXCEPTIONS -Wno-gnu-zero-variadic-macro-arguments -Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -Wvla -Wdate-time -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -Wno-missing-field-initializers -Werror=undefined-bool-conversion -Werror=tautological-undefined-c
Re: [CMake] setting/removing compiler flag (-g) for a single project directory
On Friday September 15 2017 16:51:24 Steven Velez wrote: >Yeah... I didn't mean to respond personally... i didn't realize my client >was doing that and not the list. OK, replying back to the list then. >What do you mean by "variables related to targets have global scope"? I probably could have been a bit less vague. Defining a target in a subdirectory sets something that behaves like a global variable (pardon, constant :)), at least for libraries. That's the whole point of that common_dir subtree: it defines library targets which are then used for linking the plugin. R. > >On Fri, Sep 15, 2017 at 3:44 PM, René J.V. Bertin >wrote: > >> On Friday September 15 2017 15:34:34 Steven Velez wrote: >> >> Logically that's what I'd expect, but then the variables related to >> targets have global scope, variables set in a module directories too etc. I >> preferred to ask, so thanks :) >> >> R. >> >> >All directories in cmake have their own scopes which are initialized by >> the >> >scope of the parent directory. >> > >> >So, if you set the variables you wish to set in CMakeLists.txt of >> >common_libs, they should not influence the builds in the plugin directory, >> >but will influence the builds in that directory and subdirectories. >> > >> >https://cmake.org/cmake/help/v3.9/manual/cmake-language.7. >> html#cmake-language-variables >> > >> >For more info. >> > >> >Steven -- 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] setting/removing compiler flag (-g) for a single project directory
Hi, Is it possible to set and/or remove compiler arguments on a project subdirectory that holds a tree with sources of a considerable number of build targets? An example to make this more concrete: I have a project that contains common_libs plugins/foo plugins/this_one I'm just interested in building plugins/this_one and can do so by calling make && make install/fast inside the build/plugins/this_one directory. All plugin dependencies are already installed (with debug info). The build/common_libs directory gets pretty big and is expensive to build, so ideally I would build everything in there with different flags, basically replacing -O3|-O2 with -Os and removing the -g option, possibly even running a strip before continuing the rest of the build. I know one can do this kind of thing per target or even per file, but how does one do it on a directory basis? Do I have to cache the original CMAKE_C*_FLAGS value before modifying it in common_libs/CMakeLists.txt , and restore it before returning from that file? Or is there a more elegant method? 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] /path/to/libpng.so automatic conversion to -lpng ?
Eric Noulard wrote: > From the command line I doubt it. Adding -DCMAKE_POLICY_DEFAULT_CMP0060=NEW on the commandline works. But whatever the reason, using PNG::PNG works too. Apparently policy 60 doesn't affect the IMPORTED_LOCATION target property... > Did you try to use ninja generator instead of make ? > The no-op build is really faster with ninja. I compared single full builds with ninja and make yesterday; with ninja it was actually (a bit) slower and required more resources (including a larger build directory). My main gripe with it is that you cannot simply launch a partial build from a subdirectory. R -- 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 ?
Eric Noulard wrote: > Thanks you for digging this. > I totally ignored that "feature". I guess most of us did, it's one of those things that usually works just fine but that when it breaks sends you on a nasty quest to figure out WTF is going on (IOW, makes you doubt yourself until you realise you just discovered a hidden feature). I found this only because I searched the CMake source tree for LIBRARY_PATH to see where it does the rewriting. I would never have guessed to find the feature biting me under the concept "implicit directories". > I you have a look at file: > https://github.com/Kitware/CMake/blob/master/Source/cmComputeLinkInformation.cxx > > you may discovered (as I just did) that not all CMake supported systems > kindly accept full path to library for linking... CMake being a system that allows to describe how to build a project in a platform-agnostic way it could easily have handled those systems individually. > I guess the author/contributor to this part of CMake may certainly explain > that better than me. Presumably, and I guess s/he might admit not having thought of (or tested) the kind of situation where rewriting breaks things. Something you said in a mail that apparently didn't go to the list: > OK, but I don't think CMake should "fight" the underlying compiler. No. Clang may have a reason for the different way of handling LIBRARY_PATH which means you'd have to leave a possibility for it to work that way - maybe even by default. But in this case we're not fighting the compiler, we're trying to let it work another way that is just as supported. > Looking the code is interesting because apparently what you need is to set > CMP0060 to NEW: > > $ cmake --help-policy CMP0060 > CMP0060 Ah, great. I would probably have found that by myself, eventually. > --- > > Link libraries by full path even in implicit directories. > > > The OLD behavior for this policy is to ask the linker to search for > libraries whose full paths are known to be in implicit link directories. > The NEW behavior for this policy is to link libraries by full path even > if they are in implicit link directories. > > This policy was introduced in CMake version 3.3. Unlike most policies, > CMake version 3.7.2 does *not* warn by default when this policy > is not set and simply uses OLD behavior. See documentation of the > ``CMAKE_POLICY_WARNING_CMP0060`` > variable to control the warning. > > > The thing I don't understand is that you use CMake 3.8.2 so you should get > the new behavior. Are you sure? I read from the description above that you have to set the policy explicitly. Do you know if one can set policies like this from the commandline rather than through patching each toplevel CMakeLists.txt file? Or can it be set for just a subdirectory? > However since digikam does a cmake_minimum_required(VERSION 3.0.0) which may > set the CMP0060 to old. Quite possible, I've run into naggles with that with another policy on Mac (25). It's annoying that this happens with digikam which is a really cumbersome project (it takes ages just to run make just to confirm that everything has been built). R. -- 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 ?
Andreas Naumann wrote: > cmake instrospects your compiler and asks for system directories. Just stumbled across this documentation tidbit: >>> CMAKE__IMPLICIT_LINK_DIRECTORIES -- Implicit linker search path detected for language . Compilers typically pass directories containing language runtime libraries and default library search paths when they invoke a linker. These paths are implicit linker search directories for the compiler's language. CMake automatically detects these directories for each language and reports the results in this variable. When a library in one of these directories is given by full path to :command:`target_link_libraries` CMake will generate the ``-l`` form on link lines to ensure the linker searches its implicit directories for the library. Note that some toolchains read implicit directories from an environment variable such as ``LIBRARY_PATH`` so keep its value consistent when operating in a given build tree. <<< Note the > CMake will generate the ``-l`` form on link lines to ensure the linker > searches its implicit directories What's the point in doing that when a full path is given? Full path means searching isn't required. Full path (probably) means that the operator wants to ensure that a specific library is linked. Full path thus means that searching can even have counterproductive effects. R. -- 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 ?
Eric Noulard wrote: > AFAIK the explanation you gave. CMake does not seem to play with -l or -L > options. As Rolf said above, apparently it does. > the FindPNG.cmake shipped with CMake does not do that either. Indeed, it sets PNG_LIBRARY to the path of libpng, and PNG_LIBRARIES to the 2 required libraries (libpng and libz), both with full path. There would be no problem if that data ended up in the linker command. > Which version of CMake are you using? 3.8.2 > Which version of digikam are you trying to compile? 5.6.0 > Did you try to > > message(STATUS "show me PNG_LIBRARIES=${PNG_LIBRARIES}") Yes, the variable contains the correct 2 paths. > Now I'm lost. If the culprit is a clang feature/bugs then why did you > suspect CMake in the frst place? Because at the end of the day that doesn't matter : CMake must generate Makefiles that work, and thus has to work around known issues or peculiarities in the compilers it support. That could be through hardwired exceptions, but in this case could also be by providing a way to disable rewriting those library specifications. Maybe there is, I haven't yet found any documentation whatsoever about the conditions under which CMake will (supposedly) replace a /path/to/libfoo.so libspec with -lfoo . > Does the command line produced by the CMake generator you use (?makefile > ?ninja ?) contains > the full path to lib or -L + -l flags? No. It contains -lpng -lz but no -L flag. See the more specific discussion in cmake-devel ("FindPNG.cmake doesn't return a LIBRARY_DIR variable"). R. -- 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 ?
Rolf Eike Beer wrote: >> It seems that clang handles that variable in a somewhat different manner >> than GCC does. Even in a very simple call on the commandline (including the >> -v option) I see it adds -L/opt/local/lib AFTER the user-supplied >> libraries, where GCC puts it before the 1st -l option. > > Welcome to the work of link_directories(). This is exactly the reason to avoid > it: it always causes trouble. digikam (that's the project we're talking about) doesn't use neither that nor target_link_directories. And if CMake simply used the libraries as found and specified in the target_link_libraries() call I wouldn't have run into problems either. I did raise a flag on the clang ML though. But whether it's a clang bug or feature the fact remains that ideally one should be able to tell cmake exactly what to do, without it trying to outguess the operator. R. -- 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 ?
FWIW, I do question this rewriting feature, because it clearly can go wrong. I'd argue that programmers (or build script/cmake modules/...) usually have good reason when they give the absolute path to a library: making darn sure it's indeed that one that gets linked. While I agree that replacing a full path with the -lfoo notation makes the final command shorter and thus more readable it can also introduce subtle bugs. The fact that a library can be found by the linker because it's on the search path doesn't mean that the linker will find the right, intended library. In my case I could get the correct linking by just adding -L/opt/local/lib, but what if for some reason I had wanted to include the system libpng, i.e. if PNG_LIBRARIES had pointed to /usr/lib/libpng.so? I hope this is not such a corner case that Kitware haven't foreseen it and implemented a way to deactivate the rewriting? R. -- 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 ?
Andreas Naumann wrote: > 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. Hello Andreas, Aha, I indeed have LIBRARY_PATH=/opt/local/lib set (by the build scripts I use). >From what I understand, that variable allows you to specify a set of -L directories via an env. variable (other than LDFLAGS). It seems that clang handles that variable in a somewhat different manner than GCC does. Even in a very simple call on the commandline (including the -v option) I see it adds -L/opt/local/lib AFTER the user-supplied libraries, where GCC puts it before the 1st -l option. R. -- 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] /path/to/libpng.so automatic conversion to -lpng ?
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] How to detect MSVC 2015 update 3 (= presence of /fpermissive-)
Volker Enderlein wrote: Hi, Thanks, that helps. With there is maybe something to learn from the CMake sources, too. R. > Hello, > > according to https://sourceforge.net/p/predef/wiki/Compilers/ you could > check with > > check_cxx_source_compiles(" > #if defined (_MSC_VER) && (_MSC_VER == 1900) && (_MSC_FULL_VER == > 190024210) > #else >#error compiler is not MSVC Update3 > #endif > int main() { > return 0; > } > " MSVC_UPDATE3_FOUND) > > for the requested feature. > > HTH, Cheers, Volker > > > Am 15/05/2017 um 14:56 schrieb René J.V. Bertin: >> Hello, >> >> A question that will hopefully have a quick/easy answer: >> >> I'd like to detect when the MSVC /fpermissive- (yes, that's a dash at the >> end) can be used instead of /Za . I know that a later update bumped the >> version to 14.0.25422.01 and thus undoubtedly _MSC_FULL_VER== 1402542201 in C >> code so I could assume everyone keeps installs their updates and use that >> value. >> >> But what does this translate to in CMake code (MSVC_VERSION)? Probably not >> just 1903 I presume? >> >> 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] How to detect MSVC 2015 update 3 (= presence of /fpermissive-)
René J.V. Bertin wrote: Bump. No one who can help here? -- 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] How to detect MSVC 2015 update 3 (= presence of /fpermissive-)
On Monday May 15 2017 15:58:53 Konstantin Tokarev wrote: Hello, >Have you tried CHECK_CXX_COMPILER_FLAG? I forgot to mention: I don't have a MS dev set-up at the moment. This is for a cross-platform purposes (in KDE's extra-cmake-modules). Thanks, R -- 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 detect MSVC 2015 update 3 (= presence of /fpermissive-)
Hello, A question that will hopefully have a quick/easy answer: I'd like to detect when the MSVC /fpermissive- (yes, that's a dash at the end) can be used instead of /Za . I know that a later update bumped the version to 14.0.25422.01 and thus undoubtedly _MSC_FULL_VER== 1402542201 in C code so I could assume everyone keeps installs their updates and use that value. But what does this translate to in CMake code (MSVC_VERSION)? Probably not just 1903 I presume? 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
[CMake] check_include_file for Objective C(++) triggers what looks like a clang bug (but probably isn't)
Hi, I've been trying to use the check_include_file() macro to verify if a particular ObjC header can be compiled. This turns out to be almost impossible, but I cannot put my finger on whether there isn't a compiler error involved too. Let's take the easier case for Mac OS X, where you don't have to install GNUstep. The following statement could be expected to work: check_include_file(Foundation/Foundation.h HAVE_FOUNDATION "-v -x objective-c") but it fails. The -x argument is required, the -v option is purely for debugging. The error from CMakeError.log is copied below; it seems that the intermediate object file is corrupt. However, the same symptoms occur with a comparable test file built the same way with clang: %> clang -x objective-c -c test.c %> clang -x objective-c test.o However, %> clang test.o and %> clang -x objective-c test.c work fine, and it's clear from the trace output that the -x option should NOT be passed to clang when it's used as a linker driver. Questions: - is there a more appropriate way to check if an Objective C header can be compiled? - is there a way to configure or set up things such that the trycompile functions use a single compiler invocation, or test only the object file generation (which should be enough for testing a headerfile)? Thank, René CMakeError.log extract: Building C object CMakeFiles/cmTC_61f5f.dir/CheckIncludeFile.c.o /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -O3 -march=native -g -v -x objective-c -isystem /usr/include/GNUstep-o CMakeFiles/cmTC_61f5f.dir/CheckIncludeFile.c.o -c ...//src/MSWin/ SynchroTr/CMake/Release/CMakeFiles/CMakeTmp/CheckIncludeFile.c Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn) Target: x86_64-apple-darwin13.4.0 Thread model: posix "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" -cc1 -triple x86_64-apple-macosx10.9 .0 -emit-obj -disable-free -disable-llvm-verifier -main-file-name CheckIncludeFile.c -mrelocation-model pic -pic-level 2 -mdisable-f p-elim -masm-verbose -munwind-tables -target-cpu corei7-avx -target-linker-version 241.9 -v -gdwarf-2 -coverage-file ...//src/MSWin/SynchroTr/CMake/Release/CMakeFiles/CMakeTmp/CMakeFiles/cmTC_61f5f.dir/CheckIncludeFile.c.o -resource-di r /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.0 -isystem /usr/include/GNUs tep -I/opt/local/include -O3 -fdebug-compilation-dir ...//src/MSWin/SynchroTr/CMake/Release/CMakeFiles/ CMakeTmp -ferror-limit 19 -fmessage-length 0 -stack-protector 1 -mstackrealign -fblocks -fobjc-runtime=macosx-10.9.0 -fencode-extend ed-block-signature -fobjc-exceptions -fexceptions -fdiagnostics-show-option -vectorize-loops -vectorize-slp -o CMakeFiles/cmTC_61f5f .dir/CheckIncludeFile.c.o -x objective-c ...//src/MSWin/SynchroTr/CMake/Release/CMakeFiles/CMakeTmp/Che ckIncludeFile.c clang -cc1 version 6.0 based upon LLVM 3.5svn default target x86_64-apple-darwin13.4.0 ignoring nonexistent directory "/usr/include/GNUstep" #include "..." search starts here: #include <...> search starts here: /opt/local/include /usr/local/include /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.0/include /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include /usr/include /System/Library/Frameworks (framework directory) /Library/Frameworks (framework directory) End of search list. Linking C executable cmTC_61f5f /opt/local/bin/cmake -E cmake_link_script CMakeFiles/cmTC_61f5f.dir/link.txt --verbose=1 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -O3 -march=native -g -v -x objective-c -isystem /usr/include/GNUstep -Wl,-search_paths_first -Wl,-headerpad_max_install_names CMakeFiles/cmTC_61f5f.dir/CheckIncludeFile.c.o -o cmTC_61f5f Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn) Target: x86_64-apple-darwin13.4.0 Thread model: posix "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" -cc1 -triple x86_64-apple-macosx10.9.0 -emit-obj -disable-free -disable-llvm-verifier -main-file-name CheckIncludeFile.c.o -mrelocation-model pic -pic-level 2 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu corei7-avx -target-linker-version 241.9 -v -gdwarf-2 -resource-dir /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.0 -isystem /usr/include/GNUstep -I/opt/local/include -O3 -fdebug-compilation-dir ...//src/MSWin/SynchroTr/CMake/Release/CMakeFiles/CMakeTmp -ferror-limit 19 -fmessage-length 0 -stack-protector 1 -mstackrealign -fblocks -fobjc-runtime=macosx-10.9.0 -fencode-extended-block-signature -fobjc-exceptions -fexceptions -fdiagnostics-show-option -vectorize-loops -vectorize-slp -o /var/folders/j1/1439ppj08xj8h6006s6drbq0gs/T/Che
[CMake] OS X Info.plist with POSIX executables and libraries (no app/framework bundles)
Hi, I'd like to do something like set_target_properties(foo PROPERTIES MACOSX_BUNDLE_INFO_PLIST ${CMAKE_CURRENT_SOURCE_DIR}/MacOSXBundleInfo.plist.in) set_target_properties(foo PROPERTIES MACOSX_BUNDLE_GUI_IDENTIFIER "org.bar.foo") # etc for an application that will not be an app bundle but a regular POSIX executable. The resulting Info.plist can easily be included in the executable by target_link_libraries(foo "-sectcreate __TEXT __info_plist ${CMAKE_CURRENT_BINARY_DIR}/Info.plist") but the template Info.plist isn't processed at all. What's the best way to replace the above standard sequence of Info.plist set-up commands to obtain a preprocessed Info.plist that has the correct values substituted for the variables in the template? 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] supporting cumulative variable operations via the commandline?
Hi, So how hard would it be to support syntax like -DFOO+=bar or even -DFOO-=bar on cmake's command line? Where would I have to start poking around if I wanted to make a draft/PoC implementation? 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] why no cumulative variable operations via the commandline?
Nicholas Braden wrote: > Ah, I understand now - I have a habit of forgetting that you can > configure existing CMake builds by repeatedly invoking cmake. I don't > know if such a feature exists but it definitely sounds useful. Yes, that would be another use case! R. -- 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] why no cumulative variable operations via the commandline?
Nicholas Braden wrote: > sense. Could you give an example of when you would find them useful? I > think maybe I am not understanding what you want. Yeah, I realise my explanation may not have been very clear. > If you just want to pass a list of values to a variable on the command > line, separate the values with semicolons: > cmake "-DMY_LIST=example value 1;example value 2" Now take an example where you are in fact assembling the commandline in subsequent steps. A good example would be a build system like MacPorts that uses a kind of header files (so-called PortGroups) that can be included by the build scripts for packages of dependent software (say, the Kate5 editor). There's a PortGroup for cmake itself, and there's a PortGroup for Qt5 and one for the KF5 frameworks. Each of those PortGroups can provide an element for MY_LIST (think of the module path, or preprocessor tokens), but evidently they cannot make assumptions about the contents of the variable. In other words, it would make sense for certain types of programmatically generated commandlines to do things like cmake -DMY_LIST+=val1 -DMY_LIST+=val3 -DMY_LIST+=val2 At the moment we can do this reliably by using our own registers, one for each CMake variable that might be used this way, splicing them into the commandline just before invoking cmake. Not impossible, but somewhat of a hassle and a pity for a feature that seems useful and probablye rather trivial to implement. CMake commandline can get quite long, so this might even make sense as a convenience for composing one manually. Of course it would be convenient to have a concatenation operator in the cmake language too ;) R -- 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] why no cumulative variable operations via the commandline?
Hi, I've been wondering about something that is a real stumbling block in a build/distribution system like MacPorts where settings can be modified in any number of consecutive steps. For instance, depending on what dependencies a package ("port") requires and how those dependencies are installed, elements may be added to the module search path repeatedly. In cmake language one does cumulative operations like that explicitly, but I'm not aware of any way to do that on the command line. Is there a reason why one cannot do something like cmake -DCMAKE_FOO+=bar or CMAKE -ACMAKE_FOO=bar (-A for add instead of define) (or -DCMAKE_FOO-=bar, for that matter...) ? 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
[CMake] [OS X] example CMake file to create a Preference Pane?
Hi, I'd like to experiment writing a Preference Pane for Qt-based apps. I'd prefer to use CMake instead of Xcode and wonder if someone can point me to an example CMake file that generates a proper .prefPane bundle? I'm not having much luck googling for one for now. 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] Make CMAKE_EXPORT_COMPILE_COMMANDS not default?
Hello, Sorry for reviving an old thread (https://cmake.org/pipermail/cmake/2013-December/056517.html) but it seems to have died without a proper answer, at least one that I could find. I'd like to offer an additional reason why CMAKE_EXPORT_COMPILE_COMMANDS would be beneficial if on by default, one that apparently didn't come up. IDEs like KDevelop and QtCreator use this option to know the layout/contents of a project. They will add it to the cmake invocation when you create a new build directory for said project. However, they can also be pointed to an already existing build directory, in which case it'd be preferable if they didn't have to run cmake again (neither IDE has the option to run cmake under the kind of strictly controlled environment that might be required to configure it "just right"). Regards, 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] CMAKE_BUILD_TYPE and exact control of compiler options
Dan Liew wrote: > Hi, > > >> - If not, what is the best/official way to get exact control over the >> compiler and linker options used? > > I had to do something similar recently where I didn't want > ``-DNDEBUG`` to be in any of the configurations. > > I used ``CMAKE_USER_MAKE_RULES_OVERRIDE `` to set the path to file > containing overrides, this must be set before calling ``project()`` > I'm not sure if this is really the correct route to go down though for > your use case. That wouldn't be impossible. A more generic way to achieve what you did, one that doesn't require patching "client" CMake files (which I find unacceptable): Store the customised settings in a file (I'd call it cmake.initcache) and call cmake as %> cmake -C./cmake.initcache "$@" This is an approach I follow with a more basic building workflow of my own, one where I keep localised/customised settings (CC/CXX, CFLAGS/CXXFLAGS, LDFLAGS etc) in a ./wconfigure.env file, which is parsed by wrappers to configure and cmake. It's not a usual approach for MacPorts, though. R. -- 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
Andreas Pakulat wrote: > No this is not possible in general. A CMakeLists.txt file can always just > set their own compiler/linker flags. Which would require patching each and every one of them, which isn't exactly desirable. >> - 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. I know it doesn't exist as a preset in CMake. But take a look at the CMake files shipped with KDE4's kdelibs: those actually introduce CMAKE_C*_FLAGS_DEBIAN variables (in addition to using specific install locations, for instance). It's quite important that there is such a feature: configure and its alternatives are supposed to take CFLAGS, CXXFLAGS and family into consideration (or at least should have a mode in which they do, IMVHO). I suppose that what happens is that requesting an unknown CMAKE_BUILD_TYPE is equivalent to not requesting one at all, and also prevents downstream CMake files to pick a default preset if CMAKE_BUILD_TYPE hasn't been defined by the caller. I've had a better look at the control file I mentioned, and found the reason why $CFLAGS and $CXXFLAGS weren't being used. It turns out that if you set CMAKE_CXX_FLAGS on the commandline, it is no longer set to include $CXXFLAGS from the environment. Comments in the control file suggest that that wasn't always the case. R. -- 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
René J. V. Bertin wrote: Similarly, is there a way to set preprocessor variables (cf. https://cmake.org/Bug/view.php?id=12928 which has been silent for a long time)? One could do -DINCLUDE_DIRECTORIES=${CPPFLAGS}, but that may lead to unexpected results if CPPFLAGS contains something other than -I options. R. -- 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] CMAKE_BUILD_TYPE and exact control of compiler options
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? - Out of curiosity, what's special about the CMAKE_BUILD_TYPE=Debian build type? Thanks René Bertin -- 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] --prefix commandline option?
Hello, I discovered by accident that cmake (3.2.2) apparently respects the --prefix command line option, with a result that's somewhat different from setting CMAKE_INSTALL_PREFIX. I cannot seem to find any documentation on this feature though: have I overlooked it, or is this indeed an undocumented feature that shouldn't be used? If that latter option, is there a -DCMAKE_??? equivalent that has the same effects? 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
[CMake] --sphinx-qthelp leads to build error with CMake 3.2.3
Hi, I'm trying to build the latest CMake release, with the Qt4 gui and including the docs in Qt help format. I'm using the same "recipe" as for the 3.2.2 release, but now I see this: >> [ 95%] sphinx-build qthelp: see Utilities/Sphinx/build-qthelp.log cd /build//cmake-3.2.3/Utilities/Sphinx && /opt/local/bin/sphinx-build-3.4 -c /build//cmake-3.2.3/Utilities/Sphinx -d /build//cmake-3.2.3/Utilities/Sphinx/doctrees -b qthelp /build//cmake-3.2.3/Help /build//cmake-3.2.3/Utilities/Sphinx/qthelp > build-qthelp.log WARNING: 'default' html theme has been renamed to 'classic'. Please change your html_theme setting either to the new 'alabaster' default theme, or to 'classic' to keep using the old default. cd /build//cmake-3.2.3/Utilities/Sphinx && ../../Bootstrap.cmk/cmake -DCSS_DIR=/build//cmake-3.2.3/Utilities/Sphinx/qthelp/_static -P /build//cmake-3.2.3/Utilities/Sphinx/apply_qthelp_css_workaround.cmake CMake Error at apply_qthelp_css_workaround.cmake:4 (file): file failed to open for reading (No such file or directory): /build//cmake-3.2.3/Utilities/Sphinx/qthelp/_static/default.css Utilities/Sphinx/CMakeFiles/documentation.dir/build.make:63: recipe for target 'Utilities/Sphinx/doc_format_qthelp' failed make[2]: *** [Utilities/Sphinx/doc_format_qthelp] Error 1 ><<< I cannot vouch that the WARNING wasn't already there last time, but the fact that a file called default.css is missing while there is a classic.css might be significant. I've google the error a bit, but so far haven't found anything relevant AND recent. 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] determining which system headerfile provides a given function
On Monday June 15 2015 23:05:07 Alexander Neundorf wrote: > if you have multiple candidate headers, try them all, and use separate result > variables for every one. > Is that the problem you have ? Yes. That's probably the thing I missed and why it didn't work; I used a single variable. Still, it seems surprising there's no predefined macro that would help make things easier in this kind of scenario that cannot be that uncommon (at least it used to be quite common, like for instance with string.h vs. strings.h). A macro that takes a list of candidates and returns the name of the appropriate file would seem useful, no? R. -- 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] determining which system headerfile provides a given function
On Saturday June 13 2015 22:26:12 Alexander Neundorf wrote: > did you try check_symbol_exists() and the other similar functions ? Yes, but none that I could find give any information beyond whether the symbol exists. It may be possible (or necessary) to repeat such tests trying each of the possible candidate header files in succession until a hit is found, but as I said in my initial email, that doesn't work. That's about all there's to say about it: I presume this approach doesn't work because of caching intended to avoid testing the same thing twice. 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
[CMake] wrapping a macro
Hello, Is it possible to wrap an existing macro that returns a result via one of its arguments? I think it will be clear what I would like to do from the following example: if(${INTRINSICS_TEST_TYPE} MATCHES "compiles") macro(check_intrinsics_availability source var) check_c_source_compiles(source var) endmacro() elseif(${INTRINSICS_TEST_TYPE} MATCHES "runs") include(CheckCSourceRuns) macro(check_intrinsics_availability source var) check_c_source_runs(source var) endmacro() elseif(${INTRINSICS_TEST_TYPE} MATCHES "none") macro(check_intrinsics_availability source var) set(${var} 1) set(${var}_EXITCODE 0) endmacro() else() macro(check_intrinsics_availability source var) set(${var} 0) set(${var}_EXITCODE 1) endmacro() endif() This does not have the intended effect: when INTRINSICS_TEST_TYPE == "compiles", cmake prints "Performing test var - Failed". Evidently I'd like it to perform test ${var}, in other words, the check_intrinsics_availability macro should behave exactly as either check_c_source_compiles or check_c_source_runs. Additionally, the "none" and fallback cases are supposed to behave if check_c_source_?? succeeded or failed, respectively. Are they implemented correctly? Thanks, R. -- 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] determining which system headerfile provides a given function
Ok, let me rephrase the question to see what other kind of constructive answers that'll lead to: how does one check which header file provides the prototype for a function from the system libraries? Function in question: reallocf; can apparently be in either stdlib.h or bsd/stdlib.h . -- 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] determining which system headerfile provides a given function
Hello, I need to determine the availability of a certain function (reallocf) and which headerfile provides its prototype. If there is a function that handles this case I must have overlooked it (including on google), so I tried repeating a check_symbol_exist() call repeatedly with the various known header file paths. But that also doesn't work, either because of caching or because I'm doing something else wrong. So, how does one handle this kind of situation? 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] linking a C application with a C++ library
On Wednesday June 03 2015 02:44:29 René J.V. Bertin wrote: > How do I instruct cmake to do this? never mind: set_target_properties(cseTest PROPERTIES LINKER_LANGUAGE CXX) Sorry for the noise! R. -- 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] linking a C application with a C++ library
Hello, I'm trying to write a cmake file for an older project of mine, which consists of a library (mostly C++) and a few test cases one of which is a C programme to test the library's functionality exported to C. I'd like to use a single cmake file, but am getting link error on the C app, most likely because it should be linked by the C++ linker (or at least with -X c++). How do I instruct cmake to do this? Thanks, R. -- 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] repetitive path gives filename too long errors
Hello, I'm struggling with the py-pykde4 package, which is giving me filename overflows due to constructing a path that contains repetitions of itself. I first ran into this in November, have since updated to CMake 3.1.2, and now see that the issue hasn't been solved: https://mail.kde.org/pipermail/kde-mac/2014-November/002404.html and that I'm not the only one: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750231 I saw a hint that using Ninja might avoid the issue, and indeed the cmake step works fine with that generator. However: %> (cd py27-pykde4-mp9-work/build/ ; ninja) /Volumes/Debian/MP9/var/macports/build/_Volumes_Debian_MP9_site-ports_python_py-pykde4/py27-pykde4/work/build ninja: error: stat(_Volumes_Debian_MP9_var_macports_build__Volumes_Debian_MP9_site-ports_python_py-pykde4_py27-pykde4_work_build__Volumes_Debian_MP9_var_macports_build__Volumes_Debian_MP9_site-ports_python_py-pykde4_py27-pykde4_work_build__Volumes_Debian_MP9_var_macports_build__Volumes_Debian_MP9_site-ports_python_py-pykde4_py27-pykde4_work_build_pykdeconfig.pyc): File name too long ninja: error: stat(CMakeFiles/_Volumes_Debian_MP9_var_macports_build__Volumes_Debian_MP9_site-ports_python_py-pykde4_py27-pykde4_work_build__Volumes_Debian_MP9_var_macports_build__Volumes_Debian_MP9_site-ports_python_py-pykde4_py27-pykde4_work_build__Volumes_Debian_MP9_var_macports_build__Volumes_Debian_MP9_site-ports_python_py-pykde4_py27-pykde4_work_build_pykdeconfig.pyc.util): File name too long ninja: error: stat(CMakeFiles/_Volumes_Debian_MP9_var_macports_build__Volumes_Debian_MP9_site-ports_python_py-pykde4_py27-pykde4_work_build__Volumes_Debian_MP9_var_macports_build__Volumes_Debian_MP9_site-ports_python_py-pykde4_py27-pykde4_work_build__Volumes_Debian_MP9_var_macports_build__Volumes_Debian_MP9_site-ports_python_py-pykde4_py27-pykde4_work_build_pykdeconfig.pyc.util): File name too long ninja: error: stat(CMakeFiles/_Volumes_Debian_MP9_var_macports_build__Volumes_Debian_MP9_site-ports_python_py-pykde4_py27-pykde4_work_build__Volumes_Debian_MP9_var_macports_build__Volumes_Debian_MP9_site-ports_python_py-pykde4_py27-pykde4_work_build__Volumes_Debian_MP9_var_macports_build__Volumes_Debian_MP9_site-ports_python_py-pykde4_py27-pykde4_work_build_pykdeconfig.pyc.util): File name too long (etc) Is this because of an error in pykde4's CMake files, or is this an unavoidable side-effect of the way CMake works? NB: I tried setting pykde4_SOURCE_DIR and pykde4_BINARY_DIR on the commandline, but that had no effect (other than that the values appeared in CMakeCache.txt). 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] control python exec. search from command line?
On Friday February 27 2015 10:44:11 Omar Valerio wrote: Hello Omar, >Well yes I suggest you to use a FIND_LIBRARY directive inside your >CMakeList.txt project file and HINT the compiler which location to prefer >for the library to get linked. ( >http://www.cmake.org/cmake/help/v3.0/command/find_library.html) Except that there's no need for a library, but for the python interpreter. The project in question is kdev-python (1.6.1) . >Would be helpful to know which version of CMake are you running, because in >previous versions of CMake there was a bug preventing CMake to found the >correct Python libraries. You can read more about here: 3.1.2 >Other than that there is and specific FindPython3Libs cmake module that you >may want to try. Here is the location where you can find it: > >https://qt.gitorious.org/pyside/shiboken/source/fdf8e4b70e2a82cda581ceae06a1c98fb20114f0:cmake/Modules/FindPython3Libs.cmake Thanks, I'll have a look ... but I'd just as much NOT introduce another dependency ... I'll ask around on the kdevelop ML too. R -- 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] control python exec. search from command line?
Hello, I'm trying to build a project that uses FindPythonInterp.cmake to locate the python executable. Thing is that the system I'm working on has "python" pointing to a 2.7 install, while the project requires Python 3.x. Is there a way to influence the search from the command line? I tried -DPYTHON_EXECUTABLE:PATH="/path/to/python3" but that didn't cut it. Am I going to have to patch the CMake file that invokes the FindPythonInterp routine instead? Thanks, R. -- 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 find Python 2.7 libraries if 3.x is installed too
Hello, I am trying to get a not-so-old project to build (gizmod.sourceforge.net) which requires Python2.7 and libboost-python. I cannot seem to figure out how to do a find_package(PythonLibs REQUIRED) that will not consider that Python 3.4 is a suitable newer version of Python 2.7 . Is that even possible? The documentation in FindPythonLibs.cmake suggests that one can limit the search to specific versions, but that doesn't work. And using find_package(PythonLibs 2.7.5 EXACT REQUIRED) raises an error because it too finds v3.4 ... Thanks, R.B. -- 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 define global compiler flags that are inserted before user-defined flags?
I was referred here from http://public.kitware.com/Bug/view.php?id=15127 ... so here goes: KDE defines a number of compiler options that are (supposedly) required but that include optimisation options. These settings are defined in system-wide .cmake files like FindKDE4Internal.cmake and get applied *after* user-specified settings have been applied. They even seem to override tweaks made directly in CMakeCache.txt (to CMAKE_CXX_FLAGS_RELEASE or _RELWITHDEBINFO). Even if user-specified compiler flags do make it to the list in the generated *.make files, the KDE/system-defined options are *appended* to the list, causing -O2 to override -O3 or -g -g3. Is it possible to specify the KDE/system options in such a way that they appear at the start of the options list in the *.make files? With user-defined I mean specified on the commandline, through the environment, or (even) by editing CMakeCache.txt . I raised an issue about this on bugs.kde.org, but it could be constructive to be able to propose a solution/alternative (and I guess the real experts are here, not on kde.org ;) ). Regards, René Bertin -- 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