Re: [CMake] [DKIM: Failed] Re: Alternative locations for boost in cmake

[Marcel Loose]

Hi Mahmood,

I think that "-DBoost_LIBRARY_DIRS" should be "-DBoost_LIBRARY_DIR".

Cheers,
Marcel Loose.

On 25/10/2019 09:54, Mahmood Naderan via CMake wrote:
> Even with the latest 3.15.4, I get the same error
>
>
> $ cmake --version
> cmake version 3.15.4
>
> CMake suite maintained and supported by Kitware (kitware.com/cmake).
> $ cmake -DBoost_NO_SYSTEM_PATHS=ON
> -DBOOST_INCLUDE_DIR=/storage/users/mnaderan/boost_1_65_1/build/include/
> -DBoost_LIBRARY_DIRS=/storage/users/mnaderan/boost_1_65_1/build/lib/
> -DBoost_ADDITIONAL_VERSIONS=1.65.1 ..
> -- The C compiler identification is GNU 4.8.5
> -- The CXX compiler identification is GNU 4.8.5
> -- Check for working C compiler: /bin/cc
> -- Check for working C compiler: /bin/cc -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Check for working CXX compiler: /bin/c++
> -- Check for working CXX compiler: /bin/c++ -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> -- Looking for pthread.h
> -- Looking for pthread.h - found
> -- Performing Test CMAKE_HAVE_LIBC_PTHREAD
> -- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
> -- 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
> -- Found CUDA: /usr/local/cuda-10.0 (found suitable version "10.0",
> minimum required is "7.5")
> -- Could NOT find Boost
> CMake Error at
> /storage/users/mnaderan/tools/cmake-3.15.4/share/cmake-3.15/Modules/FindPackageHandleStandardArgs.cmake:137
> (message):
>   Could NOT find Boost (missing: Boost_INCLUDE_DIR system filesystem timer
>   chrono) (Required is at least version "1.58")
> Call Stack (most recent call first):
>  
> /storage/users/mnaderan/tools/cmake-3.15.4/share/cmake-3.15/Modules/FindPackageHandleStandardArgs.cmake:378
> (_FPHSA_FAILURE_MESSAGE)
>  
> /storage/users/mnaderan/tools/cmake-3.15.4/share/cmake-3.15/Modules/FindBoost.cmake:2161
> (find_package_handle_standard_args)
>   cmake/FindBoost.cmake:6 (FIND_PACKAGE)
>   CMakeLists.txt:47 (include)
>
>
> -- Configuring incomplete, errors occurred!
>
>
>
> Regards,
> Mahmood
>
>
> On Thursday, October 24, 2019, 10:52:37 PM GMT+3:30, Mateusz Loskot
>  wrote:
>
>
> You are using very old CMake 3.9 which has no idea about Boost 1.65
> https://github.com/Kitware/CMake/blob/v3.9.0/Modules/FindBoost.cmake#L769
>
> Rule #1: Use latest version of CMake, ALWAYS!
>
> There is absolutely no reason or excuse to not to use the latest as
> there are
> - deb packages available https://apt.kitware.com/
> - generic installer for any Linux and Windows
>
> Updating CMake is easy-peasy for us lazy programmers with a bit of
> scripting:
> https://github.com/mloskot/wsl-config/blob/master/scripts/install-cmake-latest.sh
> https://github.com/mloskot/wsl-config/blob/master/scripts/install-cmake-latest.ps1
>
>
>
> 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
>
<>-- 

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] [DKIM: Failed] Troubles with ExternalProject_Add and PATCH_COMMAND

[Marcel Loose]

Hi Steven,

When you run patch manually, do you then supply the same absolute paths?
Looking at the patch file I noticed that it contains a relative path. So
maybe you should cd to
${CMAKE_BINARY_DIR}/boost/src/external_boost/project-config.jam before
running the patch command.

Cheers,
Marcel.

Op 18-07-19 om 17:29 schreef Steven Truppe:
>
> Hi everyone,
>
> i try to patch a file from an externalprojects with the PATCH_COMMAND.
>
> The patch file looks like:
>
> --- project-config.jam    2019-07-18 17:21:44.008695808 +0200
> +++ project-config.jam.tmp    2019-07-18 17:23:28.236474532 +0200
> @@ -18,7 +18,7 @@
>  import python ;
>  if ! [ python.configured ]
>  {
> -    using python : 2.7 : /usr ;
> +    using python : 3.7 : /usr ;
>  }
>  
>  path-constant ICU_PATH : /usr ;
>
> When i try to apply the patch manualy with patch originalfile <
> patchfile it's working, but when i try it with the externalproject_add
> command:
>
> if(WITH_LIB_BOOST)
>     message(STATUS "Build WITH_LIB_BOOST.")
>
>     set(LIB_BOOST_INC_PATH ${OUTPUT_PATH}/libs/boost/include/)
>     set(LIB_BOOST_LIB_PATH ${OUTPUT_PATH}/libs/boost/lib)
>     set(LIB_BOOST_DEPS external_boost)
>     set(LIB_BOOST_STATIC_LIBS boost_python27)
>  
>     ExternalProject_Add(external_boost
>         PREFIX ${CMAKE_BINARY_DIR}/boost
>         URL ${BOOST_URL}
>         DOWNLOAD_DIR ${CMAKE_BINARY_DIR}/boost
>         URL_HASH MD5=${BOOST_HASH}
>         PATCH_COMMAND /usr/bin/patch 
> ${CMAKE_BINARY_DIR}/boost/src/external_boost/project-config.jam < 
> ${CMAKE_SOURCE_DIR}/tools/patches/boost_python3.7.patch
>         CONFIGURE_COMMAND cd ${CMAKE_BINARY_DIR}/boost/src/external_boost/ &&
>                         ./bootstrap.sh --prefix=${OUTPUT_PATH}/libs/boost/ 
> --with-libraries=python
>         BUILD_COMMAND cd ${CMAKE_BINARY_DIR}/boost/src/external_boost/ &&
>                       ./b2
>         INSTALL_COMMAND cd ${CMAKE_BINARY_DIR}/boost/src/external_boost/ && 
> ./bjam && ./bjam install
>         INSTALL_DIR ${OUTPUT_PATH}/boost
>     )
>
> endif()
>
> But when running cmake i get the following output:
>
> patching file 
> /home/stuv/projects/programming/bsEdit/build/boost/src/external_boost/project-config.jam
> Hunk #1 FAILED at 18.
>
>
> I have no idea what i'm doing wrong here, i hope someone here can help
> me out.
>
>
> best regards,
>
> Steven Truppe
>
>
>
>
>

-- 

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] [FYI] clang-3.4 vs cmake-3.11.0 (How to build CMake so it works on an older Linux?)

[Marcel Loose]

Hi Suzuki,

Sorry for chiming in late, but you may want to try the PPA for Ubuntu
Toolchain test builds, which contains compiler builds up to gcc-8 for
Ubuntu version as old as 10.04. Much less of a hassle than building GCC
yourself, I can tell from experience. Check out
https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/test

Cheers,
Marcel.


On 05/04/18 07:29, suzuki toshiya wrote:
> Sorry for bothering subscribers for posting about C++11 environment
> instead of cmake itself. Now I understand building gcc >= 4.8.5
> manually might be easier, in comparison with the quest of libc++
> for clang-3.4.
>
> https://stackoverflow.com/questions/39332406/install-libc-on-ubuntu
>
> Regards,
> mpsuzuki
>
> suzuki toshiya wrote:
>> Dear Bo Zhou,
>>
>> Sorry, I've confirmed by myself.
>> By default, clang-3.4 for Ubuntu prioritizes old g++ header files, and clang
>> header files are searched as a fallback.
>> I can customize the searching order by -nostdinc++...
>>
>> Regards,
>> mpsuzuki
>>
>> suzuki toshiya wrote:
>>> Dear Bo Zhou,
>>>
>>> Thank you for prompt reply.
>>>
 Be aware that GCC suite actually is independent from the libstdc++, so if 
 you have a newer compiler, the compiler might still pick the older 
 libstdc++ without the new API.
>>> Oh, so, even if I installed clang-3.4, still it uses older (maybe C++03)
>>> libraries are referred by it?
>>>
>>> Regards,
>>> mpsuzuki
>>>
>>> Bo Zhou wrote:
 The emplace() is new API from C++11.

 Be aware that GCC suite actually is independent from the libstdc++, so if 
 you have a newer compiler, the compiler might still pick the older 
 libstdc++ without the new API.

 This issue doesn't exist at Windows, since Visual Studio is a complete 
 sytem.

 This issue happens on OSX also, so user must give the compiler a proper 
 MacOS SDK for the new header files etc.

 On Thu, Apr 5, 2018 at 1:33 PM, suzuki toshiya 
 > wrote:
 $ clang++ --version
 Ubuntu clang version 3.4-1ubuntu3~precise2 (tags/RELEASE_34/final) (based 
 on
 LLVM 3.4)
 Target: x86_64-pc-linux-gnu
 Thread model: posix

 But I got following abort:

 cmake-3.11.0/Source/cmLocalGenerator.cxx:553:36: error: no member named 
 'emplace' in
   'std::unordered_map,
   std::allocator > >'
   this->GeneratorTargetSearchIndex.emplace(gt->GetName(), gt);
    ^

 G X-D

 Regards,
 mpsuzuki

 suzuki toshiya wrote:
> Dear Bo Zhou,
>
> Thank you for the info! Now I'm checking Ubuntu 12.04 in LXC.
> So, gcc-4.8.5 or later would be needed for C++11, it seems that the last 
> version
> of gcc officially provided for Ubuntu-12 was 4.7. oh.
> According to https://clang.llvm.org/cxx_status.html , clang-3.3 supports 
> C++11,
> and the last version of clang officially provided for Ubuntu-12 was 3.4. 
> ooh.
> I will check if clang-3.4 for Ubuntu-12.04 can compile cmake (or any other
> dependency problems would arise).
>
>> Usually the ABI is not the problem but the libstdc++, you can use a old 
>> Ubuntu with old libstdc++ but build CMake with new compiler and make 
>> sure it links with old libstdc++. This is the trick.
> Indeed.
>
> Regards,
> mpsuzuki
>
> Bo Zhou wrote:
>> The latest CMake requires C++11 compiler, so what you need is just a 
>> newer GCC which supports C++11 at your platform, that's it.
>>
>> Usually the ABI is not the problem but the libstdc++, you can use a old 
>> Ubuntu with old libstdc++ but build CMake with new compiler and make 
>> sure it links with old libstdc++. This is the trick.
>>
>> I don't know how to do this on Ubuntu, but on CentOS, it's possible to 
>> build CMake in that way, so the CMake would be portable at older CentOS 
>> platform with old libstdc++ .
>>
>> Good luck.
>>
>> On Thu, Apr 5, 2018 at 12:23 PM, Eric Wing 
>> >>
>>  wrote:
>> I just discovered that CMake no longer builds on my Ubuntu 12.04. I
>> need to build binaries that are compatible with that ABI.
>>
>> I see that your binary distribution of CMake 3.11 still works on
>> Ubuntu 12.04. Can you tell me what you do to achieve this? What are
>> you doing for your official builds?
>>
>> Are you just using -static-libstdc++ -static-libgcc for
>> CMAKE_CXX_FLAGS, or is there more?
>>
>> (I just noticed that ldd shows that you don't have dependencies on
>> libssl, libcrypto, and libz, whereas I do.)
>>
>> Thanks,
>> 

Re: [CMake] Link to local glibc

[Marcel Loose]

Hi Michele,

This could become a painful exercise. You basically have two options:
1) Treat it as a cross-compilation project, or
2) Create a virtual machine running CentOS 5.8 and do the build there.
If I were you, I would go for the second option.

Cheers,
Marcel.

Op 07-03-17 om 17:56 schreef Michele Portolan:
> Hello,
> 
> I build on a Ubuntu machine (kernel 4.4.0-64-generic), but I need my
> program to be executed on an old Cento 5.8 (kernel 2.6.18). I tried
> compiling with "-static" to have static linking, but when I try to
> execute I get "ERROR: Kernel too old!"
> 
> I therefore locally compiled a glibc with support for kernel 2.6.18 ...
> but how can I have Cmake use it instead of the system one?
> 
> Thanks,
> 
> 
> Michele
> 




signature.asc
Description: OpenPGP digital signature
-- 

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] after running cmake, getting an error cannot find -levent

[Marcel Loose]

Hi Walter,

The dash before levent looks different from the ones before lrt and
lpthread. Are you sure it's not some kind of Unicode character?

Cheers,
Marcel Loose.


On 15/09/16 18:56, Gunter, Walter E wrote:
>
> I am cross-compiling for an arm, and can run cmake successfully, but
> when I run make, I am getting the following:
>
>  
>
> /opt/toolchains/arm-2008q3/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.2/../../../../arm-none-linux-gnueabi/bin/ld:
> cannot find -levent
>
>  
>
> I tried adding –levent to COMPILE_FLAGS, but that didn’t work either.
>
>  
>
> set(COMPILE_FLAGS "-lrt –levent -Wall -lpthread")
>
>  
>
> Thoughts?
>
>  
>
>  
>
> Walter E. Gunter, Jr.
>
> Mechatronics Engineer/Roboticist
>
> AGV R
>
> Dematic North America
>
> 265 S 5200 W
>
> Salt Lake City, UT 84104  
>
> 801.715.2602
>
>  
>
> Customer Service 1.800.530.9153
>
>  
>
> *DEMATIC **l*We Optimize Your Supply Chain  www.dematic.com
> <http://www.dematic.com/>
>
> *MATERIAL HANDLING & LOGISTICS CONFERENCE * www.mhlc.com
> <http://www.mhlc.com/>
>
>  
>
> CONFIDENTIALITY NOTICE: This email message and any attachments to it,
> is intended only for the individual or entity to which it is addressed
> and may contain confidential material. If you are not the intended
> recipient, or the employee or agent responsible for delivering it to
> the intended recipient, please do not disclose, copy, forward, or
> retain. If you have received this in error, please contact the sender
> by reply email and destroy all copies of the original message. ​
>
>  
>
>
>

<>

signature.asc
Description: OpenPGP digital signature
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] How do you handle recursive dependencies in CMake

[Marcel Loose]

Hi Sven,

Sorry to chime in so late. I was wondering, since you're mentioning
large computer clusters, don't you use the "module" system to select
which versions of which packages you want to use? If so, then (I assume)
your PATH and LD_LIBRARY_PATH environment variables will have been set
such that the correct binaries and libraries can be found, right? CMake
also searches for libraries in the paths specified in the environment
variables PATH and LIB (unfortunately not LD_LIBRARY_PATH). Isn't that
the way to tackle this problem?

Cheers,
Marcel Loose.


On 30/06/16 13:42, Sven Baars wrote:
> Hey Ray,
>
> For myself it is not a big problem either, but I don't want to tell
> users of my libraries that they have to look up how the administrators
> at their supercomputing facility compiled 20 other libraries so they can
> set  their environment variables in the right way, while at the same
> time making my own CMakeLists.txt files much longer (because I would
> need many more find_package calls for dependencies of dependencies that
> I don't use). Whereas if CMake would just provide some means of using
> absolute paths instead of targets for libraries, or attach the
> information about those paths to the targets or something like that,
> this would never be a problem, since in that case everything would be
> found automatically.
>
> Also, it still doesn't make sense to me that instead of one find_package
> call for a package I actually use, I also need 20 find_package calls for
> dependencies of that other package. Also it doesn't make sense that I
> would actually need these find_package calls, whereas if the packages
> were just installed in /usr/lib or something it would work without any
> knowledge of this package even being used.
>
> Something that causes problems is the case where you use either A1 or
> A2. Then in B you would do something like
>
> option(B_USE_A2 OFF "Use package A2 instead of A1")
>
> if (NOT B_USE_A2)
> find_package(A1)
> if (A1_FOUND)
> ...
> target_link_libraries(B ${A1_LIBRARIES})
> ...
> else()
> set(B_USE_A2 ON)
> endif()
>
> if (B_USE_A2)
> find_package(A2)
> if (A2_FOUND)
> ...
> target_link_libraries(B ${A2_LIBRARIES})
> ...
> endif()
> endif()
>
> which makes sense, but then also in C instead of doing
>
> find_package(B)
> if (B_FOUND)
> target_link_libraries(C ${B_LIBRARIES})
> endif()
>
> you would also have to do
>
> if (B_FOUND)
> option(C_USE_A2 OFF "Use package A2 instead of A1, which is used in
> package B. Make sure C_USE_A2 is equal to what you used in package B as
> B_USE_A2")
>
> if (NOT C_USE_A2)
> find_package(A1)
> if (A1_FOUND)
> ...
> target_link_libraries(C ${A1_LIBRARIES})
> ...
> else()
> set(C_USE_A2 ON)
> endif()
>
> if (C_USE_A2)
> find_package(A2)
> if (A2_FOUND)
> ...
> target_link_libraries(C ${A2_LIBRARIES})
> ...
> endif()
> endif()
> target_link_libraries(C ${B_LIBRARIES})
> endif()
>
> or something like that, which is quite silly. Especially the part where
> compilation fails if B_USE_A2 is unequal to C_USE_A2. In general, my
> CMakeLists.txt is a lot more complicated, so I'd prefer the option where
> I only look for B.
>
> Sven
>
> On 06/30/2016 01:05 PM, Raymond Wan wrote:
>> Hi Sven,
>>
>>
>> On Thu, Jun 30, 2016 at 6:40 PM, Sven Baars <s.ba...@rug.nl> wrote:
>>> So let's take Trilinos as an example, which is quite a big library,
>>> which depends on a lot of libraries as well. In every project that
>>> builds upon it (but does not even use functionality of any libraries),
>>> we would have to set: SCALAPACK_ROOT, LAPACK_ROOT, BLAS_ROOT,
>>> BOOST_ROOT, GTEST_ROOT, BLACS_ROOT, UMFPACK_ROOT, MKL_ROOT, etc... and
>>> then inside the CMakeFiles.txt do a find_package(Trilinos),
>>> find_package(Scalapack), find_package(LAPACK), etc... just to compile
>>> int main() {} with one call to a Trilinos function inside of it. I'd say
>>> that it should be enough to just do a find_package(Trilinos).
>> Perhaps I'm alone here, but I actually don't see this as being a "big" 
>> problem.
>>
>> For the environment variables, you can place them all in a bash script
>> and source it during log in.
>>
>> For all of the Find_Package calls, they only matter whenever you have
>> to re-run cmake.  I don't know what Trilinos is, but for something
>&g

Re: [CMake] subversion

[Marcel Loose]

See also https://cmake.org/Bug/view.php?id=10200

Cheers,
Marcel Loose.


On 27/06/16 09:23, Andreas Naumann wrote:
> Thanks for the 6 year old hint. But obviously, the patch is not in any
> recent cmake version.
> Therefore, I could use it in my own project and ship my own
> FindSubversion.cmake.. which is quite ugly.
>  
> *Gesendet:* Montag, 27. Juni 2016 um 03:11 Uhr
> *Von:* Nagger <nag...@gmx.de>
> *An:* cmake@cmake.org
> *Betreff:* Re: [CMake] subversion
> Am 24.06.2016 um 19:48 schrieb Andreas Naumann:
>
> > At the moment, I check, if my directory is a working copy and if it is
> > not, the version variable is not defined. In my oppinion, it would be
> > better, if the macro from the subversion module would simply define a
> > variable "is_working_directory" instead of failing hard.
>
> See https://cmake.org/pipermail/cmake/2010-January/034862.html
>
>
> --
>
> Powered by www.kitware.com <http://www.kitware.com>
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For
> more information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
>

<>

signature.asc
Description: OpenPGP digital signature
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] subversion

[Marcel Loose]

Hi Andreas,

I think the FindSubversion module predates CMake 2.8, which introduced
"message(WARNING ...)". I think a warning would be better than an error
in this case; and I think the same argument holds for Subversion_WC_LOG,
which also generates an error if invoked from a non-working copy.

Cheers,
Marcel Loose.

Op 24-06-16 om 19:48 schreef Andreas Naumann:
> Dear cmake users,
> 
> I have a question if, and how, you use the Subversion module of cmake.
> The module provides the macro Subversion_WC_INFO, which extracts
> information of a working copy. I use this information, to generate a sub
> minor revision number of my project.
> If I checkout my project using svn, it works. But if I export it, the
> modules failes with a fatal error.
> At the moment, I check, if my directory is a working copy and if it is
> not, the version variable is not defined. In my oppinion, it would be
> better, if the macro from the subversion module would simply define a
> variable "is_working_directory" instead of failing hard.
> What do you think about this idea? How do you use the subversion module?
> The patch would be easy, and I would send one to the developer mailing
> list, if desired.
> 
> Regards,
> Andreas




signature.asc
Description: OpenPGP digital signature
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] How to set _default_ timeout for the ctest command?

[Marcel Loose]

Hi Alan,

Just by experimenting, I discovered that you also need to set
DART_TESTING_TIMEOUT. I'm not sure what the relationship (if any) is
between CTEST_TEST_TIMEOUT and DART_TESTING_TIMEOUT. I set them both in
the file CTestConfig.cmake. I get the feeling that DART_TESTING_TIMEOUT
is there for less than historic reasons. Maybe someone from Kitware can
shed a light on this.

Regards,
Marcel Loose.


On 09/12/15 07:33, Alan W. Irwin wrote:
> For the lapack CMake-based build and test system, some of the ctests
> can exceed 1500 seconds (the default limit) for special conditions
> (e.g, a quadruple-precision build of lapack that can be very slow). To
> reduce such issues without forcing users to use the ctest --timeout
>  option, the lapack developers would like to
> increase the default limit substantially above 1500 seconds.  Does
> anyone here know how to do that?
>
> I guessed that setting CTEST_TEST_TIMEOUT might do that, but when I
> experimentally set that to a small number (actually 1) (just before
> the first add_test command of another project I am completely familiar
> with (PLplot, natch)) the ctests that ran beyond that one second limit
> did not error out (i.e., I presume they were still using the 1500
> second default).  Note, the ctests I am referring to are simply run
> using the ctest command from the command line and are not submitted to
> a dashboard server.
>
> I presume another way to do it would be to set the TIMEOUT test property
> for every ctest, but that constitutes a maintanence issue, i.e., it
> is a pretty clumsy way to do it.
>
> So any ideas for setting the default timeout (either higher or lower
> than 1500) for ctests would be welcome.
>
> Alan
> __
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and
> Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __
>
> Linux-powered Science
> __

<>-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] CMake Version Compatibility Matrix

[Marcel Loose]

Hi all,

Is there any chance that the version compatibility matrix will be
updated for cmake 3.x features?

Best regards,
Marcel Loose.

attachment: loose.vcf-- 

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] Module CMakeParseArguments: confusing last paragraph in documentation

[Marcel Loose]

Hi all,

Several times I've read the last paragraph of the documentation of
module CMakeParseArguments, but I can't get my head around it.

Keywords terminate lists of values, e.g. if directly after a
one_value_keyword another recognized keyword follows, this is
interpreted as the beginning of the new option. E.g.
my_install(TARGETS foo DESTINATION OPTIONAL) would result in
MY_INSTALL_DESTINATION set to “OPTIONAL”, but MY_INSTALL_DESTINATION
would be empty and MY_INSTALL_OPTIONAL would be set to TRUE therefor.

