Re: [CMake] check_cxx_compiler_flag usage

[Clément Gregoire]

Sorry I got confused in what you were trying to say.
It indeed seems to be an error, as checking if a compiler supports some
defines does not make sense. Might be that an error occurred when
COMPILE_FLAGS became COMPILE_OPTIONS or something.
I would suggest opening an issue on cmake gitlab about it. (I also added
the cmake-dev list to cc)

However, it does indeed work for me, the script I linked before really
tries to use the - -coverage, and fails accordingly when using msvc, and
works with GCC. It wouldn't surprise me if cmake had some fallback when
detecting options in the definition variable.


I still think that checking the CMakeError.log to see what command is used
for the test in your case would be interesting to know what really happens
in your case.

Regards,
Lectem.

Le jeu. 7 déc. 2017 à 22:04, Damien R  a écrit :

> check_cxx_compiler_flag uses CMAKE_REQUIRED_DEFINITIONS. For me its means
> that only "-DSOME_FLAG=VALUE" should be tested with this macro and I think
> that the name is misleading.
> Some people define CMAKE_REQUIRED_FLAGS / CMAKE_REQUIRED_LIBRARIES before
> invoking check_cxx_compiler_flag but I think that they should use
> check_cxx_source_compiles.
> In your case I would use CMAKE_REQUIRED_FLAGS and
> check_cxx_source_compiles.
>
> But as I am not the developer which has written this cmake code there may
> be some points that invalidate what I just said.
>
> Regards,
>
> Damien R.
>
>
> On 7 December 2017 at 15:13, Clément Gregoire  wrote:
>
>> Your usage of check_cxx_compiler_flag is correct, it's probably just
>> missing link flags or something.
>> Can you check the error log of cmake to know why it fails to compile ? It
>> is in your buildfolder : CMakeFiles/CMakeError.log
>>
>> Here's how I did it for coverage by the way (not perfect, but was enough
>> for my usage):
>>
>>
>> https://github.com/Lectem/cpp-boilerplate/blob/master/cmake/Coverage.cmake#L42
>>
>>
>>
>>
>> 2017-12-07 14:31 GMT+01:00 Damien R :
>>
>>> Thank you for pointing that. It increments the number of people using
>>> CMAKE_REQUIRED_FLAGS "trick" to make it working with
>>> check_cxx_compiler_flag.
>>>
>>> But my question is more about :
>>>  - why they coded CHECK_CXX_COMPILER_FLAG this way?
>>>  - is my usage valid or not? If not what should I do? If yes, is it a
>>> bug?
>>>
>>> Regards,
>>>
>>> Damien R.
>>>
>>>
>>>
>>> On 7 December 2017 at 10:35, Eric Noulard 
>>> wrote:
>>>
>>>>
>>>> Not really answering the question but
>>>> did you try to use an existing CMake module for handling sanitizers
>>>> config?
>>>>
>>>> I find this one https://github.com/arsenm/sanitizers-cmake very
>>>> effective, with
>>>> modern CMake target oriented features.
>>>>
>>>>
>>>>
>>>>
>>>> 2017-12-07 9:24 GMT+01:00 Damien R :
>>>>
>>>>> Hi,
>>>>>
>>>>> I am trying to use CHECK_CXX_COMPILER_FLAG with cmake 3.9 to check if
>>>>> the compiler supports asan.
>>>>> The CMakeLists.txt is:
>>>>> cmake_minimum_required(VERSION 3.9)
>>>>> include(CheckCXXCompilerFlag)
>>>>> check_cxx_compiler_flag("-fsanitize=address" COMPILER_SUPPORT_FLAG)
>>>>>
>>>>> I always got:
>>>>> -- Performing Test COMPILER_SUPPORT_FLAG - Failed
>>>>>
>>>>> Even if the documentation say that CHECK_CXX_COMPILER_FLAG sets
>>>>> CMAKE_REQUIRED_DEFINITIONS by the name of the macro I thought that it 
>>>>> would
>>>>> work.
>>>>> Can you tell me why CHECK_CXX_COMPILER_FLAG use
>>>>> CMAKE_REQUIRED_DEFINITIONS instead of CMAKE_REQUIRED_FLAGS
>>>>> and what is the official way for checking this flag?
>>>>>
>>>>> Regards,
>>>>>
>>>>> Damien 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/s

Re: [CMake] check_cxx_compiler_flag usage

[Clément Gregoire]

Your usage of check_cxx_compiler_flag is correct, it's probably just
missing link flags or something.
Can you check the error log of cmake to know why it fails to compile ? It
is in your buildfolder : CMakeFiles/CMakeError.log

Here's how I did it for coverage by the way (not perfect, but was enough
for my usage):

https://github.com/Lectem/cpp-boilerplate/blob/master/cmake/Coverage.cmake#L42




2017-12-07 14:31 GMT+01:00 Damien R :

> Thank you for pointing that. It increments the number of people using
> CMAKE_REQUIRED_FLAGS "trick" to make it working with
> check_cxx_compiler_flag.
>
> But my question is more about :
>  - why they coded CHECK_CXX_COMPILER_FLAG this way?
>  - is my usage valid or not? If not what should I do? If yes, is it a bug?
>
> Regards,
>
> Damien R.
>
>
>
> On 7 December 2017 at 10:35, Eric Noulard  wrote:
>
>>
>> Not really answering the question but
>> did you try to use an existing CMake module for handling sanitizers
>> config?
>>
>> I find this one https://github.com/arsenm/sanitizers-cmake very
>> effective, with
>> modern CMake target oriented features.
>>
>>
>>
>>
>> 2017-12-07 9:24 GMT+01:00 Damien R :
>>
>>> Hi,
>>>
>>> I am trying to use CHECK_CXX_COMPILER_FLAG with cmake 3.9 to check if
>>> the compiler supports asan.
>>> The CMakeLists.txt is:
>>> cmake_minimum_required(VERSION 3.9)
>>> include(CheckCXXCompilerFlag)
>>> check_cxx_compiler_flag("-fsanitize=address" COMPILER_SUPPORT_FLAG)
>>>
>>> I always got:
>>> -- Performing Test COMPILER_SUPPORT_FLAG - Failed
>>>
>>> Even if the documentation say that CHECK_CXX_COMPILER_FLAG sets
>>> CMAKE_REQUIRED_DEFINITIONS by the name of the macro I thought that it would
>>> work.
>>> Can you tell me why CHECK_CXX_COMPILER_FLAG use
>>> CMAKE_REQUIRED_DEFINITIONS instead of CMAKE_REQUIRED_FLAGS
>>> and what is the official way for checking this flag?
>>>
>>> Regards,
>>>
>>> Damien 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
>>>
>>
>>
>>
>> --
>> Eric
>>
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] check_cxx_compiler_flag usage

