[cmake-developers] Suggestion: include deployment target and sysroot path in feature_summary on Mac
Hi,
A thought:
I know CMAKE_OSX_DEPLOYMENT_TARGET and CMAKE_OSX_SYSROOT are intended mainly to
be used by users building a project as opposed to by the build system itself,
but it could still be informative to include these settings in the "verbose"
feature_summary() print-out.
I.e. something like
if(CMAKE_OSX_DEPLOYMENT_TARGET)
message(STATUS "OS X Deployment target: ${CMAKE_OSX_DEPLOYMENT_TARGET}")
endif()
if(CMAKE_OSX_SYSROOT)
message(STATUS "OS X SDK sysroot: ${CMAKE_OSX_SYSROOT}")
endif()
Regards,
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-developers
Re: [cmake-developers] FindPNG.cmake doesn't return a LIBRARY_DIR variable
Rolf Eike Beer wrote:
> First, FindPNG.cmake doesn't care about pkg-config files, if that is bug
Yes, I noticed that after I wrote the remark about the pkg-config files, and
didn't think to remove it (= I diagnosed the issue while writing the message).
> or feature depends on your personal things. CMake will detect the
> library using the full path (as it has done), and construct proper -L
> and -l from that. It doesn't happen here, which makes me suspect that
> you don't even link to ${PNG_LIBRARIES} or PNG::PNG (the latter being
>From the CMake file (digikam-5.6.0/core/app/CMakeLists.txt):
target_link_libraries(digikamcore
PUBLIC
Qt5::Core
Qt5::Gui
Qt5::Xml
Qt5::Widgets
Qt5::Sql
Qt5::WebKitWidgets
Qt5::PrintSupport
Qt5::Concurrent
KF5::Solid
KF5::WindowSystem
KF5::ConfigGui
KF5::CoreAddons
KF5::Service
KF5::XmlGui
KF5::I18n
# Required by CImg which use pthread internally.
${CMAKE_THREAD_LIBS_INIT}
${LCMS2_LIBRARIES} # filters
${TIFF_LIBRARIES}
${PNG_LIBRARIES}
${EXIV2_LIBRARIES}
libdng
libraw
)
> the better version). It seems to me like the -lpng you see comes from
> QtWebkitWidgets, which would also need to be linked against your library
It does and is, but I don't find a reference to libpng in its cmake modules
(nor
in any other of Qt5's modules, for that matter).
So while your hypothesis seems reasonable I don't see where the -lpng would be
added by Qt's modules. (FWIW, QtWebKit also has a .pc file, but it doesn't add -
lz after -lpng so unless someone reorders the link library order that file
cannot
be the source of the issue either.)
I've asked a more generic question about fully-qualified path conversion to
-lfoo
on the general ML ("/path/to/libpng.so automatic conversion to -lpng").
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-developers
[cmake-developers] FindPNG.cmake doesn't return a LIBRARY_DIR variable
Hi,
I routinely use cmake to build projects for installation into a prefix
(/opt/local) and that use libraries from that location which also exist in the
system locations (typically in older versions, in that case).
I thus have .pc files under /opt/local which generate linker instructions of
the type "-L/opt/local/lib -lfoo".
You'd expect this should work, but (too) often I still get linker errors about
symbols not being found which upon verification are in fact provided by the
intended library. In that case the -L/opt/local/lib is typically given only
once on the linker command line ("way" before the corresponding -l argument),
or not at all. See the example below, where I don't see the -L option at all
(linker output and data from CMakeCache.txt after the HUGE linker command).
Initially I thought this was a case where one shouldn't filter out identical -L
options because the linker could limit their scope to just the -l option
immediately following the -L, but in this case it appears that FindPNG.cmake
simply doesn't consider the possibility that libpng might be found in a
location that isn't in the standard library search path. IOW, FindPNG.cmake
doesn't return a PNG_LIBRARY_DIR variable, and provides the full path only in
an obsolete variable (PNG_LIBRARY). And for some reason, the command
`target_link_libraries(digikamcore ... ${PNG_LIBRARIES} ...)` is translated
into `-lpng -lz` .
Is that a bug or feature?
cd /path/todigikam/work/build/core/app && /opt/local/bin/cmake -E
cmake_link_script CMakeFiles/digikamcore.dir/link.txt --verbose=1
/opt/local/bin/clang++-mp-4.0 -fPIC -O3 -g -DNDEBUG -std=c++11 -m64 -std=c++0x
-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
-std=c++0x -fno-operator-names -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 -std=c++0x -fno-operator-names
-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
-fexceptions -UQT_NO_EXCEPTIONS -Wl,--no-undefined -Wl,--fatal-warnings
-Wl,--enable-new-dtags -Wl,--no-undefined -Wl,--fatal-warnings
-Wl,--enable-new-dtags -Wl,--no-undefined -Wl,--fatal-warning
s -Wl,--enable-new-dtags -Wl,-R,/opt/local/lib -shared
-Wl,-soname,libdigikamcore.so.5.6.0 -o libdigikamcore.so.5.6.0
CMakeFiles/digikamcore.dir/utils/digikam_debug.cpp.o
CMakeFiles/digikamcore.dir/digikamcore_autogen/moc_compilation.cpp.o
../libs/database/CMakeFiles/digikamdatabasecore_src.dir/server/databaseserverstarter.cpp.o
../libs/database/CMakeFiles/digikamdatabasecore_src.dir/server/databaseservererror.cpp.o
../libs/database/CMakeFiles/digikamdatabasecore_src.dir/server/databaseserver.cpp.o
../libs/database/CMakeFiles/digikamdatabasecore_src.dir/engine/dbengineconfigloader.cpp.o
../libs/database/CMakeFiles/digikamdatabasecore_src.dir/engine/dbengineconfig.cpp.o
../libs/database/CMakeFiles/digikamdatabasecore_src.dir/engine/dbengineactiontype.cpp.o
../libs/database/CMakeFiles/digikamdatabasecore_src.dir/engine/dbengineerrorhandler.cpp.o
../libs/database/CMakeFiles/digikamdatabasecore_src.dir/engine/dbengineguierrorhandler.cpp.o
../libs/database/CMakeFiles/digikamdatabasecore_
src.dir/engine/dbengineparameters.cpp.o
../libs/database/CMakeFiles/digikamdatabasecore_src.dir/engine/dbenginebackend.cpp.o
../libs/database/CMakeFiles/digikamdatabasecore_src.dir/engine/dbenginesqlquery.cpp.o
../libs/database/CMakeFiles/digikamdatabasecore_src.dir/engine/dbengineaccess.cpp.o
../libs/database/CMakeFiles/digikamdatabasecore_src.dir/tags/tagregion.cpp.o
../libs/database/CMakeFiles/digikamdatabasecore_src.dir/thumbsdb/thumbsdb.cpp.o
../libs/database/CMakeFiles/digikamdatabasecore_src.dir/thumbsdb/thumbsdbchemaupdater.cpp.o
../libs/database/CMakeFiles/digikamdatabasecore_src.dir/thumbsdb/thumbsdbbackend.cpp.o
../libs/database/CMakeFiles/digikamdatabasecore_src.dir/thumbsdb/thumbsdbaccess.cpp.o
../libs/database/CMakeFiles/digikamdatabasecore_src.dir/digikamdatabasecore_src_autogen/moc_compilation.cpp.o
../libs/dimg/CMakeFiles/dimg_src.dir/loaders/dimgloader.cpp.o
../libs/dimg/CMakeFiles/dimg_src.dir/loaders/pngloader.cpp.o
../libs/dimg/CMakeFiles/dimg_src.dir/loaders/jp
egloader.cpp.o ../libs/dimg/CMakeFiles/dimg_src.dir/loaders/tiffloader.cpp.o
../libs/dimg/CMakeFiles/dimg_src.dir/loaders/rawloader.cpp.o
../libs/dimg/CMakeFiles/dimg_src.dir/loaders/ppmloader.cpp.o
../libs/dimg/CMakeFiles/dimg_src.dir/loaders/qimageloader.cpp.o
../libs/dimg/CMakeFiles/dimg_src.dir/loaders/pgfloader.cpp.o
../libs/dimg/CMakeFiles/dimg_src.
Re: [cmake-developers] COMPILE_FEATURES, Mac and non-Apple clang versions
On Tuesday January 03 2017 15:23:45 Robert Maynard wrote: > Basically my recommendation is if a project isn't setting > cmake_minimum_required before the first project call than nothing you > can do will fix that, as it is an error. The issue here is not that the minimum version was NOT being set. Apparently that isn't an issue if I set CMP0025 from the commandline. The issue was a project that requested an earlier CMake version (2.8.something) further down. Apparently that undoes the explicit CMP0025 setting, but not if I execute a cmake_minimum_required(3.0) first. Either way, I'm getting signals from others using the build system this is about (MacPorts) to please not force a minimum required CMake version, and calling `cmake_minimum_required` in an initial cache file does not have the expected effect. 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-developers
Re: [cmake-developers] COMPILE_FEATURES, Mac and non-Apple clang versions
On Tuesday January 03 2017 14:27:40 Robert Maynard wrote: Well, that has to be set in every project, or else we'd have to write an initial cache file to be loaded with -C ... Weird, btw: I just ran into a project that apparently wasn't satisfied with setting only CMP0025 on the commandline. It did set the minimum required version to 2.8.x but that was well after the project() definition, and it seems to be behind the scenes of that call that the compiler features are tested (judging from message(STATUS "here") probes). Do you know what's happening there, and have any brilliant thoughts how we can prevent this without have to scan each project? > Sorry I wasn't clear. I mean the cmake_minimum_required command ( > https://cmake.org/cmake/help/v3.0/command/cmake_minimum_required.html > ) -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] COMPILE_FEATURES, Mac and non-Apple clang versions
On Tuesday January 03 2017 11:41:29 Robert Maynard wrote: > You can explicitly do both of those things currently see: > https://cmake.org/cmake/help/v3.0/manual/cmake-policies.7.html Are you sure about the minimum required version? I cannot seem to have any luck with `-DCMAKE_MINIMUM_REQUIRED_VERSION=3.0`. 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-developers
Re: [cmake-developers] COMPILE_FEATURES, Mac and non-Apple clang versions
On Tuesday January 03 2017 11:41:29 Robert Maynard wrote: > It is the responsibility of the project to understand what components > of CMake they require, and correctly specify a cmake_minimum required > that satisfies all those requirements. In this case to use compile > features you need a minimum of 3.0 which also automatically enables > policy 25. I agree with you in a way, but in reality it would be up to end users and packagers to feed back that information to an unknown number of projects and convince them why it's necessary to comply with the request. That's just not doable. It would be a lot easier if the policy could be set at a central location, in this case in the Qt module invoking the test that fails. And it's CMake's responsibility to generate useful error messages, and where possible provide a hint for the fix. > You can explicitly do both of those things currently see: > https://cmake.org/cmake/help/v3.0/manual/cmake-policies.7.html Ah, thanks. I take it one can also change a line in cmPolicies.h: SELECT(POLICY, CMP0025, "Compiler id for Apple Clang is now AppleClang.", \ 3, 0, 0, cmPolicies::NEW) \ ? 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-developers
Re: [cmake-developers] COMPILE_FEATURES, Mac and non-Apple clang versions
On Tuesday January 03 2017 10:36:54 Robert Maynard wrote: That's all nice and well but a bit delicate to expect from an unknown number of project to adapt their minimum required CMake version for a policy they probably don't even know they require. > The minimum cmake version of each project controls the default state > of the policies. So for policy 25 you need a minimum of CMake 3.0. > This is partially a moot point, because compiler feature detection was > added in CMake 3.0, so if you are expecting that feature to exist you > should be requiring CMake 3.0. Maybe, indeed, but that becomes a much less trivial point if the policy becomes necessary somewhere hidden deep in a module that's loaded somewhere well into running cmake. How is the user supposed to understand what happens from the error message? The point would be moot if the minimum required cmake version could be adjusted whenever necessary, or policy 25 could be set when required. Or indeed if a cmake installation can be configured locally to set a policy, or to apply a limit to how far back the minimum required version can be set. 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-developers
Re: [cmake-developers] COMPILE_FEATURES, Mac and non-Apple clang versions
On Tuesday January 3 2017 10:02:44 Robert Maynard wrote: Hi, Thanks for the sample CMake file! It appears indeed that the policy defaulting to OLD is the culprit here: setting it to NEW at an appropriate location (and throwing out build.dir/CMake*) makes detection work properly. Surprised me a bit TBH; a casual read (and unburdened with prior knowledge) of the CMP0025 doc seems to suggest that the opposite would happen. That almost begs the question what you're waiting for to make the new setting the default. :) Maybe there's a way to toggle it locally, so that it doesn't have to be set in every project that may need to be built with a non-Apple clang version? Cheers, René Bertin >The problem that was reported in that other thread was due to having >policy CMP0025 set to a false value, once that policy was enabled >compiler detection worked properly. > >I would make sure the same isn't happening for you. > >I have attached a simple CMakeList.txt file you can use to determine >if potentially you are seeing the same policy issue. > > > >On Tue, Jan 3, 2017 at 9:21 AM, René J.V. Bertin wrote: >> Hi, >> >> I just had a run-in with a CMake file from Qt5 in a project I've been >> building with a locally built Clang 3.9 version, affectionately called >> clang-mp-3.9 . I got the cryptic message >> >> CMake Error in src/platformtheme/CMakeLists.txt: >>No known features for CXX compiler >> >>"Clang" >> >>version 3.9.0. >> >> >> Would you consider adding support for non-Apple clang versions on Mac too, >> and who would best request that, a Qt dev who considers the cxx_decltype >> test crucial, or the 1st user for whom that breaks his builds (i.e. me)? >> >> I see this has already come up for HB: >> https://cmake.org/pipermail/cmake/2016-December/064719.html >> >> >> 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-developers -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] COMPILE_FEATURES, Mac and non-Apple clang versions
Hi, I just had a run-in with a CMake file from Qt5 in a project I've been building with a locally built Clang 3.9 version, affectionately called clang-mp-3.9 . I got the cryptic message CMake Error in src/platformtheme/CMakeLists.txt: No known features for CXX compiler "Clang" version 3.9.0. Would you consider adding support for non-Apple clang versions on Mac too, and who would best request that, a Qt dev who considers the cxx_decltype test crucial, or the 1st user for whom that breaks his builds (i.e. me)? I see this has already come up for HB: https://cmake.org/pipermail/cmake/2016-December/064719.html 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-developers
