[CMake] [2.6] set_tests_properties with PATH ignored?
Hi, I'm using CMake 2.6 on Windows XP. I need to set DLLs location for tests of a software I develop on Windows. So, I found Scott's solution very interesting: http://www.cmake.org/pipermail/cmake/2009-May/029464.html I followed this recipe and updated my CMakeLists.txt In CTestTestfile.cmake I can see propertly generated PATH with correctly quoted semi-colons, etc. Next, I tried ctest in mytest directory. Unfortunately, DLLs not found. When I copy DLLs to my test directory, everything works, so the problem is somewhere else than in my program. I tried to investigate it, carefully checking all quotes for \\ and semi-colon, paths, I tried very basic paths like "PATH=D:\\" without any luck. Eventually, I upgraded to latest CMake 2.8 release and without touching my CMakeLists.txt, my tests started to run, DLLs found, etc. Perhaps it's well known problem that Scott's trick does not work with CMake 2.6, but if not I think it may important users can find about it scanning the ML archives. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Get configuration-dependant LOCATION property
Hi,
I understand what the manual [1] says about LOCATION property that it is
more or less deprecated. Is that right?
I'm building software (shared libraries and executables) on both, Linux
and Windows (using VS 2005, 2008, 2010) and I'm trying to find out what
would be portable way to get target output location. It is location of
output directory where toolset genreates .so or .dll files.
I tried LOCATION property but it is empty (on Windows at least)
get_target_property(MY_TARGET_LOCATION ${MY_TARGET} LOCATION)
I tried LOCATION_Debug as well and it returns correct value,
but now I can't find how to figure out to generat
LOCATION_ in CMake run-time.
I've read CMake FAQ and ml archives and I understand CMAKE_BUILD_TYPE
doesn't help here as it's supported for make based generators.
Basically, I'm trying to improve Scott's "add_test and locating
dependent DLL's on Windows" [2] trick, so it does not stick to using
LOCATION_Debug property.
Can anyone suggest solution to how to get target ouptut folder location?
[1] http://cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:LOCATION
[2] http://www.cmake.org/pipermail/cmake/2009-May/029464.html
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
Member of ACCU, http://accu.org
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Get configuration-dependant LOCATION property
On 03/10/10 22:27, J Decker wrote:
> On Sun, Oct 3, 2010 at 10:28 AM, Mateusz Loskot wrote:
>> Hi,
>>
>> I understand what the manual [1] says about LOCATION property that it is
>> more or less deprecated. Is that right?
>>
>> I'm building software (shared libraries and executables) on both, Linux
>> and Windows (using VS 2005, 2008, 2010) and I'm trying to find out what
>> would be portable way to get target output location. It is location of
>> output directory where toolset genreates .so or .dll files.
>>
>> I tried LOCATION property but it is empty (on Windows at least)
>>
>> get_target_property(MY_TARGET_LOCATION ${MY_TARGET} LOCATION)
>
> get_target_property(MY_TARGET_LOCATION ${MY_TARGET}
> LOCATION_${CMAKE_BUILD_TYPE)) ?
It does not help.
As I mentioned in my original post, ${CMAKE_BUILD_TYPE} is empty
when you generate Visual Studio projects.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
Member of ACCU, http://accu.org
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Get configuration-dependant LOCATION property
On 04/10/10 07:33, J Decker wrote:
CMAKE_INSTALL_CONFIG_NAME I don't know if there's a simple flag like
'project supports multiple targets' so I have an if(MSVC) set(
MULTI_TARGET) endif() if( MULTI_TARGET ) Install( targets ...
${CMAKE_INSTALL_CONFIG_NAME ) else() isntall( ... ${CMAKE_BUILD_TYPE}
I need it before firing up install procedures.
I build.
I run tests (here I need to know location of build output per target).
I install.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
Member of ACCU, http://accu.org
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Get configuration-dependant LOCATION property
On 04/10/10 05:40, Michael Wild wrote:
On 3. Oct, 2010, at 23:53 , Mateusz Loskot wrote:
On 03/10/10 22:27, J Decker wrote:
On Sun, Oct 3, 2010 at 10:28 AM, Mateusz
Loskot wrote:
Hi,
I understand what the manual [1] says about LOCATION property
that it is more or less deprecated. Is that right?
I'm building software (shared libraries and executables) on
both, Linux and Windows (using VS 2005, 2008, 2010) and I'm
trying to find out what would be portable way to get target
output location. It is location of output directory where
toolset genreates .so or .dll files.
I tried LOCATION property but it is empty (on Windows at
least)
get_target_property(MY_TARGET_LOCATION ${MY_TARGET} LOCATION)
get_target_property(MY_TARGET_LOCATION ${MY_TARGET}
LOCATION_${CMAKE_BUILD_TYPE)) ?
It does not help.
As I mentioned in my original post, ${CMAKE_BUILD_TYPE} is empty
when you generate Visual Studio projects.
I didn't look into the specifics of your problem, but would it be a
solution to configure _all_ locations into a CMake script which
performs your required action at build/test time?
I haven't mention that. I try to keep default CMake build tree
layout. Regardless how simple changes it would require, IMHO,
messing with *_OUTPUT properties overrides portability
provided by CMake out of the box and would require manual
handling.
I define target for CMake and CMake knows where to output files.
Now, simply, I would like to ask "Dear CMake, tell me please where do
you send my binaries".
Can I do it? How?
> You could pass the configuration type as a -D parameter.
I could pass CMAKE_BUILD_TYPE, but this would be available once
when configuration is performed. Then, form Visual Studio IDE
user can change configuration which CMake settings will not be aware of.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
Member of ACCU, http://accu.org
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Get configuration-dependant LOCATION property
On 04/10/10 12:01, Michael Wild wrote:
>
> On 4. Oct, 2010, at 10:51 , Mateusz Loskot wrote:
>
>> On 04/10/10 05:40, Michael Wild wrote:
>>>
>>> On 3. Oct, 2010, at 23:53 , Mateusz Loskot wrote:
>>>
>>>> On 03/10/10 22:27, J Decker wrote:
>>>>> On Sun, Oct 3, 2010 at 10:28 AM, Mateusz
>>>>> Loskot wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I understand what the manual [1] says about LOCATION
>>>>>> property that it is more or less deprecated. Is that
>>>>>> right?
>>>>>>
>>>>>> I'm building software (shared libraries and executables)
>>>>>> on both, Linux and Windows (using VS 2005, 2008, 2010) and
>>>>>> I'm trying to find out what would be portable way to get
>>>>>> target output location. It is location of output directory
>>>>>> where toolset genreates .so or .dll files.
>>>>>>
>>>>>> I tried LOCATION property but it is empty (on Windows at
>>>>>> least)
>>>>>>
>>>>>> get_target_property(MY_TARGET_LOCATION ${MY_TARGET}
>>>>>> LOCATION)
>>>>>
>>>>> get_target_property(MY_TARGET_LOCATION ${MY_TARGET}
>>>>> LOCATION_${CMAKE_BUILD_TYPE)) ?
>>>>
>>>> It does not help.
>>>>
>>>> As I mentioned in my original post, ${CMAKE_BUILD_TYPE} is
>>>> empty when you generate Visual Studio projects.
>>>
>>>
>>> I didn't look into the specifics of your problem, but would it be
>>> a solution to configure _all_ locations into a CMake script
>>> which performs your required action at build/test time?
>>
>> I haven't mention that. I try to keep default CMake build tree
>> layout. Regardless how simple changes it would require, IMHO,
>> messing with *_OUTPUT properties overrides portability provided by
>> CMake out of the box and would require manual handling.
>>
>> I define target for CMake and CMake knows where to output files.
>> Now, simply, I would like to ask "Dear CMake, tell me please where
>> do you send my binaries".
>>
>> Can I do it? How?
>>
>>> You could pass the configuration type as a -D parameter.
>>
>> I could pass CMAKE_BUILD_TYPE, but this would be available once
>> when configuration is performed. Then, form Visual Studio IDE user
>> can change configuration which CMake settings will not be aware
>> of.
>
> I think you didn't understand my answer. What I proposed was to wrap
> the operation you want to perform in a script. This way you can
> configure all possible output locations into it and then select the
> correct one at build time via an argument.
Michael,
Yes, I think I misunderstood it and I still can't understand how script
would help.
myproject/
myproject/lib1/lib1.cpp
myproject/lib1/CMakeLists.txt
- builds lib1.dll
myproject/test1/test1.cpp
myproject/test1/CMakeLists.txt
- builds and runs test for lib1.dll, so needs to know where to find
intermediate output of lib1/CMakeLists.txt target that builds lib1.dll,
so ENV[PATH] can be updated to allow .dll lookup, without running
install targets.
I don't want any scripts external to CMake, because in a script I would
need to handle all platforms once again - CMake is supposed to handle
multiplatform issue, isn't it?
It's frustrating, but I can't really understand it. If CMake knows where
tell compiler/linker to output binaries, why user can not query
this location from inside CMakeLists.txt file?
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
Member of ACCU, http://accu.org
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Get configuration-dependant LOCATION property
On 04/10/10 14:24, Michael Hertling wrote:
> On 10/04/2010 10:53 AM, Mateusz Loskot wrote:
>> On 04/10/10 07:33, J Decker wrote:
>>> CMAKE_INSTALL_CONFIG_NAME I don't know if there's a simple flag like
>>> 'project supports multiple targets' so I have an if(MSVC) set(
>>> MULTI_TARGET) endif() if( MULTI_TARGET ) Install( targets ...
>>> ${CMAKE_INSTALL_CONFIG_NAME ) else() isntall( ... ${CMAKE_BUILD_TYPE}
>>
>>
>> I need it before firing up install procedures.
>> I build.
>> I run tests (here I need to know location of build output per target).
>
> Have you already taken a look at ADD_TEST()'s generator expressions like
> $? AFAIK, they've been introduced quite exactly to
> meet requirements such as yours.
Hmm, I've seen this expressions, but I'm not sure how it can be useful
because the expressions are used to generate test input.
My problem is about getting property to generate environment
for test before it is executed:
In one subtree of my sources, I have mylib target building mylib.dll
In another subtree, I have test. Next, I build and run test:
add_executable(mytest test.cpp)
target_link_libraries(mytest mylib_import.lib)
add_test(mytest ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/mytest)
set_tests_properties(mytest PROPERTIES
ENVIRONMENT "PATH=c:\path\to\dir\with\mylib.dll\")
I need to figure out this: "c:\path\to\dir\with\mylib.dll\"
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
Member of ACCU, http://accu.org
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Get configuration-dependant LOCATION property
On 03/10/10 18:28, Mateusz Loskot wrote:
> Hi,
>
> I understand what the manual [1] says about LOCATION property that it is
> more or less deprecated. Is that right?
>
> I'm building software (shared libraries and executables) on both, Linux
> and Windows (using VS 2005, 2008, 2010) and I'm trying to find out what
> would be portable way to get target output location. It is location of
> output directory where toolset genreates .so or .dll files.
>
> I tried LOCATION property but it is empty (on Windows at least)
>
> get_target_property(MY_TARGET_LOCATION ${MY_TARGET} LOCATION)
>
> I tried LOCATION_Debug as well and it returns correct value,
> but now I can't find how to figure out to generat
> LOCATION_ in CMake run-time.
>
> I've read CMake FAQ and ml archives and I understand CMAKE_BUILD_TYPE
> doesn't help here as it's supported for make based generators.
>
> Basically, I'm trying to improve Scott's "add_test and locating
> dependent DLL's on Windows" [2] trick, so it does not stick to using
> LOCATION_Debug property.
>
> Can anyone suggest solution to how to get target ouptut folder location?
I have solved my problem by globally setting CMAKE_*_OUTPUT_DIRECTORY
variables, so I can have control where to send target output
and where to look for runtime modules.
Thanks to all for brainstorming alternatives.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
Member of ACCU, http://accu.org
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Get configuration-dependant LOCATION property
On 05/10/10 02:52, Michael Hertling wrote:
> On 10/04/2010 11:15 PM, Mateusz Loskot wrote:
>> On 04/10/10 14:24, Michael Hertling wrote:
>>> On 10/04/2010 10:53 AM, Mateusz Loskot wrote:
>>>> On 04/10/10 07:33, J Decker wrote:
>>>>> CMAKE_INSTALL_CONFIG_NAME I don't know if there's a simple flag like
>>>>> 'project supports multiple targets' so I have an if(MSVC) set(
>>>>> MULTI_TARGET) endif() if( MULTI_TARGET ) Install( targets ...
>>>>> ${CMAKE_INSTALL_CONFIG_NAME ) else() isntall( ... ${CMAKE_BUILD_TYPE}
>>>>
>>>>
>>>> I need it before firing up install procedures.
>>>> I build.
>>>> I run tests (here I need to know location of build output per target).
>>>
>>> Have you already taken a look at ADD_TEST()'s generator expressions like
>>> $? AFAIK, they've been introduced quite exactly to
>>> meet requirements such as yours.
>>
>> Hmm, I've seen this expressions, but I'm not sure how it can be useful
>> because the expressions are used to generate test input.
>>
>> My problem is about getting property to generate environment
>> for test before it is executed:
>>
>> In one subtree of my sources, I have mylib target building mylib.dll
>> In another subtree, I have test. Next, I build and run test:
>>
>> add_executable(mytest test.cpp)
>>
>> target_link_libraries(mytest mylib_import.lib)
>>
>> add_test(mytest ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/mytest)
>>
>> set_tests_properties(mytest PROPERTIES
>> ENVIRONMENT "PATH=c:\path\to\dir\with\mylib.dll\")
>>
>> I need to figure out this: "c:\path\to\dir\with\mylib.dll\"
>
> You might consider to use a script as a test driver which takes
> the desired path and the test executable as parameters, e.g.
>
> ADD_TEST(mytest
> testdriver $ $)
>
> with testdriver setting the PATH and executing mytest.
I admit, such script has a lot of potential to tweak runtime environment
indeed.
At this moment I'm happy with output all binary modules in build/bin and
build/lib, so I have no need to set extra env any more.
I'll keep in mind the idea though. Thanks.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
Member of ACCU, http://accu.org
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Get configuration-dependant LOCATION property
On 05/10/10 08:10, Michael Wild wrote:
>
> On 5. Oct, 2010, at 3:52 , Michael Hertling wrote:
>
>> On 10/04/2010 11:15 PM, Mateusz Loskot wrote:
>>> On 04/10/10 14:24, Michael Hertling wrote:
>>>> On 10/04/2010 10:53 AM, Mateusz Loskot wrote:
>>>>> On 04/10/10 07:33, J Decker wrote:
>>>>>> CMAKE_INSTALL_CONFIG_NAME I don't know if there's a simple flag like
>>>>>> 'project supports multiple targets' so I have an if(MSVC) set(
>>>>>> MULTI_TARGET) endif() if( MULTI_TARGET ) Install( targets ...
>>>>>> ${CMAKE_INSTALL_CONFIG_NAME ) else() isntall( ... ${CMAKE_BUILD_TYPE}
>>>>>
>>>>>
>>>>> I need it before firing up install procedures.
>>>>> I build.
>>>>> I run tests (here I need to know location of build output per target).
>>>>
>>>> Have you already taken a look at ADD_TEST()'s generator expressions like
>>>> $? AFAIK, they've been introduced quite exactly to
>>>> meet requirements such as yours.
>>>
>>> Hmm, I've seen this expressions, but I'm not sure how it can be useful
>>> because the expressions are used to generate test input.
>>>
>>> My problem is about getting property to generate environment
>>> for test before it is executed:
>>>
>>> In one subtree of my sources, I have mylib target building mylib.dll
>>> In another subtree, I have test. Next, I build and run test:
>>>
>>> add_executable(mytest test.cpp)
>>>
>>> target_link_libraries(mytest mylib_import.lib)
>>>
>>> add_test(mytest ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/mytest)
>>>
>>> set_tests_properties(mytest PROPERTIES
>>> ENVIRONMENT "PATH=c:\path\to\dir\with\mylib.dll\")
>>>
>>> I need to figure out this: "c:\path\to\dir\with\mylib.dll\"
>>
>> You might consider to use a script as a test driver which takes
>> the desired path and the test executable as parameters, e.g.
>>
>> ADD_TEST(mytest
>>testdriver $ $)
>>
>> with testdriver setting the PATH and executing mytest.
>>
>> Regards,
>>
>> Michael
>
> Ah, yes, this is even better than my idea of configuring. So, you could have
> a CMake script like the following:
>
> testdriver.cmake
>
> # check arguments LIBDIR, TESTEXE and WIN32
> foreach(var LIBDIR TESTEXE WIN32)
> if(NOT DEFINED ${var})
> message(FATAL_ERROR "${var} not defined")
> endif()
> endforeach()
>
> # on Windows set PATH
> if(WIN32)
> set($ENV{PATH} "${LIBDIR};$ENV{PATH}")
> endif(WIN32)
>
> # run TESTEXE
> execute_process(
> COMMAND "${TESTEXE}"
> RESULT_VARIABLE result)
> if(result)
> message(FATAL_ERROR "Running ${TESTEXE} failed")
> endif()
> # EOF
>
> CMakeLists.txt
> --
> ...
> add_test(NAME bar COMMAND
> "${CMAKE_COMMAND}"
> -DLIBDIR=$ -DTESTEXE=$
> -DWIN32=${WIN32}
> -P "${CMAKE_CURRENT_SOURCE_DIR}/testdriver.cmake"
> )
> ...
> # EOF
>
> I hope this helps
Wow! I had no idea about such CMake capabilities of CMake command run
from CMake script and passing another CMake script to execute.
This is brilliant!
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
Member of ACCU, http://accu.org
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Disallowing in-source builds
On 07/10/10 10:21, fat...@crackmonkey.us wrote: Then, to clear all CMake debris: rm -r projectx/cmake/* On Unix, if a project is managed by SVN it's easy to clean tree from generated files: $ svn-clean Distributed with Debian, Ubuntu, etc. as well as downloadable [1] I'm sure there are similar commands/tools possible for Git, Mercurial and others. [1] http://websvn.kde.org/*checkout*/trunk/KDE/kdesdk/scripts/svn-clean?pathrev=499176 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake Visual Studio 64bit flag?
On 08/10/10 16:42, Michael Jackson wrote: maybe SIZE_OF_VOID_POINTER of whatever that variable is in CMake? In SOCI library, I use something like this: if(UNIX AND CMAKE_SIZEOF_VOID_P EQUAL 4) set(SOCI_LIBDIR "lib64") else() set(SOCI_LIBDIR "lib") endif() Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake Visual Studio 64bit flag?
Yes, you are right. My mistake. Thanks! Mat On 08/10/10 16:51, David Cole wrote: Either you've got that reversed, or 4 should be 8... right? lib64 should be for an 8-byte void* ... On Fri, Oct 8, 2010 at 11:48 AM, Mateusz Loskot mailto:mate...@loskot.net>> wrote: On 08/10/10 16:42, Michael Jackson wrote: maybe SIZE_OF_VOID_POINTER of whatever that variable is in CMake? In SOCI library, I use something like this: if(UNIX AND CMAKE_SIZEOF_VOID_P EQUAL 4) set(SOCI_LIBDIR "lib64") else() set(SOCI_LIBDIR "lib") endif() Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org ___ Powered by www.kitware.com <http://www.kitware.com> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Status of clang support?
Hi, I'm trying to find out what's the status of clang support in CMake. What version of CMake is recommended to make proper use of clang 2.8+ for building a C++ software, etc. Feeding the favourite search engine with this: clang site:http://www.cmake.org/pipermail/cmake/ gives me literally 4 pages os results, but no announcement-like posts. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Status of clang support?
On 24/10/10 20:07, Marcus D. Hanwell wrote: > On Sun, Oct 24, 2010 at 2:58 PM, Michael Wild wrote: >> On 24. Oct, 2010, at 17:33 , Mateusz Loskot wrote: >> >>> I'm trying to find out what's the status of clang support in >>> CMake. What version of CMake is recommended to make proper use of >>> clang 2.8+ for building a C++ software, etc. >>> >>> Feeding the favourite search engine with this: >>> >>> clang site:http://www.cmake.org/pipermail/cmake/ >>> >>> gives me literally 4 pages os results, but no announcement-like >>> posts. >> >> >> Hi >> >> Clang's UI is a clone of gcc's, so there's very little extra work >> CMake has to perform. For me it works flawlessly. I don't know >> about the earliest version to support Clang, but AFAIK 2.8 works >> well. > > > I echo Michael's reports, setting it as the compiler just works for > many projects. The ones where it fails it is a compilation issue, > and I have used CMake 2.8.2 with several projects to test out the > Clang support. Michael, Marcus, Thanks for the confirmation. I have tried clang 2.8 with one of my projects powered by CMake and it works well indeed. Although, I'm curious how to interpret the following messages: -- The C compiler identification is GNU -- The CXX compiler identification is GNU Apparently, clang is identified: -- Check for working C compiler: /usr/bin/clang -- Check for working C compiler: /usr/bin/clang -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/clang++ -- Check for working CXX compiler: /usr/bin/clang++ -- works Also, how can I distinguish clang in CMakeLists.txt to perform some conditional settings? if(CMAKE_COMPILER_IS_GNUCC OR CMAKE_COMPILER_IS_GNUCXX) elseif(MSVC) elseif(CLANG) # ??? endif() Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake-gui has very slow path completion in directories with many files
On 24/10/10 22:41, Jed Brown wrote: > Entering a path in cmake-gui causes a long stall when the directory has > many files. For example, /usr/bin and /usr/lib have about 4000 files, > and when typing a path to /usr/lib/libfoo.so, the gui locks up > completely for 15 to 20 seconds. I can confirm similar but shorter effect on Windows. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Status of clang support?
On 25/10/10 00:42, Sean McBride wrote: > On Sun, 24 Oct 2010 16:33:01 +0100, Mateusz Loskot said: > >> I'm trying to find out what's the status of clang support in CMake. >> What version of CMake is recommended to make proper use of clang 2.8+ >> for building a C++ software, etc. > > Somewhat off-topic, but if you're going to build C++ code with clang, > you should probably build clang yourself from trunk. Its C++ support is > new and much better in trunk than 2.8. Sean, I am aware of this fact. However, for the first trial I've decided to try clang 2.8. I have collected some confirmations at the IRC channel #boost where number of folks confirmed usability of 2.8. I'm going to try clang from the mainstream soon. Thanks! -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Status of clang support?
On 24/10/10 23:00, Ryan Pavlik wrote:
> My best guess would be to check for some Clang-specific defines,
> similar to the platform checks. Actually, it looks like in the Git
> repository of CMake, there is now some Clang-specific support:
> http://github.com/Kitware/CMake/commit/571dc7489111893355deba710feee5990bce92e4
> I think that this commit is included in 2.8.2.
Ryan,
It's very good to know.
> I've made a note on that commit as to where I think a Clang-specific
> variable might be set.
I've seen, great!
> For now, you might be able to look at the
> value of CMAKE_CXX_COMPILER_ID for a more general solution - it seems
> like that might contain "Clang" if building using Clang.
I'm having access to CMake 2.8.0 at this moment
And, this version sets CMAKE_CXX_COMPILER_ID to GNU, even if
C/C++ compilers set to clang:
cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++
Also, simple test always reports the "gnu".
if("${CMAKE_CXX_COMPILER_ID}" MATCHES "clang")
message(STATUS "clang")
elseif("${CMAKE_CXX_COMPILER_ID}" MATCHES "GNU")
message(STATUS "gnu")
endif()
I will try 2.8.2 soon.
Thanks for your help!
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
Member of ACCU, http://accu.org
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Status of clang support?
On 25/10/10 01:38, Mateusz Loskot wrote:
> On 24/10/10 23:00, Ryan Pavlik wrote:
>> My best guess would be to check for some Clang-specific defines,
>> similar to the platform checks. Actually, it looks like in the Git
>> repository of CMake, there is now some Clang-specific support:
>> http://github.com/Kitware/CMake/commit/571dc7489111893355deba710feee5990bce92e4
>> I think that this commit is included in 2.8.2.
>
> Ryan,
>
> It's very good to know.
>
>> I've made a note on that commit as to where I think a Clang-specific
>> variable might be set.
>
> I've seen, great!
>
>> For now, you might be able to look at the
>> value of CMAKE_CXX_COMPILER_ID for a more general solution - it seems
>> like that might contain "Clang" if building using Clang.
>
> I'm having access to CMake 2.8.0 at this moment
> And, this version sets CMAKE_CXX_COMPILER_ID to GNU, even if
> C/C++ compilers set to clang:
>
> cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++
>
> Also, simple test always reports the "gnu".
>
> if("${CMAKE_CXX_COMPILER_ID}" MATCHES "clang")
> message(STATUS "clang")
> elseif("${CMAKE_CXX_COMPILER_ID}" MATCHES "GNU")
> message(STATUS "gnu")
> endif()
>
> I will try 2.8.2 soon.
>
> Thanks for your help!
FYI,
I have tried clang 2.9 (current SVN trunk)
together with CMake from current git.
The compiler ID matching works perfectly well!
Thanks again!
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
Member of ACCU, http://accu.org
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FindODBC.cmake
Hi, You may find the one in SOCI repo useful http://soci.git.sf.net/ And go to src/cmake/modules -- Mateusz Łoskot, http::/mateusz.loskot.net (Sent from my mobile) - Reply message - From: "Adam J Richardson" Date: Mon, Nov 1, 2010 11:48 Subject: [CMake] FindODBC.cmake To: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi list, Does anyone know of a good FindODBC.cmake I can grab from somewhere? My Modules directory lacks one. :/ If not I'll write a quick one for inclusion in the new release. I'll assume either Win32 standard or unixodbc is fine since they're compatible with each other. Thanks, Adam J Richardson -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkzOqQkACgkQSUH6dLOqvqkgrwCfR9lrKOZQOwVaqWC4tWJnFDd4 jlAAn0CE5RZy+3sLWFIkLdGv42jdHaR1 =0QA1 -END PGP SIGNATURE- ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FindODBC.cmake
On 01/11/10 15:31, Adam J Richardson wrote: > On Mon, 01 Nov 2010 14:25:24 + > "Mateusz Loskot" wrote: >> Hi, >> You may find the one in SOCI repo useful >> http://soci.git.sf.net/ > >> And go to src/cmake/modules > > Thanks Mateusz, that's great! I only needed to add "odbc32" to the list > of library names (MinGW's OBDC implementation is in libodbc32.a). I'm glad it helped and thanks for the fix suggestion by the way. I have just updated my FindODBC.cmake :-) Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Embedding static library in shared object library
On 17/11/10 11:33, santosh mahto wrote: Hi all Q:-i have a 3 static library(say A.a B.a C.a) and i want to create my final library as .so (say Main.so ) which link + embedd all three Library.i tried TARGET_LINK_LIBRARIES but it only links to A.a B.a C.a.and dosnt append it.I want my final binary(Main.so) to include(or embedd) all three static library(already compiled with --fpic). Please Tell me the correct solution for this dilemma. """ Combining static libs into a shared lib is not really portable, you have to take care that you use the correct linker flags for the libs so that it will work. """ http://www.cmake.org/pipermail/cmake/2008-March/020315.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to submit new modules?
On 24/12/10 00:02, Mateusz Loskot wrote: > Hi, > > I have collected a few modules: > FindDL.cmake > FindGDAL.cmake > FindGeoTIFF.cmake > FindMySQL.cmake > FindOracle.cmake > FindPostgreSQL.cmake > FindPROJ4.cmake > FindSpatialIndex.cmake > FindSQLite3.cmake > > Perhaps CMake would find some of them useful. > > Some are already in CMake like FindGDAL.cmake, but in my module > I support a few interesting features, like finding GDAL > in official distribution of OSGeo4W (http://trac.osgeo.org/osgeo4w/) > on Windows. Perhaps a merge would be beneficial. I completely forgot to point where the modules are stored: https://github.com/mloskot/cmake-modules/ Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] How to submit new modules?
Hi, I have collected a few modules: FindDL.cmake FindGDAL.cmake FindGeoTIFF.cmake FindMySQL.cmake FindOracle.cmake FindPostgreSQL.cmake FindPROJ4.cmake FindSpatialIndex.cmake FindSQLite3.cmake Perhaps CMake would find some of them useful. Some are already in CMake like FindGDAL.cmake, but in my module I support a few interesting features, like finding GDAL in official distribution of OSGeo4W (http://trac.osgeo.org/osgeo4w/) on Windows. Perhaps a merge would be beneficial. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] MSVC 2010
On 18/01/11 15:35, Dominik Szczerba wrote: Hi, I am wondering if generator output support for Visual Studio 2010 is planned any time in the future? Currently only 2008 is supported (cmake 2.8.3) but the conversion offered by MSVC 2010 itself does not do its job correctly converting 2008 cmake outputs. It is already there: Visual Studio 10 http://cmake.org/cmake/help/cmake-2-8-docs.html#section_Generators Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] MSVC 2010
e CDT4 - Unix Makefiles = Generates Eclipse CDT 4.0 project files. Regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] MSVC 2010
On 18/01/11 16:15, David Cole wrote: Your confusion is that you are looking for a "2010" -- there isn't one -- there is "Visual Studio 10" David, This is indeed a mess in CMake. There is no such product as Visual Studio 10. Also, there is no Microsoft product named "Visual Studio .NET 2005". I reported it long time ago: http://vtk.org/Bug/view.php?id=10158 Trivial, but confusing and should be fixed, IMO Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] MSVC 2010
On 18/01/11 18:07, Hendrik Sattler wrote: Am Dienstag 18 Januar 2011, 19:02:15 schrieb Hendrik Sattler: Am Dienstag 18 Januar 2011, 18:05:50 schrieb Mateusz Loskot: On 18/01/11 16:15, David Cole wrote: Your confusion is that you are looking for a "2010" -- there isn't one -- there is "Visual Studio 10" David, This is indeed a mess in CMake. There is no such product as Visual Studio 10. Also, there is no Microsoft product named "Visual Studio .NET 2005". 10.4 million google hits, some on microsoft.com (although I wouldn't take that page as proper history indication), tell something different. We must be using different Google then. There are Visual Studio .NET 2002 Visual Studio .NET 2003 and Visual Studio 2005 but not Visual Studio .NET 2005 Microsoft officially dropped the.NET with Visual Studio 2005. I don' think all those authors invented the same name by accident. What I meant to say: the .NET in the name is not important, being it the official product name or not. 7/8/9/10 or [.NET] 2003/2005/2008/2010, who cares. I do. Users who get confused, they also care, but perhaps indirectly. Imprecise and misinforming documentation is a mess and there is no "after all" at all. What to attach any philosophy to misuse of names for? It is simpler to fix it than debating if it's pointless or not. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] FindThreads in quiet mode
Hi, Is there any way to use FindThreads in quiet mode without hacking the script itself? In my configuration, I use all Find* modules in quiet mode and only the FindThreads makes noise: -- Looking for include files CMAKE_HAVE_PTHREAD_H -- Looking for include files CMAKE_HAVE_PTHREAD_H - found -- Looking for pthread_create in pthreads -- Looking for pthread_create in pthreads - not found -- Looking for pthread_create in pthread -- Looking for pthread_create in pthread - found -- Found Threads: TRUE Any workaround possible? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Add BUILD_SHARED_LIBS as an option
Hi, The docs [1] say: "This variable [BUILD_SHARED_LIBS] is often added to projects as an option()" [1] https://cmake.org/cmake/help/latest/variable/BUILD_SHARED_LIBS.html Does that literally mean adding the option this way? option(BUILD_SHARED_LIBS "Build shared library" OFF) Or, adding an extra level of indirection via custom option: option(XXX_BUILD_SHARED "Build shared library" OFF) if (XXX_BUILD_SHARED) set(BUILD_SHARED_LIBS ON) endif() I do realise it's question about docs pedantism, but I'd like to get that cleared once for good :) I'm trying to cut number of custom options and I'm never certain how I can actually re/ab-use the standard CMake settings. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net -- 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] [Windows] clang-cl.exe detected as MSVC?
Hi,
I'm building a project with CMake 3.9 using clang-cl.exe driver [1]
from LLVM/clang 4.0 enabled with Visual Studio 2015 environment.
CMake detects the compiler as Clang 4.0.0:
-- The C compiler identification is Clang 4.0.0
-- The CXX compiler identification is Clang 4.0.0
-- Check for working C compiler: C:/Program Files/LLVM/bin/clang-cl.exe
-- Check for working C compiler: C:/Program Files/LLVM/bin/clang-cl.exe -- works
and my project builds fine.
In my CMakeLists.txt, there is this flags update:
if(MSVC)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /MP")
endif()
and in build log I see:
clang-cl.exe: warning: argument unused during compilation: '/MP'
I have double-checked and MSVC is defined and set True for clang-cl.exe.
Is this correct?
Is clang-cl.exe driver considered to be "when using Microsoft Visual C++" [2]
[1] https://clang.llvm.org/docs/UsersManual.html#clang-cl
[2] https://cmake.org/cmake/help/v3.9/variable/MSVC.html
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
--
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] [Windows] clang-cl.exe detected as MSVC?
On 11 September 2017 at 17:04, Konstantin Tokarev wrote:
> 11.09.2017, 17:59, "Mateusz Loskot" :
>> Hi,
>>
>> I'm building a project with CMake 3.9 using clang-cl.exe driver [1]
>> from LLVM/clang 4.0 enabled with Visual Studio 2015 environment.
>>
>> CMake detects the compiler as Clang 4.0.0:
>>
>> -- The C compiler identification is Clang 4.0.0
>> -- The CXX compiler identification is Clang 4.0.0
>> -- Check for working C compiler: C:/Program Files/LLVM/bin/clang-cl.exe
>> -- Check for working C compiler: C:/Program Files/LLVM/bin/clang-cl.exe --
>> works
>>
>> and my project builds fine.
>>
>> In my CMakeLists.txt, there is this flags update:
>>
>> if(MSVC)
>> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /MP")
>> endif()
>>
>> and in build log I see:
>>
>> clang-cl.exe: warning: argument unused during compilation: '/MP'
>>
>> I have double-checked and MSVC is defined and set True for clang-cl.exe.
>>
>> Is this correct?
>
> Yes. clang-cl is mostly compatible with MSVC on the command line
Mostly, or less or more, it's subjective and my experience show it is not
as compatible as one may expect.
Also, AFAIU, compatibility is only at driver level that is command
line interface.
> so it's natural that MSVC code in existing projects is applied to clang-cl
> too.
I'd rather expect CL.exe exclusively considered as CL.exe
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
--
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] [Windows] clang-cl.exe detected as MSVC?
On 12 September 2017 at 14:53, Konstantin Tokarev wrote:
> 11.09.2017, 18:12, "Mateusz Loskot" :
>> On 11 September 2017 at 17:04, Konstantin Tokarev wrote:
>>> 11.09.2017, 17:59, "Mateusz Loskot" :
>>>>
>>>> I'm building a project with CMake 3.9 using clang-cl.exe driver [1]
>>>> from LLVM/clang 4.0 enabled with Visual Studio 2015 environment.
>>>>
>>>> CMake detects the compiler as Clang 4.0.0:
>>>>
>>>> -- The C compiler identification is Clang 4.0.0
>>>> -- The CXX compiler identification is Clang 4.0.0
>>>> -- Check for working C compiler: C:/Program Files/LLVM/bin/clang-cl.exe
>>>> -- Check for working C compiler: C:/Program Files/LLVM/bin/clang-cl.exe
>>>> -- works
>>>>
>>>> and my project builds fine.
>>>>
>>>> In my CMakeLists.txt, there is this flags update:
>>>>
>>>> if(MSVC)
>>>>set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /MP")
>>>> endif()
>>>>
>>>> and in build log I see:
>>>>
>>>> clang-cl.exe: warning: argument unused during compilation: '/MP'
>>>>
>>>> I have double-checked and MSVC is defined and set True for clang-cl.exe.
>>>>
>>>> Is this correct?
>>>
>>> Yes. clang-cl is mostly compatible with MSVC on the command line
>>
>> Mostly, or less or more, it's subjective and my experience show it is not
>> as compatible as one may expect.
>> Also, AFAIU, compatibility is only at driver level that is command
>> line interface.
>>
>>> so it's natural that MSVC code in existing projects is applied to clang-cl
>>> too.
>>
>> I'd rather expect CL.exe exclusively considered as CL.exe
>
> For fine-grained distinction you have CMAKE_CXX_COMPILER_ID
I'll switch over to that one. Thanks
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
--
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] CMakeLists.txt location
On 13 September 2017 at 12:49, Nils Gladitz wrote: > On 13.09.2017 12:22, Alain Miniussi wrote: >> On 13/09/2017 11:16, Nils Gladitz wrote: >>> On 13.09.2017 10:52, Alain Miniussi wrote: >>>> >>>> Is there a way, when printing CMake error, to get the exact location of >>>> the CMakeLists.txt ? >>>> >>>> For example, right now, when I have: >>>> >>>> CMake Error at CMakeLists.txt:14 (add_executable): >>>> >>>> I need to scan all my CMakeLists.txt (~200) to check which one has >>>> add_executable at line 14. >>> >>> >>> CMake includes the (relative to the root source directory) path for me >>> e.g.: >>> CMake Error at Source/CMakeLists.txt:4 (add_executable): >> >> Well, it never did for me: >> $grep add_executable CMakeLists.txt >> $ > > Do you have a minimal reproducible example for that behaviour? > > e.g. given: > >cmake_minimum_required(VERSION 2.8.0) > project(Foo NONE) > file(WRITE foo/CMakeLists.txt "add_executable()") > add_subdirectory(foo) > > I get: > > CMake Error at foo/CMakeLists.txt:1 (add_executable): > add_executable called with incorrect number of arguments I can confirm this works with cmake version 3.9.0 on Windows 10 D:\tmp\cmake-location\build>cmake .. -- Building for: Visual Studio 15 2017 CMake Error at foo/CMakeLists.txt:1 (add_executable): add_executable called with incorrect number of arguments -- Configuring incomplete, errors occurred! See also "D:/tmp/cmake-location/build/CMakeFiles/CMakeOutput.log". Best regards, -- Mateusz Loskot, http://mateusz.loskot.net -- 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] To quote (path) variables or not, and everywhere?
Hi,
A user of one of projects I maintain pointed out that according to
CMake guidelines [1] all variables with strings (also paths) should be
quoted, ie.
include_directories(${SOCI_SOURCE_DIR}/core)
should read
include_directories("${SOCI_SOURCE_DIR}/core")
Is that so?
What is the current CMake recommendation?
Some other guidelines [2] suggest rule of thumb when using
variables in COMMAND calls:
Use quotes for the arguments that contain file paths
Does this apply to include_directories. set_target_properties, etc.?
I found "Paths with spaces - Visual Studio" [3] post which reports a
problem with not quoted paths but David Cole's recommendation [4]
uses add_library with path not quoted.
I sense, the answer to quote or not to quote might depend on
which CMake command is used.
Could anyone tell what is the current recommendation?
[1]
https://cmake.org/Wiki/CMake/Language_Syntax#CMake_splits_arguments_unless_you_use_quotation_marks_or_escapes.
[2] https://stackoverflow.com/a/35853080/151641
[3] https://public.kitware.com/pipermail/cmake/2012-July/051138.html
[4] https://public.kitware.com/pipermail/cmake/2012-July/051139.html
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
--
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] To quote (path) variables or not, and everywhere?
On 25 September 2017 at 12:57, Oleksii Vilchanskyi wrote: > As usually with CMake, there are no recommendations/guidelines. So, cases with the ammo for CMake sceptics and opponents are not empty, yet. Pity. > However, here's my logic: > > 1) if it's a path, always quote it > 2) if it's not a pat, but inside an if() or any similar core language > structure, quote it as well > 3) don't quote only if you're sure the string can't have spaces - otherwise > do quote > 4) quoting is free and doesn't hurt That sounds reasonable. Thank you. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net -- 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] To quote (path) variables or not, and everywhere?
On 25 September 2017 at 16:58, Miller Henry wrote:
> To add fuel to this, I like to argue that paths should not be quoted if at
> all possible.
I agree.
> I find that in many cases where a path is quoted those quotes are being done
> to
> work around a bad project structure and you can reorganize your project to
> get rid of the need for quotes.
What if (Windows) user runs cmake inside
c:\my awesome projects\one-superb\build
and there is xxx_command(${CMAKE_SOURCE_DIR})
I find lack of CMake standarised conventions and idioms a mistake,
softly saying.
Best regards
--
Mateusz Loskot, http://mateusz.loskot.net
--
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] To quote (path) variables or not, and everywhere?
On 25 September 2017 at 18:40, Zan Lynx wrote:
> On 09/25/2017 10:15 AM, Mateusz Loskot wrote:
>> What if (Windows) user runs cmake inside
>>
>> c:\my awesome projects\one-superb\build
>>
>> and there is xxx_command(${CMAKE_SOURCE_DIR})
>
> Indeed.
>
> In my opinion, if software cannot handle arbitrary path names which
> contain anything then that software is broken.
This is no good.
As CMake advocate, I've noticed traces of disappointment accumulated
over the years. In CMake 2 times, that was a small pill to swallow.
In CMake 3.9, it's very frustrating.
Idioms, conventions, PEP kind of papers, whatever is a must.
Niall Douglas crafted a quick CMake'ification demo for Boost [1] and
from the short README one can learn more about **how** to properly
develop a good build setup with CMake than from the CMake documentation.
[1] https://github.com/ned14/boost-bmv-cmake
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
--
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_GENERATOR_INSTANCE with absolute path to Visual Studio instance
Hi, I've just learned that CMake 3.11 solves the issue of selecting particular Visual Studio 2017 instance via CMAKE_GENERATOR_INSTANCE. This is good news and thank you for this improvement. I, however, am not entirely clear what the docs [2] mean by "The CMAKE_GENERATOR_INSTANCE variable may be set as a cache entry containing the absolute path to a Visual Studio instance." Is this supposed to be set with one of installationPath values as by vswhere [3] C:\> vswhere -all -prerelease -property installationPath C:\Program Files (x86)\Microsoft Visual Studio\Preview\Professional C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional [1] https://gitlab.kitware.com/cmake/cmake/commit/9ffb35386fb923a5959eec482bfa131aa3feaa18 [2] https://cmake.org/cmake/help/v3.11/generator/Visual Studio 15 2017.html [3] https://github.com/Microsoft/vswhere Best regards, -- Mateusz Loskot, http://mateusz.loskot.net -- 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] Generator for Visual Studio Code (Ubuntu)
On 19 March 2018 at 11:51, Richard Frank wrote: > Yes I have that plugin. But for more complex build systems that build > multiple products, running CMake from a shell script, I wondered what > generator would be used, FWIW, there no such thing as CMake generator for "Visual Studio Code". VSCode is generator-agnostic. For current list of generators, refer to the CMake docs. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net -- 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] Generator for Visual Studio Code (Ubuntu)
(you missed to reply to the mailing list!) On 19 March 2018 at 11:58, Richard Frank wrote: > Ok fair enough. So. I can output Unix make files and VS code can load those? Yes. If you have read the vscode-cmake extension docs https://vector-of-bool.github.io/, you would have seen that there is no generator required, you can choose. Consider another example: if you use Visual Studio 2017 with its CMake integration [1], you don't have to limit yourself to VisualStudio/MSBuild generator just becasue you use CMake inside Visual Studio. You can use Ninja too. [1] https://blogs.msdn.microsoft.com/vcblog/2016/10/05/cmake-support-in-visual-studio/ Best regards, -- Mateusz Loskot, http://mateusz.loskot.net -- 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] [proposal] Support for modern CMake
Hi,
I've used CMake for a 10+ years now.
I'm not a newbie, but I still discover CMake awesomeness as well as its traps.
Now, I'm trying to catch up with the modern CMake party and
I obviously watched the famous Daniel Pfeifer's lecture [1] (I'm late, I know!)
I asked a simple question on #cmake at cpplang.slack.com:
Given
add_executable(app app.cpp)
target_link_libraries(app PRIVATE Boost::filesystem)
Is that correct to expect the myapp target is also configured with
all the corresponding ***include*** directories (ie. Boost headers location)?
Or, do I need to call anything else, like:
target_include_directories(app PRIVATE Boost::boost)
Then, I realised that the current CMake API is does not follow its own evolution
that happened recently leaving lots of room for semantical ambiguity.
In the 'old school' CMake, I would write:
target_link_libraries(app ${Boost_LIBRARIES})
target_include_directories(app ${Boost_INCLUDE_DIRS})
All is clear and explicit.
In the modern CMake, I write:
target_link_libraries(app Boost::system)
Is all equally clear here? No!
Why CMake does not follow its own evolution and does not
update its API with **new** commands to support the modern CMake?
Why I can not write:
target_use(app Boost::system Boost::filesystem)
or
target_use_targets(app Boost::system Boost::filesystem)
and, actually read and understand what I'm doing?
(If you're now typing "why don't you create a custom macro wrapper"
response, please don't!)
How nicely it would fit into the concept of CMake member functions
presented by Daniel [1] (@17:25 min), wouldn't it?
Disclaimer: Originally, the idea came from Colby Pike [2] who suggested [3]
use_targets(app Boost::system)
and I just renamed it to fit in the Daniel's concept of looking at CMake API
as OOP, that is OOP like in C in GTK+ :), of course.
[1] https://twitter.com/mloskot/status/973914895287713793
[2] https://github.com/vector-of-bool/vscode-cmake-tools
[3] https://cpplang.slack.com/archives/C5Y2GDECX/p152122705490
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
--
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] [proposal] Support for modern CMake
On 20 March 2018 at 21:52, Alexander Neundorf wrote: > On 2018 M03 20, Tue 21:14:30 CET Mateusz Loskot wrote: > ... >> Why I can not write: >> >> target_use(app Boost::system Boost::filesystem) >> >> or >> >> target_use_targets(app Boost::system Boost::filesystem) >> >> and, actually read and understand what I'm doing? >> >> (If you're now typing "why don't you create a custom macro wrapper" >> response, please don't!) >> >> How nicely it would fit into the concept of CMake member functions >> presented by Daniel [1] (@17:25 min), wouldn't it? >> >> >> Disclaimer: Originally, the idea came from Colby Pike [2] who suggested [3] >> use_targets(app Boost::system) > > Not sure, I guess I was earlier ;-) Alex, please accept my apologies. I should have used s/Originally/I've learned about/ :) > You may want to have a look at > https://cmake.org/pipermail/cmake-developers/2012-December/017561.html > and the following discussion. I'm eager to have a look, thank you. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net -- 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] [proposal] Support for modern CMake
On 20 March 2018 at 21:52, Alexander Neundorf wrote: > On 2018 M03 20, Tue 21:14:30 CET Mateusz Loskot wrote: > ... >> Why I can not write: >> >> target_use(app Boost::system Boost::filesystem) >> >> or >> >> target_use_targets(app Boost::system Boost::filesystem) >> >> and, actually read and understand what I'm doing? >> >> (If you're now typing "why don't you create a custom macro wrapper" >> response, please don't!) >> >> How nicely it would fit into the concept of CMake member functions >> presented by Daniel [1] (@17:25 min), wouldn't it? >> >> >> Disclaimer: Originally, the idea came from Colby Pike [2] who suggested [3] >> use_targets(app Boost::system) > > Not sure, I guess I was earlier ;-) > You may want to have a look at > https://cmake.org/pipermail/cmake-developers/2012-December/017561.html > and the following discussion. It seems folks generally agree there is need for porcelain API. It's a pity it's been 5+ years and it is still waiting for implementation. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net -- 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] [proposal] Support for modern CMake
On 22 March 2018 at 16:51, Brad King wrote: > On 03/22/2018 10:17 AM, Mateusz Loskot wrote: >> It seems folks generally agree there is need for porcelain API. >> It's a pity it's been 5+ years and it is still waiting for implementation. > > [...] > The main driving factor was compatibility with existing projects > using `target_link_libraries` at the time. I could have an argument to that... > In the end it was decided that the extra command would be redundant and > we proceeded with `tll()` only. I'd prefer not to have this debated > endlessly again. ...but I won't and I'll shut up then. Thank you for chiming in with the extra details. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net -- 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] find_package_handle_standard_args for target-only modules
Hi, When writing a new FindX.cmake module following the spirit of Modern CMake, that is without setting any X_LIBRARY and X_INCLUDE_DIR variables, what is the strategy regarding use of find_package_handle_standard_args? Shall I not use find_package_handle_standard_args at all? If yes, shall I set X_FOUND and issue any related messages myself? Shall I use it: find_package_handle_standard_args(X DEFAULT_MSG X_LIBRARY X_INCLUDE_DIR) and follow with unset(X_LIBRARY) unset(X_INCLUDE_DIR) annoying users of FindX.cmake Shall I simply forget the Modern CMake and set the legacy style variables? Or something else? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net -- 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] FindODBC: Add module to search for ODBC library (MR #2069)
Hi, I've proposed FindODBC.cmake module: https://gitlab.kitware.com/cmake/cmake/merge_requests/2069 I'll welcome any critique and review. The module does not set any public variables, but targets only. it still uses find_package_handle_standard_args and attempts to hide private variables. I posted related question earlier in https://cmake.org/pipermail/cmake/2018-May/067504.html I'd be interested to know if the technique used in the module is sound or if there is a better one recommended. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net -- 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] Approach to both shared and static lib (again, sorry)
On 19 May 2018 at 15:00, Elvis Stansvik wrote: > I know this has been asked before, but I've never seen a really > authoritative answer. > > Say I have a simple single-library project. > > The advise I've seen is to not pass SHARED or STATIC to the > add_library(..), but instead let the user pass > -DBUILD_SHARED_LIBS:BOOL=ON/OFF to build the library as either shared > or static. > > That's fine, but leads to packagers having to do ugly things like e.g: > > https://salsa.debian.org/hle/dlib/blob/master/debian/rules > > That is, do two separate configure/build/install, in order to get both > a shared and static version. IMHO, there is nothing ugly in this approach. Not every system allows (or recomments) to generate both, static and shared, from the same object files. Why not view static vs shared as the similar to 32 vs 64 bit? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net -- 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] Approach to both shared and static lib (again, sorry)
On 19 May 2018 at 22:16, Ray Donnelly wrote: > On Sat, May 19, 2018, 8:50 PM Mateusz Loskot wrote: >> On 19 May 2018 at 15:00, Elvis Stansvik wrote: >> > I know this has been asked before, but I've never seen a really >> > authoritative answer. >> > >> > Say I have a simple single-library project. >> > >> > The advise I've seen is to not pass SHARED or STATIC to the >> > add_library(..), but instead let the user pass >> > -DBUILD_SHARED_LIBS:BOOL=ON/OFF to build the library as either shared >> > or static. >> > >> > That's fine, but leads to packagers having to do ugly things like e.g: >> > >> > https://salsa.debian.org/hle/dlib/blob/master/debian/rules >> > >> > That is, do two separate configure/build/install, in order to get both >> > a shared and static version. >> >> IMHO, there is nothing ugly in this approach. >> Not every system allows (or recomments) to generate both, >> static and shared, from the same object files. >> Why not view static vs shared as the similar to 32 vs 64 bit? > > > Because they are different architectures that in many cases require > different compilers and in some cases different host machines to run on. > Static vs shared has none of these issues to contend with. Both, static and shared may use quite different compilation/linking, that is enough to treat them differently. Apparently, my point hasn't made it through. Nevermind. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net -- 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] Approach to both shared and static lib (again, sorry)
I understand your Mateusz Loskot, mate...@loskot.net (Sent from mobile) On Sat, 19 May 2018, 22:54 Ray Donnelly, wrote: > On Sat, May 19, 2018, 9:38 PM Mateusz Loskot wrote: > >> On 19 May 2018 at 22:16, Ray Donnelly wrote: >> > On Sat, May 19, 2018, 8:50 PM Mateusz Loskot >> wrote: >> >> On 19 May 2018 at 15:00, Elvis Stansvik >> wrote: >> >> > I know this has been asked before, but I've never seen a really >> >> > authoritative answer. >> >> > >> >> > Say I have a simple single-library project. >> >> > >> >> > The advise I've seen is to not pass SHARED or STATIC to the >> >> > add_library(..), but instead let the user pass >> >> > -DBUILD_SHARED_LIBS:BOOL=ON/OFF to build the library as either shared >> >> > or static. >> >> > >> >> > That's fine, but leads to packagers having to do ugly things like >> e.g: >> >> > >> >> > https://salsa.debian.org/hle/dlib/blob/master/debian/rules >> >> > >> >> > That is, do two separate configure/build/install, in order to get >> both >> >> > a shared and static version. >> >> >> >> IMHO, there is nothing ugly in this approach. >> >> Not every system allows (or recomments) to generate both, >> >> static and shared, from the same object files. >> >> Why not view static vs shared as the similar to 32 vs 64 bit? >> > >> > >> > Because they are different architectures that in many cases require >> > different compilers and in some cases different host machines to run on. >> > Static vs shared has none of these issues to contend with. >> >> Both, static and shared may use quite different compilation/linking, >> that is enough to treat them differently. >> Apparently, my point hasn't made it through. Nevermind. >> > > Yes of course they do but the tooling in and around cmake (including > things like pkg-config and libtool) support this already. All I am pushing > for is for parity between the main 3 OSes here so that users of cmake do > not have to implement ugly hacks purely due to this. > I understand. I just have learned to live with lacking of such parity in CMake. Look, CMake does not event abstract such a basic thing as filesystem case-sensitivity, for example find_package(protobuf) vs find_package(Protobuf) The former won't work on OS witch case-sensitive filesystem. Best regards, Mateusz Loskot -- 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] Approach to both shared and static lib (again, sorry)
Sorry for garbage in previous response. I top posted partial response and bottom-posted more completed one. Not easy to edit longish emails on mobile :) Mateusz Loskot, mate...@loskot.net (Sent from mobile) On Sun, 20 May 2018, 00:03 Mateusz Loskot, wrote: > I understand your > > Mateusz Loskot, mate...@loskot.net > (Sent from mobile) > > On Sat, 19 May 2018, 22:54 Ray Donnelly, wrote: > >> On Sat, May 19, 2018, 9:38 PM Mateusz Loskot wrote: >> >>> On 19 May 2018 at 22:16, Ray Donnelly wrote: >>> > On Sat, May 19, 2018, 8:50 PM Mateusz Loskot >>> wrote: >>> >> On 19 May 2018 at 15:00, Elvis Stansvik >>> wrote: >>> >> > I know this has been asked before, but I've never seen a really >>> >> > authoritative answer. >>> >> > >>> >> > Say I have a simple single-library project. >>> >> > >>> >> > The advise I've seen is to not pass SHARED or STATIC to the >>> >> > add_library(..), but instead let the user pass >>> >> > -DBUILD_SHARED_LIBS:BOOL=ON/OFF to build the library as either >>> shared >>> >> > or static. >>> >> > >>> >> > That's fine, but leads to packagers having to do ugly things like >>> e.g: >>> >> > >>> >> > https://salsa.debian.org/hle/dlib/blob/master/debian/rules >>> >> > >>> >> > That is, do two separate configure/build/install, in order to get >>> both >>> >> > a shared and static version. >>> >> >>> >> IMHO, there is nothing ugly in this approach. >>> >> Not every system allows (or recomments) to generate both, >>> >> static and shared, from the same object files. >>> >> Why not view static vs shared as the similar to 32 vs 64 bit? >>> > >>> > >>> > Because they are different architectures that in many cases require >>> > different compilers and in some cases different host machines to run >>> on. >>> > Static vs shared has none of these issues to contend with. >>> >>> Both, static and shared may use quite different compilation/linking, >>> that is enough to treat them differently. >>> Apparently, my point hasn't made it through. Nevermind. >>> >> >> Yes of course they do but the tooling in and around cmake (including >> things like pkg-config and libtool) support this already. All I am pushing >> for is for parity between the main 3 OSes here so that users of cmake do >> not have to implement ugly hacks purely due to this. >> > > > I understand. I just have learned to live with lacking of such parity in > CMake. > Look, CMake does not event abstract such a basic thing as filesystem > case-sensitivity, for example > > find_package(protobuf) > vs > find_package(Protobuf) > > The former won't work on OS witch case-sensitive filesystem. > > > > Best regards, > Mateusz Loskot > > > -- 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] Contribute Find-module to CMake vs Config-file to upstream
Hi, I've been recently trying to update/add Find-modules to CMake: updated FindJPEG, proposed FindODBC and most recently FindLZ4. Discussion during review of the FindLZ4 [1] ended with some surprising conclusions which I, as someone who relies on CMake and occacionally contributes to CMake, don't necessarily agree with. I'd like to share some of my thoughts. [1] https://gitlab.kitware.com/cmake/cmake/merge_requests/2087#note_412640 A bit of a extract from the brief discussion [1]: The FindLZ4 discussion basically ended with suggestion from Brad that, instead of adding Find-module to CMake, I should approach LZ4 project and add Config-file to the library itself. Then I argued taht Config-files are more complex and I don't feel like asking projects, which I don't maintain myself, to accept the extra complexity. Finally, Brad replied that CMake doesn't need LZ4 itself and yet for some reason is expected to know all about it: versions, headers, libraries, etc. and that it's not scalable to teach CMake about every project in the world. This opinion does not surprise me and I understand the rationale. I argue that CMake does need to know about every project in the world, or every project that CMake users wish to use, directly or indirectly. Without the knowledge CMake would simply be useless. I understand CMake maintainers try to shift the responsibility of recognising "every project in the world" away from the CMake itself as not scalable. Good approach to avoid need to scale up the maintenance efforts, but that is a bad news for CMake users. As a CMake user, I expect to be able to install CMake and get my dependencies recognised by CMake as CMake's responsibility I do not want to care if library A which I depend on is actually CMake-ignorant or not. I do not want to learn why library A does not support CMake, as often that is philosopical reason and asking about it ends up with a rough responses. (Imagine, there are libraries on GitHub which maintainers do not accept addition of ***non-intrusive*** single .travis.yml file, because they don't trust it.) If a library is strictly GNU Autoconf, I'm on lost position trying to convince maitnainers to accept CMake stuff and even if they do, they won't be willing to maintain it - broken Config-files may be deployed with new packages. That puts users of CMake and such library on lost position: CMake says no to Find-module, the library does not care either. As CMake user I don't want to be left to the discretion of package maintainers. Packages may ignore CMake Config-file existence. Packages of libraries which provide CMake and alternative build configurations may not deploy Config-files or Find-modules. IMHO, CMake should encourage contributions of new Find-modules. It does not contradict with the recommendation that Config-files should be preferred. Once a library that used to be searchable only via Find-module only receives Config-file, both approaches still can be available, no reason to remove the Find-module. The CMake's policy of preferring Config-file can still apply, there is no clash, it is just users now have choice. If a Find-module becomes outdated, it doesn't break anything else in CMake ecosystem but can be spotted and potential contributor may arrive with a fix. I want to contribute Find-module into a **central place** where I can easily access it as well as monitor its state and submit fixes if necessary. >From a contributor POV, that is much more effective than jumping between variety of issue trackers, creating new accounts for one time use or even sending patches via e-mails to maitnainers - not everything lives in GitHub yet. Since CMake is still de-facto a standard for building C++ software, from end-user POV the current situation feels almost like vendor lock-in. I call CMake to accept *any* Find-module, filtering only based on quality of CMake idiomatic scripting. If CMake does not want Find-* modules within the source tree, then - set up https://gitlab.kitware.com/cmake/find-modules - move all existing Find-modules in there - relax maintenance rules to accept *any* Find-module, provided --- CMake scripting is decent quality (e.g no community downvotes or rejecting reviews for period of quarantine) --- CI passing tests - finally, include the complete find-modules archive in the installer so it is deployed aside of CMake itself If CMake does not care about Find-modules, it should not care or should care about them equally - thus presence of such find-modules archive deployed should not affect the health of CMake installation and its pursue fo rFind-modules ignorance. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net -- 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 info
Re: [CMake] Contribute Find-module to CMake vs Config-file to upstream
On 22 May 2018 at 12:27, Johannes Zarl-Zierl wrote:
> On Montag, 21. Mai 2018 19:39:16 CEST Mateusz Loskot wrote:
>> The FindLZ4 discussion basically ended with suggestion from Brad that,
>> instead of adding Find-module to CMake, I should approach LZ4 project
>> and add Config-file to the library itself.
>> Then I argued taht Config-files are more complex and I don't feel like
>> asking projects, which I don't maintain myself, to accept the extra
>> complexity
>
> There's more that we (as CMake community) could do to make it easier for non-
> cmake projects to add a config file, and I think this is a worthwhile goal.
>
> Currently, if the maintainer of an autotools-based project is willing to add a
> cmake config file, he or she basically needs to be an expert on cmake. There's
> no official template or guide on how to create a cmake config file without
> relying
> on a cmake module to do the work.
Hi Johannes,
I can onl agree.
In fact, I called the Config-files approach complex partially due to lack of
easy to follow tutorial.
Partially due to beign too lazy to figure step-by-step procedure from
https://cmake.org/cmake/help/v3.11/manual/cmake-packages.7.html
> If there was a good guide, or maybe even some tooling, cmake config files
> would
> not be much more work for the maintainer as pkg-config files.
This should be no-brainer.
This should be no-brainer to such extend that for cases of canonical
configurations
CMake should generate all the required *-{config|version}.cmake
And, the CMake documentation should tell what to do, how to fix my
CMakeLists.txt
to make help CMake generate all the files.
>> I call CMake to accept *any* Find-module, filtering only based on
>> quality of CMake
>> idiomatic scripting.
>
> "Filtering based on quality" being the important part.
Idiomatic quality of CMake scripts is very important.
I've seen enough cases of CMake scripting abuse to finally
strive for some linting reflex and must-obey conentions.
Very recently, I've proposed FindODBC
https://gitlab.kitware.com/cmake/cmake/merge_requests/2069
A trivial script one may think, but look at number of review-refine iterations
it too me to improve it (acceptance is still pending).
Here, I would like to thank Brad King a ton.
He's patience to review, suggest where and how to improve
every tiniest detail is priceless.
Have a look at the discussion comments for the MR 2069,
learning outcome from that MR alone makes a substantial
CMake coding guide to me.
I do realise such help consumes a lot of Brad's time and
I do realise it might be one of reasons CMake may prefer to
avoid such heavy engagement of maintainers by 'outsource'
libraries look-up responsibility.
But, perhaps an easier solution would be to move things and relax requiremnets.
Il meglio è nemico del bene
I wish there was an official CMake coding guide.
(I'm hoping to collect my experience based on reviews of my
MR-s to FindJPEG, FindODBC and FindLZ4).
>> If CMake does not want Find-* modules within the source tree, then
>> - set up https://gitlab.kitware.com/cmake/find-modules
>> - move all existing Find-modules in there
>> - relax maintenance rules to accept *any* Find-module, provided
>> --- CMake scripting is decent quality (e.g no community downvotes or
>> rejecting reviews for period of quarantine)
>> --- CI passing tests
>> - finally, include the complete find-modules archive in the installer
>> so it is deployed
>>aside of CMake itself
>
> That seems like a reasonable way to deal with the situation. Maybe this would
> also encourage better quality of the (current) core find-modules. If you take
> a
> look at those, they are in wildly different shape regarding their quality.
Yes, I have noticed the low quality modules.
I am taking baby steps to improve them, at least in (library) areas of
my interest.
My initial story started with the simple premise:
- Find-modules are very useful "guessers"
- Find-modules are going to stay as they complement preferred Config-files
- CMake installs selection of Find-modules which should be allowed to expand
- CMake installs Find-modules of good and bad or broken quality
- CMake does not suffer directly from hosting bad quality Find-modules
- CMake should let the community propose and maintain Find-modules
- CMake should not care if a Find-module becomes outdated as it would
not suffer directly (as per previous points)
...
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
--
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.or
Re: [CMake] Contribute Find-module to CMake vs Config-file to upstream
On 22 May 2018 at 13:36, wrote: > On 2018-05-21 18:39, Mateusz Loskot wrote: >> >> I've been recently trying to update/add Find-modules to CMake: >> updated FindJPEG, proposed FindODBC and most recently FindLZ4. > […] >> >> The FindLZ4 discussion basically ended with suggestion from Brad that, >> instead of adding Find-module to CMake, I should approach LZ4 project >> and add Config-file to the library itself. >> Then I argued taht Config-files are more complex and I don't feel like >> asking projects, which I don't maintain myself, to accept the extra >> complexity. >> Finally, Brad replied that CMake doesn't need LZ4 itself and yet for some >> reason is expected to know all about it: versions, headers, libraries, >> etc. >> and that it's not scalable to teach CMake about every project in the >> world. > > > It really doesn't scale. I've contributed and provided ongoing fixes for a > few Find modules out of practical necessity, for projects which are > effectively incapable of adding a Config-file, either because the project > was stagnant with no new releases (Xerces, Xalan), or where the project was > so complex that it was effectively impossible to add (Boost). It does not matter if it scales. If there is enough interest within the community, Find-modules should be allowed and maintained. If they are not, they will stagnate. That will be the community choice. Still, it will not hurt CMake principles which already does not care. > However, that work should have been done by the upstream. > The ongoing maintenance cost > has been moved from the upstream development, where it belongs, to a > volunteer (me). It's work which I do because it provides value to me and my > employer so I can use CMake with the projects I work on, but is otherwise > unjustifiable. Regarding FindBoost.cmake, being a Boost user, as well as developer and maintainer of Boost libraries, I already know it is PITA. I, however, have learned FindBoost.cmake is always step behind and I have learned how to live with that. There have been discussions about how Boost could take ove FindBoost.cmake or provide Config-files, but it always ended with discussions about (too) clever automatic solutions, Boost.Build integrations, bla bla bla that literally no one is knowledgable enough or interested to maintain in long term - should read as "it's going to implode sooner or later anyway". To me, FindBoost.cmake works in majority of cases (perhaps not quite for 1.67 ;)) I know enough CMake scripting to be able to attempt to fix stuff. Better is enemy of good. I prefer good as good enough to get things done. Finally, Find-modules are just "guesser", they do not promise marksman-like operating to find every variant of every version of every library. Find-modules, however, should be there for most, even if lacking they can serve as useful basis to develop improved Find-modules, perhaps contribute it back. If there is not CMake-provided Find-module, then there is cultivation of chaos of mostly badly written Find-modules scattered caross GitHub (thanks the spirits GitHub provides usable search engine). > You simply can't expect every Find module to keep pace with > upstream development without a small army of volunteers to keep them all up > to date. The point is, I do not expect that. I have mentioned multiple times, Find-modules should be allowed to become outdated, awaiting for intersted volunteers to deliver necessary updates. But, Find-modules should be there regardless. > If they are provided with the upstream releases, they are de facto > always up to date because they are directly matched to the library. IMHO, that is a false expectation or perception. > Note that for several of these projects (e.g. Xerces, libtiff), I have > actually provided upstream CMake build systems which install Config-files, > so in the future the Find modules can be deprecated and users can move to > the Config-file as these releases make their way into distributions. Again, my point is, there is no need for deprecating Find-modules. CMake can automatically prefer Conig-files if present. CMake users can conciously prefer one or the other. Point being, there is choice and the choice is left to both sides, users as well as maintainers, including Find-modules maintainers. > That's semi-altruistic. I've spent a lot of effort up front to make CMake > infrastructure in these projects maintainable for the long term, and > something which can be delegated to others for ongoing maintenance. I do realise the hassle may be huge. Why not simply shift the way we think about Find-modules - let them in, without deprecating, and let them remain as fall-back (regardless if up-to-date, working or not). >> Thi
Re: [CMake] Contribute Find-module to CMake vs Config-file to upstream
On 23 May 2018 at 16:37, David Demelier wrote: > On Mon, 2018-05-21 at 19:39 +0200, Mateusz Loskot wrote: >> >> I've been recently trying to update/add Find-modules to CMake: >> updated FindJPEG, proposed FindODBC and most recently FindLZ4. >> >> Discussion during review of the FindLZ4 [1] ended with some >> surprising >> conclusions which I, as someone who relies on CMake and occacionally >> contributes to CMake, don't necessarily agree with. >> I'd like to share some of my thoughts. >> >> [1] https://gitlab.kitware.com/cmake/cmake/merge_requests/2087#note_4 >> 12640 >> >> A bit of a extract from the brief discussion [1]: >> >> The FindLZ4 discussion basically ended with suggestion from Brad >> that, >> instead of adding Find-module to CMake, I should approach LZ4 project >> and add Config-file to the library itself. > > Yes, that's the way to go. I hoped it will draw clear from my earlier thoughts that I consider discussion *if* CMake should encourage Find-modules as pointless, or at least off-topic here. We should be discussing not *if*, but *how* to keep Find-modules, enourage new ones, fix existing ones and make both Find-modules and Config-files coexist. Hence, I'm not going to address any of your points trying to convince me to give up my position. If I do, we will be making circles forever. >> Packages of libraries which provide CMake and alternative build >> configurations >> may not deploy Config-files or Find-modules. >> >> IMHO, CMake should encourage contributions of new Find-modules. > > No. Yes. > What if CMake 3.12 has a FindFooBar module shipped in your package > manager. But upstream decided to break everything? Change component > name, change library name? We won't have time to inspect all find > modules and update them *because* upstream decided to change. Nothing. That is already the case and nobody expects Find-modules are 100% solid across CMake X versions of libraries it can recognise. Find-modules are "guessers" and as such CMake does not give hard promises. That is already the case. I will repeat the premise points from earlier: - Find-modules are very useful "guessers" - CMake installs Find-modules of good and bad or broken quality (that is happening today!) - CMake does not suffer directly from hosting bad quality Find-modules - CMake should not care if a Find-module becomes outdated as it would not suffer directly (as per previous points) >> I want to contribute Find-module into a **central place** where I can >> easily >> access it as well as monitor its state and submit fixes if necessary. >> From a contributor POV, that is much more effective than jumping >> between >> variety of issue trackers, creating new accounts for one time use or >> even >> sending patches via e-mails to maitnainers - not everything lives in >> GitHub yet. >> >> Since CMake is still de-facto a standard for building C++ software, >> from end-user POV the current situation feels almost like vendor >> lock-in. >> >> I call CMake to accept *any* Find-module, filtering only based on >> quality of CMake >> idiomatic scripting. >> >> If CMake does not want Find-* modules within the source tree, then >> - set up https://gitlab.kitware.com/cmake/find-modules >> - move all existing Find-modules in there >> - relax maintenance rules to accept *any* Find-module, provided >> --- CMake scripting is decent quality (e.g no community downvotes or >> rejecting >> reviews for period of quarantine) >> --- CI passing tests >> - finally, include the complete find-modules archive in the installer >> so it is deployed >>aside of CMake itself > > This sounds like more of a reasonable proposal. CMake should by itself > not propose any Find* package anymore. A user-managed repository where > everyone could push their module could be a good idea (just like AUR, > PPA, copr, and such do for distribution packages) I'm glad we agree here. I'd like to see such bundle of Find-modules always installed by CMake. I'd like to see it hosted on gitlab.kitware.com I'd like to stick to some form of community-powered dictatorship to ensure minimum quality. If there is not enough community to maintain it and keep modules up to date that is fine - single high quality but outdated FindX.cmake is worth a ton more than dozen shitty FindX.cmake dangling on GitHub. CMake scripting lazyness should be kapt away from gitlab.kitware.com/cmake-find-modules. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net -- Powered by www.kitware.com Please keep messages on-topic and check the CMak
Re: [CMake] Contribute Find-module to CMake vs Config-file to upstream
On 24 May 2018 at 08:45, Elvis Stansvik wrote: > Den ons 23 maj 2018 17:18Mateusz Loskot skrev: >> On 23 May 2018 at 16:37, David Demelier wrote: >> > On Mon, 2018-05-21 at 19:39 +0200, Mateusz Loskot wrote: >> >> >> >> >> >> IMHO, CMake should encourage contributions of new Find-modules. >> > >> > No. >> >> Yes. > > > As for my part, I'll just have to agree to disagree with this. > [...] > But I think CMake has grown so much by > now, and has such leverage (people generally are not opposed to being "CMake > compatible"), that efforts are better spent making it easy to write config > files, and supporting initiatives like that cps thing. Those will take years to get into production state for CMake. Find-modules can solve issues now, without "want to drive? build your own car first" appraoch, but basic CMake scripting knowledge. I'm very supportive to the cps, but I can not help it move forward. I, however, can help updating/adding Find-modules. > I also don't agree that it doesn't hurt CMake to have a growing number of > outdated find modules. It leads to a lot of bug reports. In the times of GitHub-like pace of development, we should really learn to use https://github.com/apps/stale or equivalents. > If it's there, people will expect it to work, and when it doesn't they become > disappointed. > If it wasn't there from the beginning there's no expectation. There is nothing wrong with it, as long as status of Find-modules is clearly stated in the documentation and users learn correctly what Find-modules are - guessers about future without promises, not configurators about present state. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net -- 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] Development Workflow with CMake and VS2017
I recommend vcpkg and Conan. You may check Boost.GIL configuration for CMake that uses both as alternatives. Conan can automatically pulls libpng etc. https://github.com/boostorg/gil Mateusz Loskot, mate...@loskot.net (Sent from mobile) On Sun, 15 Jul 2018, 09:44 Dvir Yitzchaki, wrote: > I recommend using Hunter package manager: > > https://docs.hunter.sh/en/latest/quick-start/boost-components.html > > > > It has support for FreeType as well: > > https://docs.hunter.sh/en/latest/packages/pkg/freetype.html > > > > Regards, > > Dvir > > > > -Original Message- > From: CMake On Behalf Of Innokentiy Alaytsev > Sent: Thursday, July 12, 2018 21:44 > To: cmake@cmake.org > Subject: Re: [CMake] Development Workflow with CMake and VS2017 > > > > Hello! > > > > I usually just download prebuild binaries if they are available or build > the required dependency from sources. There are some libraries (and other > > software) that are not Windows-friendly (These products are still > considered cross-platform and usually are free in the way fanatics from FSF > understand freedom, i.e. freedom is the thing that should be enforced). In > the case where it is impossible or hard to build something on Windows with > MSVC, I try to find some alternative. > > > > The reason for trying to build everything with MSVC is simple - > unfortunately, it is the official compiler for the platform and some things > can only be built with it for Windows. > > > > Sticking to Cygwin or MSYS2 may be fine unless you need some things like > Qt with WebEngine support or, probably, CUDA (I am not sure if it > officially works with anything else but MSVC). > > > > > > > > -- > > Sent from: http://cmake.3232098.n2.nabble.com/ > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > https://cmake.org/mailman/listinfo/cmake > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Boost + CMake + Windows + Sanity -> Possible?
On 7 August 2018 at 18:15, Wheeler, Gavin wrote:
> [...]
> 1. Look in C:\Program
> Files\CMake\share\cmake-3.9\Modules\FindBoost.cmake
Rule #1: never use CMake older than the latest release!
Rule #2: if you die hard for old CMake, force use of the latest FindBoost.cmake
if (CMAKE_VERSION VERSION_LESS 3.12)
if (NOT EXISTS "${CMAKE_BINARY_DIR}/cmake/FindBoost.cmake")
message(STATUS "You are using CMake older than 3.10")
message(STATUS "FindBoost.cmake has likely been updated to detect
newer or even not yet released Boost")
message(STATUS "Downloading FindBoost.cmake from
https://gitlab.kitware.com/cmake/ release branch")
message(STATUS "The auto-download can be disabled with
GIL_DISABLE_FINDBOOST_DOWNLOAD=ON")
file(DOWNLOAD
"https://gitlab.kitware.com/cmake/cmake/raw/release/Modules/FindBoost.cmake";
"${CMAKE_BINARY_DIR}/cmake/FindBoost.cmake")
endif()
list(INSERT CMAKE_MODULE_PATH 0 ${CMAKE_BINARY_DIR}/cmake)
endif()
The rules work most of the time, unless a lil' bug sneaks in eg.
https://gitlab.kitware.com/cmake/cmake/merge_requests/1731
https://gitlab.kitware.com/cmake/cmake/issues/17701
Remember, FindBoost.cmake is *always* a step or two behind CMake release.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
--
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] Output run-time files to single directory
Hi, I'm using CMake 2.6 on Linux and Windows. I'm migrating a not-so-big project from autotools to CMake, for both Linux (GCC) and Window (MSVC). The structure is simple: proj/ proj/src - build as shared and static libs proj/app - executables linking to shared and static libs On Linux, everything works very well as expected mkdir build cd build cmake ../proj make Libraries go to build/src and programs to build/app. I can go to build/app and run ./program and everything works well. No need to call ''make install', because: build/app$ ldd ./prog1 libxxx.so => /home/mloskot/build/src/libxxx.so On Windows with Visual Studio it doesn't work that nice, of course. I get similar structure of build directory and files are scattered in similar way (+ Debug vs Release subdirectory). In order to run app/prog1 that needs to load src/xxx.dll, I need to set PATH environment, of course. I would like to configure Visual Studio projects (using CMake of course) to output all runtime elements (.exe and .dll) into common directory, for instance build/bin/debug and build/bin/release. I tried to fiddle about RUNTIME_OUTPUT_DIRECTORY property but I apparently don't know how to use it. Another and related question I have is about setting Debugging -> Environment property in Visual Studio project. It is file with user specific settings (*.vcproj.*.user file). By pointing all runtime dependencies using Environment and PATH, it is possible to run program inside Visual Studio. Simply, in many cases, I build and link my projects against various 3rd-party libraries from different locations and it is easier to set PATH in Visual Studio project settings than in the system-wide environment. So, I found this: http://stackoverflow.com/questions/1005901/how-to-set-path-environment-variable-using-cmake-and-visual-studio-to-run-test and I've managed (almost) to achieve what I need using the presented UserTemplate.vcproj trick. However, perhaps it is possible to achieve this using some nice features from CMake 2.6 or CMake 2.8 ? Thank you in advance for your help. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Why FindBoost messaging not unified?
Hi, I'm using CMake 2.6-patch2 on Linux (Ubuntu 9.04). In my opinion FindBoost does not follow somewhat standard behaviour of other CMake macros (i.e. ZLIB). In my project I call FIND_PACKAGE this way: IF(WITH_ZLIB) FIND_PACKAGE(ZLIB) ENDIF() and here are output variants I get and I expect: 1. Zlib not requested $ cmake ../source ... and no verbose message if Zlib was found or not. 2. Zlib requested but missing, so error reported: $ cmake ../source -DWITH_ZLIB=ON ... -- Could NOT find ZLIB (missing: ZLIB_INCLUDE_DIR) 2. Zlib requested and found, so success reported: $ cmake ../source -DWITH_ZLIB=ON ... -- Found ZLIB: /usr/lib/libz.so I try to follow the same procedure with Boost using FindBoost IF(WITH_ZLIB) FIND_PACKAGE(Boost 1.35) ENDIF() 1. I have 1.35 version installed and I see message about success: mlos...@dog:~/proj$ cmake ../main -DWITH_BOOST=ON ... -- Boost version: 1.35.0 -- Found the following Boost libraries: 2. I have no 1.38 version installed but I ask for Boost 1.38, so I would expect to see some message, but I get "silence": mlos...@dog:~/proj$ cmake ../main -DWITH_BOOST=ON -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Configuring done -- Generating done -- Build files have been written to: /home/mloskot/proj 3. The only way to get error is to explicitly use REQUIRED option FIND_PACKAGE(Boost 1.36 REQUIRED) but for FIND_PACKAGE(ZLIB) as explained in point 2. above it is not necessary to explicitly specify REQUIRED option and error is printed. I tested the original version of FindBoost from CMake 2.6 as well as today version from CVS. No difference regarding this issue. I used ZLIB as example but most of FindXXX macros work this way, In my opinion behaviours of FindBoost is inconsistent in comparison to other standard macros. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Output run-time files to single directory
Michael Jackson wrote:
> # -- Setup output Directories -
> SET (CMAKE_LIBRARY_OUTPUT_DIRECTORY
> ${PROJECT_BINARY_DIR}/Bin )
>
> # - Setup the Executable output Directory -
> SET (CMAKE_RUNTIME_OUTPUT_DIRECTORY
> ${PROJECT_BINARY_DIR}/Bin )
>
> # - Setup the Executable output Directory -
> SET (CMAKE_ARCHIVE_OUTPUT_DIRECTORY
> ${PROJECT_BINARY_DIR}/Bin )
>
>
> Put that in the top most CMakelists.txt file
Michael,
Thank you for the quick solution.
It is exactly what I was looking for.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CTest - C Unit Testing Framework
Dixon, Shane wrote: I’m using CMake for all of my building. Currently I’m just working on Windows XP, but I’d like to leave things open for Linux builds in the near future. Any suggestions on the best testing framework for a C project that will be cross-platform compatible and I can use it with Windows and Linux? I’d like something that works well with CTest. (i.e. a command-line interface is probably ideal). I looked at cfix, but that seems Windows specific. The CUnit project looks like it hasn’t been updated in a long time. Any suggestions? Perhaps it's off-topic, as these are C++ test frameworks, not C, however I can truly recommend: - TUT: C++ Template Unit Test Framework - very lightweight and powerful - Boost UTF - much more featured, proper framework, but big. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Why FindBoost messaging not unified?
Philip Lowman wrote: > On Tue, Sep 29, 2009 at 6:04 PM, Mateusz Loskot wrote: > >> 3. The only way to get error is to explicitly use REQUIRED option >> >> FIND_PACKAGE(Boost 1.36 REQUIRED) >> >> but for FIND_PACKAGE(ZLIB) as explained in point 2. above >> it is not necessary to explicitly specify REQUIRED option >> and error is printed. >> >> I tested the original version of FindBoost from CMake 2.6 as well as >> today version from CVS. No difference regarding this issue. >> >> I used ZLIB as example but most of FindXXX macros work this way, >> >> In my opinion behaviours of FindBoost is inconsistent in comparison >> to other standard macros. >> > > Mateusz, > > You're right, this is inconsistent. I've just fixed FindBoost in CVS to > output the following to STATUS if Boost is not found: > > -- Could NOT find Boost Philip, Thank you for improving. > I also added an option which if enabled outputs the more detailed error > message (outputted in REQUIRED mode) below this line. Great. > If you have any other CMake related suggestions please feel free to > accompany your mailing list posts with a feature request and/or patch on the > bugtracker if you have the time. > > http://public.kitware.com/cgi-bin/viewcvs.cgi/Modules/FindBoost.cmake?root=CMake&view=log Sure, I'll use it next time. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Targets organisation of complex project
Hi, Me and my friend, we are porting build configuration of quite complex project (http://trac.osgeo.org/gdal/) from hand-written makefiles (with partial support autotools) to CMake. The sources are organised in large number of subdirectories and sort of logical sub-libraries, but the binary output of compilation is a single library. Trying to figure out how to organise targets I got an idea to configure these sub-libraries as static library targets (e.g. libgdal_cpl, libgdal_alg, libgdal_gcore, etc.) which eventually link to single shared library (libgdal.so). Learning CMake best practices, I stepped across an interesting thread: "build a shared library from static libraries" http://www.cmake.org/pipermail/cmake/2008-March/020315.html It actually smashed my original idea :-) It looks like the best portable approach is to walk through the whole tree of project, collect all .c and .cpp files (assigning list of files to global variables) and, back in the main CMakeLists.txt, stream all source files to single ADD_LIBRARY call. Is that the best option? What would be best way to configure such complex source tree that outputs single library? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Targets organisation of complex project
Tyler Roscoe wrote: > On Sun, Oct 11, 2009 at 08:41:27PM +0100, Mateusz Loskot wrote: >> The sources are organised in large number of subdirectories and >> sort of logical sub-libraries, but the binary output of compilation >> is a single library. > [snip] >> It looks like the best portable approach is to walk through the whole >> tree of project, collect all .c and .cpp files (assigning list of files >> to global variables) and, back in the main CMakeLists.txt, stream all >> source files to single ADD_LIBRARY call. > > This is what I would do. IME, CMake works best when you do the simplest > thing that can possibly work. I agree, but there may be some tricks lurking. For example, does CMake promise to handle well situation when two source files with the same name but in different locations are used in common ADD_LIBRARY call, like here: ADD_LIBRARY(mylib abc/algorithm.cpp xyz/algorithm.cpp) Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Targets organisation of complex project
Philip Lowman wrote:
> On Sun, Oct 11, 2009 at 9:01 PM, Tyler Roscoe wrote:
>
>> On Sun, Oct 11, 2009 at 08:41:27PM +0100, Mateusz Loskot wrote:
>>> The sources are organised in large number of subdirectories and
>>> sort of logical sub-libraries, but the binary output of compilation
>>> is a single library.
>> [snip]
>>> It looks like the best portable approach is to walk through the whole
>>> tree of project, collect all .c and .cpp files (assigning list of files
>>> to global variables) and, back in the main CMakeLists.txt, stream all
>>> source files to single ADD_LIBRARY call.
>> This is what I would do. IME, CMake works best when you do the simplest
>> thing that can possibly work.
>>
>
> I would do what makes sense in terms of the end user. If those separate
> subdirectories are meant to be separate libraries, then build separate
> libraries. If the source code is scattered across multiple subdirectories
> but is all supposed to be part of the same library then build it together.
The case here is the latter one. Single library is the only reasonable
output of the build of our project.
> You can use PARENT_SCOPE to hand lists of source files up a directory, if
> that is of interest.
> set(FOO_SRCS ${list_of_sources} PARENT_SCOPE)
Thanks for the hint. I'll learn more about this.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] [OT] Re: Targets organisation of complex project
Chris Foster wrote: > @ Philip: Apologies for the double mail, I'm unused to mailing lists > which require an explicit reply to the list :-/ Chris, I always hit Reply To All, and let the mailman to handle it so nobody receives duplicates. It usually works for mailman, I hope it works with cmake.org too. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Fwd: Targets organisation of complex project
Hi Chris, Yes, but no problem at all. Thank you very much for all the details, they are very helpful. Your approach looks good for our project, but letting myself to learn more ideas like the one project.cmake vs CMakeLists.txt by Pau Garcia. Mat Chris Foster wrote: > [ Ugh, I replied to this as a private message to Mateusz by mistake. > I'm forwarding it to the list as I hope it may be of general interest. Sorry! > ] > > > -- Forwarded message -- > From: Chris Foster > Date: Mon, Oct 12, 2009 at 9:18 AM > Subject: Re: [CMake] Targets organisation of complex project > To: Mateusz Loskot > > > Hi Mateusz, > > On Mon, Oct 12, 2009 at 5:41 AM, Mateusz Loskot wrote: >> The sources are organised in large number of subdirectories and >> sort of logical sub-libraries, but the binary output of compilation >> is a single library. >> >> Trying to figure out how to organise targets I got an idea to >> configure these sub-libraries as static library targets >> (e.g. libgdal_cpl, libgdal_alg, libgdal_gcore, etc.) which >> eventually link to single shared library (libgdal.so). > > As you've seen, doing this won't work in many cases :-( > > I've grappled with the same problem recently when rewriting the build system > for the aqsis renderer project. I certainly don't know what's *best*, but I > did find a solution which somewhat satisfied me. Let's suppose we have two > individual subdirectories, libA and libB, and we want to combine them > together. > > Here's how I have laid that kind of thing out in aqsis: > > src/ >CMakeLists.txt >libA/ >project.cmake >... lots of source >libB/ >project.cmake >... lots of source > > The idea is to define a file (arbitrarily named "project.cmake" in my system) > in the individual library directories which defines variables corresponding to > the library source. The main CMakeLists.txt then include()s these files, > makes a source list from all the individual sources, and uses those in an > add_library command to create the final library. I wrote some macros to > automate the inclusion process a little better so that the project.cmake files > were a bit like what you'd normally write in a CMakeLists.txt. > > The system has some remaining shortcomings - in particular the project.cmake > files still look more different from a plain CMakeLists.txt than I'd like - > but perhaps it can give you some ideas. You can browse the aqsis source tree > online at > > http://aqsis.git.sourceforge.net/git/gitweb.cgi?p=aqsis/aqsis;a=tree > > If you're interested, I would suggest you look at the file > libs/core/CMakeLists.txt and the project.cmake files in the subdirectories of > libs/core/. Here's an overview of the relevant directory structure: > > libs/core/ >CMakeLists.txt >api/ >project.cmake >ddmanager/ >project.cmake >geometry/ >project.cmake >raytrace/ >project.cmake > > To see the macros which are used (in particular, add_subproject and related > macros), have a look at the file cmake/UtilMacros.cmake > > HTH, > ~Chris. > ___ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake > -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Fwd: Targets organisation of complex project
Chris Foster wrote: > Mateusz: You may find the example layout I've attached useful if you're not > needing to do code generation (just delete all the stuff to do with > hello2.cpp). Yes, it's very helpful ineed. However, I'm generating some config headers (porting autotools' approach: project.h.in -> project.h) but as I've learned CMake can do the job well. > You might also consider pulling definitions from the > subdirectories into the base CMakeLists.txt using something like > > get_directory_property(libA_srcs DIRECTORY libA DEFINITION srcs) > > rather than pushing them from the subdirectories into the base scope with > set(... PARENT_SCOPE) Interesting trick. Thanks! Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Targets organisation of complex project
Hendrik Sattler wrote: > Zitat von Mateusz Loskot : >> Trying to figure out how to organise targets I got an idea to >> configure these sub-libraries as static library targets >> (e.g. libgdal_cpl, libgdal_alg, libgdal_gcore, etc.) which >> eventually link to single shared library (libgdal.so). >> Learning CMake best practices, I stepped across an interesting >> thread: "build a shared library from static libraries" >> >> http://www.cmake.org/pipermail/cmake/2008-March/020315.html >> >> It actually smashed my original idea :-) > > Why? I think you misunderstood what is written there. I believe I have understood it well and I got it exactly as Chris Foster explained it. (Thanks Chris!) Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Targets organisation of complex project
Samuel E. Henley wrote: > Some time ago I built a cmake script for the the library in your > example gdal/ogr Samuel, That's interesting news. You should have announce it to gdal-dev :-) > - primarily to generate builds for gcc under Windows and Linux Our idea is to exploit the power of CMake in terms of write once use everywhere. Personally, I really want to make life of developers and users of GDAL based on Windows just easier by providing them with native build configuration. > My first approach was to build a library for each of the map format > types and the four core libraries cpl, gcore, etc. Our approach is similar except we thought about building all formats into single sub-library. > The libraries (hundreds) would not link and the library order would > result in new set of undefined symbols on each attempt. Yes, the number of potential libraries is huge. > Gdal/Ogr is built with a makefile, and the objects generated are > saved and linked at the end of the processes. Yes. > What I did get to work > was to include the sources, using cmake include, in each of the four > core libraries, setting source file properties for each group of > source file cflags. qhite sqhite s > (http://wush.net/trac/sehenley/browser/simulator/trunk/src/builds/gdalogr) Sounds as a good but I may have been missing something. I looked at the scripts and it seems it's based on the same approach as we are trying to follow. Some of components are built as static libs linked into single shared lib: http://wush.net/trac/sehenley/browser/simulator/trunk/src/builds/gdalogr/CMakeLists.txt#L800 > Previously my system just identified groups of sources for each of > four core libraries – that system used an unreasonable amounts of > time to maintain. By having the format sources in individual groups ( > *.cmake) cmake will tell you what source file it can't find – as > large libraries the gcc linker will only tell you at the end of the > process what symbol it can't find and even worst build a library with > undefined symbols to be discoved at run time. You will still have to > run down any new source files but the link symbol will give a hint > as to where they were added. I understand. By the way, how does CMake handle passing such large number of source files, well or could be better or... http://wush.net/trac/sehenley/browser/simulator/trunk/src/builds/gdalogr/CMakeLists.txt#L668 I'm wondering if resulting Makefile (for GCC toolset) would allow to handle multi-process/jobs building. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Targets organisation of complex project
Mateusz Loskot wrote: > What would be best way to configure such complex source tree that > outputs single library? I'm trying to make my decision, so I would like to summary our brainstorm. AFAIU, linking the static libraries to single shared library is still not recommended. The recommended option is to pass all source files at once to ADD_LIBRARY call. Next, there is a couple of ways how to achieve that like appending names to variables (brute force), using PARENT_SCOPE thing, get_directory_property etc. Would that be correct? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Targets organisation of complex project
Alexander Neundorf wrote: > On Tuesday 13 October 2009, Mateusz Loskot wrote: >> Mateusz Loskot wrote: >>> What would be best way to configure such complex source tree that >>> outputs single library? >> I'm trying to make my decision, so I would like to summary >> our brainstorm. >> >> AFAIU, linking the static libraries to single shared library >> is still not recommended. >> >> The recommended option is to pass all source files at >> once to ADD_LIBRARY call. >> >> Next, there is a couple of ways how to achieve that like >> appending names to variables (brute force), > > What is brute force about that ? Actually, nothing. I just wanted to describe the process of collecting sources with plain SET() command while walking down-up the tree of subdirectories, one by one, appending, etc. >> using PARENT_SCOPE thing, > > If you do that, remember to use the full paths, otherwise the relative paths > will be wrong. Right. >> get_directory_property etc. >> >> Would that be correct? > > I think so. Great. Things are getting clear :-) Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Open Source Memory Checker
Dixon, Shane wrote: > If linux has valgrind which is an open source memory checker, is > there any equivalent on Windows? I noticed ctest supports purify, > but it looks like that's only a pay solution. Am I out of luck > trying to find a memory checker that's open source on Windows? Visual Leak Detector http://dmoulding.googlepages.com/vld It is not a fully featured memory debugger, but it is a very good leak checker, at least. Best regards -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Open Source Memory Checker
Dixon, Shane wrote: > Does this work with CMake at all? I don't know what would be CMake specific about that. VLD is just a library. CMake is a builder. You can build your program with CMake and link against VLD. That's for sure. Next, run your program under Visual C++ debugger to perform the analysis and get result. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Feature request: list(UNIQUE )
Hi, There is SORT command for lists: list(SORT ) I believe it would make sense to have UNIQUE command too: list(UNIQUE ) unless it's already available and I've not read the doc carefully, have I? Perhaps it would be trivial to implement by CMake gurus :-) Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Warning D9025 : overriding '/W3' with '/W4'
Hi,
In CMakeLists.txt I have something like this:
if(MSVC)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /W4")
endif()
I configure my build using command prompt of Visual Studio 2005 (8.0):
D:\dev\geos\_svn\build-nmake>cmake -G "NMake Makefiles" ..\trunk
and the compiler flags look as follows:
CMAKE_CXX_FLAGS= /DWIN32 /D_WINDOWS /W3 /Zm1000 /EHsc /GR /W4 /MP
I build and I'm getting D9025 warning:
D:\dev\geos\_svn\build-nmake> nmake
Microsoft (R) Program Maintenance Utility Version 8.00.50727.762
Copyright (C) Microsoft Corporation. All rights reserved.
[ 0%] Building CXX object src/CMakeFiles/geos.dir/algorithm/Angle.cpp.obj
cl : Command line warning D9025 : overriding '/W3' with '/W4'
Would it be possible to get rid of this warning with some CMake magic?
It is not really a big problem as one can just ignore this warning,
but I think it may indicate general issue with handling
flags for NMake makefiles.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Feature request: list(UNIQUE )
Hi, There is SORT command for lists: list(SORT ) I believe it would make sense to have UNIQUE command too: list(UNIQUE ) unless it's already available and I've not read the doc carefully, have I? Perhaps it would be trivial to implement by CMake gurus :-) Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Warning D9025 : overriding '/W3' with '/W4'
Hi,
In CMakeLists.txt I have something like this:
if(MSVC)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /W4")
endif()
I configure my build using command prompt of Visual Studio 2005 (8.0):
D:\dev\geos\_svn\build-nmake>cmake -G "NMake Makefiles" ..\trunk
and the compiler flags look as follows:
CMAKE_CXX_FLAGS= /DWIN32 /D_WINDOWS /W3 /Zm1000 /EHsc /GR /W4 /MP
I build and I'm getting D9025 warning:
D:\dev\geos\_svn\build-nmake> nmake
Microsoft (R) Program Maintenance Utility Version 8.00.50727.762
Copyright (C) Microsoft Corporation. All rights reserved.
[ 0%] Building CXX object src/CMakeFiles/geos.dir/algorithm/Angle.cpp.obj
cl : Command line warning D9025 : overriding '/W3' with '/W4'
Would it be possible to get rid of this warning with some CMake magic?
It is not really a big problem as one can just ignore this warning,
but I think it may indicate general issue with handling
flags for NMake makefiles.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Feature request: list(UNIQUE )
Tyler Roscoe wrote: > On Tue, Jan 19, 2010 at 12:17:04AM +0000, Mateusz Loskot wrote: >> I believe it would make sense to have UNIQUE command too: >> >> list(UNIQUE ) >> >> unless it's already available and I've not read the doc >> carefully, have I? > > It's called REMOVE_DUPLICATES. It looks exactly as what I proposed. Thanks Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Warning D9025 : overriding '/W3' with '/W4'
Philip Lowman wrote:
> On Mon, Jan 18, 2010 at 7:17 PM, Mateusz Loskot wrote:
>>
>> In CMakeLists.txt I have something like this:
>>
>> if(MSVC)
>> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /W4")
>> endif()
>>
>> I configure my build using command prompt of Visual Studio 2005 (8.0):
>>
>> D:\dev\geos\_svn\build-nmake>cmake -G "NMake Makefiles" ..\trunk
>>
>> and the compiler flags look as follows:
>>
>> CMAKE_CXX_FLAGS= /DWIN32 /D_WINDOWS /W3 /Zm1000 /EHsc /GR /W4 /MP
>>
>> I build and I'm getting D9025 warning:
>>
>> D:\dev\geos\_svn\build-nmake> nmake
>>
>> Microsoft (R) Program Maintenance Utility Version 8.00.50727.762
>> Copyright (C) Microsoft Corporation. All rights reserved.
>>
>> [ 0%] Building CXX object src/CMakeFiles/geos.dir/algorithm/Angle.cpp.obj
>> cl : Command line warning D9025 : overriding '/W3' with '/W4'
>>
>>
>> Would it be possible to get rid of this warning with some CMake magic?
>
>
> Yes, you can use a regular expression to search and replace the
> contents of CMAKE_CXX_FLAGS "/W3" (or /W[0-9]) with /W4... see
> string(REGEX REPLACE...) in the docs.
The string manipulation does the trick for me, big thanks!
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Checking function or symbol in namespace
Hi, I'm trying to perform the following checks: check_function_exists(std::pow HAVE_POW) or check_symbol_exists(std::pow cmath HAVE_POW) but it looks that both macros have troubles with resolving std:: namespace. The documentation is not very clear about that. Or I should stick to try_compile based tests? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Checking function or symbol in namespace
Michael Wild wrote: On 21. Jan, 2010, at 24:55 , Mateusz Loskot wrote: Hi, I'm trying to perform the following checks: check_function_exists(std::pow HAVE_POW) or check_symbol_exists(std::pow cmath HAVE_POW) but it looks that both macros have troubles with resolving std:: namespace. The documentation is not very clear about that. Or I should stick to try_compile based tests? Best regards, AFAIK check_symbol_exists is used for preprocessor symbols. check_function_exists looks for C functions, not C++. OK, makes sense: symbol -> preprocessor function -> real function Although, for clarity, perhaps check_symbol_exists should be called check_macro_exists. The fact check_function_exists checks C function but not C++ free function is a bit confusing. AFAIU, CMake is dedicated to build C++ source code, so I suppose many users may expect it works well for both C and C++ free functions. Why it can not work, actually? Also notice, that older C++ standard libraries and non-compliant C++ compilers don't use the namespace std. You might want to have a look at CMakeBackwardCompatibilityCXX.cmake or the various other modules it uses. Yes, I know this problem quite well. However, I rarely work with such old or incompatible libraries. IMHO, CMake should be able to handle standard C++ definitions and let users to deal with incompatibilities. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Checking function or symbol in namespace
Michael Wild wrote: On 21. Jan, 2010, at 16:44 , Mateusz Loskot wrote: Michael Wild wrote: On 21. Jan, 2010, at 24:55 , Mateusz Loskot wrote: Hi, I'm trying to perform the following checks: check_function_exists(std::pow HAVE_POW) or check_symbol_exists(std::pow cmath HAVE_POW) but it looks that both macros have troubles with resolving std:: namespace. The documentation is not very clear about that. Or I should stick to try_compile based tests? Best regards, AFAIK check_symbol_exists is used for preprocessor symbols. check_function_exists looks for C functions, not C++. OK, makes sense: symbol -> preprocessor function -> real function Although, for clarity, perhaps check_symbol_exists should be called check_macro_exists. No, as Marcel and I noticed, check_symbol_exists really checks whether that symbol exists, be it preprocessor symbol, function or global variable. Really, the docs should be updated to clarify this. Gotcha. I haven't completed reading the thread yet. The fact check_function_exists checks C function but not C++ free function is a bit confusing. AFAIU, CMake is dedicated to build C++ source code, so I suppose many users may expect it works well for both C and C++ free functions. Why it can not work, actually? Because the module writes a .c file and then compiles it with the C-compiler... What one needs is CheckCXXFunctionExists and CheckCXXSymbolExists. Or, alternatively, the modules could check the enabled languages and if C++ is enabled, write a C++ file (that should also work for C functions/symbols), otherwise fall back to plain C. Both options would work well of course. However, the latter seems to be easier to integrate seamlessly with current set of standard macros avaialble in CMake - implementations changes only, not interface. For the time being, it looks like I will need to maintain private versions of CheckCXXFunctioExists in a project. Thanks! Best regards, -- Mateusz Loskot, http://mateusz.loskot.net ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Checking function or symbol in namespace
Eric Noulard wrote: 2010/1/21 Mateusz Loskot : The fact check_function_exists checks C function but not C++ free function is a bit confusing. That's true. AFAIU, CMake is dedicated to build C++ source code, However that's look false to me :-( Perhaps I should be more precise, I meant CMake targets mainly C and C++ and is optimised with C and C++ in mind, but it does support other platforms too. At least that's what I've learned from Bill's last video lecture given to Google folks. so I suppose many users may expect it works well for both C and C++ free functions. Why it can not work, actually? You don't want to "enable " ( see CMake command enable_language(languageName [OPTIONAL] ) C++ for people which do "only" use plain C. Got your point. Then I see a little inconsistency. Some macros use CXX moniker in their names to indicate they are C++ specific. Why not apply this rule to all macros where C vs C++ incompatibilities do apply. Meaning, why there is no CheckCXXFunctionExists equivalent. Naming consistency is one of the best practices in hacking, isn't it? Thus the check_functions may be updated to be smart enough to try C++ free function if ever C++ language has been enabled? My be checking CMAKE_CXX_COMPILER_WORKS is possible ? or may be it would be easier to explicitely tell this fact to the macro CHECK_FUNCTION_EXISTS(std::copy HAVE_COPY LANGUAGE CXX) That's right, or use separate macro with CXX in name. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Checking function or symbol in namespace
Michael Wild wrote:
On 21. Jan, 2010, at 17:17 , Jed Brown wrote:
On Thu, 21 Jan 2010 17:03:27 +0100, Michael Wild
wrote:
But both of them just do a try_compile. I don't see where the
name-mangling comes in there... If the user wants to check for a
template, he has to instantiate the template, e.g.
check_cxx_function_exists("std::copy std::string::iterator>" "algorithm;string" HAVE_STD_COPY).
Tedious, but should work. To check for classes, you'd need a
different macro, however.
You're kidding, right? Have you looked at CheckFunctionExists.c?
It declares the symbol as
char SYMBOL_NAME();
and then tries to link a program that calls this function. No
headers are included, so there is no way for this symbol to match
the mangled symbol in the library.
Of course, you could write a completely different thing with an
interface more like check_cxx_source_compiles, and call this new
thing check_cxx_function_exists, but that would be terribly
inconsistent so I hope you don't.
Jed
Ahh, yes. Obviously didn't think it through...
Jed, Michael,
I confess I haven't dug the source of these check macros.
I have to agree, getting this kind of thing to work with C++ is
probably not worth the trouble... Better use a
> check_cxx_source_compiles in the first place for everything C++.
Yes, though I'd annoyingly keep my side that CXX variants of the macros
would be useful and make C vs C++ separation more clear to user.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Checking function or symbol in namespace
Mateusz Loskot wrote: > I'm trying to perform the following checks: > > check_function_exists(std::pow HAVE_POW) > > or > > check_symbol_exists(std::pow cmath HAVE_POW) > > but it looks that both macros have troubles > with resolving std:: namespace. > > The documentation is not very clear about that. > > Or I should stick to try_compile based tests? First, I would like to thank to all who shared their comments. It really helped me to understand how the macros work, so how to use them effectively. By the way, KDE is also a great source of various CMake macros. Here are a few related to the discussion and C++ features: * CheckCXXSymbolExists http://websvn.kde.org/trunk/KDE/kdelibs/cmake/modules/CheckCXXSymbolExists.cmake * CheckPrototypeExists http://websvn.kde.org/trunk/KDE/kdelibs/cmake/modules/CheckPrototypeExists.cmake * CheckPointerMember http://websvn.kde.org/trunk/KDE/kdelibs/cmake/modules/CheckPointerMember.cmake Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Checking function or symbol in namespace
Michael Wild wrote: > IMHO the documentation should be clarified... Just for records, there is bug report opened which is related to my question: http://public.kitware.com/Bug/view.php?id=8758 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Checking function or symbol in namespace
Jed Brown wrote: > On Thu, 21 Jan 2010 15:44:43 +0000, Mateusz Loskot wrote: >> Why it can not work, actually? > > C++ does name mangling so it's difficult to determine what the symbol > actually is (you have to know about various classes and templates that > may be in scope), therefore the interface would look a bit different. After some testing I did yesterday, I would add that one of the problems making it difficult to provide elegant macro checking C++ functions is the fact that in C++ functions can be overloaded. I suppose that the only flexible, robust and also elegant way to provide cross-platform macros for detecting C++ (also with mixed in C99, TR1, C++0x, etc.) features is to develop one macro per feature (function, macro, etc.) For instance, 1) check_cxx_fabs - checks std::fabs in , optionally falls back to ::fabs in if a systems has problems with std:: (i.e. Visual C++ 6.0) 2) check_cxx_isnan - tries if C++ impl. has C99 compatibility [1] additions, on some systems available as std::tr1::isnan on others as std::isnan, if fails, then falls back to system specific functions like _isnan() form Visual C++ or __inline_isnand from XCode, etc. It would probably generate large number of small macros, but I can't see a more robust and flexible way to make such checks in reusable form. Perhaps it could make into the CMake distribution one day :-) [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1568.htm Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Tips to create a UseXYZ.cmake
Anton Deguet wrote: > Hello, > > Besides digging in the existing UseVTK, UseITK, UseOpenIGTLing, ... > is there a short description of the philosophy and basic commands to > use? Any pointer is welcome. This would be for a project with > multiple external dependencies, i.e. libxml, openCV, Python, numpy, > ... > What's the difference between Use*.cmake and Find*.cmake? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Order of enable_testing and add_subdirectory
Hi, I have just learned by trial and error that enable_testing() macro should be called before a subdirector(y|ies) with tests are added, otherwise tests are not configured. Here is a bit of CMakeLists.txt in root directory of my project 1) This option works properly enable_testing() add_subdirectory(include) add_subdirectory(src) add_subdirectory(tests) # Here are my tests 2) This does not configure any tests add_subdirectory(include) add_subdirectory(src) add_subdirectory(tests) # Here are my tests enable_testing() and make test or ctest -N does not show anything but message like: Running tests... Test project /home/mloskot/dev/geos/_svn/build No tests were found!!! Is my conclusion correct, that the order of enable_testing and add_subdirectory is relevant? If it is, perhaps it would be good to update the manual appropriate note on how things in the CMakeLists.txt are being processed. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Order of enable_testing and add_subdirectory
Marcel Loose wrote: > On Sun, 2010-01-31 at 01:20 +0000, Mateusz Loskot wrote: >> Hi, >> >> I have just learned by trial and error that enable_testing() >> macro should be called before a subdirector(y|ies) with tests >> are added, otherwise tests are not configured. >> >> Here is a bit of CMakeLists.txt in root directory of my project >> >> 1) This option works properly >> >> enable_testing() >> add_subdirectory(include) >> add_subdirectory(src) >> add_subdirectory(tests) # Here are my tests >> >> 2) This does not configure any tests >> >> add_subdirectory(include) >> add_subdirectory(src) >> add_subdirectory(tests) # Here are my tests >> enable_testing() >> >> and make test or ctest -N does not show anything but message like: >> >> Running tests... >> Test project /home/mloskot/dev/geos/_svn/build >> No tests were found!!! >> >> >> Is my conclusion correct, that the order of enable_testing and >> add_subdirectory is relevant? >> If it is, perhaps it would be good to update the manual >> appropriate note on how things in the CMakeLists.txt are being > processed. >> Best regards, > > Hi Mateusz, > > Yes, your conclusion is correct. I think the docs are clear about this. > >>From the docs: > > enable_testing: Enable testing for current directory and below. > > add_test: Add a test to the project with the specified arguments. > If the ENABLE_TESTING command has been run, this command adds a test > target to the current directory. If ENABLE_TESTING has not been run, > this command does nothing. > > So order *does* matter here. Marcel, You are perfectly right. I was apparently reading the "has been run" part too quickly and with not enough consideration. Everything is in place. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Tutorial from "Mastering CMake" now online!
Bill Hoffman wrote: For more information see my blog entry: http://www.kitware.com/blog/home/post/7 Bill, Great! By the way of tutorial, SO'ers have been asking :-) http://stackoverflow.com/questions/2186110/cmake-tutorial/ Best regards, -- Mateusz Loskot, http://mateusz.loskot.net ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Manual version vs CMake version
Hi, Perhaps it will be helpful information for someone. On popular Linux distributions CMake 2.6 may not be necessarily the same CMake 2.6 as documented [1] on the website. CMake from Ubuntu 9.10 reports "cmake version 2.6-patch 4" CMake from Debian 5.0.3 reports "cmake version 2.6-patch 0" It's a micro-difference but may be significant, because on Debian, for instance, VERSION_LESS or VERSION_GREATER are not available. I understand it's probably a Debian problem, but users may be confused while trying to refer to CMake 2.6 documentation. [1] http://cmake.org/cmake/help/cmake2.6docs.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Manual version vs CMake version
Bill Hoffman wrote: > Eric Noulard wrote: > >> That's true, may be the site could indicate that the doc is for latest >> 2.6.x serie. >> However the most trustfull way to check the doc of your current cmake >> version is the command line. >> >> cmake --help-command if >> >> should give you the doc for the cmake version you are using. >> >> if you want html you can use: >> >> cmake --help-html > cmake-doc.html >> >> then browse the cmake-doc.html file. > > Or cmake --version. Yes, all this is true and I've managed to find a solution myself quite easily, but I've posted as from position of an average (read, rather lazy) user who preferes pretty website to read doc than dark console :-) Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Manual version vs CMake version
Philip Lowman wrote: > On Fri, Feb 5, 2010 at 4:31 PM, Mateusz Loskot wrote: >> Bill Hoffman wrote: >>> Eric Noulard wrote: >>> >>>> That's true, may be the site could indicate that the doc is for latest >>>> 2.6.x serie. >>>> However the most trustfull way to check the doc of your current cmake >>>> version is the command line. >>>> >>>> cmake --help-command if >>>> >>>> should give you the doc for the cmake version you are using. >>>> >>>> if you want html you can use: >>>> >>>> cmake --help-html > cmake-doc.html >>>> >>>> then browse the cmake-doc.html file. >>> Or cmake --version. >> Yes, all this is true and I've managed to find a solution myself quite >> easily, but I've posted as from position of an average >> (read, rather lazy) user who preferes pretty website to read doc >> than dark console :-) > > Also, it might not be a bad idea to mention the version number within > the documentation when features are added, especially if features are > going to be added during a patch release. > > The same should probably be true of new find modules. Yes, I also think it would be a good idea, though may be a hassle for maintainers. An alternative option would be to link to ChangeLog [1] in first words of the documentation and emphasise features may be added between patch releases. For instance, one of entries for 2.6.2 RC4 says: - Add VERSION compare to if command [1] http://www.cmake.org/files/v2.6/CMakeChangeLog-2.6.4 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.8.1 RC 1 is ready to try
Bill Hoffman wrote: - Add "NMake Makefiles JOM" generator Is this the jom speedy thing from Trolls? http://labs.trolltech.com/blogs/2009/03/27/speeding-up-visual-c-qt-builds/ Best regards, -- Mateusz Loskot, http://mateusz.loskot.net ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Canonical use of FindPackageHandleStandardArgs
Hi,
I'm writing some FindXXX.cmake macros [1] and I'd like to master some
best practices I use and I'm having troubles with picturing what should
canonical use of FindPackageHandleStandardArgs look like.
I'm aware I've used it incorrectly in many places.
I'm looking for confirmation if it should be something along
these
1) Set lookup mode to quiet if user explicitly asked to find MYLIB
quietly or if it's already found:
if(MYLIB_FIND_QUIETLY OR MYLIB_FOUND)
set(FIND_MYLIB_QUIET_ARG QUIET)
endif()
2) Call find passing selected lookup mode
find_package(MYLIB ${FIND_MYLIB_QUIET_ARG})
3) Perform other checks, but do not call message() if
MYLIB_FIND_QUIETLY is requested, otherwise lookup will not be really quiet
4) Check and report results
find_package_handle_standard_args(MYLIB
DEFAULT_MSG MYLIB_LIBRARY MY_INCLUDE_DIR)
Have I missed anything?
[1] http://github.com/mloskot/workshop/blob/master/cmake/modules/
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] windows link error
Andreas Pakulat wrote: > On 04.03.10 17:27:56, Simmons, Aaron wrote: >> You're right-- msvc uses "link"; I was thinking of gcc's "ld". I guess >> the question is why is it trying to use "ld" at all? Cmake successfully >> detects that its using msvc/nmake, as it compiles all of the .c files >> with "cl". It's the lib-linking step that falls down. >> >> Here is my "set" output: > > Hmm, can't see anything suspicious. What's in the cmake cache? Is the > ld.exe mentioned there? Perhaps, Aaron's problem is caused by some commands hardcoded in CMake files. ld.exe looks to me as MinGW (or Cygwin) utility And, perhaps, the CMake configuration assumes that Windows build is done using MinGW. Best regards, -- Mateusz Loskot http://mateusz.loskot.net ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] RecipeAddUninstallTarget fix
Hi,
I think that the regex replace command presented
in the RecipeAddUninstallTarget wiki is not correct.
It is:
STRING(REGEX REPLACE " " ";" files "${files}")
but it should read
STRING(REGEX REPLACE "\n" ";" files "${files}")
The current version of the command does not make the script
iterating over lists of files, but performs causes a single iteration
-- Uninstalling /home/mloskot/usr/include/geos/geos.h
/home/mloskot/usr/include/geos/platform.h
/home/mloskot/usr/bin/geos-config
Corrected version gives output like this:
-- Uninstalling /home/mloskot/usr/include/geos/geos.h
-- Uninstalling /home/mloskot/usr/include/geos/platform.h
-- Uninstalling /home/mloskot/usr/bin/geos-config
Am I correct?
[1] http://www.cmake.org/Wiki/RecipeAddUninstallTarget
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