[Clément Gregoire]

Well to be honest, as long as it's done correctly I don't really have any
issues with it.
The issue is that I've seen many Cmakelists.txt changing CMAKE_CXX_FLAGS
directly and forcing it upon the user by adding a target_add_* which most
of the time is not what you want.
Adding a new configuration type is indeed the best solution (though it
forces it on all the targets), it's also what I use for my coverage builds.

Le jeu. 7 déc. 2017 à 10:38, Eric Noulard  a écrit :

> 2017-12-07 9:35 GMT+01:00 Clément Gregoire :
>
>> That's probably an issue with linking because it doesn't know it has to
>> link asan.
>> Either way, settings asan flags is the job of the user, not the
>> cmakelists.txt.
>> Such things should be kept in tool chain or config files IMHO.
>>
>
> I do not agree with you.
>
> Most of the time you will have to handle various type of build for the
> same toolchain: i.e. debug, optimize, profiling etc...
> sanitizing is another case of build type.
> I wouldn't put it in the toolchain since it could work with various
> toolchain and at least with GCC or Clang.
>
> I don't know what you mean by "config file".
>
>
>> You can try running cmake in verbose mode for more information.
>>
>> Le jeu. 7 déc. 2017 à 09:25, Damien R  a écrit :
>>
>>> Hi,
>>>
>>> I am trying to use CHECK_CXX_COMPILER_FLAG with cmake 3.9 to check if
>>> the compiler supports asan.
>>> The CMakeLists.txt is:
>>> cmake_minimum_required(VERSION 3.9)
>>> include(CheckCXXCompilerFlag)
>>> check_cxx_compiler_flag("-fsanitize=address" COMPILER_SUPPORT_FLAG)
>>>
>>> I always got:
>>> -- Performing Test COMPILER_SUPPORT_FLAG - Failed
>>>
>>> Even if the documentation say that CHECK_CXX_COMPILER_FLAG sets
>>> CMAKE_REQUIRED_DEFINITIONS by the name of the macro I thought that it would
>>> work.
>>> Can you tell me why CHECK_CXX_COMPILER_FLAG use
>>> CMAKE_REQUIRED_DEFINITIONS instead of CMAKE_REQUIRED_FLAGS
>>> and what is the official way for checking this flag?
>>>
>>> Regards,
>>>
>>> Damien 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
>>
>>
>> --
>>
>> 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
>>
>
>
>
> --
> Eric
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] check_cxx_compiler_flag usage

[Clément Gregoire]

That's probably an issue with linking because it doesn't know it has to
link asan.
Either way, settings asan flags is the job of the user, not the
cmakelists.txt.
Such things should be kept in tool chain or config files IMHO.
You can try running cmake in verbose mode for more information.

Le jeu. 7 déc. 2017 à 09:25, Damien R  a écrit :

> Hi,
>
> I am trying to use CHECK_CXX_COMPILER_FLAG with cmake 3.9 to check if the
> compiler supports asan.
> The CMakeLists.txt is:
> cmake_minimum_required(VERSION 3.9)
> include(CheckCXXCompilerFlag)
> check_cxx_compiler_flag("-fsanitize=address" COMPILER_SUPPORT_FLAG)
>
> I always got:
> -- Performing Test COMPILER_SUPPORT_FLAG - Failed
>
> Even if the documentation say that CHECK_CXX_COMPILER_FLAG sets
> CMAKE_REQUIRED_DEFINITIONS by the name of the macro I thought that it would
> work.
> Can you tell me why CHECK_CXX_COMPILER_FLAG use
> CMAKE_REQUIRED_DEFINITIONS instead of CMAKE_REQUIRED_FLAGS
> and what is the official way for checking this flag?
>
> Regards,
>
> Damien 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
-- 

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] Cannot seem to add include directory

[Clément Gregoire]

Well, that's the standard way to add include for msbuild projects, other
variables are meant to be used for the tool chain includes only

Le mer. 22 nov. 2017 à 20:04, Michael Powell  a
écrit :

> On Wed, Nov 22, 2017 at 1:45 PM, Michael Powell 
> wrote:
> > Hello,
> >
> > I have a couple of libraries added, one SHARED and the other STATIC,
> > for which I want to add include directories, but they are not adding.
>
> Oh, okay... So they are being added under "additional include
> directories". Or they seem to be...
>
> > I am trying the following:
> >
> > target_include_directories (${MY_PROJECT_NAME_SHARED} PUBLIC
> > "G:/Source/Boost.Installed/boost-1.65.1/include"
> > )
> >
> > Where MY_PROJECT_NAME_SHARED if my project name.
> >
> > I've also tried with the $, to no avail.
> >
> > I review my VS2015 project settings and I do not see any directories
> > changing after the solution reloads.
> >
> > Cheers,
> >
> > Michael Powell
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] How to find dll's on Cygwin? (fwd)

[Clément Gregoire]

Hi,

I think you are looking for fixup_bundle if you are missing DLLs at
install. There's no real need to look for the DLLs yourself.

Lectem

Le sam. 28 oct. 2017 à 08:18, Hendrik Sattler  a
écrit :