Huh? [...] MY_INSTALL_DESTINATION will be set to OPTIONAL, but would
be empty [...] ???

Reading the first sentence of this paragraph, I concluded that
MY_INSTALL_DESTINATION will be empty, not would be.

Best regards,
Marcel Loose.

attachment: loose.vcf-- 

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] Module CMakeParseArguments: confusing last paragraph in documentation

[Marcel Loose]

I guess that would imply that not is missing twice,

[...] would not be empty [...]

and

[...] would not be set to TRUE [...].


Marcel.

On 24/02/15 12:31, Petr Kmoch wrote:
 My guess is there's a not missing between would and result in
 MY_INSTALL_DESTINATION set to

 Petr

 On Tue, Feb 24, 2015 at 12:05 PM, Marcel Loose lo...@astron.nl
 mailto:lo...@astron.nl wrote:

 Hi all,

 Several times I've read the last paragraph of the documentation of
 module CMakeParseArguments, but I can't get my head around it.

 Keywords terminate lists of values, e.g. if directly after a
 one_value_keyword another recognized keyword follows, this is
 interpreted as the beginning of the new option. E.g.
 my_install(TARGETS foo DESTINATION OPTIONAL) would result in
 MY_INSTALL_DESTINATION set to “OPTIONAL”, but
 MY_INSTALL_DESTINATION would be empty and MY_INSTALL_OPTIONAL
 would be set to TRUE therefor.

 Huh? [...] MY_INSTALL_DESTINATION will be set to OPTIONAL, but
 would be empty [...] ???

 Reading the first sentence of this paragraph, I concluded that
 MY_INSTALL_DESTINATION will be empty, not would be.

 Best regards,
 Marcel Loose.


 --

 Powered by www.kitware.com http://www.kitware.com

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

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

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

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

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



attachment: loose.vcf-- 

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] Include path perference

[Marcel Loose]

On 13/01/15 18:18, leemachine wrote:
 Hello all,

 I am using CMAKE 2.8.7:

 My question is I have a project that looks for dependencies (libraries and
 headers) in both the source tree (*CMAKE_SOURCE_DIR* and
 *CMAKE_CURRENT_SOURCE_DIR* as well as the *CMAKE_INSTALL_PREFIX*. The issue
 I am having is I'm making changes to the source tree that are not compatible
 with the header files installed in the *CMAKE_INSTALL_PREFIX*.

 In all the cmake message prints statements I make it returns the expected
 results. CMAKE is using .cc and .h files in the source tree even though the
 .h files are also in the *CMAKE_INSTALL_PREFIX*.

 When compiling I get an error relating to the incompatablity I mentioned.
 GCC is using the header files in the *CMAKE_INSTALL_PREFIX* and the .cc
 files in *CMAKE_CURRENT_SOURCE_DIR*

 How do I tell CMAKE to NOT use the header files in the
 *CMAKE_INSTALL_PREFIX*?

 I understand a fresh *CMAKE_INSTALL_PREFIX* would resolve this issue, but
 I'm looking for a workaround to that as well.

 Thanks,

 -Brandon



 --
 View this message in context: 
 http://cmake.3232098.n2.nabble.com/Include-path-perference-tp7589463.html
 Sent from the CMake mailing list archive at Nabble.com.
Hi Brandon,

I'm confused as to why you would want to look for dependencies in
CMAKE_INSTALL_PREFIX at all. The header files in there will (obviously)
always be (at least) one cycle behind with those in your source tree.

Cheers,
Marcel Loose.

attachment: loose.vcf-- 

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] Specifying different compilers for subsets of a project

[Marcel Loose]

Hi George,

You could (ab)use the assembler plugin system for that. Define your
own CMake-ASM-BGQ*.cmake files and use the assembler to compile the
sources.

Here's how I did this a couple of years ago for the BG/P.

In the CMakeLists.txt file for the files that need to be compiled with
the BG/P compiler I have:

## ---
## Enable BGP specific assembler.
## Use the BGP assembler also for linking C/C++ programs.
## ---
enable_language(ASM-BGP)
set(CMAKE_C_LINK_EXECUTABLE ${CMAKE_ASM-BGP_LINK_EXECUTABLE})
set(CMAKE_CXX_LINK_EXECUTABLE ${CMAKE_ASM-BGP_LINK_EXECUTABLE})

CMakeASM-BGPInformation.cmake:

set(ASM_DIALECT -BGP)
set(CMAKE_ASM${ASM_DIALECT}_SOURCE_FILE_EXTENSIONS S)
set(CMAKE_ASM${ASM_DIALECT}_COMPILE_OBJECT CMAKE_ASM${ASM_DIALECT}_COMPILER 
DEFINES FLAGS -c -o OBJECT SOURCE)
set(CMAKE_ASM${ASM_DIALECT}_LINK_EXECUTABLE CMAKE_ASM${ASM_DIALECT}_COMPILER 
FLAGS LINK_FLAGS OBJECTS  -o TARGET LINK_LIBRARIES)
include(CMakeASMInformation)
set(ASM_DIALECT)


CMakeDetermineASM-BGPCompiler.cmake:

set(ASM_DIALECT -BGP)
set(CMAKE_ASM${ASM_DIALECT}_COMPILER_INIT ${CMAKE_ASM_COMPILER})
include(CMakeDetermineASMCompiler)
set(ASM_DIALECT)

CMakeTestASM-BGPCompiler.cmake:

set(ASM_DIALECT -BGP)
include(CMakeTestASMCompiler)
set(ASM_DIALECT)


Hope this helps.

Regards,
Marcel Loose.

On 15/10/14 04:23, George Zagaris wrote:
 Dear all,

 I am working on a project where on certain platforms, namely, on a
 BG/Q or Cray, we have to cross-compile the code, but still, there are
 parts of the code that should only be compiled for the front end,
 login nodes.

 Typically, we have a toolchain file, which among other things sets:
 - CMAKE_CXX_COMPILER
 - CMAKE_C_COMPILER
 - CMAKE_FORTRAN_COMPILER

 to the respective cross-compilers available on the target platform.

 This compiles everything for the back-end.

 The obvious way to compile front-end tools is to create another
 directory, e.g., front-end-build and run cmake therein to
 re-configure and build with a front-end compiler.

 However, since only a relatively small subset of the files needs to be
 compiled for the front-end, it is desirable to do this within the same
 build, which leads to my question:

 Is it possible to tell CMake to build certain files with a different
 compiler? I know there is a way to set file properties to control the
 compiler flags of certain files. Is there a blessed approach to
 control the compiler for certain files and/or directories (and avoid
 things like set(CMAKE_CXX_COMPILER...) within a CMakeLists file)?

 Thank you very much for all your help.

 Best,
 George

  



attachment: loose.vcf-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] how to force assign sequence in multi-thread in cmake

[Marcel Loose]

Hi Yu,

I think you need to add an explicit dependency of main.cc on the
generated (well, not really generated, but installed) header file
crfpp.h. CMake has no clue as to what files are being compiled/installed
by your external project, so you have to make this explicit.

HTH,
Marcel Loose.