> Hi,
>
> looking at the location of the gnat static library, it seems to be a
> compiler library like libm. You usually do not use find_package on those
> but directly use -lgnat and the compiler knows how to find it. Requesting
> static linking will also work then.
>
> HS
>
>
> Am 28. Oktober 2017 05:38:19 MESZ schrieb "Alan W. Irwin" <
> ir...@beluga.phys.uvic.ca>:
> >On 2017-10-27 22:31+0200 Marco Atzeri wrote:
> >
> >> On 27/10/2017 09:32, Alan W. Irwin wrote:
> >>> I am pretty sure there are a non-zero number of CMake users here who
> >>> have had CMake experience finding dll's on Cygwin (since it appears
> >>> from the quote below that import libraries can be replaced by dll's
> >>> for the purposes of linking on that platform).  So if you are one
> >with
> >>> such experience, I would really appreciate an answer to (or commment
> >>> on) the specific question below concerning finding cyggnat-6.dll on
> >>> Cygwin or if you prefer to frame your response to the more general
> >>> question of finding dll's on that platform, that would be great as
> >>> well.
> >>>
> >>> Alan
> >>
> >> using the import library is the standard way for linking,
> >> looking for the shared library is surely unusual.
> >>
> >> I am not a user of ADA, but the import libraries seems
> >> the one on /usr/lib/gcc/x86_64-pc-cygwin/6.4.0/adalib/
> >
> >Hi Marco:
> >
> >Thanks for your input to the discussion.
> >
> >I believe you are referring to
> >/usr/lib/gcc/x86_64-pc-cygwin/6.4.0/adalib/libgnat.a
> >
> >(at least that appears to be the only library candidate I can come up
> >with
> >by searching for the RE
> >
> >"usr/lib/gcc/x86_64-pc-cygwin/6.4.0/adalib/.*gnat"
> >
> >using the  package search
> >engine.)
> >
> >Our understanding is the Cygwin naming convention for the various
> >kinds of libraries would be (in the gnat library case)
> >
> >dll   cyggnat-6.dll
> >import librarylibgnat-6.dll.a
> >static librarylibgnat.a
> >
> >If you use the above search engine to search for the RE "gnat.*dll" it
> >only finds the above dll and no corresponding import library.
> >
> >We are pretty sure from its name that libgnat.a is just a static
> >library. Anyhow, when we link our test_ada library against libgnat.a
> >that link does appear to work, but afterward when linking Ada
> >executables against our Ada library (which involves a gnatlink step
> >with hidden link to one form of the gnat library but likely also
> >cyggnat-6.dll) we get multiple symbol definition errors. That linking
> >inconsistency does not happen if we link our Ada library against
> >cyggnat-6.dll so it appears that is the library CMake needs to find in
> >this case.
> >
> >Which neatly ( :-) ) leads back to my original question which is what
> >is the
> >best CMake logic to find that dll?
> >
> >Alan
> >
> >__
> >Alan W. Irwin
> >
> >Astronomical research affiliation with Department of Physics and
> >Astronomy,
> >University of Victoria (astrowww.phys.uvic.ca).
> >
> >Programming affiliations with the FreeEOS equation-of-state
> >implementation for stellar interiors (freeeos.sf.net); the Time
> >Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> >software package (plplot.sf.net); the libLASi project
> >(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> >and the Linux Brochure Project (lbproject.sf.net).
> >__
> >
> >Linux-powered Science
> >__
> >--
> >
> >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
>
> --
> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
> gesendet.
> --
>
> 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.ki

Re: [CMake] Problem measuring coverage in CTest scripts

[Clément Gregoire]

No since the point of cmake scripts is to build the project (for CI
basically).

I'm not sure what happens but I remember people having issues when using
ninja? I'm not sure.

You can have a look at
https://github.com/Lectem/cpp-boilerplate
I use a Ctest script for my Travis coverage build.

The script is the following :
https://github.com/Lectem/cpp-boilerplate/blob/master/cmake/CI.CTestScript.cmake

Le sam. 28 oct. 2017 à 08:30, Edoardo Pasca  a
écrit :

> Afaik, Ctest should be run in the build directory. From your command it
> seems you run it in the source. I'm not surprised it doesn't work.
>
> Edo
>
> On Oct 28, 2017 6:59 AM, "Maarten Anonymous" 
> wrote:
>
>> Hey,
>>
>> I have a question about using CMake+CTest+CTest scripts for coverage
>> tests.
>>
>> If I manually build the project and run "make ExperimantalCoverage" in a
>> build folder,
>> the coverage succeeds.
>> If I run the coverage from within a CTest script,
>> it fails.
>>
>> Am I forgetting something?
>>
>> A minimum example that exhibits my problem can be found at
>> https://gist.github.com/madebr/07ebd0de59e789cd819643b58db25df9.
>>
>> This works:
>> mkdir build && cd build && cmake .. && make && make test && make
>> ExperimentalCoverage && cd ..
>> This fails:
>> ctest -S test.ctest
>>
>> Source listing:
>> ###
>> #CMakeLists.txt:
>> ###
>> cmake_minimum_required(VERSION 3.9)
>> project(cmake_coverage)
>>
>> file(WRITE "${CMAKE_CURRENT_BINARY_DIR}/main.c" "int main() {return 0;}")
>>
>> add_executable(main
>> main.c
>> )
>>
>> target_compile_options(main
>> PUBLIC
>> "-O0"
>> "-fprofile-arcs"
>> "-ftest-coverage"
>> )
>>
>> target_link_libraries(main
>> gcov
>> )
>>
>> include(CTest)
>> enable_testing()
>>
>> add_test(NAME test
>> COMMAND main
>> )
>>
>> ##
>> # test.ctest:
>> ##
>> set(CTEST_SOURCE_DIRECTORY "${CTEST_SCRIPT_DIRECTORY}")
>> set(CTEST_BINARY_DIRECTORY "${CTEST_SCRIPT_DIRECTORY}/build/ctest")
>>
>> ctest_empty_binary_directory("${CTEST_BINARY_DIRECTORY}")
>>
>> set(CTEST_SITE "${CMAKE_SYSTEM_NAME}")
>> set(CTEST_BUILD_NAME "experimental build")
>>
>> set(CTEST_CMAKE_GENERATOR "Ninja")
>> set(CTEST_COVERAGE_COMMAND "gcov")
>>
>> ctest_start("Experimental")
>> ctest_configure()
>> ctest_build()
>> ctest_test()
>> ctest_coverage()
>>
>> ##
>> # CTestConfig.cmake:
>> ##
>> set(CTEST_PROJECT_NAME "Simple ctest_coverage project")
>>
>>
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake
>>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
-- 

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] Interface Libraries allow include directories but not link directories.. Why?

[Clément Gregoire]

I can't argue too much why paths or absolute on cmake as I don't know the
rationale behind it is. While your point about command line limit makes
sense, I feel like a system limiting command line size to this extent is
dumb if it doesn't allow reading more arguments through a file. (again, I
don't know the system at all).
I kinda understand your point about not being able to set the libdir per
target but (might have missed it in your previous mails) I don't know what
kind of project would need that. At best I would need one version of the
library per configuration, which is supported.

I entirely agree with for the rest. CMake badly documenting good practices
or even giving tutorials is an issue. Probably the biggest issue I found. I
myself still fight after years of using and experimenting with it. This
lead to a plethora of badly written cmakelists.txt or module scripts, that
even people in this list still advocates without understanding the problems
behind it. Even some tutorial series found on github.com or used by
coverage websites do it wrong.

At the moment the only reference I trust is Daniel's presentation and some
of the internal cmake scripts.

While not solving your problem, I documented most of my findings in this
small template /reference https://github.com/Lectem/cpp-boilerplate (which
might still do things the wrong way)

Le mer. 23 août 2017 à 02:14, Brian Davis  a écrit :

> On Tue, Aug 22, 2017 at 12:42 PM, Clément Gregoire 
> wrote:
>
>> No you're not meant to specify paths yourself, you should just use
>> find_library.
>> Check how modules such as FindTIFF.cmake are implemented.
>>
>
> Please doc in CMake all the things I am "meant to" so as I can live inside
> that happy little bubble world.
>
> Did I not just provide a perfectly rational reason why a crazed end user
> may want set lib path... err themselves
>
> /LIBPATH: is there for a reason in the compiler / linker sadly it appears
> CMake does not get this.  Clearly like the toolchain developers thought it
> was a good idea... hmm wonder it it had anything to do with the command
> line length problem?  Ahh yes must be a pesky little throwback from the
> days of yore.  Full paths eureka!  Nope not buying it.
>
> It appears CMake wants to save me from myself by not allowing me to set
> LIBPATH.  I mean do I got this right?  If so who's going to save CMake from
> themselves?
>
> Hey why not completely save me from myself and take away
> target_include_directories.
>
> I find find_library (I tried it and had in the past) still yields full
> path for every library even if multiple libs are in same dir and is even
> documented as such:
>
>
> https://cmake.org/cmake/help/latest/command/find_library.html?highlight=find_library
>
> "If the library found is a framework, then  will be set to the full
> path to the framework /A.framework. When a full path to a
> framework is used as a library, CMake will use a -framework A, and a
> -F to link the framework to the target."
>
> When these full lib dirs are chucked at the linker  kerpow... if large
> paths are used where project is located.
>
>
> But hey if find_library or whatever insanity I should use would say use a
> parameterized variable other than what is currently:
>
> find_library(
>MY_LIB_DEBUG
>NAMES 4DFUtilities.lib
>HINTS C:/projects/4DRTProto/4DRTProto/build/x64/Debug
> )
>
> FUORO4D_UTILITY_LIB_DEBUG =
> C:/projects/4DRTProto/4DRTProto/build/x64/Debug/Libraries/4DFUtilities.lib
>
> but rather generate a paramaterized version:
>
> FUORO4D_UTILITY_LIB_DEBUG =
> "LIBRARY_NAME;4DFUtilities.lib;LINK_DIRECTORY;C:/projects/4DRTProto/4DRTProto/build/x64/Debug/Libraries"
>
> (above is goop I have had to resort to  in
> CMake and VARARG macros for some  resemblance of inherited build properties
> prior to interface libraries)
>
> Then prior to command generation for linker *could* through the power of
> filtering for unique strings search all those LINK_DIRECTORY paths
> specifications and retain unique and set that crazy elusive, never to be
> gazed upon by human eyes, it-who-must-not-be-named /LIBPATH flag.  Doesn't
> that little cursor have enough to do with out dancing all over the place
> printing out full paths to libraries... I mean give the little bugger a
> break will ya!
>
> Let me be clear.  There are two problems here:
>
> 1) Abs paths to link libraries causing command line length issues such as
> in ITK
> 2) Inability to set lib dirs at target resolution.  find_library which is
> suggested a solution to this could be *if* it did not force abs paths to
> libs and would rather gather up unique full path

Re: [CMake] Interface Libraries allow include directories but not link directories.. Why?

[Clément Gregoire]

No you're not meant to specify paths yourself, you should just use
find_library.
Check how modules such as FindTIFF.cmake are implemented.

Le mar. 22 août 2017 à 19:05, Brian Davis  a écrit :

>
> and provide future
>
> ​target_link_directories(
>targ
>INTERFACE
>debug ${TOP}/build/x64/Debug/Libraries/
>optimized ${TOP}/build/x64/Release/Libraries/
> )
>
> with debug / optimized / general capability
>
> then targets could support multiple debug / release dirs even if CMake
> (CMAKE_INSTALL_PREFIX) can't (ie no CMAKE_INSTALL_PREFIX_
> capability)
>
> If anyone is looking at those dirs and wondering *why* (as I often do)...
> I need CMake in mixed mode with CMake generated projs and imported existing
> vcxproj files.
>
> if provided I could then targ link dirs, include dirs, and interface the
> libs from a position of relative sanity or at least the white jacket with
> wrap around arms tied in the back would be a little looser to the fit.
>
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] cmake-gui on windows and qt5 dlls

[Clément Gregoire]

So the following worked for me:


move cmake-gui.exe, all dlls and qt.conf to a "cmkae/bin/gui" subfolder

create a batch file named

cmake-gui.bat

with the following content

@echo off
start "" /B "%~dp0\gui\cmake-gui.exe" %*

And modify qt.conf so that the plugin directory is correct :

from  Plugins = ../plugins toPlugins = ../../plugins


I'm not (yet) on the dev mailing list, so feel free to transfer the
solution there.


2017-08-14 15:33 GMT+02:00 Lectem :