On 16/09/14 10:41, Yu Jing wrote:
 Hello  Micha ,

 It seems doesn’t work.
 I updated code , and move the external project to src , and it still
 not work.

 what should be noticed is :
 1. If I just use 
 $ make
 as make command ,all styles are work
 2. If I use in multi jobs
 $ make -j8
 It will run abnormal (not desired sequence) .


 On Sep 16, 2014, at 15:27, Micha Hergarden micha.hergar...@gmail.com
 mailto:micha.hergar...@gmail.com wrote:

 It may be that you have line 63 and 64 the wrong way around:
 ADD_SUBDIRECTORY(src)
 ADD_SUBDIRECTORY(lib)

 The externalproject is added in lib, but you add a dependency on it
 in src. CMake will descend in the subdirectories in the order you
 supply them.
 Does reversing the directories help?

 Regards,
 Micha

 On 09/16/2014 09:17 AM, Yu Jing wrote:
 I am in OSX 10.9.4 , a sample in  github is
 : https://github.com/yujing5b5d/cmake_sample
 after git clone this project , a operation like this :
 

 *yu:cmake_sample yu$ mkdir build*
 *yu:cmake_sample yu$ cd build/*
 *yu:build yu$ cmake ..*
 …. # skip some useless output
 -- Configuring done
 -- Generating done
 -- Build files have been written to:
 /Users/yu/Workspace/res/cmake_sample/build
 *yu:build yu$ make -j8 ### *
 Scanning dependencies of target LEVELDB_EX_PROJ
 Scanning dependencies of target iniparser
 Scanning dependencies of target relfiles
 Scanning dependencies of target CRFPP_EX_PROJ
 Scanning dependencies of target iniparser_static
 [ 15%] [ 15%] [ 20%] [ 20%] [ 25%] Building C object
 lib/iniparser/CMakeFiles/iniparser_static.dir/ini.c.o
 Creating directories for 'CRFPP_EX_PROJ'
 Creating directories for 'LEVELDB_EX_PROJ'
 Building C object lib/iniparser/CMakeFiles/iniparser.dir/ini.c.o
 Building CXX object src/CMakeFiles/relfiles.dir/main.cc.o
 [ 30%] [ 35%] Performing download step (git clone) for 'LEVELDB_EX_PROJ'
 Performing download step (git clone) for 'CRFPP_EX_PROJ'
 /Users/yu/Workspace/res/cmake_sample/src/main.cc
 http://main.cc/:3:10: fatal error: 'crfpp.h' file not found
 #include crfpp.h // crfpp
  ^
 Cloning into 'CRFPP_EX_PROJ'...
 Cloning into 'LEVELDB_EX_PROJ'...
 Linking C static library ../libiniparser.a
 Linking C shared library ../libiniparser.dylib
 [ 35%] [ 35%] Built target iniparser_static
 Built target iniparser
 Scanning dependencies of target cmake_sample
 [ 40%] Building CXX object src/CMakeFiles/cmake_sample.dir/main.cc.o
 /Users/yu/Workspace/res/cmake_sample/src/main.cc
 http://main.cc/:3:10: fatal error: 'crfpp.h' file not found
 #include crfpp.h // crfpp
  ^
 1 error generated.
 1 error generated.
 make[2]: *** [src/CMakeFiles/relfiles.dir/main.cc.o] Error 1
 make[2]: *** [src/CMakeFiles/cmake_sample.dir/main.cc.o] Error 1
 make[1]: *** [src/CMakeFiles/relfiles.dir/all] Error 2
 make[1]: *** Waiting for unfinished jobs
 make[1]: *** [src/CMakeFiles/cmake_sample.dir/all] Error 2
 ….
 

 BE CAREFUL OF THIS LINE :
 * yu:build yu$ make -j8*
 *
 *
 the ExternalProject CRFPP_EX_PROJ’s result contains copy a crfpp.h
  header to a special path, after this process , we can use #include
 “crfpp.h ,and If I use 
 make -j8
 this means 8 jobs can be running at the same time, I can not
 constraints and let my compiler compile my main.cc http://main.cc/
 after CRFPP_EX_PROJ finished.

 Of course , I’m not sure is this my misuse this project .



 On Sep 16, 2014, at 14:55, Micha Hergarden
 micha.hergar...@gmail.com mailto:micha.hergar...@gmail.com wrote:

 Hello all,

 I do use the ExternalProject to prebuild some binaries, without the
 'superproject' setup, and it does seem to work. Using the
 add_dependencies, I can make sure some third party libs are
 prebuild before I start to build my project. I have seen some
 issues with ExternalProject (failing to extract, or build), but
 they are too rare to pinpoint and create a bugreport.

 What exactly does not work? Is the external project not build at
 all, or just not in time?

 Regards,
 Micha

 On 09/16/2014 08:30 AM, Petr Kmoch wrote:
 Hi.

 I've never worked with ExternalProject myself, so I can't comment
 with certainty, but from what I understand, the correct way of
 using ExternalProject is to add your own project as an
 ExternalProject as well. Basically, the toplevel CMakeList becomes
 a superbuild which *only* does ExternalProject_Add() calls and
 does not add any libraries/executables directly. After you build
 the superbuild once to get all the dependencies correct, you
 switch to the external

[CMake] How to let CTest pass a signal (e.g. ctrl-c) to test program

[Marcel Loose]

Hi all,

I noticed that CTest doesn't seem to pass (Unix) signals to the test(s)
it is running. This is unfortunate, because some of my tests need to do
some cleanup when they receive a signal like SIGHUP, SIGINT, SIGQUIT, or
SIGTERM. When I run these tests manually from the command-line and
interrupt them with Ctrl-C, cleanup is done properly. However, if I run
them from CTest and interrupt them, cleanup is not done.

Is there a way to let CTest pass these signals? Or is there another
solution for this?

Best regards,
Marcel Loose.

attachment: loose.vcf-- 

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] Linker error with sub project's static libs

[Marcel Loose]

Hi Olaf,

See my reply below inline.

On 21/08/14 20:19, Olaf Peter wrote:
 Hello Marcel,
 Olaf,

 Unless your code snippets are incomplete, I'm missing the following
 statement in ./source/eea/ui/CMakeLists.txt

  target_link_libraries(eea_ui_lib
  eea_ui_schematic_lib)

 I'm not sure this is causing the link error, but it's worth a try.
 thank you a lot, this solves the linker problem - I have to add these
 twice, reference to the other lib each time.

 Furthermore, I think the order of add_subdirectory(), add_library(), and
 target_link_libraries() is important. You might want to check those
 as well.
 The order matches of course, but I haven't never such linker problems.
 The first time I'm using target_link_lib for a library self. The
 reason is not clear for me. What happens under the hood here?
Libraries can depend on one another. If code that produces libB uses
functions that are implemented in code that produces libA, then libB
depends on libA. When creating static libraries this doesn't make much
of a difference; after all a static library is just a bunch of object
files. However, when creating shared libraries it does. Shared library
libB will record internally that it depends on libA; something a static
library cannot do.

Suppose you're linking a main program that only uses functions defined
in libB. When using shared libraries, you only need to link your main
program against libB; remember, libB has recorded internally that it
depends on libA. However, when using static libraries you need to link
against libB and libA, even though your main program doesn't use any
functions in libA.

CMake to the rescue!

The only thing you have to tell CMake is that libB depends on libA,
using target_link_libraries(B A). CMake will then make sure that the
correct libraries on put on the link line in the correct order. There's
only one exception: circular dependencies. In that case you may need to
help CMake a bit. IMHO you should try very hard to avoid circular
library dependencies; they are a real PITA.
 Thanks,
 Olaf

Cheers,
Marcel Loose.
attachment: loose.vcf-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] How to deal with incompatible changes in interface of target_link_libraries()?

[Marcel Loose]

On 20/08/14 22:50, Alexander Neundorf wrote:
 On Tuesday, August 12, 2014 09:06:13 Brad King wrote:
 ...
 FYI, the only intended use case for setting a policy to OLD is to
 quiet warnings in a maintenance branch of an existing release.
 Some day support for OLD behavior of some policies may be dropped,
 so all project development moving forward should set the policy
 to NEW.
 Fixing a warning may make the project require the newer cmake version.
 E.g. if MyProject requires cmake 2.8.10, and there is a new policy in 3.0.0, 
 which generates a warning, a developer using cmake 3.0.0 may see the warning 
 and fix it, but by that he may have broken the build for the required 2.8.10 
 and actually now 3.0.0 is required.

 Alex
That's exactly the problem I keep running into. I want my project to be
compatible with any CMake 2.8.x, but also want it to run warning-free
with newer CMake versions, without having to resort to -Wno-dev. AFAIK
that can only be accomplished by setting some policies temporarily to
OLD. However, wrapping target_link_libraries() in a macro that
temporarily sets CMP0022 to OLD failed, due to scoping issues :(

Cheers,
Marcel
attachment: loose.vcf-- 

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] Linker error with sub project's static libs

[Marcel Loose]

Olaf,

Unless your code snippets are incomplete, I'm missing the following
statement in ./source/eea/ui/CMakeLists.txt

target_link_libraries(eea_ui_lib
eea_ui_schematic_lib)

I'm not sure this is causing the link error, but it's worth a try.

Furthermore, I think the order of add_subdirectory(), add_library(), and
target_link_libraries() is important. You might want to check those as well.

Cheers,
Marcel Loose.

On 21/08/14 13:29, Olaf Peter wrote:
 no idea here? It's seems to be a C++ problem, but how to solve it.
 Changing the order of

  target_link_libraries(eea
   eea_ui_schematic_lib
   eea_ui_lib

 to

  target_link_libraries(eea
   eea_ui_lib
   eea_ui_schematic_lib

 makes it even worser - more unresolved symbols. So what happens here?

 for my project I have the following structure in my project directory:

 ./CMakeLists.txt
 ./source/CMakeLists.txt
 ./source/eea/CMakeLists.txt
 ./source/eea/ui/CMakeLists.txt
 ./source/eea/ui/schematic/CMakeLists.txt

 with
 ---8---
 ./CMakeLists.txt:
 project(eea)
 ...

 ---8---
 ./source/CMakeLists.txt:
 add_subdirectory(eea)
 ...

 ---8---
 ./source/eea/CMakeLists.txt
 add_executable(eea ...)

 target_link_libraries(eea
  eea_ui_schematic_lib
  eea_ui_lib
  ...
 )

 qt5_use_modules(eea Widgets ...)

 add_subdirectory(ui)
 ...

 ---8---
 ./source/eea/ui/CMakeLists.txt
 project(eea_ui)
 ...
 set(eea_ui_SOURCE mainwindow_private.cpp graphics_view.cpp...)
 add_library(eea_ui_lib STATIC
  ${eea_ui_SOURCE}
  ...
 )

 qt5_use_modules(eea_ui_lib Widgets ...)

 add_subdirectory(schematic)
 ...
 ---8---
 ./source/eea/ui/schematic/CMakeLists.txt:
 project(eea_ui_schematic)
 ...
 set(eea_ui_schematic_SOURCE schematics_view.cpp ...)
 add_library(eea_ui_schematic_lib STATIC
  ${eea_ui_schematic_SOURCE}
  ...
 )

 qt5_use_modules(eea_ui_schematic_lib Widgets ...)

 So far, so good - all compiles.



 With
 ---8---
 ./source/eea/ui/mainwindow_private.cpp :
 ...
 createWindows() {
  SchematicView* schematicView = new SchematicView(q);
  ...
 }

 ---8---
 ./source/eea/ui/graphics_view.cpp:
 GraphicsView::GraphicsView(QWidget* parent) { ...  }

 ---8---
 ./source/eea/ui/schematic/schematic_view.cpp
 class SchematicView
 : public GraphicsView
 {  }


 I got the linker error:

 ../../lib/libeea_ui_lib.a(mainwindow_private.cpp.o): In function
 `eea::ui::MainWindowPrivate::createWindows()':
 mainwindow_private.cpp:(.text+0xbb): warning: undefined reference to
 `eea::ui::SchematicView::SchematicView(QWidget*)'

 So, what happened here and how to solve it? Before the contents of
 ui/schematic moved into the ui directory/project and I've got no errors.

 Thanks,
 Olaf


attachment: loose.vcf-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] How to deal with incompatible changes in interface of target_link_libraries()?

[Marcel Loose]

Op 12-08-14 om 15:06 schreef Brad King:
 On 08/12/2014 03:48 AM, Marcel Loose wrote:
 On a side note. Even using the new PRIVATE and PUBLIC keywords I am
 unable to exactly specify which libraries are needed for linking.
 
 Can you provide a concrete example of this trouble?
I've further analyzed the problem, and figured out that the troubles I'm
facing are caused by the way I add libraries and executables to the
build. It's no big deal. Like I said, modern versions of ld will get rid
of unused libraries anyway, so the only remaining problem would be some
increased link time. I can live with that.
 
 -Brad
 
Cheers,
Marcel.

-- 

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] No Such File or Directory

[Marcel Loose]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Op 16-08-14 om 22:02 schreef David Zemon:
 Hello,
 
 After downloading the 3.0.1 binary Linux distribution of CMake, I
 am running into the following bash error:
 
 *david@fresh-ubuntu:~/**PropWare/util$* cmake bash:
 /home/david/cmake-3.0.1-Linux-i386/bin/cmake: No such file or 
 directory *david@fresh-ubuntu:~/**PropWare/util$* which cmake 
 /home/david/cmake-3.0.1-Linux-i386/bin/cmake 
 *david@fresh-ubuntu:~/**PropWare/util$* 
 /home/david/cmake-3.0.1-Linux-i386/bin/cmake bash:
 /home/david/cmake-3.0.1-Linux-i386/bin/cmake: No such file or 
 directory *david@fresh-ubuntu:~/PropWare/util$*
 
 Does anyone have any idea why? This problem seems to have existed
 for quite a long time as I am seeing evidence of it 
 http://www.cfd-online.com/Forums/openfoam/64045-cmake-no-such-file-directory.html

 
as far back as 2009.
 
 The system in question is a fresh installation of Ubuntu 14.04
 64-bit running in VirtualBox. CMake has never been installed on the
 machine before. The only non-default packages installed are git,
 vim, make and VirtualBox Guest Additions.
 
 Thanks, David
 
 
Hi David,

- From the directory name where your cmake resides, I gather this is a
32-bit version. If you have a 64-bit Ubuntu, then you must install the
32-bit libraries. Unfortunately, bash its error message is far from
clear in that respect :(

Usually, it boils down to installing the package ia32-libs, but I
heard some rumors that more recent Ubuntu's no longer support
multi-arch by default. In that case you might need to run the
following command:

sudo dpkg --add-architecture i386

After that you will be able to install all 32-bit libraries at once
(package ia32-libs), or one at a time, by just specifying the
architecture of the package, e.g. libc6:i386.

Hope this helps,
Marcel Loose.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJT7+UrAAoJEEpMyb1AIWdYH8EH/2xcKu1vtXuoGvMDEzFZwkos
DRsR3BPjiU5MYyoGIaatIH7N4ioR6r0vniS4r+BP4qDqbt33Wuv/UHTMbGTN3iyf
4HCJI3xCEO6MCDpkhl59EciRyQb4GmFM9pi/NYDzTUaPvfQoLQ/ZldHaP0jkm72q
AEt51Y1bsc3p822Hv68AD2BFDwkf2VUsg+ooB1vhlo1qn0nlbyAqkmk0nSKs2thh
Zsi0gbfxuRNFILUBC8pvMw62QSmcqYZD6SaYViFGvCUMSn7If8nJvEwiVWKpcOr3
+agyi8a6adAiHGI/AMtzB0DJYB82olMwjhR19H9rIaaAcxdxefNRs6951b4J31k=
=No1X
-END PGP SIGNATURE-
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] How to deal with incompatible changes in interface of target_link_libraries()?

[Marcel Loose]

On 11/08/14 18:47, Brad King wrote:
 On 08/09/2014 09:46 AM, Marcel Loose wrote:
 CMake 2.8.12 introduced the keywords PRIVATE, INTERFACE and PUBLIC, and
 immediately deprecated the LINK_INTERFACE_LIBRARIES keyword,
 triggering policy warnings CMP0022 and CMP0023.

 What is the proper way to get rid of these policy warnings, while at
 the same time staying backward compatible with older CMake versions?
 From the documentation of CMP0022:

  Warning-free future-compatible code which works with CMake 2.8.9
   onwards can be written by using the LINK_PRIVATE and LINK_PUBLIC
   keywords of target_link_libraries().

 Actually it should say 2.8.7, not 2.8.9.  CMP0023 docs mention 2.8.7.

 -Brad
Hi,

Another problem I faced with policy CMP0022 is that I was unable to
really silence it. Setting the policy to OLD doesn't really work (at
least not in my case), maybe because the cmake_policy() command is
scoped(?). I have a macro that contains the now deprecated use of
LINK_INTERFACE_LIBRARIES, so I thought I could simply wrap that
statement inside the following code block:

if (POLICY CMP0022)
cmake_policy(PUSH)
cmake_policy(SET CMP0022 OLD)
endif()
target_link_libraries (... LINK_INTERFACE_LIBRARIES ...)
if (POLICY CMP0022)
cmake_policy(POP)
endif()

But that doesn't seem to work. I still get the policy warnings for
CMP0022. Also setting the policy to OLD once at top-level doesn't seem
to work; probably due to policy scoping. I played a bit with
NO_POLICY_SCOPE to different include() and find_package() statements,
but to no avail.

Regards,
Marcel Loose.


attachment: loose.vcf-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] How to deal with incompatible changes in interface of target_link_libraries()?

[Marcel Loose]

On 11/08/14 18:47, Brad King wrote:
 On 08/09/2014 09:46 AM, Marcel Loose wrote:
 CMake 2.8.12 introduced the keywords PRIVATE, INTERFACE and PUBLIC, and
 immediately deprecated the LINK_INTERFACE_LIBRARIES keyword,
 triggering policy warnings CMP0022 and CMP0023.

 What is the proper way to get rid of these policy warnings, while at
 the same time staying backward compatible with older CMake versions?
 From the documentation of CMP0022:

  Warning-free future-compatible code which works with CMake 2.8.9
   onwards can be written by using the LINK_PRIVATE and LINK_PUBLIC
   keywords of target_link_libraries().

 Actually it should say 2.8.7, not 2.8.9.  CMP0023 docs mention 2.8.7.

 -Brad
Hmm,

That's probably in the CMake 3.0.x docs; CMake 2.8.12 doesn't mention
LINK_PUBLIC and LINK_PRIVATE in the policy documentation. I only read
the following in the docs on target_link_libraries

   The LINK_PUBLIC and LINK_PRIVATE modes can be used to specify
both the
   link dependencies and the link interface in one command.  This
   signature is for compatibility only.  Prefer the PUBLIC or PRIVATE
   keywords instead. 

... for compatibility only didn't give me the feeling that this is the
way to go, which is underscored by the next sentence: Prefer the ...

On a side note. Even using the new PRIVATE and PUBLIC keywords I am
unable to exactly specify which libraries are needed for linking.
Without breaking builds with static libraries, I am forced to specify
too many library dependencies. Maybe I'm doing something wrong, but my
setup is quite complicated. Fortunately, modern version of ld will get
rid of unused libraries anyway, so it's not really that much of an issue
for me.

Regards,
Marcel Loose.
attachment: loose.vcf-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] How to deal with incompatible changes in interface of target_link_libraries()?

[Marcel Loose]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi all,

I'm struggling with the problem that CMake 2.8.12 introduced
incompatible changes in the interface of target_link_libraries()
w.r.t. dealing with direct and indirect (transitive) link
dependencies. Pre-2.8.12 you would use the keyword
LINK_INTERFACE_LIBRARIES to indicate indirect link dependencies. CMake
2.8.12 introduced the keywords PRIVATE, INTERFACE and PUBLIC, and
immediately deprecated the LINK_INTERFACE_LIBRARIES keyword,
triggering policy warnings CMP0022 and CMP0023.

What is the proper way to get rid of these policy warnings, while at
the same time staying backward compatible with older CMake versions? I
need to support all 2.8.x versions, but I don't want to set these
policies to OLD. I also don't want to wrap each call to
target_link_libraries() inside a conditional

if (${CMAKE_VERSION} VERSION_LESS 2.8.12)
...
else()
...
endif()

Of course I could put this logic in a macro, but how then do I handle
the new keywords. Some hints or tips would be very much appreciated.

Kind regards,
Marcel Loose.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJT5iYxAAoJEEpMyb1AIWdYFR4IAJXH0KV9dc8cCPItf2R1UTTS
dkdvoqJtRRqKIS/fyQv4VHsbqP0DqH9qlCjc6O6h27I461PUwwfk+hYNDQI+q5wH
SKu3kosT4rIxDg+CmGr/yhzSdzuWKyhRu+L4syunoOxeXXreKSzSIrTvdRA1fPZg
aSJR4hvnA5cDUA/0pdV9pPKm4JATK8s2/S64PPjA2CRbq6pZfnnX4tRrQMnkt/+S
R1xmmVVzcuctdIAdanUnDlTfRHMNOyY3uWozXkO2OCeTFJLc00xQcvJdcr2zXyRx
EtvpFVmBU9IsAu4LY3gZZfjWwpwsMyYptaYSSF7oDJjshw5LctObJZ89jgFhtmw=
=RhRJ
-END PGP SIGNATURE-
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Getting the svn revision number of our source.

[Marcel Loose]

Hi,

The command

SET(ENV{LC_ALL} C)

somewhere inside your cmake macro will do the trick. If you really care
about the original contents of LC_ALL you should save it first and
restore once your done.

BTW: you might consider using the Subversion_WC_INFO() macro in the
FindSubversion module.

Cheers,
Marcel Loose.


On 02/07/14 09:04, Eric Noulard wrote:
 May be you can avoid localized output by setting LANG env var to C.


 Or you can ask svn for xml output which may not be localized e.g.

 # Get the SVN revision number of an svn command line client is
 # available.  This version will run at build time rather than only
 # at configuration generation time.
 FIND_PROGRAM(SVN_EXECUTABLE svn
   DOC subversion command line client)

 # only do this if we have an svn client.
 if (SVN_EXECUTABLE)
 MACRO(Subversion_GET_REVISION dir variable)
   EXECUTE_PROCESS(COMMAND ${SVN_EXECUTABLE} --xml info ${dir}
 OUTPUT_VARIABLE ${variable}
 OUTPUT_STRIP_TRAILING_WHITESPACE)
   STRING(REGEX REPLACE .*entry.*revision=\([0-9]+)\\n.*kind.*
 \\1 ${variable} ${${variable}})
 ENDMACRO(Subversion_GET_REVISION)

 Subversion_GET_REVISION(${CMAKE_SOURCE_DIR} ORX_BLD_LVL)
 endif ()

 message(STATUS SVN Revision Number is ${ORX_BLD_LVL})




 2014-07-02 1:04 GMT+02:00 Rick McGuire object.r...@gmail.com
 mailto:object.r...@gmail.com:

 We like to include the SVN revision number in our build artifacts
 to help keep track of what version people are working with.  I
 found the following code on the mailing lists which appears to
 work fine:  

 # Get the SVN revision number of an svn command line client is
 # available.  This version will run at build time rather than only
 # at configuration generation time.
 FIND_PROGRAM(SVN_EXECUTABLE svn
   DOC subversion command line client)

 # only do this if we have an svn client.
 if (SVN_EXECUTABLE)
 MACRO(Subversion_GET_REVISION dir variable)
   EXECUTE_PROCESS(COMMAND ${SVN_EXECUTABLE} info ${dir}
 OUTPUT_VARIABLE ${variable}
 OUTPUT_STRIP_TRAILING_WHITESPACE)
   STRING(REGEX REPLACE ^(.*\n)?Revision: ([^\n]+).*
 \\2 ${variable} ${${variable}})
 ENDMACRO(Subversion_GET_REVISION)

 Subversion_GET_REVISION(${CMAKE_SOURCE_DIR} ORX_BLD_LVL)
 endif ()

 message(STATUS SVN Revision Number is ${ORX_BLD_LVL})

 Unfortunately, the first person not in the core team who building was 
 running a Spanish language version of SVN, so the ORX_BLD_LEVEL variable 
 ended up with the entire output of the svn info command because it could not 
 find the string REVISION.  This was not a good thing!

 Is there a better way to obtain the SVN revision number that does not 
 suffer from this sort of problem?

 Rick


 --

 Powered by www.kitware.com http://www.kitware.com

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

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

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

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

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




 -- 
 Erk
 L'élection n'est pas la démocratie -- http://www.le-message.org



attachment: loose.vcf-- 

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] header files/build orgainization with cmake

[Marcel Loose]

Hi Majo,

We have a similar situation. I assume you want to use lib1 in proj2 at
build time, without doing a separate install. The way I solved this
involves symbolic links, which AFAIK only work on Unix-like systems.

We have an include directory inside the build directory that is
populated with symbolic links to the diverse directories containing
header files at cmake configure time. So, in your case there should be a
symbolic link ${CMAKE_BINARY_DIR}/include/lib1 that points to
${CMAKE_SOURCE_DIR}/lib1/include. Then, somewhere at the top of your
main CMakeLists.txt file you should add ${CMAKE_BINARY_DIR}/include to
the include path using include_directories().

Now proj2 should be able to locate lib1/lib1.h through the symbolic
link, because ${CMAKE_BINARY_DIR}/include is in the -Ipath.

Hope this helps.

Regards,
Marcel Loose.

On 17/06/14 13:46, majo huber wrote:
 Hi @all,

 I have a question regarding the organization of the header files of
 libraries.
 I have a meta project with following structure:

 metaproj1/
 |-- CMakeLists.txt
 |-- lib1/
 |-- include/
 |   |
 |   `-- lib1.h
 |   |-- CMakeLists.txt
 |   `-- lib1.c
 `-- proj2/
 |-- CMakeLists.txt
 `-- main.c

 The meta project contains several other projects not mentioned here.
 I would like to be able to do following things.
 - the lib1 project should be usable in any other meta project without
 any changes to the library. E.g. in metaproject metaproj2
 - install library header file to include/lib1/ in the system (e.g.
 /usr/local/include/lib1/lib1.h)
 - include in any other source like that: #include lib1/lib1.h (see
 following examples)
   - include the header from the system location it is installed in
 (e.g. /usr/local/include/lib1/lib1.h) ( with #include lib1/lib1.h)
   - include the header from project proj2 with #include lib1/lib1.h
 (for builds from inside the meta project without installing the library)
  
 One approach I thought of is the following:
 - copy all installed header files to a temp. build directory named lib1
 - set variable LIB1_INCLUDE_DIR to point to that directory
 - use the variable with include_directories(${LIB1_INCLUDE_DIR}) in proj2

 I know that there is a mechanism called find_package(), but if I am
 correct this does not allow to have a different directory inside the
 library for the headers (include) and as installation path (lib1/), right?

 Now I wanted to know if there is any better solution to my problem?


 Thanks in Advance,
 majo



attachment: loose.vcf-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMake master slowdown in generation step

[Marcel Loose]

On 04/04/14 12:45, Nils Gladitz wrote:
 CMake execution time of one of my projects jumps from 0m6.121s
 (2.8.12.2) to 1m5.084s (3.0.20140404-gce0aa).

 Most time seems to be spend after -- Configuring done.

 Any ideas?

 Nils
Maybe this http://public.kitware.com/Bug/view.php?id=14758 has something
to do with it?

Cheers,
Marcel.

attachment: loose.vcf-- 

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/cgi-bin/mailman/listinfo/cmake-developers

Re: [CMake] Regarding option for regenerating CMakeCache everytime we do cmake

[Marcel Loose]

On 24/03/14 11:01, Devyani Godbole wrote:
 Hi ,
 I am getting a problem wherein the if I add the flag say -DWITH_DATE=1
 and do a cmake I get it enabled. But now if I do not use this flag and
 again do cmake , it still remains DEFINED i.e. it is still present in
 CMakeCache.

 I do not want it to be DEFINED if I have not specified it in cmake
 command line. i.e. I want the CMakeCache to be rebuilt everytime I do
 a cmake.

 Is there any way by which I can do this?


 -- 
 -- Devyani S. Godbole


Hi Devyani,

You can use the -U option to remove WITH_DATE from the cache: cmake
-UWITH_DATE [whatever options you want to pass to cmake].

Other than that, if you want to rebuild the cache, why not simply delete
it before you run cmake?

Regards,
Marcel Loose.



attachment: loose.vcf-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake 3.0-rc1 now ready for testing!

[Marcel Loose]

That's a nice long list ;)

I noticed when building this RC on Ubuntu 13.10, that 'make test' fails:

$ make test
Running tests...
make: Bootstrap.cmk/ctest: Command not found
make: *** [test] Error 127

Copying ./bin/ctest to ./Bootstrap.cmk solves this issue.

Best regards,
Marcel Loose.

On 28/02/14 20:28, Robert Maynard wrote:
 I am proud to announce that CMake 3.0 has entered the release candidate stage.

 Sources and binaries are available at:
   http://www.cmake.org/files/v3.0/?C=M;O=D

 Documentation is available at:
   http://www.cmake.org/cmake/help/v3.0

 Release notes appear below and are also published at
   http://www.cmake.org/cmake/help/v3.0/release/3.0.0.html

 Some of the more significant features of CMake 3.0 are:
 * Compatibility options supporting code written for CMake versions
   prior to 2.4 have been removed.

 * The CMake language has been extended with *Bracket Argument* and
   *Bracket Comment* syntax inspired by Lua long brackets.

 * The CMake documentation has been converted to reStructuredText and
   uses Sphix generation.

 * Generators for Visual Studio 10 (2010) and later were renamed to
   include the product year like generators for older VS versions:
   * Visual Studio 10 - Visual Studio 10 2010
   * Visual Studio 11 - Visual Studio 11 2012
   * Visual Studio 12 - Visual Studio 12 2013
   This clarifies which generator goes with each Visual Studio version.
   The old names are recognized for compatibility.

 * A new CodeLite extra generator is available for use with the
   Makefile or Ninja generators.

 * A new Kate extra generator is available for use with the
   Makefile or Ninja generators.

 * The add_library() command learned a new INTERFACE library
   type. Interface libraries have no build rules but may have
   properties defining usage requirements and may be installed,
   exported, and imported.  This is useful to create header-only
   libraries that have concrete link dependencies on other libraries.

 * The export() command learned a new EXPORT mode that retrieves
   the list of targets to export from an export set configured by the
   install(TARGETS) command EXPORT option.  This makes it easy to
   export from the build tree the same targets that are exported from
   the install tree.

 * The project() command learned to set some version variables to
   values specified by the new VERSION option or to empty strings.
   See policy CMP0048.

 * Several long-outdated commands that should no longer be called
   have been disallowed in new code by policies:
   * Policy CMP0029 disallows subdir_depends()
   * Policy CMP0030 disallows use_mangled_mesa()
   * Policy CMP0031 disallows load_command()
   * Policy CMP0032 disallows output_required_files()
   * Policy CMP0033 disallows export_library_dependencies()
   * Policy CMP0034 disallows utility_source()
   * Policy CMP0035 disallows variable_requires()
   * Policy CMP0036 disallows build_name()


 CMake 3.0.0 Release Notes
 *

 Changes made since CMake 2.8.12.2 include the following.

 Documentation Changes
 =
 * The CMake documentation has been converted to reStructuredText and
   now transforms via Sphinx (http://sphinx-doc.org) into man and html
   pages.  This allows the documentation to be properly indexed and to
   contain cross-references.

   Conversion from the old internal documentation format was done by an
   automatic process so some documents may still contain artifacts.
   They will be updated incrementally over time.

   A basic reStructuredText processor has been implemented to support
   cmake --help-command and similar command-line options.

 * New manuals were added:
   * cmake-buildsystem(7)

   * cmake-commands(7), replacing cmakecommands(1) and
 cmakecompat(1)

   * cmake-developer(7)

   * cmake-generator-expressions(7)

   * cmake-generators(7)

   * cmake-language(7)

   * cmake-modules(7), replacing cmakemodules(1)

   * cmake-packages(7)

   * cmake-policies(7), replacing cmakepolicies(1)

   * cmake-properties(7), replacing cmakeprops(1)

   * cmake-qt(7)

   * cmake-toolchains(7)

   * cmake-variables(7), replacing cmakevars(1)


 * Release notes for CMake 3.0.0 and above will now be included with
   the html documentation.

 New Features
 

 Syntax
 --
 * The CMake language has been extended with *Bracket Argument* and
   *Bracket Comment* syntax inspired by Lua long brackets:

  set(x [===[bracket argument]===] #[[bracket comment]])

   Content between equal-length open- and close-brackets is taken
   literally with no variable replacements.

   Warning: This syntax change could not be made in a fully
 compatible way. No policy is possible because syntax parsing
 occurs before any chance to set a policy.  Existing code using an
 unquoted argument that starts with an open bracket will be
 interpreted differently without any diagnostic.  Fortunately the
 syntax is obscure enough

Re: [CMake] Path vs. name preference during search.

[Marcel Loose]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

For more discussion on the search order of PATHS and NAMES used by the
different Find_* commands see, e.g.:

http://www.cmake.org/pipermail/cmake/2009-October/032565.html
http://www.cmake.org/pipermail/cmake/2010-March/035889.html
http://public.kitware.com/Bug/view.php?id=10718

The current CMake behaviour is not likely to change. IIRC, Bill
Hoffman once explained that the NAMES option was introduced to specify
name *aliases* like 'gtk' 'gtk12' in FindGTK.cmake. It was *not* meant
to specify a list of names for *different* entities.

Best regards,
Marcel Loose.

op 14-02-14 09:02, Jakub Zakrzewski schreef:
 Hi,
 
 what about searching multiple times, each time giving only the path
 you want (in order of prefference)? If I'm correct, once the
 library is found, next attempts to find it againg will be a no-op.
 
 
 
 --
 
 Gruesse,
 
 Jakub
 
 
 
 
 
 *From:*CMake [mailto:cmake-boun...@cmake.org] *On Behalf Of *Rob
 McDonald *Sent:* Donnerstag, 13. Februar 2014 19:21 *To:*
 Jean-Christophe Fillion-Robin *Cc:* CMake ML *Subject:* Re: [CMake]
 Path vs. name preference during search.
 
 
 
 Jc,
 
 
 
 That is an approach I have thought about.  I even think I have
 looked at Slicer for how you work your CMake system.
 
 
 
 I prefer to use project-supplied FindLIB.cmake (or a slightly
 modified version thereof) because some of them do more than just
 setting LIBRARY, INCLUDE_DIR, and FOUND variables.
 
 
 
 Rather than duplicate everything done in the FindLIB.cmake script
 (which can have platform-dependent logic), I have gone the path of
 encouraging the FindLIB.cmake to find the one I want.
 
 
 
 Rob
 
 
 
 
 
 On Thu, Feb 13, 2014 at 10:09 AM, Jean-Christophe Fillion-Robin 
 jchris.filli...@kitware.com mailto:jchris.filli...@kitware.com
 wrote:
 
 Hi Rob,
 
 Do address the use case you described, I usually explicitly set the
 path the library when built as an external project and rely only on
 the find_* command for the use_system case.
 
 See 
 https://github.com/Slicer/Slicer/blob/c5a39acf7af28ba82cc0097c84d1ebda89cce3b4/SuperBuild/External_teem.cmake#L13-16

  Hth
 
 Jc
 
 
 
 On Thu, Feb 13, 2014 at 12:51 PM, Rob McDonald
 rob.a.mcdon...@gmail.com mailto:rob.a.mcdon...@gmail.com
 wrote:
 
 When I search for a given library, specifying multiple possible 
 names and multiple hints for paths...
 
 
 
 FIND_LIBRARY( FINDME_LIB
 
 NAMES name1 name2 name3
 
 HINTS path1 path2 path3
 
 DOC Library to find)
 
 
 
 CMake seems to have a preference for name1, and it first searches 
 all HINTS for name1.  If it doesn't find name1, it moves to name2 
 and then searches all HINTS for name2, etc.
 
 
 
 I would prefer to have a preference for path1, no matter the name. 
 Try for all names in path1, then move to path2, etc.
 
 
 
 Is there a way to toggle this behavior?
 
 
 
 Rob
 
 
 
 
 
 Background...  Basically, I am using ExternalProject_Add to build
 a library.  However, to make it possible to use the system-library 
 instead, this is optional.  I use a FindThelib.cmake so the main 
 project works seamlessly either way.
 
 
 
 I'm targeting the case where a version of this library is
 installed on the system, but I want to use my own copy.
 
 
 
 The name of the library depends on build options and platform, so 
 controlling on the name is a little fragile.  However, I have 
 explicitly built it in a known directory, so having preference for 
 the known directory is desirable.
 
 
 
 --
 
 Powered by www.kitware.com http://www.kitware.com
 
 Please keep messages on-topic and check the CMake FAQ at: 
 http://www.cmake.org/Wiki/CMake_FAQ
 
 Kitware offers various services to support the CMake community.
 For more information on each offering, please visit:
 
 CMake Support: http://cmake.org/cmake/help/support.html CMake
 Consulting: http://cmake.org/cmake/help/consulting.html CMake
 Training Courses: http://cmake.org/cmake/help/training.html
 
 Visit other Kitware open-source projects at 
 http://www.kitware.com/opensource/opensource.html
 
 Follow this link to subscribe/unsubscribe: 
 http://www.cmake.org/mailman/listinfo/cmake
 
 
 
 
 -- +1 919 869 8849 tel:%2B1%20919%20869%208849
 
 
 
 
 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJS/eiRAAoJEEpMyb1AIWdYJjwH/0IQjZhRXHVu2Z9UsFgGpPp6
m9EG9dEfRFoasd9QrmWwpl+JXTPlqHwS9xJO4QZFjJV4k86VwW9SxCheNaoVX+ro
k4DBzdpsCniMxIwal03dICnPZjjZsNVGI2B5xayRW5spTn48kBWI0nA7OaDii/Ib
p4/RK4hFBKbt89NAl/8u2fO36KFXCkro826lvLpIlmZ52rev35S3hZ8OuwNC4JIH
PUKBxo7VM8Qg0MqSVsHL2rl3J9Uf88miTUKW0rO9fvHup969rqyqmjjpABRA4OK0
eQ0cVVoe2K//bLr4v+FiX/sb535qtfJDqlAevkvp24wOt5zM0erPyE162MbAcnE=
=CcZH
-END PGP SIGNATURE-
-- 

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

Re: [CMake] include_directories(...) versus set_directory_properties(PROPERTIES INCLUDE_DIRECTORIES ...)

[Marcel Loose]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

op 10-02-14 13:38, David Cole schreef:
 Should I file this as a bug in the issue tracker then?
 
 
 Sure. Especially if you have an easy way to reproduce. (Either
 reference an external, publicly available project we can just
 build and get it to happen, or attach a CMakeLists that
 demonstrates the issue if possible.)
 
 That way, we can reproduce it ourselves, and verify that any fix
 we propose actually improves the situation for the reproduce case.
 
 
 Thanks, David C.
 
Hi David,

For what it's worth. This problem is related to another issue I
reported: http://public.kitware.com/Bug/view.php?id=14094. Here I also
got a quite long, but still manageable list of include directories.

Regards,
Marcel Loose.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJS+q1tAAoJEEpMyb1AIWdYF4IH/39GG3zfrq9wn3SWpDG2Vu1v
Ce1EGrEIP4r7K10S0rhhEqXaYw7u/WWkp9NztaL/hilhJFP4MsdmJHkG+5TP3F+z
FbiK8mGfZ3llrZT2MHDuQXWI50hBaZlyof1Xiabrww37zEtaOhMvBKRnVfn7oI2b
KBF1k/jOOVM2/Z/RBJzdf1oHKHDgbk/ue7MVpSTTuwNndpryDkAYFy+9ettG1hLv
pLWVP3zzV/xwxOUf44f6Fu6KQ9UhD8Qf1HmDSbaR4fBr+ARxhdU5cckrnjY0Wiyk
dALtDFi24N3BPp7ZMHwlB1h0ujMrfJxdb7YDHADK8KM9HIGqpLlMkQbaegjuAY8=
=8JWY
-END PGP SIGNATURE-
-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Using a toplevel CMakeList.txt to build all sub projects at once.

[Marcel Loose]

On 06/02/14 07:14, PCMan wrote:
 Hello,
 I'm PCMan, one of the developers of LXDE desktop (now LxQt after
 merged with Razor-qt project).
 http://lxde.org/ and http://razor-qt.org/

 We're migrating from gtk+ to Qt and autotools to CMake and encountered
 some issues.
 There are many small modules or components in our project.
 Each of them has their own CMakeLists.txt and can be built separately.
 However, it's hard to build so many projects manually.
 So we'd like to create a toplevel CMakeLists.txt to build them all at once.
 However, the small projects depend on each other.
 For example, our project layout look like this:

 libqtxdg - a base lib required by others
 liblxqt - a library depends on libqtxdg
 lxqt-config - a tool depends on liblxqt and libqtxdg.

 To build lxqt-config, liblxqt and libqtxdg need to be installed first.
 So simply adding them using add_subdirectoyy() won't work.
 When configuring lxqt-config, liblxqt needs to be installed first.
 To configure and compile liblxqt, cmake modules and headers from
 libqtxdg are required so libqtxdg needs to be installed first.

 Is it possible to use CMake to build them all at once since one
 component requires that the other is installed first.

 Even worse, two of our components are still automake-based.
 The cmake ExternalProject_Add() command did not solve the problem that
 some of them needs to be installed first before others can be
 compiled.

 I tried to google and read the existing docs but remain clueless.
 We're stuck! Any help is really appreciated.
 Thank you very much!
Hi PCMan,

It depends very much on what you mean by installed. We're in a similar
situation. We have a lot of so-called packages in our project, that can
depend on other (internal) packages. I've setup a build system, using
CMake, that can build these packages in the right order without actually
installing them. We don't have any Autotools-based packages, but it
shouldn't be too hard (I guess) to wrap these as a separate package.

Best regards,
Marcel Loose.



attachment: loose.vcf-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] AStyle or similar code beautifier

[Marcel Loose]

On 31/01/14 14:11, Paul Smith wrote:
 On Fri, 2014-01-31 at 02:26 -0800, Alan W. Irwin wrote:
 And to answer the OP's question, I can highly recommend uncrustify for
 code styling
 I agree with Alan.  We did a huge reformatting effort last year to
 change a very large C++ codebase from a style based loosely on
 Whitesmith to a more common style.  I started with AStyle which is a
 solid program, but it has limited customization support.

 Then I found uncrustify and was quite satisfied with it.  I sent a few
 patches for minor fixes and they were well received.  The main issue
 with uncrustify is that the documentation could be better: for some of
 the more advanced settings it's very hard to understand exactly what
 they control.
That's why I like universalindentgui, a standard Ubuntu package. You can
immediately see what changes will be made to the code when you fiddle
with one of the many settings in uncrustify (assuming it has effect on
the source file you're viewing).

 I had to do a bit of scripting around it since uncrustify didn't handle
 all the whitespace conversion we wanted, but it worked great!

 We didn't try to integrate it with the build system.  We just checked in
 the configuration file and a script people could use if they wanted to
 re-beautify their code.


attachment: loose.vcf-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] include_directories(...) versus set_directory_properties(PROPERTIES INCLUDE_DIRECTORIES ...)

[Marcel Loose]

Hi all,

Recently I ran into a problem with a medium-large sized project with
newer CMakes. At first I didn't know what was going on: a cmake run
started to crawl, until it almost came to a standstill and then the OS
killed my login session. It turned out that, just before being logged
out forcibly by the OS, cmake was consuming a whopping 14GB(!) of RAM
memory.

Time for some digging. Luckily I have a number of different version of
CMake lying around on my system, so it was quite easy to figure out that
CMake  2.8.8 behaved normally, wheras CMake = 2.8.8 would just blow
up. When I started to print some variables and properties I understood
why: my list of include paths had grown ridiculously large. I won't go
into detail about the setup of this specific project, but suffice it to
say that include_directories() is used inside a macro that is called
quite a lot in order to resolve cross-dependencies. This never was a
problem, because CMake automatically performed de-duplication of include
paths; until version 2.8.8.

Now my question. What is the proper (or best) way to handle this. I've
been thinking along the following line: replace the call to
include_directories() in the offending macro with:

-include_directories(${_dirs})
+list(APPEND _inc_dirs ${_dep_inc_dirs})
+list(REMOVE_DUPLICATES _inc_dirs)
+set_directory_properties(PROPERTIES INCLUDE_DIRECTORIES ${_inc_dirs})


Any suggestions or comments?

Best regards,
Marcel Loose.

attachment: loose.vcf-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [cmake-developers] Minor regression in --version results for CMake 2.8.12.1 (A FALSE ALARM)

[Marcel Loose]

On 05/12/13 18:27, Matthew Woehlke wrote:
 On 2013-12-05 02:36, Alan W. Irwin wrote:
 Sorry, this turned out to be a false alarm. Despite which cmake
 telling me I was using cmake-2.8.12.1 [snip]

 ...which is, of course, why you should always use type in bash
 rather than which :-). type, being a shell built-in, will tell you
 what bash will *actually* run, hashing - and shell builtins, and
 functions, and aliases - included.

Hmm, interesting. I didn't know the type command. However, is there a
way to easily parse the output of type? The which command simply
returns the command it will execute or an empty string if there's no
match. With type, I've seen different outputs, like:

$ type ls
ls is aliased to `ls --color=auto'

$ type rm
rm is hashed (/bin/rm)

$ type ld
ld is /usr/bin/ld

This make it pretty hard to parse :(

Best regards,
Marcel Loose.

attachment: loose.vcf--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] TARGET property LOCATION

[Marcel Loose]

On 01/12/13 09:34, Nils Gladitz wrote:
 On 30.11.2013 20:49, Marcel Loose (Astron) wrote:
 According to the CMake documentation, the TARGET property LOCATION for a
 non-imported target is provided for compatibility with CMake 2.4 and
 below. My question is: are there any plans to deprecate this property? I
 want to know, because AFAIK, the only way to determine the full path to
 a built target is to use this property.

 This is from the documentation of the master branch (which will
 eventually become 3.0):
 http://www.cmake.org/cmake/help/git-master/policy/CMP0026.html

 Nils
Hi Nils,

Thanks for that pointer.

What would be the preferred way to pass the location of a built
executable target to ADD_TEST? By using the COMMAND option of ADD_TEST,
or by using the $TARGET_FILE generator expression?

Best regards,
Marcel Loose.

attachment: loose.vcf--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

[cmake-developers] TARGET property LOCATION

[Marcel Loose (Astron)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi all,

A couple of days ago I sent the same question to the list
cm...@cmake.org, but got very little response. Maybe you developers
can shed more light on this.

According to the CMake documentation, the TARGET property LOCATION for a
non-imported target is provided for compatibility with CMake 2.4 and
below. My question is: are there any plans to deprecate this property? I
want to know, because AFAIK, the only way to determine the full path to
a built target is to use this property.

Best regards,
Marcel Loose.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSmkFhAAoJEEpMyb1AIWdY+LgH/1lzxjRhOSFDr2VNfTLcnXSv
CA+qywkoA1qv/BWCE29ExiABZZuTZkJJk77VmTAoH1MtUUxg+qubXu/bNR/1vknY
+Yl5EjZrHGHTiA081I+fqXDnztPmM9QgQLFgFn/xqCZEP2I4cYf0d59fTGhH/9MW
czZpF20cjqD6c5s/YEcAO64F3unmJldYUGO97rKGxOasn9aN/RbxbYGxW3LX4cPq
xdhGNJWK3uOqKXURYMoSYiOdfpemt6npDRtldeU2aLdLvtOmpxRjA5WucYKRWSIn
EWxSKimhkaa6ivaBmGgohKWopS1UIckq187ISDqyEETsZDCjTLOCitkIGfZqGgk=
=sjMz
-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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

[CMake] TARGET property LOCATION

[Marcel Loose]

Hi all,

According to the CMake documentation, the TARGET property LOCATION for a
non-imported target is provided for compatibility with CMake 2.4 and
below. My question is: are there any plans to deprecate this property? I
want to know, because AFAIK, the only way to determine the full path to
a built target is to use this property.

Best regards,
Marcel Loose.

attachment: loose.vcf--

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CMAKE_languageName_COMPILER_WORKS no longer cached?!

[Marcel Loose]

Hi all,

I noticed that, as of CMake 2.8.10, the variable 
CMAKE_languageName_COMPILER_WORKS is no longer cached. This breaks 
some of my code.


I have wrapped find_package() into a my own project-specific 
CMake-function myproject_find_package(). In one of my Find*.cmake 
files I do a enable_language(Fortran) and check the value of 
CMAKE_Fortran_COMPILER_WORKS. The thing is, this works when this Find* 
macro is called for the first time, but not for subsequent calls; and I 
think it is caused by the fact that CMAKE_Fortran_COMPILER_WORKS is no 
longer cached.


Stripping away the irrelevant parts of my Find module, here's what remains:

# Enable the Fortran compiler, if that has not been done yet.
get_property(_enabled_languages GLOBAL PROPERTY ENABLED_LANGUAGES)
if(NOT _enabled_languages MATCHES Fortran)
  # Work-around for CMake issue #9220
  if(CMAKE_Fortran_COMPILER MATCHES ^$)
set(CMAKE_Fortran_COMPILER CMAKE_Fortran_COMPILER-NOTFOUND)
  endif(CMAKE_Fortran_COMPILER MATCHES ^$)
  enable_language(Fortran)
endif(NOT _enabled_languages MATCHES Fortran)

# Check if we have a working Fortran compiler
if(CMAKE_Fortran_COMPILER_WORKS)
  # Do some fancy stuff.
else(CMAKE_Fortran_COMPILER_WORKS)
  message(SEND_ERROR A working Fortran compiler is required!)
endif(CMAKE_Fortran_COMPILER_WORKS)

When this Find module is called for the first time by 
myproject_find_package(), the Do some fancy stuff is done. On 
subsequent calls, however, the error is triggered, because 
CMAKE_Fortran_COMPILER_WORKS is empty.


What's the correct way of handling this, without breaking backward 
compatibility?


Best regards,
Marcel Loose.

attachment: loose.vcf--

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] enable_languague (... OPTIONAL) broken?

[Marcel Loose]

Hi all,

I'm puzzled w.r.t. the behavior of enable_language(... OPTIONAL).
When trying to enable Fortran optionally on a system without a working 
Fortran compiler (/usr/bin/f95 is a dead symbolic link) I get:


CMAKE_Fortran_COMPILER = /usr/bin/f95
CMAKE_Fortran_COMPILER_WORKS = TRUE

which is quite surprising IMHO. I would expect that 
CMAKE_Fortran_COMPILER_WORKS were set to FALSE, and 
CMAKE_Fortran_COMPILER to NOTFOUND.


I don't know what the last sentence ... has been enabled successfully. 
in the help text for enable_language really means in the context of 
enable_language(... OPTIONAL)?


Best regards,
Marcel Loose.

attachment: loose.vcf--

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] FindCUDA fails to find libcuda.so

[Marcel Loose]

Hi Robert,

I created an issue for this in Mantis: 
http://public.kitware.com/Bug/view.php?id=14122


Best regards,
Marcel Loose.

On 01/05/13 15:09, Robert Maynard wrote:

It looks like you used the ubuntu cuda package which installs the cuda
library to a directory that FindCUDA wasn't expecting. I think we can
extend FindCUDA to also use x86_64-linux-gnu as a valid directory to
search for libcuda.

can you submit a bug on mantis for this, so it doesn't get forgotten?

On Tue, Apr 30, 2013 at 4:37 PM, Marcel Loose marcel.lo...@zonnet.nl wrote:

Here are the results on my Ubuntu 12.10 system:

$ cmake --debug-output ..
Running with debug output on.
-- The C compiler identification is GNU 4.7.2
Called from: [2]
/usr/share/cmake-2.8/Modules/CMakeDetermineCCompiler.cmake
 [1] /home/marcel/temp/cmake/cuda/CMakeLists.txt
-- The CXX compiler identification is GNU 4.7.2
Called from: [2]
/usr/share/cmake-2.8/Modules/CMakeDetermineCXXCompiler.cmake
 [1] /home/marcel/temp/cmake/cuda/CMakeLists.txt

-- Check for working C compiler: /usr/bin/gcc
Called from: [2] /usr/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake
 [1] /home/marcel/temp/cmake/cuda/CMakeLists.txt

-- Check for working C compiler: /usr/bin/gcc -- works
Called from: [2] /usr/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake
 [1] /home/marcel/temp/cmake/cuda/CMakeLists.txt

-- Detecting C compiler ABI info
Called from: [2] /usr/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake
 [1] /home/marcel/temp/cmake/cuda/CMakeLists.txt

-- Detecting C compiler ABI info - done
Called from: [2] /usr/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake
 [1] /home/marcel/temp/cmake/cuda/CMakeLists.txt

-- Check for working CXX compiler: /usr/bin/c++
Called from: [2] /usr/share/cmake-2.8/Modules/CMakeTestCXXCompiler.cmake
 [1] /home/marcel/temp/cmake/cuda/CMakeLists.txt

-- Check for working CXX compiler: /usr/bin/c++ -- works
Called from: [2] /usr/share/cmake-2.8/Modules/CMakeTestCXXCompiler.cmake
 [1] /home/marcel/temp/cmake/cuda/CMakeLists.txt

-- Detecting CXX compiler ABI info
Called from: [2] /usr/share/cmake-2.8/Modules/CMakeTestCXXCompiler.cmake
 [1] /home/marcel/temp/cmake/cuda/CMakeLists.txt

-- Detecting CXX compiler ABI info - done
Called from: [2] /usr/share/cmake-2.8/Modules/CMakeTestCXXCompiler.cmake
 [1] /home/marcel/temp/cmake/cuda/CMakeLists.txt
-- Found CUDA: /usr (found version 4.2)
Called from: [2] /usr/share/cmake-2.8/Modules/FindCUDA.cmake
 [1] /home/marcel/temp/cmake/cuda/CMakeLists.txt
-- CUDA_LIBRARIES = /usr/lib/x86_64-linux-gnu/libcudart.so
Called from: [1] /home/marcel/temp/cmake/cuda/CMakeLists.txt
-- Configuring done
-- Generating /home/marcel/temp/cmake/cuda/build
-- Generating done
-- Build files have been written to: /home/marcel/temp/cmake/cuda/build

And here's the output when setting CUDA_LIB_PATH:

$ CUDA_LIB_PATH=/usr/lib/nvidia-current cmake --debug-output ..
Running with debug output on.
-- The C compiler identification is GNU 4.7.2
Called from: [2]
/usr/share/cmake-2.8/Modules/CMakeDetermineCCompiler.cmake
 [1] /home/marcel/temp/cmake/cuda/CMakeLists.txt
-- The CXX compiler identification is GNU 4.7.2
Called from: [2]
/usr/share/cmake-2.8/Modules/CMakeDetermineCXXCompiler.cmake
 [1] /home/marcel/temp/cmake/cuda/CMakeLists.txt

-- Check for working C compiler: /usr/bin/gcc
Called from: [2] /usr/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake
 [1] /home/marcel/temp/cmake/cuda/CMakeLists.txt

-- Check for working C compiler: /usr/bin/gcc -- works
Called from: [2] /usr/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake
 [1] /home/marcel/temp/cmake/cuda/CMakeLists.txt

-- Detecting C compiler ABI info
Called from: [2] /usr/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake
 [1] /home/marcel/temp/cmake/cuda/CMakeLists.txt

-- Detecting C compiler ABI info - done
Called from: [2] /usr/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake
 [1] /home/marcel/temp/cmake/cuda/CMakeLists.txt

-- Check for working CXX compiler: /usr/bin/c++
Called from: [2] /usr/share/cmake-2.8/Modules/CMakeTestCXXCompiler.cmake
 [1] /home/marcel/temp/cmake/cuda/CMakeLists.txt

-- Check for working CXX compiler: /usr/bin/c++ -- works
Called from: [2] /usr/share/cmake-2.8/Modules/CMakeTestCXXCompiler.cmake
 [1] /home/marcel/temp/cmake/cuda/CMakeLists.txt

-- Detecting CXX compiler ABI info
Called from: [2] /usr/share/cmake-2.8/Modules/CMakeTestCXXCompiler.cmake
 [1] /home/marcel/temp/cmake/cuda/CMakeLists.txt

-- Detecting CXX compiler ABI info - done
Called from: [2] /usr/share/cmake-2.8/Modules/CMakeTestCXXCompiler.cmake
 [1] /home/marcel/temp/cmake/cuda

Re: [CMake] FindCUDA fails to find libcuda.so

[Marcel Loose]

Here are the results on my Ubuntu 12.10 system:

$ cmake --debug-output ..
Running with debug output on.
-- The C compiler identification is GNU 4.7.2
   Called from: [2] 
/usr/share/cmake-2.8/Modules/CMakeDetermineCCompiler.cmake

[1] /home/marcel/temp/cmake/cuda/CMakeLists.txt
-- The CXX compiler identification is GNU 4.7.2
   Called from: [2] 
/usr/share/cmake-2.8/Modules/CMakeDetermineCXXCompiler.cmake

[1] /home/marcel/temp/cmake/cuda/CMakeLists.txt
-- Check for working C compiler: /usr/bin/gcc
   Called from: [2] /usr/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake
[1] /home/marcel/temp/cmake/cuda/CMakeLists.txt
-- Check for working C compiler: /usr/bin/gcc -- works
   Called from: [2] /usr/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake
[1] /home/marcel/temp/cmake/cuda/CMakeLists.txt
-- Detecting C compiler ABI info
   Called from: [2] /usr/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake
[1] /home/marcel/temp/cmake/cuda/CMakeLists.txt
-- Detecting C compiler ABI info - done
   Called from: [2] /usr/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake
[1] /home/marcel/temp/cmake/cuda/CMakeLists.txt
-- Check for working CXX compiler: /usr/bin/c++
   Called from: [2] /usr/share/cmake-2.8/Modules/CMakeTestCXXCompiler.cmake
[1] /home/marcel/temp/cmake/cuda/CMakeLists.txt
-- Check for working CXX compiler: /usr/bin/c++ -- works
   Called from: [2] /usr/share/cmake-2.8/Modules/CMakeTestCXXCompiler.cmake
[1] /home/marcel/temp/cmake/cuda/CMakeLists.txt
-- Detecting CXX compiler ABI info
   Called from: [2] /usr/share/cmake-2.8/Modules/CMakeTestCXXCompiler.cmake
[1] /home/marcel/temp/cmake/cuda/CMakeLists.txt
-- Detecting CXX compiler ABI info - done
   Called from: [2] /usr/share/cmake-2.8/Modules/CMakeTestCXXCompiler.cmake
[1] /home/marcel/temp/cmake/cuda/CMakeLists.txt
-- Found CUDA: /usr (found version 4.2)
   Called from: [2] /usr/share/cmake-2.8/Modules/FindCUDA.cmake
[1] /home/marcel/temp/cmake/cuda/CMakeLists.txt
-- CUDA_LIBRARIES = /usr/lib/x86_64-linux-gnu/libcudart.so
   Called from: [1] /home/marcel/temp/cmake/cuda/CMakeLists.txt
-- Configuring done
-- Generating /home/marcel/temp/cmake/cuda/build
-- Generating done
-- Build files have been written to: /home/marcel/temp/cmake/cuda/build

And here's the output when setting CUDA_LIB_PATH:

$ CUDA_LIB_PATH=/usr/lib/nvidia-current cmake --debug-output ..
Running with debug output on.
-- The C compiler identification is GNU 4.7.2
   Called from: [2] 
/usr/share/cmake-2.8/Modules/CMakeDetermineCCompiler.cmake

[1] /home/marcel/temp/cmake/cuda/CMakeLists.txt
-- The CXX compiler identification is GNU 4.7.2
   Called from: [2] 
/usr/share/cmake-2.8/Modules/CMakeDetermineCXXCompiler.cmake

[1] /home/marcel/temp/cmake/cuda/CMakeLists.txt
-- Check for working C compiler: /usr/bin/gcc
   Called from: [2] /usr/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake
[1] /home/marcel/temp/cmake/cuda/CMakeLists.txt
-- Check for working C compiler: /usr/bin/gcc -- works
   Called from: [2] /usr/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake
[1] /home/marcel/temp/cmake/cuda/CMakeLists.txt
-- Detecting C compiler ABI info
   Called from: [2] /usr/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake
[1] /home/marcel/temp/cmake/cuda/CMakeLists.txt
-- Detecting C compiler ABI info - done
   Called from: [2] /usr/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake
[1] /home/marcel/temp/cmake/cuda/CMakeLists.txt
-- Check for working CXX compiler: /usr/bin/c++
   Called from: [2] /usr/share/cmake-2.8/Modules/CMakeTestCXXCompiler.cmake
[1] /home/marcel/temp/cmake/cuda/CMakeLists.txt
-- Check for working CXX compiler: /usr/bin/c++ -- works
   Called from: [2] /usr/share/cmake-2.8/Modules/CMakeTestCXXCompiler.cmake
[1] /home/marcel/temp/cmake/cuda/CMakeLists.txt
-- Detecting CXX compiler ABI info
   Called from: [2] /usr/share/cmake-2.8/Modules/CMakeTestCXXCompiler.cmake
[1] /home/marcel/temp/cmake/cuda/CMakeLists.txt
-- Detecting CXX compiler ABI info - done
   Called from: [2] /usr/share/cmake-2.8/Modules/CMakeTestCXXCompiler.cmake
[1] /home/marcel/temp/cmake/cuda/CMakeLists.txt
-- Found CUDA: /usr (found version 4.2)
   Called from: [2] /usr/share/cmake-2.8/Modules/FindCUDA.cmake
[1] /home/marcel/temp/cmake/cuda/CMakeLists.txt
-- CUDA_LIBRARIES = 
/usr/lib/x86_64-linux-gnu/libcudart.so;/usr/lib/nvidia-current/libcuda.so

   Called from: [1] /home/marcel/temp/cmake/cuda/CMakeLists.txt
-- Configuring done
-- Generating /home/marcel/temp/cmake/cuda/build
-- Generating done
-- Build files have been written to: /home/marcel/temp/cmake/cuda/build

Best regards,
Marcel Loose.

Op 29-04-13 18:04, Robert Maynard schreef:

I have had no problem

[CMake] FindCUDA fails to find libcuda.so

[Marcel Loose]

Hi all,

I noticed that FindCUDA.cmake fails to locate libcuda.so on at least two 
different platforms: Ubuntu 12.10 and CentOS 6.3 using Cluster Manager 
v5.2. I can persuade FindCUDA.cmake to search for this library by 
explicitly setting the environment variable CUDA_LIB_PATH, and then it 
finds it. However, IMHO, using this trick should only be necessary as a 
last resort. Is this a bug?


Best regards,
Marcel Loose.




attachment: loose.vcf--

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] FindCUDA fails to find libcuda.so

[Marcel Loose]

Hi,

It fails to find CUDA 5.0. See below.

$ env | grep CUDA
CUDA_PATH=/cm/shared/apps/cuda50/toolkit/5.0.35
CUDA_INC_PATH=/cm/shared/apps/cuda50/toolkit/5.0.35
CUDA_SDK=/cm/shared/apps/cuda50/sdk/5.0.35
CUDA_CACHE_DISABLE=1
CUDA_INSTALL_PATH=/cm/shared/apps/cuda50/toolkit/5.0.35
CUDA_ROOT=/cm/local/apps/cuda50/libs/304.54

$ cat ../CMakeLists.txt
cmake_minimum_required(VERSION 2.8)
project(CheckCUDALibs)
find_package(CUDA)
message(STATUS CUDA_LIBRARIES = ${CUDA_LIBRARIES})

$ cmake ..
-- 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
-- Found CUDA: /cm/shared/apps/cuda50/toolkit/5.0.35 (found version 5.0)
-- CUDA_LIBRARIES = /cm/shared/apps/cuda50/toolkit/5.0.35/lib64/libcudart.so
-- Configuring done
-- Generating done
-- Build files have been written to: /home/loose/temp/cmake/cuda/build

$ CUDA_LIB_PATH=$CUDA_ROOT/lib cmake ..
-- CUDA_LIBRARIES = 
/cm/shared/apps/cuda50/toolkit/5.0.35/lib64/libcudart.so;/cm/local/apps/cuda50/libs/304.54/lib64/libcuda.so

-- Configuring done
-- Generating done
-- Build files have been written to: /home/loose/temp/cmake/cuda/build

Only when explicitly setting CUDA_LIB_PATH, libcuda.so is found.

BTW: On Ubuntu I also need to set CUDA_LIB_PATH, but then to 
/usr/lib/nvidia-current.


Regards,
Marcel Loose.


On 29/04/13 15:36, Robert Maynard wrote:

Can you provide what Cuda version FindCuda is failing to find, and
where Cluster Manager is installing the CUDA toolkit and library?

On Mon, Apr 29, 2013 at 7:38 AM, Marcel Loose lo...@astron.nl wrote:

Hi all,

I noticed that FindCUDA.cmake fails to locate libcuda.so on at least two
different platforms: Ubuntu 12.10 and CentOS 6.3 using Cluster Manager v5.2.
I can persuade FindCUDA.cmake to search for this library by explicitly
setting the environment variable CUDA_LIB_PATH, and then it finds it.
However, IMHO, using this trick should only be necessary as a last resort.
Is this a bug?

Best regards,
Marcel Loose.





--

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


attachment: loose.vcf--

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] FindCUDA fails to find libcuda.so

[Marcel Loose]

Hi Robert,

I agree that on the CentOS machine the install paths are non-standard. 
For the Ubuntu system, on the other hand, I have to disagree with that 
statement. It is a *standard* Ubuntu 12.10 system, so IMHO 
FindCUDA.cmake should be able to locate libcuda.so on that system.


Regards,
Marcel Loose.

On 29/04/13 16:54, Robert Maynard wrote:

You have a nonstandard install path that will require you to use
CUDA_PATH / CUDA_BIN_PATH and CUDA_LIB_PATH.

On Mon, Apr 29, 2013 at 10:10 AM, Marcel Loose lo...@astron.nl wrote:

Hi,

It fails to find CUDA 5.0. See below.

$ env | grep CUDA
CUDA_PATH=/cm/shared/apps/cuda50/toolkit/5.0.35
CUDA_INC_PATH=/cm/shared/apps/cuda50/toolkit/5.0.35
CUDA_SDK=/cm/shared/apps/cuda50/sdk/5.0.35
CUDA_CACHE_DISABLE=1
CUDA_INSTALL_PATH=/cm/shared/apps/cuda50/toolkit/5.0.35
CUDA_ROOT=/cm/local/apps/cuda50/libs/304.54

$ cat ../CMakeLists.txt
cmake_minimum_required(VERSION 2.8)
project(CheckCUDALibs)
find_package(CUDA)
message(STATUS CUDA_LIBRARIES = ${CUDA_LIBRARIES})

$ cmake ..
-- 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
-- Found CUDA: /cm/shared/apps/cuda50/toolkit/5.0.35 (found version 5.0)
-- CUDA_LIBRARIES = /cm/shared/apps/cuda50/toolkit/5.0.35/lib64/libcudart.so
-- Configuring done
-- Generating done
-- Build files have been written to: /home/loose/temp/cmake/cuda/build

$ CUDA_LIB_PATH=$CUDA_ROOT/lib cmake ..
-- CUDA_LIBRARIES =
/cm/shared/apps/cuda50/toolkit/5.0.35/lib64/libcudart.so;/cm/local/apps/cuda50/libs/304.54/lib64/libcuda.so
-- Configuring done
-- Generating done
-- Build files have been written to: /home/loose/temp/cmake/cuda/build

Only when explicitly setting CUDA_LIB_PATH, libcuda.so is found.

BTW: On Ubuntu I also need to set CUDA_LIB_PATH, but then to
/usr/lib/nvidia-current.

Regards,
Marcel Loose.



On 29/04/13 15:36, Robert Maynard wrote:

Can you provide what Cuda version FindCuda is failing to find, and
where Cluster Manager is installing the CUDA toolkit and library?

On Mon, Apr 29, 2013 at 7:38 AM, Marcel Loose lo...@astron.nl wrote:

Hi all,

I noticed that FindCUDA.cmake fails to locate libcuda.so on at least two
different platforms: Ubuntu 12.10 and CentOS 6.3 using Cluster Manager
v5.2.
I can persuade FindCUDA.cmake to search for this library by explicitly
setting the environment variable CUDA_LIB_PATH, and then it finds it.
However, IMHO, using this trick should only be necessary as a last
resort.
Is this a bug?

Best regards,
Marcel Loose.





--

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




attachment: loose.vcf--

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] Regression in INCLUDE_DIRECTORIES command between cmake 2.8.7 and 2.8.8?

[Marcel Loose]

Hi David,

I filed a bug (14094) and attached a patch that solves it.

Cheers,
Marcel.

On 16/04/13 15:32, David Cole wrote:
I guess you could file a bug/request to de-duplicate in the FindCUDA 
cmake code.


Anybody who reads the property via get_property (or 
get_target_property or get_directory_property) and then sets it back 
with some appended info is directly manipulating the property itself. 
Moreover, include_directories itself simply appends to these 
properties now as it goes, and the de-duplication happens later, at 
generate time.


So if the cuda stuff is using get_property (and friends) to 
retrieve the value of the include directories, then it will now need 
to de-duplicate that list itself if it wants to.


On the other hand, the additional -I arguments should still work, 
unless you're running up against a command line too long problem.


Is there an actual build issue you're having, or is this just an 
aesthetic I don't like seeing -I duplicate arguments thing...?



D




-Original Message-
From: Marcel Loose lo...@astron.nl
To: David Cole dlrd...@aol.com
Cc: cmake cmake@cmake.org
Sent: Tue, Apr 16, 2013 4:16 am
Subject: Re: [CMake] Regression in INCLUDE_DIRECTORIES command between 
cmake 2.8.7 and 2.8.8?



Hi David,

Appears you are right. However nvcc is clearly not playing by the new
rules. When using cuda_add_executable() I do get multiple -I entries on
the command line. Should I file a bug report for FindCUDA then?

Regards,
Marcel.

On 16/04/13 01:03, David Cole wrote:
It removes duplicates during generation, though. You shouldn't see 

duplicates
in the generated make files or project files...



On Apr 15, 2013, at 5:34 PM, Marcel Loose marcel.lo...@zonnet.nl 

wrote:



Hi all,

I noticed that, starting from cmake 2.8.8, INCLUDE_DIRECTORIES no 

longer
remove duplicates. I this a regression?


$ cat ../CMakeLists.txt
cmake_minimum_required(VERSION 2.6)
project(TestIncludeDirectories)

get_directory_property(_inc_dirs INCLUDE_DIRECTORIES)
message(STATUS INCLUDE_DIRECTORIES=${_inc_dirs})

include_directories(/usr/include)
get_directory_property(_inc_dirs INCLUDE_DIRECTORIES)
message(STATUS INCLUDE_DIRECTORIES=${_inc_dirs})

include_directories(/usr/include)
get_directory_property(_inc_dirs INCLUDE_DIRECTORIES)
message(STATUS INCLUDE_DIRECTORIES=${_inc_dirs})

$ ~/x86_64/usr/local/cmake-2.8.7/bin/cmake ..
-- INCLUDE_DIRECTORIES=
-- INCLUDE_DIRECTORIES=/usr/include
-- INCLUDE_DIRECTORIES=/usr/include
-- Configuring done
-- Generating done
-- Build files have been written to: 

/home/marcel/temp/cmake/include_directories/build


$ ~/x86_64/usr/local/cmake-2.8.8/bin/cmake ..
-- INCLUDE_DIRECTORIES=
-- INCLUDE_DIRECTORIES=/usr/include
-- INCLUDE_DIRECTORIES=/usr/include;/usr/include
-- Configuring done
-- Generating done
-- Build files have been written to: 

/home/marcel/temp/cmake/include_directories/build


Best regards,
Marcel Loose.

--

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




attachment: loose.vcf--

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] Regression in INCLUDE_DIRECTORIES command between cmake 2.8.7 and 2.8.8?

[Marcel Loose]

Hi David,

Appears you are right. However nvcc is clearly not playing by the new 
rules. When using cuda_add_executable() I do get multiple -I entries on 
the command line. Should I file a bug report for FindCUDA then?


Regards,
Marcel.

On 16/04/13 01:03, David Cole wrote:

It removes duplicates during generation, though. You shouldn't see duplicates 
in the generated make files or project files...


On Apr 15, 2013, at 5:34 PM, Marcel Loose marcel.lo...@zonnet.nl wrote:


Hi all,

I noticed that, starting from cmake 2.8.8, INCLUDE_DIRECTORIES no longer remove 
duplicates. I this a regression?

$ cat ../CMakeLists.txt
cmake_minimum_required(VERSION 2.6)
project(TestIncludeDirectories)

get_directory_property(_inc_dirs INCLUDE_DIRECTORIES)
message(STATUS INCLUDE_DIRECTORIES=${_inc_dirs})

include_directories(/usr/include)
get_directory_property(_inc_dirs INCLUDE_DIRECTORIES)
message(STATUS INCLUDE_DIRECTORIES=${_inc_dirs})

include_directories(/usr/include)
get_directory_property(_inc_dirs INCLUDE_DIRECTORIES)
message(STATUS INCLUDE_DIRECTORIES=${_inc_dirs})

$ ~/x86_64/usr/local/cmake-2.8.7/bin/cmake ..
-- INCLUDE_DIRECTORIES=
-- INCLUDE_DIRECTORIES=/usr/include
-- INCLUDE_DIRECTORIES=/usr/include
-- Configuring done
-- Generating done
-- Build files have been written to: 
/home/marcel/temp/cmake/include_directories/build

$ ~/x86_64/usr/local/cmake-2.8.8/bin/cmake ..
-- INCLUDE_DIRECTORIES=
-- INCLUDE_DIRECTORIES=/usr/include
-- INCLUDE_DIRECTORIES=/usr/include;/usr/include
-- Configuring done
-- Generating done
-- Build files have been written to: 
/home/marcel/temp/cmake/include_directories/build

Best regards,
Marcel Loose.

--

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


attachment: loose.vcf--

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] Regression in INCLUDE_DIRECTORIES command between cmake 2.8.7 and 2.8.8?

[Marcel Loose]

Hi all,

I noticed that, starting from cmake 2.8.8, INCLUDE_DIRECTORIES no longer 
remove duplicates. I this a regression?


$ cat ../CMakeLists.txt
cmake_minimum_required(VERSION 2.6)
project(TestIncludeDirectories)

get_directory_property(_inc_dirs INCLUDE_DIRECTORIES)
message(STATUS INCLUDE_DIRECTORIES=${_inc_dirs})

include_directories(/usr/include)
get_directory_property(_inc_dirs INCLUDE_DIRECTORIES)
message(STATUS INCLUDE_DIRECTORIES=${_inc_dirs})

include_directories(/usr/include)
get_directory_property(_inc_dirs INCLUDE_DIRECTORIES)
message(STATUS INCLUDE_DIRECTORIES=${_inc_dirs})

$ ~/x86_64/usr/local/cmake-2.8.7/bin/cmake ..
-- INCLUDE_DIRECTORIES=
-- INCLUDE_DIRECTORIES=/usr/include
-- INCLUDE_DIRECTORIES=/usr/include
-- Configuring done
-- Generating done
-- Build files have been written to: 
/home/marcel/temp/cmake/include_directories/build


$ ~/x86_64/usr/local/cmake-2.8.8/bin/cmake ..
-- INCLUDE_DIRECTORIES=
-- INCLUDE_DIRECTORIES=/usr/include
-- INCLUDE_DIRECTORIES=/usr/include;/usr/include
-- Configuring done
-- Generating done
-- Build files have been written to: 
/home/marcel/temp/cmake/include_directories/build


Best regards,
Marcel Loose.

--

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 use CMAKE_POLICY?

[Marcel Loose]

Op 18-12-12 13:46, David Cole schreef:
On Mon, Dec 17, 2012 at 11:57 AM, Alexander Neundorf 
a.neundorf-w...@gmx.net mailto:a.neundorf-w...@gmx.net wrote:


On Monday 17 December 2012, David Cole wrote:
 I thought we wanted them to switch to the new behavior... Isn't
that the
 goal of emitting warnings from policy implementations...?

...but not as long as the project still wants to keep the old
minimum required
cmake version (or am I mixing things up) ?

Alex



No, you're not mixing things up. You're correct.

If somebody wants to use minimum required 2.6.2 *and* they don't like 
warnings emitted by newer versions of CMake about new policies, then 
they have to change their code, or use the -D 
CMAKE_POLICY_DEFAULT_CMP technique.


Now if they're going to change their code anyway, why not make a 
change that is compatible with the new policy introduced rather than 
adding a bunch of code to keep things in the OLD state. With many 
policies it is possible to write CMake code that honors the NEW state 
of the policy, but still works with older CMakes.


I would ask for specific advice regarding the particulars of the 
policy violation to see if there is such a way to re-write the code to 
work with older AND newer CMakes before I would ever consider setting 
a policy to OLD in my own CMakeLists files.



HTH,
David


I can send specific examples if you want. I'm not sure I can send 
attachments to the mailing list, though.


Regards,
Marcel Loose.

--

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 use CMAKE_POLICY?

[Marcel Loose]

Hi David,

I need to set a policy to OLD, because I have wrapped a few existing 
Find*.cmake files to overcome some bugs or shortcomings. However, since 
CMake 2.8.4 (or 2.8.3, I'm not sure), this triggers a policy warning 
CMP0017 with newer versions of CMake, because some macros are now 
included from my CMAKE_MODULE_PATH and some from CMAKE_CURRENT_LIST_DIR, 
which expands to somewhere inside CMAKE_ROOT.


Best regards,
Marcel Loose.


Op 17-12-12 15:30, David Cole schreef:

If you need to set a policy to OLD, then we have failed...

Why do you need to set a policy to OLD?

How can we make it work so that you don't need to do that?




On Mon, Dec 17, 2012 at 3:58 AM, Marcel Loose lo...@astron.nl 
mailto:lo...@astron.nl wrote:


Hi David,

See my remarks inline.


On 15/12/12 16:47, David Cole wrote:

On Sat, Dec 15, 2012 at 10:33 AM, Marcel Loose
marcel.lo...@zonnet.nl mailto:marcel.lo...@zonnet.nl wrote:

Thanks, that seems to work.

Is the idiom

if(POLICY CMP)
  cmake_policy(PUSH)
  cmake_policy(SET CMP OLD)
  cmake_policy(POP)
endif()

one that you also need to use with newer CMakes? Or does it
then suffice to do

cmake_policy(SET CMP OLD)


I assume you really mean:

if(POLICY CMP)
  cmake_policy(PUSH)
  cmake_policy(SET CMP OLD)
endif()

...
other code where the policy is set to OLD
...

if(POLICY CMP)
  cmake_policy(POP)
endif()


Yes, you're right. I was oversimplifying.


The policies are tightly tied to the minimum required version of
CMake. So if you use cmake_minimum_required with a certain
version number, you can write code without if(POLICY assuming
that all the policies you need to set are known as of that
minimum version. If they are not (and they must not be in this
particular case), then you'll need the if(POLICY construct.


So, that basically means that you need to use if(POLICY...) for
all policies that are not part of the minimum required version? Is
there a way to find out which policies exist for which version of
CMake?

I was hoping for a more forward compatible solution. In other
words, I was hoping that I could always use CMAKE_POLICY(SET...)
unconditionally. It's a bit of a shame that I have to clutter my
CMakeLists.txt and *.cmake files with these extra conditionals;
and have to remove them (or should I say: clean up) whenever I
bump the minimum required version.

What's the reason that cmake doesn't silently ignore a
CMAKE_POLICY(SET...) for a policy it doesn't know about?


The other option is to bump up your minimum required version.

Sure, but that defeats the whole purpose of setting a minimum
required version. I need to be compatible with version 2.6.2.

Best regards,
Marcel Loose.




--

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 use CMAKE_POLICY?

[Marcel Loose]

On 19/12/12 17:56, David Cole wrote:
I think the safest/wisest thing to do in this case is to update your 
minimum required version to CMake 2.8.4, and then adjust your custom 
code to eliminate the warning if it still occurs.


2.8.4 is more than 18 months old at this point. Is there a reason why 
2.6.2 is still required for some?
Yep. Old machines running old software that nobody wants to touch, 
adhering to the principle Don't fix anything that ain't broke.





On Wed, Dec 19, 2012 at 11:24 AM, Alexander Neundorf 
a.neundorf-w...@gmx.net mailto:a.neundorf-w...@gmx.net wrote:


On Wednesday 19 December 2012, Marcel Loose wrote:
 Hi David,

 I need to set a policy to OLD, because I have wrapped a few existing
 Find*.cmake files to overcome some bugs or shortcomings.
However, since
 CMake 2.8.4 (or 2.8.3, I'm not sure), this triggers a policy warning
 CMP0017 with newer versions of CMake, because some macros are now
 included from my CMAKE_MODULE_PATH and some from
CMAKE_CURRENT_LIST_DIR,
 which expands to somewhere inside CMAKE_ROOT.

you get this warning if a module from CMake/Modules/ includes a
module from
outside CMake/Modules/, if the same module exists also inside
CMake/Modules/.

This is a serious warning, because the including module expects
the module
from the same cmake version as itself, having the features as they
are in this
version, and by getting a different file it may not get what it
expects.

Alex
--

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




attachment: loose.vcf--

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 use CMAKE_POLICY?

[Marcel Loose]

On 19/12/12 16:21, David Cole wrote:
No need for specific examples. Just wanted to understand the context 
better.


One good way to avoid this warning would be to get your Find* script 
changes into CMake itself, and then eliminate your need for the custom 
copies of them when using a new-enough CMake.


Is it feasible for you to propose a patch series that fixes the 
problems you speak of in the Find* modules, or are they controversial 
or somehow non-public, and you can't do that...?


It depends. Some changes are generic enough, I think. Others are 
probably too specific for my use cases. To make things a bit more 
concrete, I wrapped four Find modules: BLAS, Boost, JNI, and LAPACK.


The BLAS and LAPACK changes are closely related and fix a problem with 
setting the Fortran compiler if it hasn't been set yet. The changes for 
JNI are only needed for older versions of CMake. Finally, the changes I 
made for Boost are probably the most controversial and likely not 
generic enough. For one thing I define all uppercase variables for all 
the relevant Boost-variables that are set.


Should I file an issue in Mantis for BLAS and LAPACK?

Best regards,
Marcel Loose.


attachment: loose.vcf--

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 use CMAKE_POLICY?

[Marcel Loose]

Hi David,

See my remarks inline.

On 15/12/12 16:47, David Cole wrote:
On Sat, Dec 15, 2012 at 10:33 AM, Marcel Loose marcel.lo...@zonnet.nl 
mailto:marcel.lo...@zonnet.nl wrote:


Thanks, that seems to work.

Is the idiom

if(POLICY CMP)
  cmake_policy(PUSH)
  cmake_policy(SET CMP OLD)
  cmake_policy(POP)
endif()

one that you also need to use with newer CMakes? Or does it then
suffice to do

cmake_policy(SET CMP OLD)


I assume you really mean:

if(POLICY CMP)
  cmake_policy(PUSH)
  cmake_policy(SET CMP OLD)
endif()

...
other code where the policy is set to OLD
...

if(POLICY CMP)
  cmake_policy(POP)
endif()


Yes, you're right. I was oversimplifying.


The policies are tightly tied to the minimum required version of 
CMake. So if you use cmake_minimum_required with a certain version 
number, you can write code without if(POLICY assuming that all the 
policies you need to set are known as of that minimum version. If they 
are not (and they must not be in this particular case), then you'll 
need the if(POLICY construct.


So, that basically means that you need to use if(POLICY...) for all 
policies that are not part of the minimum required version? Is there a 
way to find out which policies exist for which version of CMake?


I was hoping for a more forward compatible solution. In other words, I 
was hoping that I could always use CMAKE_POLICY(SET...) unconditionally. 
It's a bit of a shame that I have to clutter my CMakeLists.txt and 
*.cmake files with these extra conditionals; and have to remove them (or 
should I say: clean up) whenever I bump the minimum required version.


What's the reason that cmake doesn't silently ignore a 
CMAKE_POLICY(SET...) for a policy it doesn't know about?



The other option is to bump up your minimum required version.
Sure, but that defeats the whole purpose of setting a minimum required 
version. I need to be compatible with version 2.6.2.


Best regards,
Marcel Loose.

attachment: loose.vcf--

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 use CMAKE_POLICY?

[Marcel Loose]

Thanks, that seems to work.

Is the idiom

   if(POLICY CMP)
  cmake_policy(PUSH)
  cmake_policy(SET CMP OLD)
  cmake_policy(POP)
   endif()

one that you also need to use with newer CMakes? Or does it then suffice 
to do


   cmake_policy(SET CMP OLD)

Best regards,
Marcel Loose.


Op 13-12-12 14:00, David Cole schreef:
You could use if(POLICY (if 2.6.2 supports that... I think it does, 
but it was very long ago..) to avoid the call on older CMakes.



On Thu, Dec 13, 2012 at 6:31 AM, Marcel Loose lo...@astron.nl 
mailto:lo...@astron.nl wrote:


Hi all,

I'm trying to figure out how to use the CMAKE_POLICY() command. I
want to get rid of the warning on CMP0017. I've strategically
placed cmake_policy(PUSH), cmake_policy(SET CMP0017 OLD), and
cmake_policy(POP) which solves the problem when configuring with
CMake 2.8.9.

However, our project also needs to be compatible with CMake 2.6.2.
The problem is that this older CMake now bails out with an error
message:

CMake Error at CMake/FindLAPACK.cmake:44 (cmake_policy):
  Policy CMP0017 is not known to this version of CMake.

This sounds like a catch-22. I've fixed the warning for the new
CMake, but get an error in return for the old CMake. What am I
doing wrong??

Best regards,
Marcel Loose.


--

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




--

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 use CMAKE_POLICY?

[Marcel Loose]

Hi all,

I'm trying to figure out how to use the CMAKE_POLICY() command. I want 
to get rid of the warning on CMP0017. I've strategically placed 
cmake_policy(PUSH), cmake_policy(SET CMP0017 OLD), and 
cmake_policy(POP) which solves the problem when configuring with CMake 
2.8.9.


However, our project also needs to be compatible with CMake 2.6.2. The 
problem is that this older CMake now bails out with an error message:


CMake Error at CMake/FindLAPACK.cmake:44 (cmake_policy):
  Policy CMP0017 is not known to this version of CMake.

This sounds like a catch-22. I've fixed the warning for the new CMake, 
but get an error in return for the old CMake. What am I doing wrong??


Best regards,
Marcel Loose.

attachment: loose.vcf--

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] Inconsistent CMake Warning on policy CMP0012

[Marcel Loose]

Hi all,

I noticed that, when using a string expression in an IF() statement -- 
which you obviously shouldn't do, but I was just playing around -- CMake 
sometimes generates a developer warning CMP0012. Whether it does that or 
not depends on the string your using.


The following file

$ cat string_in_conditional.cmake
if(x)
  message(STATUS \x\ evaluate to TRUE)
else()
  message(STATUS \x\ evaluate to FALSE)
endif()
if(y)
  message(STATUS \y\ evaluate to TRUE)
else()
  message(STATUS \y\ evaluate to FALSE)
endif()

produces the following output when run with cmake 2.8.9

$ cmake -P string_in_conditional.cmake
-- x evaluate to FALSE
CMake Warning (dev) at string_in_conditional.cmake:6 (if):
  given arguments:

y

  An argument named y appears in a conditional statement.  Policy CMP0012
  is not set: if() recognizes numbers and boolean constants.  Run cmake
  --help-policy CMP0012 for policy details.  Use the cmake_policy 
command to

  set the policy and suppress this warning.
This warning is for project developers.  Use -Wno-dev to suppress it.

-- y evaluate to FALSE

I.e., it doesn't produce a warning when using x in an if() statement, 
but it does when using y.



Best regards,
Marcel Loose.

attachment: loose.vcf--

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: GCC pthreads bug?

[Marcel Loose]

Hi all,

I was browsing the FindThreads.cmake code and was wondering whether it 
is doing the right thing when using GCC and pthreads.


The thing is that it first tries to locate the threads library and only 
if it *cannot* find it, tries the command-line option -pthread.


The proper way to tell GCC to compile with thread support is to use the 
-pthread command-line option. Besides instructing the linke to link 
against -lpthread, it will also set some preprocessor variables, like 
_REENTRANT. Hence, simply linking against -lpthread is not sufficient.


So, IMHO, the test for the command-line option -pthread should be 
tried first; and FindThreads should also set a variable containing the 
preprocessor variables that should be set using add_definitions().


And a bit off topic: shouldn't FindThreads.cmake adhere to the 
convention of setting a cache variable THREADS_LIBRARY and a non-cache 
variable THREADS_LIBRARIES?


Best regards,
Marcel Loose.

attachment: loose.vcf--

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-developers] Tests with custom launchers and Not Run

[Marcel Loose]

On 19/09/12 08:18, Rolf Eike Beer wrote:

David Cole wrote:

I don't like it. Existing tests that run and return, for example, a number
of errors that occurred, will magically appear as not run when that
number just so happens to be 77.

If there are enough people who think this is simple and works and are not
concerned about the accidental matching of an intentional return value of
77 that does NOT mean not run ... then I will relent and say, so be it,
and allow it in.

But only if there are some people who speak up here or add notes to the bug.

It just seems wrong to me to treat 77 as some special number here.

I would still go and make that a target property where you can set the return
code where something is considered skipped. The only question is: how to name
the property?

Eike


--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
I already suggested to use a test property three years ago (see issue 
#8466). At that time David was very much against it, fearing to find a 
***huueee*** can of worms right underneath the surface. Seems 
I'm slowly getting more fellow thinkers ;)


Regards,
Marcel Loose.

attachment: loose.vcf--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Modifying RPATH feature to run tests uninstalled

[Marcel Loose]

Hi Stephen,

On Fri, 2012-02-17 at 12:06 +0100, Stephen Kelly wrote:

-- 8  8  8  8  8  8  8  8  8 --

 diff --git a/templates/tests/CMakeLists.txt
b/templates/tests/CMakeLists.txt
 index d2e37d2..ad471c7 100644
 --- a/templates/tests/CMakeLists.txt
 +++ b/templates/tests/CMakeLists.txt
 @@ -83,6 +83,7 @@ macro(GRANTLEE_TEMPLATES_UNIT_TESTS)
${_testresource_rcc_src}
  )
  add_test(${_testname} ${_testname}_exec )
 +set_property(TEST ${testname} PROPERTY ENVIRONMENT 
 LD_LIBRARY_PATH=${CMAKE_BINARY_DIR}/templates/lib)
 
 
 Do you see anything wrong there?

You should use ${_testname} in the set_property() command. Don't you get
an error message from CMake? Or do you happen to have a variable
testname as well.

 
 Thanks,
 
 Steve.

Cheers,
Marcel.


--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [CMake] Linking problem

[Marcel Loose]

On Wed, 2011-07-27 at 12:14 +0100, Sanatan Rai wrote:
 Hi,
This is a newbie question. So apologies in advance if this is
covered
 somewhere in the docs (I haven't been able to find a satisfactory
explanation).
 
 The issue is this:
 
 * I have a library called (lib)atmath as per:
 
 include_directories(${at_SOURCE_DIR})
 add_library(atfwmath RngStream.cpp RngStream.h coin.cpp coin.hpp)
 target_link_libraries(atfwmath)
 
 Where coin.hpp:
 
 #ifndef COIN_HPP_INCLUDED
 #define COIN_HPP_INCLUDED


 #include sstream
 #include fw/math/RngStream.h
 using namespace std;


 class coin
 {
 private:
   static string name()
   {
 static unsigned long id(0);
 stringstream str;
 str  Coin_  (++id)  _stream;
 return str.str();
   }
   double p;
   RngStream *rng;
   void init();
 public:
   coin();
   coin(double _p);
   ~coin();
   bool toss();
   void reset(double _p);
 };
 #endif
 
 and coin.cpp:
 
 #include fw/math/coin.hpp


 coin::coin() : p(0.5), rng(0) { init();}
 coin::coin(double _p) : p(_p), rng(0)
 {
   if ((p  0) || (p  1))
 throw;
   init();
 }
 coin::~coin()
 {
   delete rng, rng = 0;
 }
 void coin::init()
 {
   rng = new RngStream(name().c_str());
 }
 bool coin::toss()
 {
   double u(rng-RandU01());
   return (u = p);
 }
 void coin::reset(double _p)
 {
   if ((_p  0) || (_p  1)) throw;
   p = _p;
 }
 
 
 I use these classes in another library:
 
 add_library(atidt STATIC idt.cpp)
 target_link_libraries(atidt atmath boost_date_time boost_signals)
 
 
 which is then linked to the final executable:
 add_executable(bt bt.cpp)
 target_link_libraries(bt atidt atmath boost_date_time
boost_program_options)
 target_link_libraries(bt -Wl,-whole-archive -L../idt/ -latidt
 -Wl,-no-whole-archive)
 
 When I run make:
 
* libatmath compiles fine.
* libatidt complies fine.
* when compiling bt, it complains about coin::coin, coin::reset etc
 being undefined.
  Ie it would see it is not finding them in the linked libraries.
 Even though:
 
  $ ar t libatmath.a
   RngStream.cpp.o
   coin.cpp.o
 
 What am I missing here? It is also quite bizarre as it doesn't
 complain about the declarations in
 RngStream.h which are defined in RngStream.c.
 
 Thanks in advance!
 
 --Sanatan
 
 



___
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] Linking problem

[Marcel Loose]

Hi Sanatan,

If you didn't make any copy/paste errors, then I think you made a typo.

 add_library(atfwmath RngStream.cpp RngStream.h coin.cpp coin.hpp)
 :
 :
 target_link_libraries(bt atidt atmath boost_date_time
boost_program_options)

See: atfwmath versus atmath. You should fix your add_library() line.

Best regards,
Marcel Loose.


___
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] CTest/CDash reports lots of false errors for Autotools projects

[Marcel Loose]

Hi all,

I have a dashboard running for a project that consists of several
external packages that are built using the GNU Autotools. I get a lot of
false errors in my dashboard. Here are some examples:

configure: WARNING: cannot find 'swig' program. You should look
at http://www.swig.org
../../lib/autoconf/fortran.m4:255: AC_LANG_COMPILER(Fortran 77)
is expanded from...
/usr/share/aclocal/libtool.m4:4170: _LT_LINKER_SHLIBS is
expanded from...

Browsing cmCTestBuildHandler.cxx I noticed that the above messages
indeed match one of the regexes in cmCTestErrorMatches.

:[ \\t]cannot find # matches first line
([^ :]+):([0-9]+): ([^ \\t])   # matches second and third line

I know I can create exception regexes, but I'm wondering whether the
current set of regexes may be overcomplete?

Best regards,
Marcel Loose.

-- 
Marcel Loose
Senior Software Engineer, Computing Group RD, Astron, the Netherlands

___
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 is macro PARSE_ARGUMENTS() not part of standard CMake modules?

[Marcel Loose]

Ah, sorry.

I didn't check the (almost) latest cmake. I'm currently stuck with
Ubuntu LTS 10.04, which ships cmake 2.8.0. I'll backport then.

Regards,
Marcel Loose.


On Wed, 2011-07-20 at 22:14 +0200, Alexander Neundorf wrote:
 On Wednesday 20 July 2011, Jean-Christophe Fillion-Robin wrote:
  Hi Marcel,
  
  Before CMAKE_PARSE_ARGUMENT [1] was integrated (11 months ago by
Alex
  Neundorf), within CTK, we created a macro named
ctkMacroParseArgument based
  on [2].
 
 Yes, so it is in cmake since 2.8.3.
 
 Alex



___
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 fetch exit status of INSTALL(CODE ...)

[Marcel Loose]

Hi Jc,

Thanks for the tip. It makes sense to let the build fail early (i.e.
during compilation, instead of installation). I'll take it into
consideration.

Regards,
Marcel Loose.

On Wed, 2011-07-20 at 06:41 -0400, Jean-Christophe Fillion-Robin wrote:
 Hi Marcel,
 
 Aware I won't be answering your question regarding the exit code
 associated with INSTALL(CODE ...), I still would like to suggest you
 an approach that could help you addressing your issue.
 
 What about byte-compiling the python source at build time ? In that
 case, the build step would fail instead ... 
 
 You could look at macro like this one to help you: See

https://github.com/commontk/CTK/blob/master/CMake/ctkMacroCompilePythonScript.cmake
 
 Hth
 Jc
 
 On Wed, Jul 20, 2011 at 3:47 AM, Marcel Loose lo...@astron.nl wrote:
 Hi all,
 
 I have a macro that, during install, compiles python source
 files to
 byte code. Sometimes, there's a syntax error in the python
 source that
 can be caught during compilation; i.e. during the execution of
 INSTALL(CODE ...).
 
 Is is possible to somehow fetch the exit status of commands
 executed
 inside INSTALL(CODE ...), so that I can let 'make install'
 exit with a
 non-zero exit status?
 
 Best regards,
 Marcel Loose.
 
 --
 Marcel Loose
 Senior Software Engineer, Computing Group RD, Astron, the
 Netherlands
 
 ___
 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
 
 
 
 -- 
 +1 919 869 8849
 



___
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 fetch exit status of INSTALL(CODE ...)

[Marcel Loose]

Thanks David,

I never realized you can use just about any CMake-construct inside
CODE... 

Regards,
Marcel Loose.

On Wed, 2011-07-20 at 10:41 -0400, David Cole wrote:
 To produce an error from an install(CODE snippet, simply add:
 
 
   if(error)
 message(FATAL_ERROR \error message here\)
   endif()
 
 
 inside the CODE based on some other error flag also in your CODE...
 
 
 On Wed, Jul 20, 2011 at 7:45 AM, Marcel Loose lo...@astron.nl wrote:
 Hi Jc,
 
 Thanks for the tip. It makes sense to let the build fail early
 (i.e.
 during compilation, instead of installation). I'll take it
 into
 consideration.
 
 Regards,
 Marcel Loose.
 
 
 On Wed, 2011-07-20 at 06:41 -0400, Jean-Christophe
 Fillion-Robin wrote:
  Hi Marcel,
 
  Aware I won't be answering your question regarding the exit
 code
  associated with INSTALL(CODE ...), I still would like to
 suggest you
  an approach that could help you addressing your issue.
 
  What about byte-compiling the python source at build time ?
 In that
  case, the build step would fail instead ...
 
  You could look at macro like this one to help you: See
 

https://github.com/commontk/CTK/blob/master/CMake/ctkMacroCompilePythonScript.cmake
 
  Hth
  Jc
 
  On Wed, Jul 20, 2011 at 3:47 AM, Marcel Loose
 lo...@astron.nl wrote:
  Hi all,
 
  I have a macro that, during install, compiles python
 source
  files to
  byte code. Sometimes, there's a syntax error in the
 python
  source that
  can be caught during compilation; i.e. during the
 execution of
  INSTALL(CODE ...).
 
  Is is possible to somehow fetch the exit status of
 commands
  executed
  inside INSTALL(CODE ...), so that I can let 'make
 install'
  exit with a
  non-zero exit status?
 
  Best regards,
  Marcel Loose.
 
  --
  Marcel Loose
  Senior Software Engineer, Computing Group RD,
 Astron, the
  Netherlands
 
  ___
  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
 
 
 
  --
  +1 919 869 8849
 
 
 
 
 ___
 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

[CMake] Why is macro PARSE_ARGUMENTS() not part of standard CMake modules?

[Marcel Loose]

Hi all,

As a spin-off of my question earlier today on INSTALL(CODE...) --
http://www.mail-archive.com/cmake@cmake.org/msg37292.html --
I followed the link
https://github.com/commontk/CTK/blob/master/CMake/ctkMacroCompilePythonScript.cmake
that was supplied in the first reply and finally arrived at
http://www.cmake.org/Wiki/CMakeMacroParseArguments which sounds like a
very useful macro to have.

I was wondering why this macro is only implemented in CPack.cmake as
cpack_parse_arguments(). Is there a reason for not having it as standard
CMake module?

Best regards,
Marcel Loose.


-- 
Marcel Loose
Senior Software Engineer, Computing Group RD, Astron, the Netherlands

___
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] Parallel make custom command

[Marcel Loose]

On Wed, 2011-06-29 at 23:43 +0200, Marcel Loose wrote:
 On Wed, 2011-06-29 at 20:46 +0200, Michael Wild wrote:
  On 06/29/2011 05:22 PM, Marcel Loose wrote:
   Hi all,
   
   I'm having a problem with a parallel 'make' where one or more
 sources
   are generated by a custom command.
   
   The situation is as follows. There are a couple of targets
 (executables)
   that depend on the same source file being generated by a custom
   command. 
   
   I notice that, when doing a parallel build, the custom command is
   executed multiple times, thereby potentially overwriting or
 corrupting
   the same file that's generated in different threads.
   
   My feeling is that this is caused by the fact that CMake generates
a
   build.cmake file for each target separately. Hence, when doing a
   parallel build, these build.cmake files are also processed in
 parallel. 
   
   Am I correct in this assumption? And if so, what's the proper
 solution
   for this problem?
   
   Best regards,
   Marcel Loose.
   
  
  Yes, I've seen this issue too. The only way I can think of fixing
this
  is by having a single custom target which depends on the generated
  files, and then have the executables using the generated sources
 depend
  on that custom target. This way you force the custom target to be
run
  first before the other targets, thus avoiding the custom commands
  generating the sources from running multiple times.
  
  Michael
  ___
  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
 
 Seems my webmail client completely screwed up the topic threading :-(
 Here's my reply again, hopefully now placed properly. Sorry for the
 noise.
 
 After I had posted my question I realized that this issue has come up
 quite recently on the mailing list in a thread that I started -- see
 http://www.mail-archive.com/cmake@cmake.org/msg36362.html. Although
the
 original question was related to building mulitple targets in
parallel,
 Michael Hertling showed that CMake inherently has problems with
parallel
 builds when custom targets/commands come into play.
 
 So maybe I should open an isse for this?
 
 Best regards,
 Marcel Loose.
 
 
 ___
 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


I've created an issue for this in the bug tracker:
http://public.kitware.com/Bug/view.php?id=12311

Regards,
Marcel Loose.


___
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] Parallel make custom command

[Marcel Loose]

Hi all,

I'm having a problem with a parallel 'make' where one or more sources
are generated by a custom command.

The situation is as follows. There are a couple of targets (executables)
that depend on the same source file being generated by a custom
command. 

I notice that, when doing a parallel build, the custom command is
executed multiple times, thereby potentially overwriting or corrupting
the same file that's generated in different threads.

My feeling is that this is caused by the fact that CMake generates a
build.cmake file for each target separately. Hence, when doing a
parallel build, these build.cmake files are also processed in parallel. 

Am I correct in this assumption? And if so, what's the proper solution
for this problem?

Best regards,
Marcel Loose.

-- 
Marcel Loose
Senior Software Engineer, Computing Group RD, Astron, the Netherlands

___
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] Betr.: Re: Parallel make custom command

[Marcel Loose]

-- 
Marcel Loose
Senior Software Engineer, Computing Group RD, Astron, the Netherlands
 Michael Wild  29-06-11 20:47 
On 06/29/2011 05:22 PM, Marcel Loose wrote:
 Hi all,
 
 I'm having a problem with a parallel 'make' where one or more sources
 are generated by a custom command.
 
 The situation is as follows. There are a couple of targets
(executables)
 that depend on the same source file being generated by a custom
 command. 
 
 I notice that, when doing a parallel build, the custom command is
 executed multiple times, thereby potentially overwriting or corrupting
 the same file that's generated in different threads.
 
 My feeling is that this is caused by the fact that CMake generates a
 build.cmake file for each target separately. Hence, when doing a
 parallel build, these build.cmake files are also processed in
parallel. 
 
 Am I correct in this assumption? And if so, what's the proper solution
 for this problem?
 
 Best regards,
 Marcel Loose.
 

Yes, I've seen this issue too. The only way I can think of fixing this
is by having a single custom target which depends on the generated
files, and then have the executables using the generated sources depend
on that custom target. This way you force the custom target to be run
first before the other targets, thus avoiding the custom commands
generating the sources from running multiple times.

Michael
___
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


After I had posted my question I realized that this issue has come up
quite recently on the mailing list in a thread that I started -- see
http://www.mail-archive.com/cmake@cmake.org/msg36362.html. Although the
original question was related to building mulitple targets in parallel,
Michael Hertling showed that CMake inherently has problems with parallel
builds when custom targets/commands come into play.

So maybe I should open an isse for this?

Best regards,
Marcel Loose.


___
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] Parallel make custom command

[Marcel Loose]

On Wed, 2011-06-29 at 20:46 +0200, Michael Wild wrote:
 On 06/29/2011 05:22 PM, Marcel Loose wrote:
  Hi all,
  
  I'm having a problem with a parallel 'make' where one or more
sources
  are generated by a custom command.
  
  The situation is as follows. There are a couple of targets
(executables)
  that depend on the same source file being generated by a custom
  command. 
  
  I notice that, when doing a parallel build, the custom command is
  executed multiple times, thereby potentially overwriting or
corrupting
  the same file that's generated in different threads.
  
  My feeling is that this is caused by the fact that CMake generates a
  build.cmake file for each target separately. Hence, when doing a
  parallel build, these build.cmake files are also processed in
parallel. 
  
  Am I correct in this assumption? And if so, what's the proper
solution
  for this problem?
  
  Best regards,
  Marcel Loose.
  
 
 Yes, I've seen this issue too. The only way I can think of fixing this
 is by having a single custom target which depends on the generated
 files, and then have the executables using the generated sources
depend
 on that custom target. This way you force the custom target to be run
 first before the other targets, thus avoiding the custom commands
 generating the sources from running multiple times.
 
 Michael
 ___
 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

Seems my webmail client completely screwed up the topic threading :-(
Here's my reply again, hopefully now placed properly. Sorry for the
noise.

After I had posted my question I realized that this issue has come up
quite recently on the mailing list in a thread that I started -- see
http://www.mail-archive.com/cmake@cmake.org/msg36362.html. Although the
original question was related to building mulitple targets in parallel,
Michael Hertling showed that CMake inherently has problems with parallel
builds when custom targets/commands come into play.

So maybe I should open an isse for this?

Best regards,
Marcel Loose.


___
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] Betr.: Re: Parallel make custom command

[Marcel Loose]

On Wed, 2011-06-29 at 21:55 +0200, Marcel Loose wrote:

Seems my webmail client completely screwed up the subject threading.
Sorry for the noise.

Best regards,
Marcel Loose.


___
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] Parallel build test problem

[Marcel Loose]

 by a custom command which - due to its construction - is
 sensitive to parallel execution and gives rise to a race condition.
 So, the warning w.r.t. building multiple targets in parallel must
 be taken absolutely seriously.

 However, David, things can even get worse: Enhance the above-noted
 PARALLEL project's CMakeLists.txt with the following three lines:

 FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
 ADD_EXECUTABLE(main main.c)
 TARGET_LINK_LIBRARIES(main f g)

 Most certainly, this is a quite common configuration, and IMO, it's
 perfectly legal to build with make -j2 main, i.e. explicitly only
 one target in parallel. When I enter the following lines

 while true; do
 (make clean; make -j2 main)  /dev/null;
 echo generate.txt: $(cat generate.txt);
 done

 I see plenty of generate.txt: 2 messages, i.e. the custom command is
 still executed twice and usually in sequence, but sometimes there's a
 generate.txt: 1 message. Obviously, the race condition hasn't gone.

 What does this mean in regard to parallel building a single target?
 Are independent targets the only ones that can be reliably built in
 parallel, i.e. do I have to build f,g and main individually in the
 correct order by hand? That would be strange, IMO. Maybe, someone
 can shed light upon this issue.


Hi Michael,

Nice example. Do you know, by any chance, if this only happens with
custom targets/commands. I get the feeling that race condition only seem
to happen with these user-defined thingies.

Maybe this should be put in the issue tracker? 

I haven't had any issues with race condition when building just one
target in parallel, but I *do* have occasional broken builds when
building multiple targets in parallel. In that case, one of the targets
is a custom target. I therefore recommended my colleague to build one
target at a time when doing parallel builds.

Regards,
Marcel Loose.


___
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] Parallel build test problem

[Marcel Loose]

Hi all,

A colleague of mine reported a bug in our CMake-base build system when
doing a parallel build of multiple targets where one of the targets is
'test'.

quote
Running 'make -j16 tMutex test' (or any test other than tMutex)
for example will result in building tMutex in parallel to
testing it.

Expected behaviour is first building tMutex, followed by running
the tests.
/quote

Is this indeed a bug? Either in our build system or in CMake? 
AFAIK it is not possible to define dependencies between the 'test'
target and the target to build the test program. Correct?

Best regards,
Marcel Loose.


-- 
Marcel Loose
Senior Software Engineer, Computing Group RD, Astron, the Netherlands

___
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] Parallel build test problem

[Marcel Loose]

On Mon, 2011-05-23 at 07:21 -0400, David Cole wrote:
 On Mon, May 23, 2011 at 4:13 AM, Marcel Loose lo...@astron.nl wrote:
 Hi all,
 
 A colleague of mine reported a bug in our CMake-base build
 system when
 doing a parallel build of multiple targets where one of the
 targets is
 'test'.
 
 quote
Running 'make -j16 tMutex test' (or any test other than
 tMutex)
for example will result in building tMutex in parallel
 to
testing it.
 
Expected behaviour is first building tMutex, followed
 by running
the tests.
 /quote
 
 Is this indeed a bug? Either in our build system or in CMake?
 AFAIK it is not possible to define dependencies between the
 'test'
 target and the target to build the test program. Correct?
 
 Best regards,
 Marcel Loose.
 
 
 --
 Marcel Loose
 Senior Software Engineer, Computing Group RD, Astron, the
 Netherlands
 
 ___
 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
 
 To the best of my knowledge you can only do a parallel make of one
 target at a time.
 
 
 The best way to do what you want is to do two parallel make runs in
 sequence, like this:
 
 
   make -j16 tMutex
   make -j16 test
 
 
 The test target is defined by CMake, though, and runs all tests.
 
 
 HTH,
 David
 
 

Hi David,

I vaguely remembered that limitation of 'make' as well, but I couldn't
find any relevant pointers on this, and colleagues questioned this
alleged limitation. Therefore I thought it might be a limitation of
CMake, or maybe I should say: the combination of CMake and make.

Anyway, my response was also to do two separate 'make' calls, one for
each target.

Regards,
Marcel Loose.


___
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] FIND_LIBRARY and PATH_SUFFIXES: documentation or implementation bug

[Marcel Loose]

Hi Michael,

 AFAICS, this is not true, see cmFindBase::AddPathSuffixes(). The paths
 with the additional suffixes are searched first, but the paths without
 the suffixes are considered, too. Look at the following
CMakeLists.txt:

 CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
 PROJECT(PATHSUFFIXES NONE)
 FILE(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/lib/config)
 FILE(WRITE ${CMAKE_BINARY_DIR}/lib/libxyz.so )
 FILE(WRITE ${CMAKE_BINARY_DIR}/lib/config/libxyz.a )
 SET(CMAKE_PREFIX_PATH ${CMAKE_BINARY_DIR})
 FIND_LIBRARY(XYZ1 xyz PATH_SUFFIXES config)
 MESSAGE(XYZ1: ${XYZ1})
 SET(CMAKE_FIND_LIBRARY_SUFFIXES .so)
 FIND_LIBRARY(XYZ2 xyz PATH_SUFFIXES config)
 MESSAGE(XYZ2: ${XYZ2})

 This yields:

 XYZ1: ${CMAKE_BINARY_DIR}/lib/config/libxyz.a
 XYZ2: ${CMAKE_BINARY_DIR}/lib/libxyz.so

You are right. I can reproduce this output. I now understand what led me
to the wrong conclusion.

I'm still using cmake 2.6.4 and there's a crucial difference between the
FindPythonLibs.cmake that ships with cmake 2.6.4 and 2.8.4. The latter
does indeed first search the normal path and only then uses the
config path suffix. The former, however, immediately starts of using
the config path suffix. 

Problem solved.

Regards,
Marcel Loose.


___
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] FIND_LIBRARY and PATH_SUFFIXES: documentation or implementation bug

[Marcel Loose]

Hi all,

I stumbled upon this issue, while trying to track down why
FindPythonLibs finds the static library libpython2.6.a
in /usr/lib64/python2.6/config, instead of the shared library
libpython2.6.so in /usr/lib64 on my system.

The find module uses PATH_SUFFIXES python${_CURRENT_VERSION}/config,
which in my case expands to python2.6/config. The documentation of
find_library() reads:

PATH_SUFFIXES specifies additional subdirectories to check below
each search path

Additional(!) subdirectories. However, if I do an strace I notice that
*only* the directories with the path suffixes are searched, not the
directories in the search path *without* the suffixes.

Is this a bug in the documentation or a bug in the implementation of
CMake?

Best regards,
Marcel Loose.

-- 
Marcel Loose
Senior Software Engineer, Computing Group RD, Astron, the Netherlands

___
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] TRY_LINK and CheckCXXSourceLinks ??

[Marcel Loose]

 On 11-1-2011 at 21:51, in message
20110111213036.af4c126...@public.kitware.com, Rolf Eike Beer
e...@sf-mail.de wrote: 
 Am Dienstag, 11. Januar 2011, 11:20:06 schrieb David Cole:
 Yes... this confused me when I first encountered it as well.
 
 TRY_COMPILE is misnamed in CMake.
 
 In functionality, it's actually a TRY_LINK operation.
 
 Update the doc?
 
 Eike

I opened an issue for this:
http://public.kitware.com/Bug/view.php?id=11688

Marcel.

___
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] TRY_LINK and CheckCXXSourceLinks ??

[Marcel Loose]

Hi all,

I was wondering how I can check whether I can successfully compile and
link an executable, without actually running it. CheckCXXSourceCompiles
checks whether I can compile the code, however linking could still fail.
CheckCXXSourceRuns OTOH also tries to run the executable, which causes
problems when cross-compiling. So, why is there no CheckCXXSourceLinks?

Best regards,
Marcel Loose.



-- 
Marcel Loose
Senior Software Engineer, Computing Group RD, Astron, the Netherlands

___
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] TRY_LINK and CheckCXXSourceLinks ??

[Marcel Loose]

Hi David,

I guess you're right. Further playing with CheckCXXSourceCompiles and
investigating the generated CMakeLists.txt file led me to the conclusion
that the link step is indeed also performed. I was led astray by the
name of the command and my notion that it wraps TRY_COMPILE. Also my
background in the GNU Autotools, which has TRY_COMPILE, TRY_LINK and
TRY_RUN, didn't really help. Sorry for the noise.

Best regards,
Marcel Loose.

-- 
Marcel Loose
Senior Software Engineer, Computing Group RD, Astron, the Netherlands
 David Cole  11-01-11 13:44 
Doesn't CheckCXXSourceCompiles link?

I think there's no way to avoid the link in a try_compile...


On Tue, Jan 11, 2011 at 5:49 AM, Marcel Loose  wrote:

 Hi all,

 I was wondering how I can check whether I can successfully compile and
 link an executable, without actually running it.
CheckCXXSourceCompiles
 checks whether I can compile the code, however linking could still
fail.
 CheckCXXSourceRuns OTOH also tries to run the executable, which causes
 problems when cross-compiling. So, why is there no
CheckCXXSourceLinks?

 Best regards,
 Marcel Loose.



 --
 Marcel Loose
 Senior Software Engineer, Computing Group RD, Astron, the Netherlands

 ___
 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] FindMPI doesn't differentiate between languages

[Marcel Loose]

 On 19-12-2010 at 0:04, in message
a43e19d1-af96-4935-99fd-705a4cda7...@llnl.gov, Todd Gamblin
tgamb...@llnl.gov wrote: 
 Hey all,
 
 This has been brought up before (sort of) here:
 

http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/26533
 
 FindMPI doesn't currently give you the libraries, includes, etc. for

 different languages. MPI compilers can (and typically do) have
different 
 includes/libraries depending on the language you're using.  It was
noted 
 above that you don't get the fortran libraries for MPI using the
current 
 macro.  Another problem with the current setup is that you're also
likely to 
 inadvertently get the C++ includes with the current FindMPI, unless
you 
 explicitly disable them using things like -DOMPI_SKIP_MPICXX.  This
can get 
 you unwanted C++ symbols in your MPI libraries (because the MPI C++
interface 
 and headers suck, but that's a whole different story).
 
 I'd be interested in fixing this.  But I would like guidance on how
to do 
 it.  My inclination would be to make a new version that gives you not
just 
 MPI_FOUND, MPI_LIBRARIES, etc.. but MPI_LANG_FOUND,
MPI_LANG_LIBRARIES, 
 MPI_LANG_INCLUDE_PATH, etc.  If you read the thread above, someone
suggested 
 using components for this back in January, but that was left on the
table and 
 seems not to have been implemented.
 
 What's the best way to implement proper language support in the
FindMPI 
 module?
 
 -Todd

Hi Todd,

I think this is a good idea. You might consider taking into account
which languages are currently enabled, either explicitly with
enable_language() or implicitly with project().

Best regards,
Marcel Loose.



-- 
Marcel Loose
Senior Software Engineer, Computing Group RD, Astron, the Netherlands

___
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] Howto let FIND_LIBRARY prefer static over shared libraries

[Marcel Loose]

Hi all,

Is there a way to let FIND_LIBRARY prefer static over shared
libraries?
I know of one, but that's a bit hack-ish: 

  SET(CMAKE_FIND_LIBRARY_SUFFIXES .a)

Are there other options? 
Ideally, I would like to be able to specify this per library search,
i.e. as an option to FIND_LIBRARY.

Best regards,
Marcel Loose.

___
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] Simultaneous --build-and-test and CDash submission

[Marcel Loose]

 On 9-12-2010 at 10:13, in message mwkqnalvczcgriuir...@oodl,
Wojciech Migda
wojtek.g...@interia.pl wrote: 
 Hi,
 
 I have unit tests configured for CDash submissions. Submissions do
work if I 
 issue in sequence TWO commands which go pretty much like this:
 
 # configure the build system
 ${CMAKE_ROOT}${CMAKE_BINDIR}/cmake .
 # build tests
 make clean ; make
 # run tests
 ${CMAKE_ROOT}${CMAKE_BINDIR}/ctest
 
 However, when doing that CDash shows useful results only for the test
phase 
 - build info is missing and configure info shows only 3 lines despite
removal 
 of CMakeCache.txt.
 
 So I attepmted using the build-and-test option. I would expect this
to work:
 
 /vob/tetra/tools/CMake/bin_linux_x86_64/ctest -D Experimental 
 --build-and-test . . --build-generator 'Unix Makefiles'
--build-makeprogram 
 `which clearmake`
 
 but it only builds and tests --- '-D' option seems to be ignored.
 
 I also tried this:
 
 /vob/tetra/tools/CMake/bin_linux_x86_64/ctest --build-and-test . . 
 --build-generator 'Unix Makefiles' --build-makeprogram `which
clearmake` 
 --test-command ./test_command.sh
 
 where test_command.sh executes 'ctest -D Experimental' but although
it 
 submission is achieved the CDash contents is the same as with the
original 
 two commands.
 
 So my question is how to achieve CDash submission with 'scratch'
configure 
 info (just as if cmake was invoked on clean environment), build info

 (compilation warnings and such) and test results by issueing single
command ?
 
 Thanks for help,
 
 Wojtek

Hi Wojtek,

If I understand you correctly, then you would in fact like to run ctest
without cmake. You can do that, be you'll need some plumbing (i.e. a
small ctest-script) to get ctest going. I think you'll find
http://www.cmake.org/Wiki/CTest:Using_CTEST_and_CDASH_without_CMAKE
useful.

Hope this helps,
Marcel Loose.

___
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 diagnostics when FIND_XXX fails

[Marcel Loose]

Hi all,

Is there a way to get useful diagnostics when, e.g., FIND_PATH()
fails.
I would like to be able to get a message like:

  Failed to find myheader.h, while searching the following directories:
/foo /bar /baz.

Now, I often find myself browsing a FindXXX.cmake file when it fails to
find some file, and try to understand why it couldn't find it. This is
not as easy as it sounds, due to the fact that the FIND_XXX command have
a quite a number of options, like HINTS and PAHTS, which makes it quite
hard to figure out which directories have been searched. 

As a last resort I sometimes use strace, but this is IMHO really not
the way it should be.

Best regards,
Marcel Loose.



___
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] Need some directions for non-trivial setup

[Marcel Loose]

 On 7-12-2010 at 11:59, in message
aanlktimssr9mqjgkhkz9xdtgh=1b9vsu1utlb90vb...@mail.gmail.com, Klaim
mjkl...@gmail.com wrote: 
 
 I would try to start with just one (base-)project, try to get
 everything in place and building the way you want it. If you're new
to
 CMake, that's really the way to go. Once you have this base-project
 ready, you can think of starting a second project, using the
 base-project as EXTERNAL_PROJECT(), etc.


 Yes, I started like that exactly.
 I've setup a simple library project, with the minimum CMakeLists.txt
file.
 It generates correctly, find all required sources, correctly build
when I
 try to build with MSVC2010.
 
 Now I tried to setup an executable project using this library
project.
 Maybe I'm kind of stupid but I can't find a clear
exlpaination/documentation
 about using EXTERNAL_PROJECT() so I failed so far to use it. Do you
have a
 simple example somewhere? I'm sure I missed something in the doc but
can't
 find what.
 
 I'm also looking for a way to provide/retreive the include paths of
those
 external projects.

Hi Klaim,

I would suggest that you use the FIND_XXX commands when building
against your CMakeified library project. EXTERNAL_PROJECT() really is
meant for downloading, configuring, building, etc. of non-CMake
packages.

Since you have full control over all your different CMake projects,
your life is (much) easier. All you have to do is to generate
ConfigXXX.cmake files for your XXX library. These ConfigXXX.cmake files
should set the same variables as a FindXXX.cmake file would. Only
difference is that you can generate the ConfigXXX.cmake file using the
information about XXX availabe to CMake.

Hope this helps,
Marcel Loose.



___
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] Need some directions for non-trivial setup

[Marcel Loose]

 On 8-12-2010 at 11:41, in message
aanlktike_bxnege96vtpzinyv6scwvjwtg+un74vn...@mail.gmail.com, Klaim
mjkl...@gmail.com wrote: 
 Thanks! I'll try this solution.
 
 By the way is there a way to list all projects found recursively in
a
 folder?

Not that I know of.
You can of course do a grep, but that's probably not what you mean.

Regards,
Marcel.

___
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] Need some directions for non-trivial setup

[Marcel Loose]

Sorry,

I really wouldn't know, I do development on Linux. My knowledge of MS
Visual Studio is negligible. 
On a general note, though, CMake uses a so-called generator to generate
the Visual Studio project files, as it can also generate Unix Makefiles,
or KDevelop project files.

Maybe you should start a new thread if you have MS-VS specific
questions. You'll have a much bigger chance that people will respond.

Regards,
Marcel


 On 8-12-2010 at 16:57, in message
aanlktinaqc9r94eudbepskrbdhtr45bj3vfarjc3j...@mail.gmail.com, Klaim
mjkl...@gmail.com wrote: 
 Sorry, a part of my sentence got cut :
 
  I don't understand what makes, for example, the CLang project
generate
 different projects in the Visual Studio solution generated depending
on the
 project folder content in LLVM repo. Or maybe it's automatic because
Cmake
 will scan all the subfolders of folders where there is a
CMakeLists.txt?
 
 On Wed, Dec 8, 2010 at 16:53, Klaim mjkl...@gmail.com wrote:
 
 I don't understand what makes, for example, the CLang project
generate
 different projects in the solution folder depending on the project
folder
 content in LLVM repo? Or maybe it's automatic because Cmake will
scan all
 the subfolders of folders where there is a CMakeLists.txt?


___
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] Need some directions for non-trivial setup

[Marcel Loose]

Hi Klaim,

I would try to start with just one (base-)project, try to get
everything in place and building the way you want it. If you're new to
CMake, that's really the way to go. Once you have this base-project
ready, you can think of starting a second project, using the
base-project as EXTERNAL_PROJECT(), etc. 

Good luck.
Marcel Loose.

 On 6-12-2010 at 21:46, in message
aanlktimmvbbx-bq1kceahsxd=pkz-aagkbsj5dscu...@mail.gmail.com, Klaim
mjkl...@gmail.com wrote: 
 

 It's a bit clearer to me  now ;-)
 Reading between the lines I get the feeling that you're probably
better
 off using just a single project anyway.
 A developer doesn't need to continuously update the whole project
when
 working on his subproject. Building the whole thing once in his
working
 copy should suffice.

 Most of those projects (and future related projects) are not
 interdependent. I had a repository with everything inside before
(using
 MSVC10 projects files) but it don't suit the developpement as each
project
 really need a separate repository with separate history and separate
teams
 working on it. I know I could use branches but that would make things
harder
 when managing the different projects separately.
 
 They have to be separate. That's not a question to me anymore.
 
 
 Personally, I have not yet gained any experience with
 EXTERNAL_PROJECT(), so I cannot really help you there. If your
 subsystems are *really* stand-alone pieces of software, then you
should
 create different CMake projects for them. However, like I said, I
get
 the feeling that that's not the case in your situation.

 
 It is this very case. I need them to be separate projects, sometime
linked
 because sometime you need some dependencies and maybe those
dependencies are
 in the same family of projects or something. Those dependencies
might be
 from outside too, but those projects have to be isolated.
 
 

 You might consider to use multiple PROJECT() commands inside your
 source tree. It will make your life slightly easier when you later
 decide you do want to split things up.

 
 That's already what I do. Well that's what's i'm trying but until now
I
 can't find a way to say to CMake where are the other projects. I
think I'm
 misusing EXTERNAL_PROJECT() but I'm not sure how.
 I'll get back on this issue in the week, see if I can make
 EXTERNAL_PROJECT() work as I need. I really think I don't have all
the
 pieces of the puzzle. I'm reading the other thread about how to make
 libraries works correctly with CMake and I think I don't know a lot
about
 what's really required.
 
 Anyway, thanks for your help.
 
 
 On 3-12-2010 at 13:13, in message
 

aanlktimfweyejp+maqkzcg-7a92bebvxhgo0bxrlj...@mail.gmail.comAANLkTimfWeyEJP%2
 bmaqkzcg-7a92bebvxhgo0bxrlj...@mail.gmail.com,
 Klaim
 mjkl...@gmail.com wrote:
  Thanks for pointing EXTERNAL_PROJECT , I've looked at it but
can't
  understand how to get the path from outside.
  I'll try again see if I missed something about this feature and
get
 back to
  you.
 
  The projects are almost all independent and I need to allow
working
 with a
  clone of one subproject without retrieving everything, just it
 dependencies.
 
  I'll try to be more clear :
   - there is a common language used to describe a Sequence (it's
 not
  important so just understand that the important projects in the
 framework
  will require this)
   - there are tools, all made to manipulate the sequences, so each
 project is
  independant (separate repo) but some projects need to use other
 projects, so
  we need to provide their path in their Cmake
   - there are players that are like tools but are just interpreter
 projects -
  anyway they are as indpendant or dependant as tools
 projects/subrepos
   - now I have central repository (default) that is just meant
to
 gather
  everything together; That's for people wanting everything but
they
 are few.
  Most subproject developers will just get their dependencies and
work
 from
  their, without updating the dependencies while developping. If
you
 get the
  default repo, you have synchronized repos togethere (read: we
use
 specific
  tags for each subrespo). So the default repository is mainly for
the
  developers needing to touch everything. Like me.
 
  Is it more clear?
 
  On Fri, Dec 3, 2010 at 11:16, Marcel Loose lo...@astron.nl
wrote:
 
   On 2-12-2010 at 16:12, in message
 
 
 

aanlktimju5wav=ekxnbmkplnl7dn_c+xssgkoefm5...@mail.gmail.comEKxnbmkpLnL7dN_c%
 2bxssgkoefm5...@mail.gmail.com
 EKxnbmkpLnL7dN_c%
  2bxssgkoefm5...@mail.gmail.com,
  Klaim
  mjkl...@gmail.com wrote:
   Hi!
  
   I'm currently trying to understand how to use CMake for a
 non-trivial
  setup
   of multiple-projects-framework. I'm a beginner at CMake (as
 developer
  I
   mean, not as library user).
   I've read the docs and I tried to read the Ogre project CMake
  organization
   but it's a bit overkill for my project I think. Anyway, I'm
lost
  here
   because
   I think I don't understand all I need to achieve what I

Re: [CMake] Need some directions for non-trivial setup

[Marcel Loose]

Hi Klaim,

It's a bit clearer to me  now ;-)
Reading between the lines I get the feeling that you're probably better
off using just a single project anyway.
A developer doesn't need to continuously update the whole project when
working on his subproject. Building the whole thing once in his working
copy should suffice.

Personally, I have not yet gained any experience with
EXTERNAL_PROJECT(), so I cannot really help you there. If your
subsystems are *really* stand-alone pieces of software, then you should
create different CMake projects for them. However, like I said, I get
the feeling that that's not the case in your situation.

You might consider to use multiple PROJECT() commands inside your
source tree. It will make your life slightly easier when you later
decide you do want to split things up.

Hope this helps.
Marcel Loose.

 On 3-12-2010 at 13:13, in message
aanlktimfweyejp+maqkzcg-7a92bebvxhgo0bxrlj...@mail.gmail.com, Klaim
mjkl...@gmail.com wrote: 
 Thanks for pointing EXTERNAL_PROJECT , I've looked at it but can't
 understand how to get the path from outside.
 I'll try again see if I missed something about this feature and get
back to
 you.
 
 The projects are almost all independent and I need to allow working
with a
 clone of one subproject without retrieving everything, just it
dependencies.
 
 I'll try to be more clear :
  - there is a common language used to describe a Sequence (it's
not
 important so just understand that the important projects in the
framework
 will require this)
  - there are tools, all made to manipulate the sequences, so each
project is
 independant (separate repo) but some projects need to use other
projects, so
 we need to provide their path in their Cmake
  - there are players that are like tools but are just interpreter
projects -
 anyway they are as indpendant or dependant as tools
projects/subrepos
  - now I have central repository (default) that is just meant to
gather
 everything together; That's for people wanting everything but they
are few.
 Most subproject developers will just get their dependencies and work
from
 their, without updating the dependencies while developping. If you
get the
 default repo, you have synchronized repos togethere (read: we use
specific
 tags for each subrespo). So the default repository is mainly for the
 developers needing to touch everything. Like me.
 
 Is it more clear?
 
 On Fri, Dec 3, 2010 at 11:16, Marcel Loose lo...@astron.nl wrote:
 
  On 2-12-2010 at 16:12, in message
 

aanlktimju5wav=ekxnbmkplnl7dn_c+xssgkoefm5...@mail.gmail.comEKxnbmkpLnL7dN_c%
 2bxssgkoefm5...@mail.gmail.com,
 Klaim
 mjkl...@gmail.com wrote:
  Hi!
 
  I'm currently trying to understand how to use CMake for a
non-trivial
 setup
  of multiple-projects-framework. I'm a beginner at CMake (as
developer
 I
  mean, not as library user).
  I've read the docs and I tried to read the Ogre project CMake
 organization
  but it's a bit overkill for my project I think. Anyway, I'm lost
 here
  because
  I think I don't understand all I need to achieve what I want.
 
  My project is made of several sub projects that are all in
separate
  (mercurial) repositories.
  There is one default repository that use the mercurial subrepos
 feature to
  gather everything in one big framework project.
  You can see the repos there :
  http://code.google.com/p/art-of-sequence/source/browse/ (it's an
open
 source
  project but Idon't have the website ready yet to explain the
 concept)
 
  The Cmake organisation I want to setup I've already seen
somewhere
 else I
  think, but I'm a bit lost with all the ways to do it and I think
I'll
 make
  something very bad if I don't ask here for help here.
  I need each project (subrepo) to be available separately and can
be
 built
  giving to Cmake the paths of the project's dependencies.
  And I need the default repo to provide the paths.
 
  So I have this folder organisation in the default repo (that
gather
 all
  subrepos) :
 
  /language   # the intermediate language
(AOSL)
  definition project/subrepo
  /tools/# the folder that will contain
all
 the
  tools projects/subrepos
  /tools/aosdesigner   # a tool project/subrepo (in fact
the
 most
  important) - an executable
  /tools/aoslcpp # a tool project/subrepo that is a
 dependency
  of aosdesigner - a library (shared)
  /players/ # the folder that will contain
all
 the
  players (AOSL interpreters)
  /players/aoswebplayer # a player project/subrepo
 
  There will be additional tools and players projects, and I
think
 I'll
  need another folder for exporters but that's another subject.
 
  Here, what I'm trying to do, is to have a CMakeLists.txt for each
 project
  (but /language that is not source code but xsd, xml and text).
  Those projects will need the path of dependencies, like
 /tools/aosdesigner
  will require the path of /tools/aoslcpp.
 
  Then I want to set the paths of each

Re: [CMake] Need some directions for non-trivial setup

[Marcel Loose]

 On 2-12-2010 at 16:12, in message
aanlktimju5wav=ekxnbmkplnl7dn_c+xssgkoefm5...@mail.gmail.com, Klaim
mjkl...@gmail.com wrote: 
 Hi!
 
 I'm currently trying to understand how to use CMake for a non-trivial
setup
 of multiple-projects-framework. I'm a beginner at CMake (as developer
I
 mean, not as library user).
 I've read the docs and I tried to read the Ogre project CMake
organization
 but it's a bit overkill for my project I think. Anyway, I'm lost
here
 because
 I think I don't understand all I need to achieve what I want.
 
 My project is made of several sub projects that are all in separate
 (mercurial) repositories.
 There is one default repository that use the mercurial subrepos
feature to
 gather everything in one big framework project.
 You can see the repos there :
 http://code.google.com/p/art-of-sequence/source/browse/ (it's an open
source
 project but Idon't have the website ready yet to explain the
concept)
 
 The Cmake organisation I want to setup I've already seen somewhere
else I
 think, but I'm a bit lost with all the ways to do it and I think I'll
make
 something very bad if I don't ask here for help here.
 I need each project (subrepo) to be available separately and can be
built
 giving to Cmake the paths of the project's dependencies.
 And I need the default repo to provide the paths.
 
 So I have this folder organisation in the default repo (that gather
all
 subrepos) :
 
 /language   # the intermediate language (AOSL)
 definition project/subrepo
 /tools/# the folder that will contain all
the
 tools projects/subrepos
 /tools/aosdesigner   # a tool project/subrepo (in fact the
most
 important) - an executable
 /tools/aoslcpp # a tool project/subrepo that is a
dependency
 of aosdesigner - a library (shared)
 /players/ # the folder that will contain all
the
 players (AOSL interpreters)
 /players/aoswebplayer # a player project/subrepo
 
 There will be additional tools and players projects, and I think
I'll
 need another folder for exporters but that's another subject.
 
 Here, what I'm trying to do, is to have a CMakeLists.txt for each
project
 (but /language that is not source code but xsd, xml and text).
 Those projects will need the path of dependencies, like
/tools/aosdesigner
 will require the path of /tools/aoslcpp.
 
 Then I want to set the paths of each project at the root level. It
would be
 perfect if I could symply get the name of all folders in /tools/
and
 /players/
 and simply provide them to the CMakeLists.txt of the sub projects.
 
 Is there a simple example of this kind of organisation out there that
I
 could be inspered of?
 Do you have some guidance to give me to setup all this?
 I tried to write this organisation but I'm clueless on how to gather
and
 provide the paths of each projects...
 
 Once I understand how to do this I think I'll use this organisation
for
 another big project too.
 
 Any help would be really.helpful :)
 Thanks for reading. Tell me if I was not clear on some points.
 
 Klaim

Hi Klaim,

It's not completely clear to me how tightly your subprojects are
coupled.

I would suggest you'd create a CMake project for each of your
subprojects and use the EXTERNAL_PROJECT feature to import the required
subproject. UNLESS: your subprojects cannot really exist as stand-alone
products, but are just parts of one overall project. In that case, I
would choose to create just one CMake project.

HTH,
Marcel Loose.
___
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] set CMAKE_INSTALL_PREFIX in CMakeLists

[Marcel Loose]

 On 30-11-2010 at 18:48, in message
20101130174852.gc10...@cryptio.net, Tyler
Roscoe ty...@cryptio.net wrote: 
 On Thu, Nov 25, 2010 at 02:01:31PM +0100, Marcel Loose wrote:
  On 24-11-2010 at 17:45, in message
 20101124164507.gg23...@cryptio.net, Tyler
 Roscoe ty...@cryptio.net wrote: 
  On Wed, Nov 24, 2010 at 12:11:56PM +0100, Micha Renner wrote:
  
 SET(CMAKE_INSTALL_PREFIX /foo/bar CACHE PATH Foo install
 prefix)
   
   So, without the test to
 CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT,
   and without the FORCE option.
 
  No, as I mentioned, there was an article of one the
 CMake-maintainers
  who recommended this.
  
  Micha is correct. CMAKE_INSTALL_PREFIX is set before your
 CMakeLists.txt
  is processed, so the above will never do anything.
  
  tyler
 
 Well, I tested this before I posted my reply. It does work the way
I
 describe it. Try it yourself.
 
 It doesn't work for me:
 
 [tyle...@tpb006:~/cmake-test-install-prefix]$ cmake --version
 cmake version 2.8.3
 
 [tyle...@tpb006:~/cmake-test-install-prefix]$ cat CMakeLists.txt
 cmake_minimum_required(VERSION 2.8)
 project(p)
 
 set (CMAKE_INSTALL_PREFIX foo CACHE PATH docstring)
 message (CMAKE_INSTALL_PREFIX = ${CMAKE_INSTALL_PREFIX})
 
 [tyle...@tpb006:~/cmake-test-install-prefix]$ mkdir b  cd b 
cmake ..
 -- 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
 CMAKE_INSTALL_PREFIX = /usr/local
 -- Configuring done
 -- Generating done
 -- Build files have been written to:
/tpb006/tylermr/cmake-test-install-prefix/b

Hi Tyler,

I now see why it works for me and not for you. Maybe I didn't write it
clearly, but I do SET(CMAKE_INSTALL_PREFIX ...) *before* the call to
PROJECT(). You are right that it doesn't work when you do it after the
PROJECT() call. Unfortunately, the solution with the IF-test doesn't
work when you use it before the PROJECT() call, for obvious reasons I
would say.

So, there are two solutions that work, but you have to choose carefully
among them.

1) Use this snippet *before* PROJECT(xxx):
  SET(CMAKE_INSTALL_PREFIX path CACHE PATH comment)

2) Use this snippet *after* PROJECT(xxx):
  IF(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
SET(CMAKE_INSTALL_PREFIX path CACHE PATH comment FORCE)
  ENDIF(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)

Best regards,
Marcel Loose.

___
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] set CMAKE_INSTALL_PREFIX in CMakeLists

[Marcel Loose]

 On 30-11-2010 at 21:36, in message
759ee5dc-038d-4c17-91da-98121049a...@mac.com, S Roderick
kiwi@mac.com
wrote: 
 On Nov 30, 2010, at 13:40 , David Cole wrote:
 
 It probably works accidentally if you do the set before the
project 
 command.
 
 That is what we do, and it definitely works for us. Set it _before_
the 
 PROJECT() statement.
 
+1 for me. I have a LofarInit.cmake file that is included before
PROJECT(LOFAR). I wouldn't want this feature to break.

Regards,
Marcel Loose.

___
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 apply the --as-needed linker flag?

[Marcel Loose]

 On 28-11-2010 at 9:10, in message
alpine.deb.2.00.1011272348290.11...@ybpnyubfg.ybpnyqbznva, Alan W.
Irwin
ir...@beluga.phys.uvic.ca wrote: 
 On 2010-11-28 06:39+0100 Michael Hertling wrote:
 
 On 11/27/2010 06:45 PM, Alan W. Irwin wrote:
 I just discovered that many Linux distros these days use the
 --as-needed Linux linker option by default.  At first glance that
 option makes a lot of sense since it tends to reduce startup
times.
 But I guess there are some caveats as well which is probably why
CMake
 does not adopt this linker option by default for Linux builds.
 However, I would at least like to try this option for my own Linux
 builds without forcing it using target_link_libraries. Is it
possible
 to specify linker options such as --as-needed using environment
 variables and/or -D options?

 On Linux, CMake takes account of the LDFLAGS environment variable
 for the initial configuration of the build directory, so saying

 LDFLAGS=-Wl,--as-needed cmake path/to/srcdir

 enables --as-needed for this build directory - forever.
 
 Thanks, Michael, that was exactly what I needed.  I was completely
 unaware that environment variable worked for CMake despite many
years
 of using CMake on Linux.  Is the LDFLAGS environment variable
 documented for CMake anywhere?  I couldn't find it in the
 documentation you get with cmake --help-full, and it is also not
 documented at http://www.cmake.org/Wiki/CMake_Useful_Variables. The
 useful environment variables CXXFLAGS, CFLAGS, and FFLAGS that allow
 you to specify general compiler flags in a convenient way are
 undocumented as well, and that is a real shame.
 
 Alan
 __
 Alan W. Irwin
 
 Astronomical research affiliation with Department of Physics and
Astronomy,
 University of Victoria (astrowww.phys.uvic.ca).
 
 Programming affiliations with the FreeEOS equation-of-state
implementation
 for stellar interiors (freeeos.sf.net); PLplot scientific plotting
software
 package (plplot.org); the libLASi project (unifont.org/lasi); the
Loads of
 Linux Links project (loll.sf.net); and the Linux Brochure Project
 (lbproject.sf.net).

Hi Alan,

You may find the following links of interest. They discuss the virtues
and risks of using --as-needed in the light of underlinking and
overlinking; and how to fix broken packages in distributions.

http://wiki.mandriva.com/en/Overlinking
http://wiki.mandriva.com/en/Underlinking
http://www.gentoo.org/proj/en/qa/asneeded.xml

Regards,
Marcel Loose.

___
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] providing library information, what's the cmake way

[Marcel Loose]

 On 25-11-2010 at 17:34, in message
201011251734.55788.johannes.z...@jku.at,
Johannes Zarl johannes.z...@jku.at wrote: 

 I took the liberty and compiled such a compatibility matrix here:
 http://www.cmake.org/Wiki/CMake_Version_Compatibility_Matrix
 
 It's a draft and does not (yet) contain information about properties
and 
 variables, but if this idea receives general consent I could complete
the 
 information.
 
 What do you think? Is this worth the effort, or would no one ever
bother to 
 update the information?

NICE !! I think this is really handy and definitely worth the effort. 

However, how's keeping 
http://www.cmake.org/Wiki/CMake_Released_Versions  up-to-date?
Since, you're matrix is just a user-friendly representation of that
information.

Regards,
Marcel Loose.

___
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] providing library information, what's the cmake way

[Marcel Loose]

 On 24-11-2010 at 17:34, in message
ddc068a445e2cc6dcf015e9b84217da0.squir...@webmail.sf-mail.de, Rolf
Eike
Beer e...@sf-mail.de wrote: 
  On Wed, Nov 24, 2010 at 6:57 AM, Rolf Eike Beer e...@sf-mail.de
wrote:
 In KDE we have a macro MACRO_WRITE_BASIC_CMAKE_VERSION_FILE()
which
 helps
 with
 creating a basic version-info file which should be installed along
with
 the
 Config-file.
 It consists of MacroWriteBasicCMakeVersionFile.cmake and
 BasicFindPackageVersion.cmake.in which you can find in
 http://websvn.kde.org/trunk/KDE/kdelibs/cmake/modules/ .

 I wonder why you use

 get_filename_component(_currentListFileDir
${CMAKE_CURRENT_LIST_FILE}
 PATH)

 in there instead of CMAKE_CURRENT_LIST_DIR.
 
 Probably because CMAKE_CURRENT_LIST_DIR was just invented and is
only
 in CMake 2.8.3... get_filename_component works with several
versions
 of CMake, and does not require 2.8.3 or later.
 
 So I think it is _really_ necessary to go through all the CMake
 documentation items and add a line about when which feature was
added.
 
 Everyone looks into his local CMake documentation and uses what he
finds
 in there. And then it breaks on older versions. You currently have
no
 chance to know what works but to install all older versions and do a
 binary search in the documentation. That simply does not scale.
 
 Eike

That's what CMAKE_MINIMUM_REQUIRED() is for. If you're developing with
CMake 2.8.2, and you want to make sure that you don't use any features
that are not supported by CMake prior to version 2.8.2, you should put
this at the top of your CMakeLists.txt file:

CMAKE_MINIMUM_REQUIRED(VERSION 2.8.2)

But you do have a point. It would really help people developing CMake
files to know whether they can use a given command or not if they want
to support, say, CMake 2.6.0. To be honest, the people at Kitware don't
make that an easy job, because almost every patch-release contains new
features :-(

Best regards,
Marcel Loose.

___
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] set CMAKE_INSTALL_PREFIX in CMakeLists

[Marcel Loose]

 On 24-11-2010 at 17:45, in message
20101124164507.gg23...@cryptio.net, Tyler
Roscoe ty...@cryptio.net wrote: 
 On Wed, Nov 24, 2010 at 12:11:56PM +0100, Micha Renner wrote:
 
SET(CMAKE_INSTALL_PREFIX /foo/bar CACHE PATH Foo install
prefix)
  
  So, without the test to
CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT,
  and without the FORCE option.

 No, as I mentioned, there was an article of one the
CMake-maintainers
 who recommended this.
 
 Micha is correct. CMAKE_INSTALL_PREFIX is set before your
CMakeLists.txt
 is processed, so the above will never do anything.
 
 tyler

Well, I tested this before I posted my reply. It does work the way I
describe it. Try it yourself.

Marcel.

___
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] set CMAKE_INSTALL_PREFIX in CMakeLists

[Marcel Loose]

 On 23-11-2010 at 15:37, in message
1290523061.2001.8.ca...@gildemeister-2,
Micha Renner micha.ren...@t-online.de wrote: 
 Am Dienstag, den 23.11.2010, 15:01 +0100 schrieb Michael Wild:
 On 11/23/2010 02:33 PM, Micha Renner wrote:
  Am Dienstag, den 23.11.2010, 14:01 +0100 schrieb
tomas...@sbc.su.se:
  Dear Cmake users,
 
  1) I am trying to set CMAKE_INSTALL_PREFIX in the CMakeLists file
with
  SET(CMAKE_INSTALL_PREFIX, my/path)
   ^
   No comma!
  
  greetings
  Micha
 
 And *NEVER EVER* set CMAKE_INSTALL_PREFIX in your CMakeLists.txt
file.
 That is a user-setting and you will make people angry at you if you
 override their choice in your code.
 
 Okay, then this might help:
 
 IF(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
   SET(CMAKE_INSTALL_PREFIX /usr/local CACHE PATH Foo install
prefix FORCE)
 ENDIF(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
 
 Of course, this is not my idea. It had someone from kitware, I don't
 remember who it was.
 
 
 greetings
 Micha

Hi Micha,

I would prefer to use

  SET(CMAKE_INSTALL_PREFIX /foo/bar CACHE PATH Foo install prefix)

So, without the test to CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT,
and without the FORCE option.

Reason: if someone unsets CMAKE_INSTALL_PREFIX on the command-line with
-U, CMAKE_INSTALL_PREFIX will default to /foo/bar (which is the
project's default), instead of /usr/local (which is CMake's default).

Just my 2cts.

Marcel Loose.
___
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] set_source_files_properties for include directories

[Marcel Loose]

 On 23-11-2010 at 10:55, in message 4ceb8f76.80...@korg.it, Andrea
Galeazzi
galea...@korg.it wrote: 
 In a project I've got two groups of files having different include 
 paths. These paths have some conflicts so I need to specify just one 

 for each file requires it.
 My first idea was to apply set_source_files_properties with a
property 
 like include_directories but I don't find anything similar. My next 
 attempt is gonna use the COMPILE_FLAGS property, does anybody know a

 more efficient and elegant way to accomplish a such task?
 An equivalent issue was discussed in this thread 
 http://www.mail-archive.com/cmake@cmake.org/msg05276.html but I
didn't 
 find any useful answer.
 ___
 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

Hi Andrea,

As you noted include_directories is a per-directory setting. So, if
you're free to reorganize your source files, you could put the two
groups of files in two different directories. Then you can use
include_directories() in each directory. Make sure you don't make one of
these directories a subdirectory of the other.

HTH,
Marcel Loose.

___
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-developers] User vs CMake include mismatch handling

[Marcel Loose]

 be the default.
 
 OLD and warn should be the default. Then projects themselves that
have
 these modules, can say use cmake 2.8.3 until we have a chance to
 update our code... then you can use cmake 2.8.4
 
 It should be consistent with all other policies.
 
 Otherwise, it will be too hard to explain this policy.
 
 OLD and warn.
 NEW if a project explicitly sets it NEW or requires 2.8.4.
 
 Why should this policy be the first intentional exception to this
pattern?
 
 It shouldn't.
 
 
 David

Hi all,

I've been following this discussion with interest for quite a while. I
was wondering if both worlds could be united (Alex's and David's) if it
were possible to set cmake_minimum_required on the command line? That
way Alex can be happy, because he doesn't have to modify CMakeLists.txt
files - something he cannot do for previous KDE releaeses; and David
will be happy, because old projects will not suddenly break due to some
incompatible changes in CMake.

BTW: IMHO this new policy should default to NEW for CMake 2.8.4 and
later, but I think that's what David suggested as well.

Just my 2cts.

Regards,
Marcel Loose.


___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [CMake] Problems with parallel builds

[Marcel Loose]

 On 18-11-2010 at 13:06, in message
306960.51089...@web65407.mail.ac4.yahoo.com, Denis Scherbakov
denis_scherba...@yahoo.com wrote: 
 Dear All,
 
 I am using CMake 2.8.1 on Linux x86. I have a project that needs to
be built 
 two times. One with -fPIC, the other - without. The project depends
on header 
 files that need to be generated by an external script.
 
 When I build this project with several parallel jobs (gmake -j5, for
example) 
 to my disappointment CMake calls external script several times so at
the end 
 I get corrupted header files.
 
 Does anybody know a cross-platform way of implementing a mutex (or
something 
 like that) to make sure that scripts that generate files are called
only 
 once?
 
 So far for me parallel builds do not work with CMake at all. 
 
 Thanks.
 Denis
 
 
   
 ___
 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

Hi Denis,

If you have two different build directories, which you need to have
anyway when compiling with and without -fPIC, then you shouldn't have a
problem, as long as you generate those header files in the build
directory, which is IMHO the only sensible place to put generated files
(your source tree might even be read-only!). Or maybe I completely
misunderstood your question.

Best regards,
Marcel Loose.

___
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] make test missing

[Marcel Loose]

On Mon, 2010-11-08 at 18:28 -0800, Alan W. Irwin wrote:
 On 2010-11-09 02:52+0100 Michael Hertling wrote:
 
  On 11/08/2010 10:03 PM, Jochen Issing wrote:
  Hi list,
 
  I tried to add ctest to my project and did this by adding
ENABLE_TESTING() and several ADD_TEST(...) to my CMakeLists.txt file.
  The tests are run on executables, which are built inside a
dedicated test directory in my project root and the execs show up in my
Makefile.
  After reading through some docs, I am told to call make test after
building. However, no target named 'test' is available.
 
  I.e. it doesn't show up in the listing of make help?
 
  Here my question: Does my directory 'test' interfere with the
'test' rule or do I have to install the executables before testing or do
I still miss something?
 
  On *nix, I can see the following CMakeLists.txt work:
 
  CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
  PROJECT(TEST C)
  ENABLE_TESTING()
  FILE(MAKE_DIRECTORY ${CMAKE_SOURCE_DIR}/test
${CMAKE_BINARY_DIR}/test)
  FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
  ADD_EXECUTABLE(main main.c)
  SET_TARGET_PROPERTIES(
 main
 PROPERTIES
 RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/test
  )
  ADD_TEST(NAME main COMMAND main)
 
  The output of make test - without installation - is:
 
  Running tests...
  Test project /home/hertling/work/cmake/issing/obj
 Start 1: main
  1/1 Test #1: main .   Passed0.00 sec
 
  100% tests passed, 0 tests failed out of 1
 
  Total Test time (real) =   0.11 sec
 
  So, I'd conclude the test directories' presence doesn't matter,
  nor does the fact if an installation has already been performed.
 
 In the past this mattered a lot so the PLplot project had to rename
 our test source tree directory to plplot_test to avoid the clash with
 the name of the test target.
 
 It is possible your example above is not complicated
 enough to trigger the clash.  For example, your test
 subdirectories are just created, but you do not have an
 add_subdirectory(test) command to actually run cmake within that
 test subdirectory.
 
 So I would suggest to the OP that they do rename their test directory
 to something else because I am pretty sure that will solve the issue.
 Until PLplot did that (for a much earlier version of CMake) make
 test failed to work for us.
 
 Alan
 
 
 
 
  Maybe, you could post your CMakeLists.txt for further inspection.
 
  Regards,
 
  Michael
 
  Anyhow, 'ctest -D Experimental' seems to do something :/
 
  Also, I am not sure if I need to setup a Dashboard-Server to use
testing at all. I suppose it's possible without a dashboard, but don't
know how.
  Thanks in advance!
  Cheers,
 
  - jochen
  gpg: 1024D/013400C7
  ___
  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
 
 
 __
 Alan W. Irwin
 
 Astronomical research affiliation with Department of Physics and
Astronomy,
 University of Victoria (astrowww.phys.uvic.ca).
 
 Programming affiliations with the FreeEOS equation-of-state
implementation
 for stellar interiors (freeeos.sf.net); PLplot scientific plotting
software
 package (plplot.org); the libLASi project (unifont.org/lasi); the
Loads of
 Linux Links project (loll.sf.net); and the Linux Brochure Project
 (lbproject.sf.net).
 __
 
 Linux-powered Science
 __

Hi Alan and others,

We have lots of directories named 'test' that contain test programs. I
add them with add_subdirectory() and never ran into problems of target
'test' not existing. My assumption is that there's something else going
wrong here.

Best regards,
Marcel Loose.

___
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