> Right, as mentionned by Craig Scott, a script might do the trick ? Just a
> cmake-gui.bat that calls cmake-gui.exe should work.
>
>
>
> *De : *Robert Maynard 
> *Envoyé le :*lundi 14 août 2017 15:24
> *À : *Craig Scott 
> *Cc : *Clément Gregoire ; CMake 
> *Objet :*Re: [CMake] cmake-gui on windows and qt5 dlls
>
>
>
> More importantly symlinks are restricted to administrator accounts
>
> only in Windows Vista/7/8. Windows 10 with Developer Mode activated
>
> allows none-elevated accounts to create symlinks.
>
>
>
> This is important as CMake does ship non-installer windows binaries.
>
>
>
> On Mon, Aug 14, 2017 at 9:00 AM, Craig Scott 
> wrote:
>
> >
>
> >
>
> > On Mon, Aug 14, 2017 at 9:05 PM, Clément Gregoire 
> wrote:
>
> >>
>
> >> Wouldn't it be possible to move it to a subfolder with the DLLs and put
> a
>
> >> link next to cmake and ccmake? Executables look for DLLs in their
> directory
>
> >> and it wouldn't pollute the PATH
>
> >
>
> >
>
> > Symlinks are available on NTFS filesystems from Vista onwards. If the
> user
>
> > installed CMake on, say, a FAT filesystem instead or on an old XP box
> (CMake
>
> > appears to still try to support that), then symlinks wouldn't be
> available
>
> > from what I can make out. One could potentially use a forwarding script
> of
>
> > some kind though to achieve essentially the same thing.
>
> >
>
> >
>
> >> I personally like to be able to launch it through the command line, it
> is
>
> >> faster than looking for it and then browse for the folder.
>
> >>
>
> >>
>
> >> Le lun. 14 août 2017 à 11:48, Craig Scott  a
>
> >> écrit :
>
> >>>
>
> >>> This is a common problem, not just with CMake. I'm wondering if there's
>
> >>> any real need for cmake-gui to be on the PATH at all, since it will
> usually
>
> >>> be invoked by a desktop or menu icon. At the moment though, it is in
> the
>
> >>> same directory as the cmake and ccmake executables which have a much
>
> >>> stronger case for being on the PATH. There's a reasonable argument that
>
> >>> cmake-gui should be in a different directory, then it wouldn't be an
> issue
>
> >>> if shared Qt libs were used rather than static. I'll bring this up on
> the
>
> >>> developer mailing list and see what discussions yield.
>
> >>>
>
> >>>
>
> >>> On Mon, Aug 14, 2017 at 6:22 PM, Christian Ehrlicher
>
> >>>  wrote:
>
> >>>>
>
> >>>> Hi,
>
> >>>>
>
> >>>> I recently upgraded from cmake 3.3 to 3.9 on windows and got some
>
> >>>> problems during my build because it looks like the pre-compile
> binaries for
>
> >>>> windows are now shipping Qt5 - dlls instead static compile libs
> (since 3.5
>
> >>>> afaics).
>
> >>>> The problem is, that I had the path to cmake *before* the path to my
> own
>
> >>>> Qt5 libaries. So during the build / run of my application, the wrong
>
> >>>> libraries were loaded and I got a symbol lookup error.
>
> >>>> Would it be possible to use the static Qt5 libs instead or maybe
> prefix
>
> >>>> the Qt5 libs shipped with cmake-gui somehow?
>
> >>>>
>
> >>>> Thx,
>
> >>>> Christian
>
> >>>>
>
> >>>> --
>
> >>>>
>
> >>>> 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:
>
> >>>>
>
> >>>> CMak

Re: [CMake] cmake-gui on windows and qt5 dlls

[Clément Gregoire]

Wouldn't it be possible to move it to a subfolder with the DLLs and put a
link next to cmake and ccmake? Executables look for DLLs in their directory
and it wouldn't pollute the PATH

I personally like to be able to launch it through the command line, it is
faster than looking for it and then browse for the folder.

Le lun. 14 août 2017 à 11:48, Craig Scott  a
écrit :

> This is a common problem, not just with CMake. I'm wondering if there's
> any real need for cmake-gui to be on the PATH at all, since it will usually
> be invoked by a desktop or menu icon. At the moment though, it is in the
> same directory as the cmake and ccmake executables which have a much
> stronger case for being on the PATH. There's a reasonable argument that
> cmake-gui should be in a different directory, then it wouldn't be an issue
> if shared Qt libs were used rather than static. I'll bring this up on the
> developer mailing list and see what discussions yield.
>
>
> On Mon, Aug 14, 2017 at 6:22 PM, Christian Ehrlicher 
> wrote:
>
>> Hi,
>>
>> I recently upgraded from cmake 3.3 to 3.9 on windows and got some
>> problems during my build because it looks like the pre-compile binaries for
>> windows are now shipping Qt5 - dlls instead static compile libs (since 3.5
>> afaics).
>> The problem is, that I had the path to cmake *before* the path to my own
>> Qt5 libaries. So during the build / run of my application, the wrong
>> libraries were loaded and I got a symbol lookup error.
>> Would it be possible to use the static Qt5 libs instead or maybe prefix
>> the Qt5 libs shipped with cmake-gui somehow?
>>
>> Thx,
>> Christian
>>
>> --
>>
>> 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
>>
>
>
>
> --
> Craig Scott
> Melbourne, Australia
> https://crascit.com
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] DLL handling under CMake

[Clément Gregoire]

ndif()
>
>   set(${output_variable} ${${output_variable}} PARENT_SCOPE)
>
> endfunction(RECURSIVE_SCAN)
>
>
> Best regards,
>
> Louis-Paul CORDIER
> Le 04/05/2017 à 09:51, lec...@gmail.com a écrit :
>
> I managed to get it working by using an intermediate script.
>
> One might want to generate the script instead of using the « RUN_IT »
> variable trick.
>
> This was only tested on Windows, but seems to work fine.
>
> Put the following code in a xx.cmake file, include it from your
> CMakeLists.txt and enjoy.
>
>
>
>
>
> # This is a helper script to run BundleUtilities fixup_bundle as postbuild
>
> # for a target. The primary use case is to copy .DLLs to the build
> directory for
>
> # the Windows platform. It allows generator expressions to be used to
> determine
>
> # the binary location
>
> #
>
> # Usage : run_fixup(TARGET LIBS DIRS)
>
> # - TARGET : A cmake target
>
> # - See fixup_bundle for LIBS and DIRS arguments
>
>
>
> if(RUN_IT)
>
> # Script ran by the add_custom_command
>
> include(BundleUtilities)
>
> fixup_bundle("${TO_FIXUP_FILE}" "${TO_FIXUP_LIBS}"
> "${TO_FIXUP_DIRS}")
>
> # End of script ran by the add_custom_command
>
> else()
>
>
>
> set(THIS_FILE ${CMAKE_CURRENT_LIST_FILE})
>
> message(${THIS_FILE})
>
> function(run_fixup _target _libs _dirs)
>
> message(${THIS_FILE})
>
> add_custom_command(
>
>TARGET ${_target} POST_BUILD
>
>COMMAND ${CMAKE_COMMAND} -DRUN_IT:BOOL=ON
> -DTO_FIXUP_FILE=$ -DTO_FIXUP_LIBS=${_libs}
> -DTO_FIXUP_DIRS=${_dirs}  -P ${THIS_FILE}
>
>COMMENT "Fixing up dependencies for
> ${_target}"
>
>VERBATIM
>
> )
>
>
>
> endfunction()
>
>
>
> endif()
>
>
>
>
>
> *De : *Clément Gregoire 
> *Envoyé le :*jeudi 4 mai 2017 08:37
> *À : *Hendrik Sattler ; Louis-Paul CORDIER
> ; Cmake Mailing List 
> *Objet :*Re: [CMake] DLL handling under CMake
>
>
>
> I'd also be interested in this. I saw an old mail in the ML about this,
> but it seems fixup_bundle is old and cant use generator expressions, making
> it hard to use (I don't want to hardcode the executable path).
>
>
>
> Do you have a sample for this ?
>
> CMake would really benefit from having those features made more accessible
> instead of everyone having to write its own script
>
> Le sam. 29 avr. 2017 22:10, Hendrik Sattler  a
> écrit :
>
>
>
> Am 27. April 2017 10:43:50 MESZ schrieb Louis-Paul CORDIER <
> lp.cord...@dynamixyz.com>:
> >This steps are tedious and I'm wondering if there is a mechanism that
> >exists or that have to be imagined to make the DLL nightmare end.
>
> I use BundleUtilities to achieve the copying of DLL files to the
> installation directory. The main problem for this is to enumerate the
> needed directories.
>
> I use the same for copying DLL files to the output directory to ease
> debugging.
>
> The advantage is the inspection of the exe for really needed DLL files.
> This AUTOMATICALLY handles the case debug vs. release.
>
> HS
>
> --
> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
> gesendet.
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
>
>
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
-- 

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] INTERPROCEDURAL_OPTIMIZATION still not using CMAKE__COMPILER_AR

[Clément Gregoire]

Should I file a bug report for this?

Le mar. 1 août 2017 à 22:52, Brad King  a écrit :

> On 07/22/2017 07:33 AM, lec...@gmail.com wrote:
> > So I downloaded the 3.9 release and thought my LTO nightmares we over but
> > cmake still isn't using CMAKE__COMPILER_AR when linking on MSYS.
>
> The problem is that this code:
>
>
> https://gitlab.kitware.com/cmake/cmake/blob/v3.9.0/Modules/Platform/Windows-GNU.cmake#L117-127
>
> inserts use of the archiver into the main linking process as a way
> to work around Windows command-line length limits.  Since it is
> using the archiver as part of linking instead of just for creating
> a static library, our logic to switch to CMAKE__COMPILER_AR
> for LTO is not triggering.
>
> -Brad
>
-- 

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] Coverage support

[Clément Gregoire]

This is mainly why I started this thread, I want to know the best way to do
this without using those variables.
CMAKE_lang_FLAGS is a pain as soon as someone wants to use add_subdirectory
(be it to add an external project or your project being used in another) or
a user wants to change the value. Those variables should really only be set
by the toolchain file or from the command-line.

Other solutions were mentioned in my first mail, the easiest one being to
add a new build type.
The other option is to uses something like a special script that will set
those variables before your Cmakelists.txt (ie a toolchain file).



Le lun. 7 août 2017 à 17:22, Konstantin Tokarev  a
écrit :

>
>
> 07.08.2017, 17:24, "Clément Gregoire" :
> >> I usually stop reading Cmakelists.txt as soon as I see this
> >>
> >> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -pedantic -pthread -g -O0
> >> -fprofile-arcs -ftest-coverage")
> >>
> >> The pthread thing there is likely wrong anyway, and the -Wall is
> entirely optional. The other things are needed, otherwise gcov will not
> produce any useful output.
> >
> > I don't have an issue with the flags per se, but with the usage of
> set(CMAKE_CXX_FLAGS). Setting flags like that should be banned from modern
> cmake scripts.
>
> How can one set global compiler flags without use of CMAKE_CXX_FLAGS or
> setting flags for each individual target?
>
> >
> >> Also you need to use the SETUP_TARGET_FOR_COVERAGE for every single test
> >> target, which seems to be a difficult to scale on big projects
> >>
> >> No, you don't. It's entirely fine if you just run "make test" as I do
> in OSM2go.
> > From what I saw in the documentation of the script :
> >
> >> # Param _testrunner The name of the target which runs the tests
> >
> > It seems to call directly the command named _testrunner, which is
> somehow confirmed from the cmakelists :
> >
> >> # src/CMakelists.txt
> >> add_executable(tests ${TEST_FILES})
> >>
> >> # Linking up all libraries
> >>
> >> target_link_libraries(tests complex)
> >>
> >> add_test(NAME example_test COMMAND tests)
> >> # CMakelists.txt
> >> setup_target_for_coverage(${PROJECT_NAME}_coverage tests coverage)
> > From this I deduce that you need to call setup_target_for_coverage for
> each different test executable.
> >
> > 2017-08-07 13:37 GMT+02:00 Rolf Eike Beer :
> >> Am 2017-08-07 11:06, schrieb Clément Gregoire:
> >> I usually stop reading Cmakelists.txt as soon as I see this
> >>
> >> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -pedantic -pthread -g -O0
> >> -fprofile-arcs -ftest-coverage")
> >>
> >> The pthread thing there is likely wrong anyway, and the -Wall is
> entirely optional. The other things are needed, otherwise gcov will not
> produce any useful output.
> >>
> >> Also you need to use the SETUP_TARGET_FOR_COVERAGE for every single test
> >> target, which seems to be a difficult to scale on big projects
> >>
> >> No, you don't. It's entirely fine if you just run "make test" as I do
> in OSM2go.
> >>
> >> Eike
> >> --
> >>
> >> Powered by www.kitware.com
> >>
> >> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
> >>
> >> Kitware offers various services to support the CMake community. For
> more information on each offering, please visit:
> >>
> >> CMake Support: http://cmake.org/cmake/help/support.html
> >> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> >> CMake Training Courses: http://cmake.org/cmake/help/training.html
> >>
> >> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> >>
> >> Follow this link to subscribe/unsubscribe:
> >> http://public.kitware.com/mailman/listinfo/cmake
> > ,--
> >
> > Powered by www.kitware.com
> >
> > Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
> >
> > Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
> >
> > CMake Support: http://cmake.org/cmake/help/support.html
> > CMake Consulting: http://cmake.org/cmake/help/consulting.html
> > CMake Training Courses: http://cmake.org/cmake/help/training.html
> >
> > Visit other Kitware open-source projects at
> http://www.k

Re: [CMake] Coverage support

[Clément Gregoire]

>
> I usually stop reading Cmakelists.txt as soon as I see this
>
>
>
> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -pedantic -pthread -g -O0
>
>
> -fprofile-arcs -ftest-coverage")
>
>
>
> The pthread thing there is likely wrong anyway, and the -Wall is entirely
> optional. The other things are needed, otherwise gcov will not produce any
> useful output.
>


I don't have an issue with the flags per se, but with the usage of
set(CMAKE_CXX_FLAGS).
Setting flags like that should be banned from modern cmake scripts.


Also you need to use the SETUP_TARGET_FOR_COVERAGE for every single test
>
>
> target, which seems to be a difficult to scale on big projects
>
>
>
> No, you don't. It's entirely fine if you just run "make test" as I do in
> OSM2go.
>

>From what I saw in the documentation of the script :


# Param _testrunner The name of the target which runs the tests


It seems to call directly the command named _testrunner, which is somehow
confirmed from the cmakelists :



# src/CMakelists.txt
add_executable(tests ${TEST_FILES})
# Linking up all libraries
target_link_libraries(tests complex)

add_test(NAME example_test COMMAND tests)
# CMakelists.txt
setup_target_for_coverage(${PROJECT_NAME}_coverage tests coverage)


>From this I deduce that you need to call setup_target_for_coverage for each
different test executable.



2017-08-07 13:37 GMT+02:00 Rolf Eike Beer :

> Am 2017-08-07 11:06, schrieb Clément Gregoire:
>
>> I usually stop reading Cmakelists.txt as soon as I see this
>>
>> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -pedantic -pthread -g -O0
>> -fprofile-arcs -ftest-coverage")
>>
>
> The pthread thing there is likely wrong anyway, and the -Wall is entirely
> optional. The other things are needed, otherwise gcov will not produce any
> useful output.
>
> Also you need to use the SETUP_TARGET_FOR_COVERAGE for every single test
>> target, which seems to be a difficult to scale on big projects
>>
>
> No, you don't. It's entirely fine if you just run "make test" as I do in
> OSM2go.
>
>
> Eike
> --
>
> 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/opensou
> rce/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Coverage support

[Clément Gregoire]

I usually stop reading Cmakelists.txt as soon as I see this

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -pedantic -pthread -g -O0
-fprofile-arcs -ftest-coverage")

Also you need to use the SETUP_TARGET_FOR_COVERAGE for every single test
target, which seems to be a difficult to scale on big projects

Le lun. 7 août 2017 à 12:50, Rolf Eike Beer  a écrit :

> Am 2017-08-07 09:57, schrieb Clément Gregoire:
> > Hi,
> > I'm a bit stuck when trying to add coverage reports to Cmake (gcov +
> > lcov)
> > as I can't figure out what is the best (idiomatic) way to do it.
> > So far here are the ways I know of :
> > - setting the CMAKE_LANG_FLAGS based on a boolean + scan all files /
> > run
> > gcov on it : would like to avoid this
> > - same but adding a new build type : seems to be way better but running
> > gcov would still be a pain
> > - same with a tool chain file for the flags : doesn't sound a good idea
> > since coverage should only be ran in debug
> > - some library to link with that propagates the flags : not possible
> > because link flags are not transient
> > - macro that adds the flags / does magic on a per target basis : many
> > scripts do this but seems to be a pain to maintain. Also I would rather
> > have all my test targets be set up automatically
> > - any of the above for flags and Ctest ctest_coverage but all I need
> > are
> > the gcov/lcov reports, not the coverage.xml for the dashboard
> > - using the command parameter of add_test
> > - something I missed?
> >
> > I want the setup to be easy and compatible with codecov.io, sadly all
> > the
> > script I found are bad, undocumented, or old and using bad practices.
>
> What's wrong with this one:
> https://github.com/codecov/example-cpp11-cmake ?
>
> I use it for both Codecov.io and CDash at the same time, see
> https://github.com/osm2go/osm2go/blob/master/.travis.yml
>
> Eike
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] Coverage support

[Clément Gregoire]

Hi,
I'm a bit stuck when trying to add coverage reports to Cmake (gcov + lcov)
as I can't figure out what is the best (idiomatic) way to do it.
So far here are the ways I know of :
- setting the CMAKE_LANG_FLAGS based on a boolean + scan all files / run
gcov on it : would like to avoid this
- same but adding a new build type : seems to be way better but running
gcov would still be a pain
- same with a tool chain file for the flags : doesn't sound a good idea
since coverage should only be ran in debug
- some library to link with that propagates the flags : not possible
because link flags are not transient
- macro that adds the flags / does magic on a per target basis : many
scripts do this but seems to be a pain to maintain. Also I would rather
have all my test targets be set up automatically
- any of the above for flags and Ctest ctest_coverage but all I need are
the gcov/lcov reports, not the coverage.xml for the dashboard
- using the command parameter of add_test
- something I missed?

I want the setup to be easy and compatible with codecov.io, sadly all the
script I found are bad, undocumented, or old and using bad practices.

Any help is welcome!

Thanks
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Change LTO Type in CMake 3.9 with Clang?

[Clément Gregoire]

Not yet, but it is a known issue :
https://gitlab.kitware.com/cmake/cmake/issues/16808

Le ven. 4 août 2017 à 06:03, Breannan Smith  a
écrit :

> Testing the new LTO support in CMake 3.9, it appears that
> setting INTERPROCEDURAL_OPTIMIZATION to TRUE causes CMake to pass
> '-flto=thin' to Clang. Is it possible to instead have CMake pass
> '-flto=full' (or just '-flto') to Clang?
>
> Thanks!
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] DLL handling under CMake

[Clément Gregoire]

I'd also be interested in this. I saw an old mail in the ML about this, but
it seems fixup_bundle is old and cant use generator expressions, making it
hard to use (I don't want to hardcode the executable path).

Do you have a sample for this ?
CMake would really benefit from having those features made more accessible
instead of everyone having to write its own script

Le sam. 29 avr. 2017 22:10, Hendrik Sattler  a
écrit :

>
>
> Am 27. April 2017 10:43:50 MESZ schrieb Louis-Paul CORDIER <
> lp.cord...@dynamixyz.com>:
> >This steps are tedious and I'm wondering if there is a mechanism that
> >exists or that have to be imagined to make the DLL nightmare end.
>
> I use BundleUtilities to achieve the copying of DLL files to the
> installation directory. The main problem for this is to enumerate the
> needed directories.
>
> I use the same for copying DLL files to the output directory to ease
> debugging.
>
> The advantage is the inspection of the exe for really needed DLL files.
> This AUTOMATICALLY handles the case debug vs. release.
>
> HS
>
> --
> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
> gesendet.
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Good practice: using INTERFACE-libraries in FindABC.cmake?

[Clément Gregoire]

Speaking of imported targets, I'm wondering why alias imported targets
aren't added to all default FindXXX.cmake scripts. This would help provide
better examples, and have the community use better cmakelists.txt and
hopefully reduce the bad usages of include_directories and such

Le lun. 29 févr. 2016 09:43, Nils Gladitz  a écrit :

> On 02/29/2016 03:34 PM, Patrick Boettcher wrote:
> > Hi list,
> >
> > I came across the INTERFACE-type of libraries when writing a
> > FindModule.cmake-file for custom libraries installed by my
> > project.
> >
> > Here is what I'm doing after having found the libraries and the
> > determined the paths: LIB1 is the library and LIB1_INCLUDE_DIRS its
> > include-dirs:
> >
> >add_library(name INTERFACE)
> >
> >target_link_libraries(name INTERFACE ${LIB1})
> >
> >if(FFTW3_FOUND)
> >   target_include_directories(name INTERFACE
> >   {$FFTW3_INCLUDE_DIRS})
> >   target_link_libraries(name INTERFACE ${FFTW3_LIBRARIES} )
> >endif()
> >
> >target_include_directories(name INTERFACE ${LIB1_INCLUDE_DIRS})
> >
> ># need c++11 compile options for if-name
> >set_property(TARGET name PROPERTY
> >   INTERFACE_COMPILE_FEATURES cxx_range_for)
> >
> > This makes that in the CMakeLists.txt which includes my package-file a
> > user needing libname for his executable does:
> >
> >add_executable(main main.cpp)
> >target_link_libraries(main name)
> >
> > This will
> >
> > 1) set C++11 flags for compilation
> > 2) set the right include-pathes
> > 3) link with the right libraries as per my order
> >
> > Awesome. But is this a good practice? Are there any pitfalls?
>
> This sounds like a use case for IMPORTED rather than INTERFACE libraries.
> INTERFACE libraries can be IMPORTED as well but are not intended for
> pre-build linkable libraries (which you seem to have).
>
> This documents how to create find modules with IMPORTED targets:
>
> https://cmake.org/cmake/help/v3.4/manual/cmake-developer.7.html#find-modules
>
> Nils
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] Modules FindXXX.cmake for toolchains under windows

[Clément Gregoire]

Hi,

I have some experience with cmake toolchain files, and wanted to try it
under windows. Everything works fine (find_library, path etc) except
find_package.

I added a custom FindCTRULIB.cmake file in my folder D:/devkitPro/devkitArm
and this folder is listed in my CMAKE_FIND_ROOT_PATH, printing its value
gives this :

 d:/devkitPro/devkitARM;d:/devkitPro

I also tried to put it in D:/devkitPro/devkitArm/cmake and
D:/devkitPro/devkitArm/share/cmake but it doesn't work.

Did I misunderstand the find_package documentation ?

I know that I could use CMAKE_MODULE_PATH, but I think this one should only
be used by the projects, not for scripts that are shipped with other
libraries.

Thanks,
Lectem
-- 

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 and devkitpro

[Clément Gregoire]

Hi,
I'm looking for a way to use CMake with the devkitpro toolchain (
http://sourceforge.net/projects/devkitpro/files/ )
I would like to be able to compile nds and 3ds homebrews.
It is a gcc based toolchain, and users have to define DEVKITPRO and
DEVKITARM env variables, giving the location of the devkitpro files.

the DEVKITARM folder contains the bin and lib folders, but those platforms
need specific commands to build the final files.


All the rules are based on makefiles available here :
https://github.com/devkitPro/buildscripts/tree/master/dkarm-eabi/rules

I started by looking at the cmake toolchain stuff (CMAKE_SYSTEM_NAME,
CMAKE_FIND_ROOT_PATH etc) but I don't think it will work well.

Any suggestions ?
-- 

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