Re: [CMake] CMake 2.8.6-rc4 ready for testing!

[Alan W. Irwin]

On 2011-09-22 16:14-0400 David Cole wrote:


Please try this version of CMake on your projects and report any
issues to the list or the bug tracker.

Happy building!


Hi Dave:

I have done fairly exhaustive tests of the PLplot build and test system
using CMake-2.8.6-rc4, and unlike rc3 all seems well for rc4.  As far as I
am concerned, bring on 2.8.6-final!

Much thanks to you and the rest of the CMake development team for this
effort!

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

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] Scope of find_package inside a function block

[Michael Wild]

On Thu 22 Sep 2011 11:17:14 PM CEST, Lori Pritchett-Sheats wrote:
> I was wondering what the scope of the variables set in a FindXXX.cmake
> file is and does find_package_handle_standard_args change that scope.
>
> For example, I create a FindBar.cmake file that sets Bar_INCLUDE_DIR,
> Bar_LIBRARY, Bar_INCLUDE_DIRS and Bar_LIBRARIES, and calls
> find_package_handle_standard_args to set Bar_FOUND correctly if
> Bar_INCLUDE_DIRS and Bar_LIBRARIES is set. If I call find_package(Bar)
> inside a function-endfunction block, are the variables scoped outside
> the function block?
>
> I have a simple test case and I'm seeing strange results where some of
> the Bar_* variables are defined outside the function block. It's very
> strange. I'm wondering if my find_package_handle_standard_args call
> affects the variable scope, because  in my simple test case,
> Bar_FOUND, Bar_INCLUDE_DIRS and Bar_LIBRARIES are not set outside the
> function block, but Bar_INCLUDE_DIR and Bar_LIBRARY are.
>
> Thanks.
>

Only the cached variables will be visible outside the function scope,
all others not. Usually a FindXXX.cmake module looks like this:

find_path(XXX_INCLUDE_DIR xxx.h)
find_library(XXX_xxx_LIBRARY xxx)
find_library(XXX_yyy_LIBRARY yyy)
include(FindPackageHandleStandardArgs)
find_package_handle_standard_args(XXX DEFAULT_MSG
  XXX_INCLUDE_DIR XXX_xxx_LIBRARY XXX_yyy_LIBRARY)
if(XXX_FOUND)
  set(XXX_INCLUDE_DIRS ${XXX_INCLUDE_DIR})
  set(XXX_LIBRARIES ${XXX_xxx_LIBRARY} ${XXX_yyy_LIBRARY})
endif()

Now, the find_path() and find_library() calls store their results in the
cache, so the values are global, but all the other variables, such as
XXX_FOUND, XXX_INCLUDE_DIRS and XXX_LIBRARIES (notice the plural of the
latter two) are not cached, and thus subject to the function scope.
Also, their value will not be propagated upwards in the directory tree.

BTW: This is one of the few exceptions where I think that macros are
useful, because they allow you to call find_package() without knowing
all the variable that are being set.

HTH

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

Re: [CMake] using matlab mex compiler with cmake on windows

[David Cole]

You can't set CC and CXX and use them with the Visual Studio generators. Try
using a makefile generator instead...

HTH,
David


On Thursday, September 22, 2011, Jaka Katrašnik 
wrote:
> Hi,
>
> I'm having trouble using cmake to compile a matlab mex file. When I try to
to use cmake with the CC CXX environment variables set to mex I get the
following error
>
> E:\Jaka_docs\cmake tutorial\step1>cmake .
> -- Building for: Visual Studio 10
> CMake Error at C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/CMakeDet
> ermineCCompiler.cmake:44 (MESSAGE):
>   Could not find compiler set in environment variable CC:
>
>   mex.
> Call Stack (most recent call first):
>   CMakeLists.txt:2 (project)
>
>
> CMake Error: Could not find cmake module file:E:/Jaka_docs/cmake
tutorial/step1/
> CMakeFiles/CMakeCCompiler.cmake
> CMake Error: Could not find cmake module file:E:/Jaka_docs/cmake
tutorial/step1/
> CMakeFiles/CMakeCXXCompiler.cmake
> -- Configuring incomplete, errors occurred!
>
>
> Has anyone had a similar problem? Do you know of a solution to this?
>
> Thank you
> Jaka Katrasnik
>
>
--

Powered by www.kitware.com

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

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

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

Re: [CMake] CMake 2.8.6-rc4 ready for testing!

[David Cole]

Sorry, but no, not for 2.8.6. From now on we will only consider fixes for
regressions, and we hope to finalize 2.8.6 by end of next week.

On the other hand, you can override all the settings in CTestConfig already,
if you set the variables at the right point in a ctest -S script (typically
after the call to ctest_configure...)

That would be an alternative you can consider for using with any ctest 2.8.x

If you really want a change like this in CMake, we'd consider it for the
next release, but it should be in 'next' and tested on the dashboard well
before the release candidate phase leading up to a release.

Thx,
David C.


On Thursday, September 22, 2011, Jean-Christophe Fillion-Robin <
jchris.filli...@kitware.com> wrote:
> Hi Dave,
>
> Would it be possible to include the following topic in the release:
>  https://github.com/jcfr/CMake/tree/check-ctestconfig-in-builddir
>
> The change is documented and tests have been added:
>
> Expect CTestConfig.cmake in either the build or source directory <
https://github.com/jcfr/CMake/commit/268c0e5d015e36145c4d48c91d169c636ea172cd>
…
>
> Provide the ability to configure CTest with setting different from the one
> available in the source tree by checking first if CTestConfig.cmake
> exists in the build tree first.
>
>
>
> The motivation is to allow build system checking out external project to
> test and/or package them and submit the associated results to a different
> dashboard than the one specified (or not) in the source of the external
>
>
> project.
>
> For example, the build system of Slicer can checkout, build, test
> and package what I will  call "extension". These extensions can be
developed
> by third party who can test and submit to their own dashboard / project.
>
>
> When checkout by Slicer build system, the default dashboard can be now
> overwritten by adding a custom CTestConfig.cmake to the build directory.
> And if not overwritten, it would avoid to create CTestConfig.cmake within
>
>
> the source checkout of the extension.
>
> Thanks
> Jc
>
> On Thu, Sep 22, 2011 at 4:14 PM, David Cole 
wrote:
>>
>> The CMake 2.8.6 release candidate stream continues! You can find the
>> source and binaries here:
>>
>>  http://www.cmake.org/files/v2.8/?C=M;O=D
>>
>> This email is also available on the Kitware blog at
>>
>>  http://www.kitware.com/blog/home/post/170
>>
>> This is the last rc before the final release, unless somebody finds a
>> showstopper issue between now and next Thursday.
>>
>> This release candidate we do not have pre-built binaries for the
>> SunOS anymore. As mentioned on the CMake mailing list recently, our
>> Sun hardware has bitten the proverbial dust.
>>
>> However, we are now providing two sets of installers for the Mac.
>> The "Darwin" versions are for Mac OSX 10.4 and later, and are "ppc;i386"
>> universal binaries. The "Darwin64" versions are for 10.6 and later,
>> and are "x86_64;i386" universal binaries.
>>
>> Following is the list of changes in this release. Since we switched to
>> git, this list is now the 'git log' one line summary written by the
>> named CMake developers.
>>
>> Please try this version of CMake on your projects and report any
>> issues to the list or the bug tracker.
>>
>> Happy building!
>> -Dave
>>
>>
>> Changes in CMake 2.8.6-rc4 (since 2.8.6-rc3)
>> 
>> Alex Neundorf (3):
>>  FindFLEX.cmake: also search the include dir
>>  Fix typos in FeatureSummary.cmake (#12462)
>>  Don't warn when setting a property multiple times to the same value
#12464
>>
>> Bill Hoffman (2):
>>  For VS Intel Fortran IDE builds, add a check to find the Fortran
>> library PATH.
>>  Enable Fortran tests for IDE builds.
>>
>> Brad King (5):
>>  FortranCInterface: Compile separate Fortran lib in VerifyC[XX]
>>  Move IntelVSImplicitPath project to better location
>>  Simplify IntelVSImplicitPath detection project
>>  libarchive: Fix ssize_t detection with mingwrt 3.20
>>  Make file(DOWNLOAD) fail on http error
>>
>> David Cole (8):
>>  Tests: Add a KWStyle test, equivalent to the make StyleCheck target
>>  KWStyle Test: Activate by default if KWStyle is found
>>  Xcode: Use EFFECTIVE_PLATFORM_NAME reference in ComputeOutputDir
>>  Xcode: Add test to demonstrate iOS project in Xcode
>>  CMake: Reference test targets only when BUILD_TESTING is ON
>>  Tests: Add the more modern Mac64 nightly build
>>  Release Scripts: Use Qt 4.7.4 on dashmacmini5 (#12460)
>>  Revert "FindThreads: Try pthreads with no special option first
(#11333)"
>>
>> Eric NOULARD (4):
>>  CPack fix #12449 doc mispelled
>>  CPack fix template too
>>  CPackDeb fix #10325 automagically use fakeroot for DEB if
>> fakeroot is found
>>  CPackRPM authorize per-component pre/post-[un]install scripts
(#0012063)
>>
>> Marcus D. Hanwell (4):
>>  Just code style changes.
>>  Don't warn when nothing to do in visibility function.
>>  Made ADD_COM

[CMake] using matlab mex compiler with cmake on windows

[Jaka Katrašnik]

Hi,

I'm having trouble using cmake to compile a matlab mex file. When I try to
to use cmake with the CC CXX environment variables set to mex I get the
following error

E:\Jaka_docs\cmake tutorial\step1>cmake .
-- Building for: Visual Studio 10
CMake Error at C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/CMakeDet
ermineCCompiler.cmake:44 (MESSAGE):
  Could not find compiler set in environment variable CC:

  mex.
Call Stack (most recent call first):
  CMakeLists.txt:2 (project)


CMake Error: Could not find cmake module file:E:/Jaka_docs/cmake
tutorial/step1/
CMakeFiles/CMakeCCompiler.cmake
CMake Error: Could not find cmake module file:E:/Jaka_docs/cmake
tutorial/step1/
CMakeFiles/CMakeCXXCompiler.cmake
-- Configuring incomplete, errors occurred!


Has anyone had a similar problem? Do you know of a solution to this?

Thank you
Jaka Katrasnik
--

Powered by www.kitware.com

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

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

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

Re: [CMake] CMake 2.8.6-rc4 ready for testing!

[Jean-Christophe Fillion-Robin]

Hi Dave,

Would it be possible to include the following topic in the release:
 https://github.com/jcfr/CMake/tree/check-ctestconfig-in-builddir

The change is documented and tests have been added:

Expect CTestConfig.cmake in either the build or source
directory
…

Provide the ability to configure CTest with setting different from the one
available in the source tree by checking first if CTestConfig.cmake
exists in the build tree first.


The motivation is to allow build system checking out external project to
test and/or package them and submit the associated results to a different
dashboard than the one specified (or not) in the source of the external

project.

For example, the build system of Slicer can checkout, build, test
and package what I will  call "extension". These extensions can be developed
by third party who can test and submit to their own dashboard / project.

When checkout by Slicer build system, the default dashboard can be now
overwritten by adding a custom CTestConfig.cmake to the build directory.
And if not overwritten, it would avoid to create CTestConfig.cmake within

the source checkout of the extension.


Thanks
Jc

On Thu, Sep 22, 2011 at 4:14 PM, David Cole  wrote:

> The CMake 2.8.6 release candidate stream continues! You can find the
> source and binaries here:
>
>  http://www.cmake.org/files/v2.8/?C=M;O=D
>
> This email is also available on the Kitware blog at
>
>  http://www.kitware.com/blog/home/post/170
>
> This is the last rc before the final release, unless somebody finds a
> showstopper issue between now and next Thursday.
>
> This release candidate we do not have pre-built binaries for the
> SunOS anymore. As mentioned on the CMake mailing list recently, our
> Sun hardware has bitten the proverbial dust.
>
> However, we are now providing two sets of installers for the Mac.
> The "Darwin" versions are for Mac OSX 10.4 and later, and are "ppc;i386"
> universal binaries. The "Darwin64" versions are for 10.6 and later,
> and are "x86_64;i386" universal binaries.
>
> Following is the list of changes in this release. Since we switched to
> git, this list is now the 'git log' one line summary written by the
> named CMake developers.
>
> Please try this version of CMake on your projects and report any
> issues to the list or the bug tracker.
>
> Happy building!
> -Dave
>
>
> Changes in CMake 2.8.6-rc4 (since 2.8.6-rc3)
> 
> Alex Neundorf (3):
>  FindFLEX.cmake: also search the include dir
>  Fix typos in FeatureSummary.cmake (#12462)
>  Don't warn when setting a property multiple times to the same value
> #12464
>
> Bill Hoffman (2):
>  For VS Intel Fortran IDE builds, add a check to find the Fortran
> library PATH.
>  Enable Fortran tests for IDE builds.
>
> Brad King (5):
>  FortranCInterface: Compile separate Fortran lib in VerifyC[XX]
>  Move IntelVSImplicitPath project to better location
>  Simplify IntelVSImplicitPath detection project
>  libarchive: Fix ssize_t detection with mingwrt 3.20
>  Make file(DOWNLOAD) fail on http error
>
> David Cole (8):
>  Tests: Add a KWStyle test, equivalent to the make StyleCheck target
>  KWStyle Test: Activate by default if KWStyle is found
>  Xcode: Use EFFECTIVE_PLATFORM_NAME reference in ComputeOutputDir
>  Xcode: Add test to demonstrate iOS project in Xcode
>  CMake: Reference test targets only when BUILD_TESTING is ON
>  Tests: Add the more modern Mac64 nightly build
>  Release Scripts: Use Qt 4.7.4 on dashmacmini5 (#12460)
>  Revert "FindThreads: Try pthreads with no special option first
> (#11333)"
>
> Eric NOULARD (4):
>  CPack fix #12449 doc mispelled
>  CPack fix template too
>  CPackDeb fix #10325 automagically use fakeroot for DEB if
> fakeroot is found
>  CPackRPM authorize per-component pre/post-[un]install scripts
> (#0012063)
>
> Marcus D. Hanwell (4):
>  Just code style changes.
>  Don't warn when nothing to do in visibility function.
>  Made ADD_COMPILER_EXPORT_FLAGS into a macro.
>  Make add_compiler_export_flags a function again.
>
> Rolf Eike Beer (1):
>  remove stray brace in CPackDeb documentation
> --
>
> 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] CMake 2.8.6 RC3 FindBoost Regression Error

[Todd Gamblin]

David,

Sounds good.  I'll fix this at some point and push it to next for after 2.8.6.  
Philip: if you have any other suggestions let me know; I'll try to put those in 
too.

-Todd


On Sep 22, 2011, at 1:17 PM, David Cole wrote:

> Todd,
> 
> Unless somebody other than Mike speaks up that there's a regression,
> we won't take any more changes for the final CMake 2.8.6.
> 
> From right now on (I just sent the -rc4 email out...) we will only
> accept fixes for MAJOR regressions that people notice between now and
> next week.
> 
> I am targeting producing the final binaries for CMake 2.8.6 on
> Thursday, 9/29 or Friday 9/30 next week.
> 
> 
> Thanks,
> David
> 
> 
> On Thu, Sep 22, 2011 at 3:51 PM, Todd Gamblin  wrote:
>> David,
>> 
>> I just tried 2.8.6-rc3 on a Linux machine with a system boost version 1.33.1 
>> and a boost-cmake version 1.47.0.  It seems to find both of them fine.
>> 
>> It looks like Michael is using boost-cmake version 1.44, so I tried that 
>> too, but it also works.  I'm not sure what could be wrong here.
>> 
>> I did notice that there is a problem with printing the boost version for 
>> boost-cmake.  My module prints Boost_FIND_VERSION instead of Boost_VERSION, 
>> and the print format is inconsistent with what the module does.  I am not 
>> sure if you want me to fix that for 2.8.6.
>> 
>> -Todd
>> 
>> 
>> 
>> On Sep 22, 2011, at 11:41 AM, David Cole wrote:
>> 
>>> Philip and Todd have been the recent authors/committers in FindBoost.cmake.
>>> 
>>> Any comments on this one, guys?
>>> 
>>> 
>>> Thanks,
>>> David
>>> 
>>> 
>>> On Thu, Sep 22, 2011 at 12:23 PM, Michael Jackson
>>>  wrote:
 Semi Answering my own question if I "set (Boost_NO_BOOST_CMAKE 1)" my 
 project seems to configure ok.
  So I guess that is new.
 ___
 Mike Jackson  www.bluequartz.net
 Principal Software Engineer   mike.jack...@bluequartz.net
 BlueQuartz Software   Dayton, Ohio
 
 On Sep 22, 2011, at 12:14 PM, Michael Jackson wrote:
 
> There seems to be either a regression or my project has been slipping 
> through the cracks with respect to FindBoost. I have the following CMake 
> code in my project:
> 
> 
> # -- Find Boost Headers/Libraries ---
> SET (Boost_FIND_REQUIRED TRUE)
> SET (Boost_DEBUG FALSE)
> set (Boost_USE_MULTITHREADED TRUE)
> set (Boost_USE_STATIC_LIBS TRUE)
> SET (Boost_ADDITIONAL_VERSIONS "1.47.0" "1.46.0" "1.44.0" "1.44" "1.41" 
> "1.41.0" "1.39" "1.39.0")
> set (Boost_FIND_COMPONENTS "")
> FIND_PACKAGE(Boost COMPONENTS  ${Boost_FIND_COMPONENTS} )
> INCLUDE_DIRECTORIES(${Boost_INCLUDE_DIRS})
> LINK_DIRECTORIES(${Boost_LIBRARY_DIRS})
> 
> Under CMake 2.8.5 (all prior) this worked just fine. Now with CMake 2.8.6 
> I get the following error:
> 
> 
> globbed: 
> ../../boost-1.41.0//cmake//BoostConfig.cmake;../../boost-1.44.0//cmake//BoostConfig.cmake
> FOUNDVERSION=1.44.0
> CMake Error at 
> /Users/Shared/Toolkits/MXABoost-1.44/share/boost-1.44.0/cmake/BoostConfig.cmake:87
>  (message):
>  Boost components not found: thread;program_options;date_time
> Call Stack (most recent call first):
>  
> /Users/Shared/Toolkits/MXABoost-1.44/share/cmake/boost/BoostConfig.cmake:15
>  (include)
>  
> /Users/Shared/Toolkits/CMake-2.8.6/CMake-2.8.6.app/Contents/share/cmake-2.8/Modules/FindBoost.cmake:282
>  (find_package)
>  CMakeLists.txt:144 (FIND_PACKAGE)
> 
> 
> -- Configuring incomplete, errors occurred!
> 
> I dug into the FindBoost.cmake file that comes with RC3 and started 
> reading the docs at the top. It states that if I am using Boost Headers 
> only then I can leave out the "COMPONENTS" part. I changed my 
> CMakeLists.txt file to reflect this and I still get the error.
> 
> Operator Error or regression?
> 
> ___
> Mike Jackson  www.bluequartz.net
> Principal Software Engineer   mike.jack...@bluequartz.net
> BlueQuartz Software   Dayton, Ohio
> 
 
 --
 
 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
 
>> 
>> __
>> Todd Gamblin, tgamb...@llnl.gov, http://people.llnl.gov/gamblin2
>> CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA
>> 
>> 

__
Todd Gamblin, tgamb...@llnl.gov, http:

Re: [CMake] CMake 2.8.6 RC3 FindBoost Regression Error

[Todd Gamblin]

That was introduced in this version, and it disables the recursive call to 
find_package with NO_MODULE.

Given the symptoms you are describing, it *sounds* like you might've renamed 
the lib/boost-1.44.0 directory that boost-cmake installs to something more 
compatible with a standard boost install.  Boost-cmake installs libraries by 
default in a lib/boost- directory rather than a lib/boost_ 
directory as bjam does.  This fix was introduced because FindBoost could *not* 
find boost-cmake due to this problem.

If you moved things without changing BoostConfig.cmake, then your boost-cmake 
install is going to be broken, at least as far as finding it using find_package 
goes.  If I'm right, then the fix in 2.8.6 will allow you to install 
boost-cmake versions without making these changes.

-Todd


On Sep 22, 2011, at 1:04 PM, Michael Jackson wrote:

> So was (Boost_NO_BOOST_CMAKE 1) introduced in this version of CMake or Past 
> versions? I will tell you up front that I am only using a subset of Boost 
> that I create with "bcp" from boost itself so there could very well be 
> something slightly "off" with what I have that has been able to get through 
> the previous versions of FindBoost but now with updates to FindBoost it is 
> starting to fail. 
>  Just to be clear, add (Boost_NO_BOOST_CMAKE 1) allowed my project to use my 
> own boost version.
> ___
> Mike Jackson  www.bluequartz.net
> Principal Software Engineer   mike.jack...@bluequartz.net 
> BlueQuartz Software   Dayton, Ohio
> 
> On Sep 22, 2011, at 3:51 PM, Todd Gamblin wrote:
> 
>> David,
>> 
>> I just tried 2.8.6-rc3 on a Linux machine with a system boost version 1.33.1 
>> and a boost-cmake version 1.47.0.  It seems to find both of them fine.
>> 
>> It looks like Michael is using boost-cmake version 1.44, so I tried that 
>> too, but it also works.  I'm not sure what could be wrong here.
>> 
>> I did notice that there is a problem with printing the boost version for 
>> boost-cmake.  My module prints Boost_FIND_VERSION instead of Boost_VERSION, 
>> and the print format is inconsistent with what the module does.  I am not 
>> sure if you want me to fix that for 2.8.6.
>> 
>> -Todd
>> 
>> 
>> 
>> On Sep 22, 2011, at 11:41 AM, David Cole wrote:
>> 
>>> Philip and Todd have been the recent authors/committers in FindBoost.cmake.
>>> 
>>> Any comments on this one, guys?
>>> 
>>> 
>>> Thanks,
>>> David
>>> 
>>> 
>>> On Thu, Sep 22, 2011 at 12:23 PM, Michael Jackson
>>>  wrote:
 Semi Answering my own question if I "set (Boost_NO_BOOST_CMAKE 1)" my 
 project seems to configure ok.
 So I guess that is new.
 ___
 Mike Jackson  www.bluequartz.net
 Principal Software Engineer   mike.jack...@bluequartz.net
 BlueQuartz Software   Dayton, Ohio
 
 On Sep 22, 2011, at 12:14 PM, Michael Jackson wrote:
 
> There seems to be either a regression or my project has been slipping 
> through the cracks with respect to FindBoost. I have the following CMake 
> code in my project:
> 
> 
> # -- Find Boost Headers/Libraries ---
> SET (Boost_FIND_REQUIRED TRUE)
> SET (Boost_DEBUG FALSE)
> set (Boost_USE_MULTITHREADED TRUE)
> set (Boost_USE_STATIC_LIBS TRUE)
> SET (Boost_ADDITIONAL_VERSIONS "1.47.0" "1.46.0" "1.44.0" "1.44" "1.41" 
> "1.41.0" "1.39" "1.39.0")
> set (Boost_FIND_COMPONENTS "")
> FIND_PACKAGE(Boost COMPONENTS  ${Boost_FIND_COMPONENTS} )
> INCLUDE_DIRECTORIES(${Boost_INCLUDE_DIRS})
> LINK_DIRECTORIES(${Boost_LIBRARY_DIRS})
> 
> Under CMake 2.8.5 (all prior) this worked just fine. Now with CMake 2.8.6 
> I get the following error:
> 
> 
> globbed: 
> ../../boost-1.41.0//cmake//BoostConfig.cmake;../../boost-1.44.0//cmake//BoostConfig.cmake
> FOUNDVERSION=1.44.0
> CMake Error at 
> /Users/Shared/Toolkits/MXABoost-1.44/share/boost-1.44.0/cmake/BoostConfig.cmake:87
>  (message):
> Boost components not found: thread;program_options;date_time
> Call Stack (most recent call first):
> /Users/Shared/Toolkits/MXABoost-1.44/share/cmake/boost/BoostConfig.cmake:15
>  (include)
> /Users/Shared/Toolkits/CMake-2.8.6/CMake-2.8.6.app/Contents/share/cmake-2.8/Modules/FindBoost.cmake:282
>  (find_package)
> CMakeLists.txt:144 (FIND_PACKAGE)
> 
> 
> -- Configuring incomplete, errors occurred!
> 
> I dug into the FindBoost.cmake file that comes with RC3 and started 
> reading the docs at the top. It states that if I am using Boost Headers 
> only then I can leave out the "COMPONENTS" part. I changed my 
> CMakeLists.txt file to reflect this and I still get the error.
> 
> Operator Error or regression?
> 
> _

[CMake] Scope of find_package inside a function block

[Lori Pritchett-Sheats]

I was wondering what the scope of the variables set in a FindXXX.cmake 
file is and does find_package_handle_standard_args change that scope.


For example, I create a FindBar.cmake file that sets Bar_INCLUDE_DIR, 
Bar_LIBRARY, Bar_INCLUDE_DIRS and Bar_LIBRARIES, and calls 
find_package_handle_standard_args to set Bar_FOUND correctly if 
Bar_INCLUDE_DIRS and Bar_LIBRARIES is set. If I call find_package(Bar) 
inside a function-endfunction block, are the variables scoped outside 
the function block?


I have a simple test case and I'm seeing strange results where some of 
the Bar_* variables are defined outside the function block. It's very 
strange. I'm wondering if my find_package_handle_standard_args call 
affects the variable scope, because  in my simple test case, Bar_FOUND, 
Bar_INCLUDE_DIRS and Bar_LIBRARIES are not set outside the function 
block, but Bar_INCLUDE_DIR and Bar_LIBRARY are.


Thanks.

--
Lori A. Pritchett-Sheats, PhD.
CCS-2, Computational Physics and Methods
Office: 505-665-6675
Fax: 505-665-4972

Los Alamos National Laboratory
P.O. Box 1663
MS D413
Los Alamos, NM 87544

--

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] dmg CPack Options

[Eric Noulard]

2011/9/22 Michael Jackson :
> I just found that and have been playing with it but if I set it to 1 then I 
> get the following error:
>
> CPack: Create package using DragNDrop
> CPack: Install projects
> CPack: - Run preinstall target for: DREAM3D
> CPack: - Install project: DREAM3D
> CPack: -   Install component: Applications
> CPack: -   Install component: Unspecified
> CPack: Create package
> CPack Error: Error executing: /usr/bin/hdiutil create -ov -srcfolder 
> "/Users/mjackson/Workspace/DREAM3D/Build/_CPack_Packages/Darwin/DragNDrop/ALL_IN_ONE"
>  -volname "DREAM3D-v2.1488.gfb63bc8-OSX" -format UDRW 
> "/Users/mjackson/Workspace/DREAM3D/Build/_CPack_Packages/Darwin/DragNDrop/temp.dmg"
> CPack Error: Error generating temporary disk image.
> CPack Error: Problem compressing the directory
> CPack Error: Error when generating package: DREAM3D
> make: *** [package] Error 1
>
> This is reproducible toggling the value between 1 and 0.

Unfortunately this is a known but yet unresolved issue:
http://public.kitware.com/Bug/view.php?id=12129

If you use COMPONENT packaging.
the  CPACK_INCLUDE_TOPLEVEL_DIRECTORY does not play well with this
because component install already plays (mangle) with the name of
the temporary install directory...



-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
--

Powered by www.kitware.com

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

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

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

Re: [CMake] Post Packaging Script?

[Eric Noulard]

2011/9/22 Michael Jackson :
> Is there some way to run a shell script/command/cmake script AFTER all the 
> packaging is completed?

None that I am aware of.
May be you can craft you own

package_end_cleanup

custom_command which would call
1) make package
2) cmake -E remove_directory _CPack_Packages

>
> When I run "make package" from the command line everything goes just fine. 
> The issue is that the folder _CPack_Packages is left over which contains a 
> Symlink to /Applications for OS X systems. Having this link over loads 
> Eclipse as Eclipse will then try to find all executables in /Applications 
> which does not tend to work out well.
>
>  So basically I just want to delete the _CPack_Packages folder after the 
> package has been generated.

This could be a useful cpack options VAR though
something like

CPACK_CLEANUP_PACKAGING_DIRECTORIES
or
CPACK__CLEANUP_PACKAGING_DIRECTORIES
in order to control this on per-generator basis.

may be worth a feature request.

-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
--

Powered by www.kitware.com

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

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

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

Re: [CMake] Setting IMPORTED_LOCATION_* for existing packages

[Michael Hertling]

On 09/22/2011 09:21 PM, Hauke Heibel wrote:
> Hi Michael,
> 
> First, thank you for the feedback.
> 
> On Thu, Sep 22, 2011 at 7:19 PM, Michael Hertling  wrote:
>> AFAICS, you've a single imported target GTest, and you are continuously
>> setting *this* target's location - sometimes for a debug configuration,
>> sometimes without configuration - to the location of its *prerequisite*
>> libraries reported by the GTest package's find module or config file.
> 
> If I am not totally wrong, in this case I am only setting the GTest
> libraries and no additional *prerequisite*. The variable
> GTEST_LIBRARIES only contains full qualified paths to gtest.lib and
> gtestd.lib.
> 
>> IMO, this doesn't make any sense. Possibly, you want to set the GTest
>> target's IMPORTED_LINK_INTERFACE_LIBRARIES[_] properties in
>> place of the IMPORTED_LOCATION[_] ones.
> 
> Maybe I am wrong, but I just tried to copy what is done in the
> FindQt4.cmake file or in other words to manually define what the
> export() directive generates. I recognized an issue since I forgot to
> define the property IMPORTED_CONFIGURATIONS. If I did not
> misunderstand things completely, you were right if GTEST_LIBRARIES
> would contain non GTest libs (the prerequisites).
> 
>> What do you actually intent to achieve? Introduce a GTest imported
>> target and set up its prerequisites reported in GTEST_LIBRARIES as
>> it would be done for imported targets from the first?
> 
> I think that's pretty much what I want to do. Create the import target
> as if GTest were compiled with an export() directive.
> 
>> Doesn't the
>> GTEST_LIBRARIES variable per se work for you?
> 
> To be honest, in this case it does. Maybe the example was bad. I think
> I really need it for shared library targets, such as e.g. OpenCL.
> 
> I want to prepare my libraries such that in the future a CMake based
> installation also collects and installs DLLs of interface libraries. I
> am further assuming that if I define a target of mine and link it
> against an imported (let's say) OpenCL target with properly specified
> IMPORTED_LOCATION (the DLL for shared libs), install() will copy it
> for me.

No, it won't:

CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(IMPORTTARGET C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c "int main(void){return 0;}\n")
ADD_EXECUTABLE(main main.c)
FIND_LIBRARY(M_LIBRARY m PATHS /usr/lib NO_DEFAULT_PATH)
ADD_LIBRARY(m SHARED IMPORTED)
SET_TARGET_PROPERTIES(m PROPERTIES IMPORTED_LOCATION ${M_LIBRARY})
TARGET_LINK_LIBRARIES(main m)
INSTALL(TARGETS main RUNTIME DESTINATION bin)

As you'll see after "cmake -DCMAKE_INSTALL_PREFIX=/dev/shm/usr ...",
e.g., a "make install" will install the main executable but not the
prerequisite libm.so library. Imported targets are meant to inform
the project about targets already built - and possibly installed -
by other projects; they don't suit to resolve a project's external
dependencies during the installation. If you need this, you
should definitely have a look at the BundleUtilities.

> Maybe that's long shot - I need to read more about the actual
> installation process and how it deals with dependencies.
> 
> Regards,
> Hauke

Regards,

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

Re: [CMake] CMake 2.8.6 RC3 FindBoost Regression Error

[David Cole]

Todd,

Unless somebody other than Mike speaks up that there's a regression,
we won't take any more changes for the final CMake 2.8.6.

>From right now on (I just sent the -rc4 email out...) we will only
accept fixes for MAJOR regressions that people notice between now and
next week.

I am targeting producing the final binaries for CMake 2.8.6 on
Thursday, 9/29 or Friday 9/30 next week.


Thanks,
David


On Thu, Sep 22, 2011 at 3:51 PM, Todd Gamblin  wrote:
> David,
>
> I just tried 2.8.6-rc3 on a Linux machine with a system boost version 1.33.1 
> and a boost-cmake version 1.47.0.  It seems to find both of them fine.
>
> It looks like Michael is using boost-cmake version 1.44, so I tried that too, 
> but it also works.  I'm not sure what could be wrong here.
>
> I did notice that there is a problem with printing the boost version for 
> boost-cmake.  My module prints Boost_FIND_VERSION instead of Boost_VERSION, 
> and the print format is inconsistent with what the module does.  I am not 
> sure if you want me to fix that for 2.8.6.
>
> -Todd
>
>
>
> On Sep 22, 2011, at 11:41 AM, David Cole wrote:
>
>> Philip and Todd have been the recent authors/committers in FindBoost.cmake.
>>
>> Any comments on this one, guys?
>>
>>
>> Thanks,
>> David
>>
>>
>> On Thu, Sep 22, 2011 at 12:23 PM, Michael Jackson
>>  wrote:
>>> Semi Answering my own question if I "set (Boost_NO_BOOST_CMAKE 1)" my 
>>> project seems to configure ok.
>>>  So I guess that is new.
>>> ___
>>> Mike Jackson                      www.bluequartz.net
>>> Principal Software Engineer       mike.jack...@bluequartz.net
>>> BlueQuartz Software               Dayton, Ohio
>>>
>>> On Sep 22, 2011, at 12:14 PM, Michael Jackson wrote:
>>>
 There seems to be either a regression or my project has been slipping 
 through the cracks with respect to FindBoost. I have the following CMake 
 code in my project:


 # -- Find Boost Headers/Libraries ---
 SET (Boost_FIND_REQUIRED TRUE)
 SET (Boost_DEBUG FALSE)
 set (Boost_USE_MULTITHREADED TRUE)
 set (Boost_USE_STATIC_LIBS TRUE)
 SET (Boost_ADDITIONAL_VERSIONS "1.47.0" "1.46.0" "1.44.0" "1.44" "1.41" 
 "1.41.0" "1.39" "1.39.0")
 set (Boost_FIND_COMPONENTS "")
 FIND_PACKAGE(Boost COMPONENTS  ${Boost_FIND_COMPONENTS} )
 INCLUDE_DIRECTORIES(${Boost_INCLUDE_DIRS})
 LINK_DIRECTORIES(${Boost_LIBRARY_DIRS})

 Under CMake 2.8.5 (all prior) this worked just fine. Now with CMake 2.8.6 
 I get the following error:


 globbed: 
 ../../boost-1.41.0//cmake//BoostConfig.cmake;../../boost-1.44.0//cmake//BoostConfig.cmake
 FOUNDVERSION=1.44.0
 CMake Error at 
 /Users/Shared/Toolkits/MXABoost-1.44/share/boost-1.44.0/cmake/BoostConfig.cmake:87
  (message):
  Boost components not found: thread;program_options;date_time
 Call Stack (most recent call first):
  /Users/Shared/Toolkits/MXABoost-1.44/share/cmake/boost/BoostConfig.cmake:15
  (include)
  /Users/Shared/Toolkits/CMake-2.8.6/CMake-2.8.6.app/Contents/share/cmake-2.8/Modules/FindBoost.cmake:282
  (find_package)
  CMakeLists.txt:144 (FIND_PACKAGE)


 -- Configuring incomplete, errors occurred!

 I dug into the FindBoost.cmake file that comes with RC3 and started 
 reading the docs at the top. It states that if I am using Boost Headers 
 only then I can leave out the "COMPONENTS" part. I changed my 
 CMakeLists.txt file to reflect this and I still get the error.

 Operator Error or regression?

 ___
 Mike Jackson                      www.bluequartz.net
 Principal Software Engineer       mike.jack...@bluequartz.net
 BlueQuartz Software               Dayton, Ohio

>>>
>>> --
>>>
>>> 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
>>>
>
> __
> Todd Gamblin, tgamb...@llnl.gov, http://people.llnl.gov/gamblin2
> CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA
>
>
--

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] CMake 2.8.6-rc4 ready for testing!

[David Cole]

The CMake 2.8.6 release candidate stream continues! You can find the
source and binaries here:

  http://www.cmake.org/files/v2.8/?C=M;O=D

This email is also available on the Kitware blog at

  http://www.kitware.com/blog/home/post/170

This is the last rc before the final release, unless somebody finds a
showstopper issue between now and next Thursday.

This release candidate we do not have pre-built binaries for the
SunOS anymore. As mentioned on the CMake mailing list recently, our
Sun hardware has bitten the proverbial dust.

However, we are now providing two sets of installers for the Mac.
The "Darwin" versions are for Mac OSX 10.4 and later, and are "ppc;i386"
universal binaries. The "Darwin64" versions are for 10.6 and later,
and are "x86_64;i386" universal binaries.

Following is the list of changes in this release. Since we switched to
git, this list is now the 'git log' one line summary written by the
named CMake developers.

Please try this version of CMake on your projects and report any
issues to the list or the bug tracker.

Happy building!
-Dave


Changes in CMake 2.8.6-rc4 (since 2.8.6-rc3)

Alex Neundorf (3):
  FindFLEX.cmake: also search the include dir
  Fix typos in FeatureSummary.cmake (#12462)
  Don't warn when setting a property multiple times to the same value #12464

Bill Hoffman (2):
  For VS Intel Fortran IDE builds, add a check to find the Fortran
library PATH.
  Enable Fortran tests for IDE builds.

Brad King (5):
  FortranCInterface: Compile separate Fortran lib in VerifyC[XX]
  Move IntelVSImplicitPath project to better location
  Simplify IntelVSImplicitPath detection project
  libarchive: Fix ssize_t detection with mingwrt 3.20
  Make file(DOWNLOAD) fail on http error

David Cole (8):
  Tests: Add a KWStyle test, equivalent to the make StyleCheck target
  KWStyle Test: Activate by default if KWStyle is found
  Xcode: Use EFFECTIVE_PLATFORM_NAME reference in ComputeOutputDir
  Xcode: Add test to demonstrate iOS project in Xcode
  CMake: Reference test targets only when BUILD_TESTING is ON
  Tests: Add the more modern Mac64 nightly build
  Release Scripts: Use Qt 4.7.4 on dashmacmini5 (#12460)
  Revert "FindThreads: Try pthreads with no special option first (#11333)"

Eric NOULARD (4):
  CPack fix #12449 doc mispelled
  CPack fix template too
  CPackDeb fix #10325 automagically use fakeroot for DEB if
fakeroot is found
  CPackRPM authorize per-component pre/post-[un]install scripts (#0012063)

Marcus D. Hanwell (4):
  Just code style changes.
  Don't warn when nothing to do in visibility function.
  Made ADD_COMPILER_EXPORT_FLAGS into a macro.
  Make add_compiler_export_flags a function again.

Rolf Eike Beer (1):
  remove stray brace in CPackDeb documentation
--

Powered by www.kitware.com

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

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

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

Re: [CMake] CMake 2.8.6 RC3 FindBoost Regression Error

[Michael Jackson]

So was (Boost_NO_BOOST_CMAKE 1) introduced in this version of CMake or Past 
versions? I will tell you up front that I am only using a subset of Boost that 
I create with "bcp" from boost itself so there could very well be something 
slightly "off" with what I have that has been able to get through the previous 
versions of FindBoost but now with updates to FindBoost it is starting to fail. 
  Just to be clear, add (Boost_NO_BOOST_CMAKE 1) allowed my project to use my 
own boost version.
___
Mike Jackson  www.bluequartz.net
Principal Software Engineer   mike.jack...@bluequartz.net 
BlueQuartz Software   Dayton, Ohio

On Sep 22, 2011, at 3:51 PM, Todd Gamblin wrote:

> David,
> 
> I just tried 2.8.6-rc3 on a Linux machine with a system boost version 1.33.1 
> and a boost-cmake version 1.47.0.  It seems to find both of them fine.
> 
> It looks like Michael is using boost-cmake version 1.44, so I tried that too, 
> but it also works.  I'm not sure what could be wrong here.
> 
> I did notice that there is a problem with printing the boost version for 
> boost-cmake.  My module prints Boost_FIND_VERSION instead of Boost_VERSION, 
> and the print format is inconsistent with what the module does.  I am not 
> sure if you want me to fix that for 2.8.6.
> 
> -Todd
> 
> 
> 
> On Sep 22, 2011, at 11:41 AM, David Cole wrote:
> 
>> Philip and Todd have been the recent authors/committers in FindBoost.cmake.
>> 
>> Any comments on this one, guys?
>> 
>> 
>> Thanks,
>> David
>> 
>> 
>> On Thu, Sep 22, 2011 at 12:23 PM, Michael Jackson
>>  wrote:
>>> Semi Answering my own question if I "set (Boost_NO_BOOST_CMAKE 1)" my 
>>> project seems to configure ok.
>>> So I guess that is new.
>>> ___
>>> Mike Jackson  www.bluequartz.net
>>> Principal Software Engineer   mike.jack...@bluequartz.net
>>> BlueQuartz Software   Dayton, Ohio
>>> 
>>> On Sep 22, 2011, at 12:14 PM, Michael Jackson wrote:
>>> 
 There seems to be either a regression or my project has been slipping 
 through the cracks with respect to FindBoost. I have the following CMake 
 code in my project:
 
 
 # -- Find Boost Headers/Libraries ---
 SET (Boost_FIND_REQUIRED TRUE)
 SET (Boost_DEBUG FALSE)
 set (Boost_USE_MULTITHREADED TRUE)
 set (Boost_USE_STATIC_LIBS TRUE)
 SET (Boost_ADDITIONAL_VERSIONS "1.47.0" "1.46.0" "1.44.0" "1.44" "1.41" 
 "1.41.0" "1.39" "1.39.0")
 set (Boost_FIND_COMPONENTS "")
 FIND_PACKAGE(Boost COMPONENTS  ${Boost_FIND_COMPONENTS} )
 INCLUDE_DIRECTORIES(${Boost_INCLUDE_DIRS})
 LINK_DIRECTORIES(${Boost_LIBRARY_DIRS})
 
 Under CMake 2.8.5 (all prior) this worked just fine. Now with CMake 2.8.6 
 I get the following error:
 
 
 globbed: 
 ../../boost-1.41.0//cmake//BoostConfig.cmake;../../boost-1.44.0//cmake//BoostConfig.cmake
 FOUNDVERSION=1.44.0
 CMake Error at 
 /Users/Shared/Toolkits/MXABoost-1.44/share/boost-1.44.0/cmake/BoostConfig.cmake:87
  (message):
 Boost components not found: thread;program_options;date_time
 Call Stack (most recent call first):
 /Users/Shared/Toolkits/MXABoost-1.44/share/cmake/boost/BoostConfig.cmake:15
  (include)
 /Users/Shared/Toolkits/CMake-2.8.6/CMake-2.8.6.app/Contents/share/cmake-2.8/Modules/FindBoost.cmake:282
  (find_package)
 CMakeLists.txt:144 (FIND_PACKAGE)
 
 
 -- Configuring incomplete, errors occurred!
 
 I dug into the FindBoost.cmake file that comes with RC3 and started 
 reading the docs at the top. It states that if I am using Boost Headers 
 only then I can leave out the "COMPONENTS" part. I changed my 
 CMakeLists.txt file to reflect this and I still get the error.
 
 Operator Error or regression?
 
 ___
 Mike Jackson  www.bluequartz.net
 Principal Software Engineer   mike.jack...@bluequartz.net
 BlueQuartz Software   Dayton, Ohio
 
>>> 
>>> --
>>> 
>>> 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
>>> 
> 
> __
> Todd Gamblin, tgamb...@llnl.gov, http://people.llnl.gov/gamblin2
> CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA
> 

--

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.cmak

Re: [CMake] CMake 2.8.6 RC3 FindBoost Regression Error

[Todd Gamblin]

David,

I just tried 2.8.6-rc3 on a Linux machine with a system boost version 1.33.1 
and a boost-cmake version 1.47.0.  It seems to find both of them fine.

It looks like Michael is using boost-cmake version 1.44, so I tried that too, 
but it also works.  I'm not sure what could be wrong here.

I did notice that there is a problem with printing the boost version for 
boost-cmake.  My module prints Boost_FIND_VERSION instead of Boost_VERSION, and 
the print format is inconsistent with what the module does.  I am not sure if 
you want me to fix that for 2.8.6.

-Todd



On Sep 22, 2011, at 11:41 AM, David Cole wrote:

> Philip and Todd have been the recent authors/committers in FindBoost.cmake.
> 
> Any comments on this one, guys?
> 
> 
> Thanks,
> David
> 
> 
> On Thu, Sep 22, 2011 at 12:23 PM, Michael Jackson
>  wrote:
>> Semi Answering my own question if I "set (Boost_NO_BOOST_CMAKE 1)" my 
>> project seems to configure ok.
>>  So I guess that is new.
>> ___
>> Mike Jackson  www.bluequartz.net
>> Principal Software Engineer   mike.jack...@bluequartz.net
>> BlueQuartz Software   Dayton, Ohio
>> 
>> On Sep 22, 2011, at 12:14 PM, Michael Jackson wrote:
>> 
>>> There seems to be either a regression or my project has been slipping 
>>> through the cracks with respect to FindBoost. I have the following CMake 
>>> code in my project:
>>> 
>>> 
>>> # -- Find Boost Headers/Libraries ---
>>> SET (Boost_FIND_REQUIRED TRUE)
>>> SET (Boost_DEBUG FALSE)
>>> set (Boost_USE_MULTITHREADED TRUE)
>>> set (Boost_USE_STATIC_LIBS TRUE)
>>> SET (Boost_ADDITIONAL_VERSIONS "1.47.0" "1.46.0" "1.44.0" "1.44" "1.41" 
>>> "1.41.0" "1.39" "1.39.0")
>>> set (Boost_FIND_COMPONENTS "")
>>> FIND_PACKAGE(Boost COMPONENTS  ${Boost_FIND_COMPONENTS} )
>>> INCLUDE_DIRECTORIES(${Boost_INCLUDE_DIRS})
>>> LINK_DIRECTORIES(${Boost_LIBRARY_DIRS})
>>> 
>>> Under CMake 2.8.5 (all prior) this worked just fine. Now with CMake 2.8.6 I 
>>> get the following error:
>>> 
>>> 
>>> globbed: 
>>> ../../boost-1.41.0//cmake//BoostConfig.cmake;../../boost-1.44.0//cmake//BoostConfig.cmake
>>> FOUNDVERSION=1.44.0
>>> CMake Error at 
>>> /Users/Shared/Toolkits/MXABoost-1.44/share/boost-1.44.0/cmake/BoostConfig.cmake:87
>>>  (message):
>>>  Boost components not found: thread;program_options;date_time
>>> Call Stack (most recent call first):
>>>  
>>> /Users/Shared/Toolkits/MXABoost-1.44/share/cmake/boost/BoostConfig.cmake:15 
>>> (include)
>>>  
>>> /Users/Shared/Toolkits/CMake-2.8.6/CMake-2.8.6.app/Contents/share/cmake-2.8/Modules/FindBoost.cmake:282
>>>  (find_package)
>>>  CMakeLists.txt:144 (FIND_PACKAGE)
>>> 
>>> 
>>> -- Configuring incomplete, errors occurred!
>>> 
>>> I dug into the FindBoost.cmake file that comes with RC3 and started reading 
>>> the docs at the top. It states that if I am using Boost Headers only then I 
>>> can leave out the "COMPONENTS" part. I changed my CMakeLists.txt file to 
>>> reflect this and I still get the error.
>>> 
>>> Operator Error or regression?
>>> 
>>> ___
>>> Mike Jackson  www.bluequartz.net
>>> Principal Software Engineer   mike.jack...@bluequartz.net
>>> BlueQuartz Software   Dayton, Ohio
>>> 
>> 
>> --
>> 
>> 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
>> 

__
Todd Gamblin, tgamb...@llnl.gov, http://people.llnl.gov/gamblin2
CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA

--

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] Setting IMPORTED_LOCATION_* for existing packages

[Hauke Heibel]

Hi Michael,

First, thank you for the feedback.

On Thu, Sep 22, 2011 at 7:19 PM, Michael Hertling  wrote:
> AFAICS, you've a single imported target GTest, and you are continuously
> setting *this* target's location - sometimes for a debug configuration,
> sometimes without configuration - to the location of its *prerequisite*
> libraries reported by the GTest package's find module or config file.

If I am not totally wrong, in this case I am only setting the GTest
libraries and no additional *prerequisite*. The variable
GTEST_LIBRARIES only contains full qualified paths to gtest.lib and
gtestd.lib.

> IMO, this doesn't make any sense. Possibly, you want to set the GTest
> target's IMPORTED_LINK_INTERFACE_LIBRARIES[_] properties in
> place of the IMPORTED_LOCATION[_] ones.

Maybe I am wrong, but I just tried to copy what is done in the
FindQt4.cmake file or in other words to manually define what the
export() directive generates. I recognized an issue since I forgot to
define the property IMPORTED_CONFIGURATIONS. If I did not
misunderstand things completely, you were right if GTEST_LIBRARIES
would contain non GTest libs (the prerequisites).

> What do you actually intent to achieve? Introduce a GTest imported
> target and set up its prerequisites reported in GTEST_LIBRARIES as
> it would be done for imported targets from the first?

I think that's pretty much what I want to do. Create the import target
as if GTest were compiled with an export() directive.

> Doesn't the
> GTEST_LIBRARIES variable per se work for you?

To be honest, in this case it does. Maybe the example was bad. I think
I really need it for shared library targets, such as e.g. OpenCL.

I want to prepare my libraries such that in the future a CMake based
installation also collects and installs DLLs of interface libraries. I
am further assuming that if I define a target of mine and link it
against an imported (let's say) OpenCL target with properly specified
IMPORTED_LOCATION (the DLL for shared libs), install() will copy it
for me.

Maybe that's long shot - I need to read more about the actual
installation process and how it deals with dependencies.

Regards,
Hauke
--

Powered by www.kitware.com

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

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

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

Re: [CMake] CMake 2.8.6 RC3 FindBoost Regression Error

[David Cole]

Philip and Todd have been the recent authors/committers in FindBoost.cmake.

Any comments on this one, guys?


Thanks,
David


On Thu, Sep 22, 2011 at 12:23 PM, Michael Jackson
 wrote:
> Semi Answering my own question if I "set (Boost_NO_BOOST_CMAKE 1)" my project 
> seems to configure ok.
>  So I guess that is new.
> ___
> Mike Jackson                      www.bluequartz.net
> Principal Software Engineer       mike.jack...@bluequartz.net
> BlueQuartz Software               Dayton, Ohio
>
> On Sep 22, 2011, at 12:14 PM, Michael Jackson wrote:
>
>> There seems to be either a regression or my project has been slipping 
>> through the cracks with respect to FindBoost. I have the following CMake 
>> code in my project:
>>
>>
>> # -- Find Boost Headers/Libraries ---
>> SET (Boost_FIND_REQUIRED TRUE)
>> SET (Boost_DEBUG FALSE)
>> set (Boost_USE_MULTITHREADED TRUE)
>> set (Boost_USE_STATIC_LIBS TRUE)
>> SET (Boost_ADDITIONAL_VERSIONS "1.47.0" "1.46.0" "1.44.0" "1.44" "1.41" 
>> "1.41.0" "1.39" "1.39.0")
>> set (Boost_FIND_COMPONENTS "")
>> FIND_PACKAGE(Boost COMPONENTS  ${Boost_FIND_COMPONENTS} )
>> INCLUDE_DIRECTORIES(${Boost_INCLUDE_DIRS})
>> LINK_DIRECTORIES(${Boost_LIBRARY_DIRS})
>>
>> Under CMake 2.8.5 (all prior) this worked just fine. Now with CMake 2.8.6 I 
>> get the following error:
>>
>>
>> globbed: 
>> ../../boost-1.41.0//cmake//BoostConfig.cmake;../../boost-1.44.0//cmake//BoostConfig.cmake
>> FOUNDVERSION=1.44.0
>> CMake Error at 
>> /Users/Shared/Toolkits/MXABoost-1.44/share/boost-1.44.0/cmake/BoostConfig.cmake:87
>>  (message):
>>  Boost components not found: thread;program_options;date_time
>> Call Stack (most recent call first):
>>  /Users/Shared/Toolkits/MXABoost-1.44/share/cmake/boost/BoostConfig.cmake:15 
>> (include)
>>  /Users/Shared/Toolkits/CMake-2.8.6/CMake-2.8.6.app/Contents/share/cmake-2.8/Modules/FindBoost.cmake:282
>>  (find_package)
>>  CMakeLists.txt:144 (FIND_PACKAGE)
>>
>>
>> -- Configuring incomplete, errors occurred!
>>
>> I dug into the FindBoost.cmake file that comes with RC3 and started reading 
>> the docs at the top. It states that if I am using Boost Headers only then I 
>> can leave out the "COMPONENTS" part. I changed my CMakeLists.txt file to 
>> reflect this and I still get the error.
>>
>> Operator Error or regression?
>>
>> ___
>> Mike Jackson                      www.bluequartz.net
>> Principal Software Engineer       mike.jack...@bluequartz.net
>> BlueQuartz Software               Dayton, Ohio
>>
>
> --
>
> 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] return value of find_library

[David Cole]

It should always be a full path for a valid found library. Under what
circumstances are you getting exactly "mylib" ... ?


On Thu, Sep 22, 2011 at 11:26 AM, Yifei Li  wrote:
> Hi all,
>
> Say I have find_library(MYLIB mylib  PATHS …) ,   I don't understand why 
> MYLIB sometimes is a full path to mylib and sometimes only contains 'mylib'.
>
> Thanks
>
> Yifei
>
> --
>
> 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] Visual Studio 2008 configure and build step independency

[Bill Hoffman]

On 9/22/2011 1:07 PM, Thomas Wolf wrote:

Addition:

if i try to fake the contents of the CTK use file, like

set_found true
usefile_included 1

find_package still tries to include the CTKConfig.cmake. I always thougt
if the Find-variable is set to true find_package just assumes that
everything went fine and continues (silent mode). Or is this only the
module mode of find_package?

This is a limitation of external_project.  For external_project to work 
all of the toplevel projects must also be external_projects.  There is 
not an easy cross platform way to have external_project targets be used 
by non-external targets.  This is not supported:


add_external_project(foo ..) # creates a library foo
find_package(foo) # find the library created by the external project foo
add_executable(bar ..)
target_link_libraries(bar foo)

It has to be like this:

add_external_project(foo ...)
add_external_project(bar ...)  # inside here it does a find_package(foo)

external project defers configuration and of course build until build 
time.  find_package, find_library expect to find an "already built" 
package.


http://www.kitware.com/products/html/BuildingExternalProjectsWithCMake2.8.html

-Bill


--

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] Setting IMPORTED_LOCATION_* for existing packages

[Michael Hertling]

On 09/21/2011 09:07 AM, Hauke Heibel wrote:
> Hi,
> 
> I started to work with imported targets and thus with setting the
> property IMPORTED_LOCATION and the like. I stumbled over a case
> (GTest) where the standard find_package call returns me a list of libs
> for 'debug' and 'optimized' modes and I am setting them like this
> 
> find_package(GTest REQUIRED)
> add_library(GTest UNKNOWN IMPORTED)
> foreach(arg ${GTEST_LIBRARIES})
>   if("${arg}" MATCHES "^(debug|optimized)$")
> set(_doing "${arg}")
>   elseif("${_doing}" MATCHES "^debug$")
> message("setting debug lib to: ${arg}")
> set_target_properties(GTest PROPERTIES IMPORTED_LOCATION_DEBUG "${arg}")
>   else()
> message("setting optimized lib to: ${arg}")
> set_target_properties(GTest PROPERTIES IMPORTED_LOCATION "${arg}")
>   endif()
> endforeach()

AFAICS, you've a single imported target GTest, and you are continuously
setting *this* target's location - sometimes for a debug configuration,
sometimes without configuration - to the location of its *prerequisite*
libraries reported by the GTest package's find module or config file.
IMO, this doesn't make any sense. Possibly, you want to set the GTest
target's IMPORTED_LINK_INTERFACE_LIBRARIES[_] properties in
place of the IMPORTED_LOCATION[_] ones. Moreover, note that
TARGET_LINK_LIBRARIES()'s debug/optimized/general switches apply to
the immediately following library only, so you probably need to re-
set the "_doing" variable in the ELSEIF() and ELSE() branches in
order to obtain the expected result.

> I am just wondering whether there is a more simple method to do this.
> It looks a bit cumbersome.

What do you actually intent to achieve? Introduce a GTest imported
target and set up its prerequisites reported in GTEST_LIBRARIES as
it would be done for imported targets from the first? Doesn't the
GTEST_LIBRARIES variable per se work for you?

> Regards,
> Hauke

Regards,

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

Re: [CMake] Visual Studio 2008 configure and build step independency

[Thomas Wolf]

Addition:

if i try to fake the contents of the CTK use file, like

set_found true
usefile_included 1

find_package still tries to include the CTKConfig.cmake. I always thougt
if the Find-variable is set to true find_package just assumes that
everything went fine and continues (silent mode). Or is this only the
module mode of find_package?

regards,
Thomas
--

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] ExternalProject_Add and Dependent Targets

[David Cole]

On Thu, Sep 22, 2011 at 10:13 AM, Lori Pritchett-Sheats
 wrote:
>
>
> David Cole wrote:
>>
>> On Wed, Sep 21, 2011 at 11:45 AM, Lori Pritchett-Sheats
>>  wrote:
>>
>>>
>>> Reading the documentation it is not clear how the DEPENDS option works in
>>> ExternalProject_Add.
>>>
>>> For example, I add HDF5 to my build and HDF5 depends on zlib the
>>> following
>>> doesn't work
>>>
>>> find_package(ZLIB)
>>> add_library(zlib UNKNOWN IMPORTED)
>>> set_target_properties(zlib PROPERTIES IMPORTED_LOCATION ${ZLIB_LIBRARY})
>>>
>>> ExternalProject_Add(hdf5 DEPENDS zlib ..)
>>>
>>> throws an error with the message 'No rule to make /zlib-done', needed by
>>> external_projects/src/hdf5-stamp/hdf5-configure
>>>
>>> For ExternalProject_Add, are the targets listed under the DEPENDS option
>>> only targets that will be built with another ExternalProject_Add, not
>>> existing libraries?
>>>
>>>
>>
>> That's correct.
>>
>> The first argument to ExternalProject_Add does become the name of a
>> custom target, though. So after the ExternalProject_Add call, you can
>> do:
>>
>> ExternalProject_Add(hdf5 ...)
>>
>> add_dependencies(hdf5 zlib)
>>
>> However, in this particular case, you are finding an existing zlib and
>> then using an imported target to say where it is *for other
>> non-external project targets in the same CMake build*... For the
>> ExternalProject build of hdf5, you're going to have to pass down in
>> the location of zlib via some arguments, because the ExternalProject
>> build knows nothing about the context of what else is built in the
>> current CMake build...
>>
>> So in this particular case, the hdf5 custom target does not actually
>> depend (in a build order sense) on the zlib target -- because the zlib
>> target doesn't build anything, it's just imported. So you don't
>> actually need the dependency... you just need to tell hdf5 where zlib
>> is.
>>
>> Does that make sense?
>>
>>
>> HTH,
>> David
>>
>>
>
> I think so. The HDF5 configuration has switch options to pass in the zlib
> include and library path, both are available once I call find_package(ZLIB).
> But if I'm building a library that depends on HDF5 I need to include the
> zlib target in the dependency definitions, correct?
>
> If I'm understanding this correctly, after the ExternalProject_Add call, I
> need to define HDF5_INCLUDE_PATH, HDF5_LIBRARIES, since the project will not
> exist when CMake runs. Then when I create a library or executable that needs
> the HDF5 libraries for linking, I would do the following:
>
> add_library(mylib ${some_source})
> target_link_libraries(mylib ${HDF5_LIBRARIES} zlib)
>
>

That looks right to me. Let us know if you run into problems with it.

Thanks,
David
--

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] Visual Studio 2008 configure and build step independency

[Thomas Wolf]

Hello all,

i think i stumbled upon something that keeps me occupied for quite some
time now:

I have a quite large CMake based project, wich is intended to generate a
Visual Studo 2008 solution. The problem is, that I use mixed internal
and external projects, which depend on each other, like VTK, ITK, CTK
and a main project which uses them. This is partly intended, because
including the projects (with add_subdirectory) guarantees that the
source files and headers show up in the final Visual Studio solution.

CTK for example is an external project, and the main project always
fails to get the configuration of the CTK project (usefile, configfile).

This is why:

During generation, the main project does a find_packag(CTK). As there is
no find module for this, the method then works in config mode.

Now things get a little awkward:

The main project does the request with findpackage during its config and
generation time, whereas the external projects like CTK, Log4Qt etc.
generate such things only when the projects's solution file is loaded
into Visual Stuido and is beeing built!

But of course, generation failed due to the missing external projects
configs...

Does anyone have some ideas or a solution to this problem?

The problem s apparently that build time in visual Studio is separated
from the configuration. Is there a way how to force a exterbal project
into the configuration step *without* buildng afterwards, like a custom
CONFIGURE_COMMAND that triggers cmake itself? The subprojects are pure
CMakeprojects, after all...

Help is highly appreciated!

Regards,
Thomas
--

Powered by www.kitware.com

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

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

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

Re: [CMake] CMake 2.8.6 RC3 FindBoost Regression Error

[Michael Jackson]

Semi Answering my own question if I "set (Boost_NO_BOOST_CMAKE 1)" my project 
seems to configure ok.
 So I guess that is new.
___
Mike Jackson  www.bluequartz.net
Principal Software Engineer   mike.jack...@bluequartz.net 
BlueQuartz Software   Dayton, Ohio

On Sep 22, 2011, at 12:14 PM, Michael Jackson wrote:

> There seems to be either a regression or my project has been slipping through 
> the cracks with respect to FindBoost. I have the following CMake code in my 
> project:
> 
> 
> # -- Find Boost Headers/Libraries ---
> SET (Boost_FIND_REQUIRED TRUE)
> SET (Boost_DEBUG FALSE)
> set (Boost_USE_MULTITHREADED TRUE)
> set (Boost_USE_STATIC_LIBS TRUE)
> SET (Boost_ADDITIONAL_VERSIONS "1.47.0" "1.46.0" "1.44.0" "1.44" "1.41" 
> "1.41.0" "1.39" "1.39.0")
> set (Boost_FIND_COMPONENTS "")
> FIND_PACKAGE(Boost COMPONENTS  ${Boost_FIND_COMPONENTS} )
> INCLUDE_DIRECTORIES(${Boost_INCLUDE_DIRS})
> LINK_DIRECTORIES(${Boost_LIBRARY_DIRS})
> 
> Under CMake 2.8.5 (all prior) this worked just fine. Now with CMake 2.8.6 I 
> get the following error:
> 
> 
> globbed: 
> ../../boost-1.41.0//cmake//BoostConfig.cmake;../../boost-1.44.0//cmake//BoostConfig.cmake
> FOUNDVERSION=1.44.0
> CMake Error at 
> /Users/Shared/Toolkits/MXABoost-1.44/share/boost-1.44.0/cmake/BoostConfig.cmake:87
>  (message):
>  Boost components not found: thread;program_options;date_time
> Call Stack (most recent call first):
>  /Users/Shared/Toolkits/MXABoost-1.44/share/cmake/boost/BoostConfig.cmake:15 
> (include)
>  
> /Users/Shared/Toolkits/CMake-2.8.6/CMake-2.8.6.app/Contents/share/cmake-2.8/Modules/FindBoost.cmake:282
>  (find_package)
>  CMakeLists.txt:144 (FIND_PACKAGE)
> 
> 
> -- Configuring incomplete, errors occurred!
> 
> I dug into the FindBoost.cmake file that comes with RC3 and started reading 
> the docs at the top. It states that if I am using Boost Headers only then I 
> can leave out the "COMPONENTS" part. I changed my CMakeLists.txt file to 
> reflect this and I still get the error.
> 
> Operator Error or regression?
> 
> ___
> Mike Jackson  www.bluequartz.net
> Principal Software Engineer   mike.jack...@bluequartz.net 
> BlueQuartz Software   Dayton, Ohio
> 

--

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] CMake 2.8.6 RC3 FindBoost Regression Error

[Michael Jackson]

There seems to be either a regression or my project has been slipping through 
the cracks with respect to FindBoost. I have the following CMake code in my 
project:


# -- Find Boost Headers/Libraries ---
SET (Boost_FIND_REQUIRED TRUE)
SET (Boost_DEBUG FALSE)
set (Boost_USE_MULTITHREADED TRUE)
set (Boost_USE_STATIC_LIBS TRUE)
SET (Boost_ADDITIONAL_VERSIONS "1.47.0" "1.46.0" "1.44.0" "1.44" "1.41" 
"1.41.0" "1.39" "1.39.0")
set (Boost_FIND_COMPONENTS "")
FIND_PACKAGE(Boost COMPONENTS  ${Boost_FIND_COMPONENTS} )
INCLUDE_DIRECTORIES(${Boost_INCLUDE_DIRS})
LINK_DIRECTORIES(${Boost_LIBRARY_DIRS})

Under CMake 2.8.5 (all prior) this worked just fine. Now with CMake 2.8.6 I get 
the following error:


globbed: 
../../boost-1.41.0//cmake//BoostConfig.cmake;../../boost-1.44.0//cmake//BoostConfig.cmake
FOUNDVERSION=1.44.0
CMake Error at 
/Users/Shared/Toolkits/MXABoost-1.44/share/boost-1.44.0/cmake/BoostConfig.cmake:87
 (message):
  Boost components not found: thread;program_options;date_time
Call Stack (most recent call first):
  /Users/Shared/Toolkits/MXABoost-1.44/share/cmake/boost/BoostConfig.cmake:15 
(include)
  
/Users/Shared/Toolkits/CMake-2.8.6/CMake-2.8.6.app/Contents/share/cmake-2.8/Modules/FindBoost.cmake:282
 (find_package)
  CMakeLists.txt:144 (FIND_PACKAGE)


-- Configuring incomplete, errors occurred!

I dug into the FindBoost.cmake file that comes with RC3 and started reading the 
docs at the top. It states that if I am using Boost Headers only then I can 
leave out the "COMPONENTS" part. I changed my CMakeLists.txt file to reflect 
this and I still get the error.

Operator Error or regression?

___
Mike Jackson  www.bluequartz.net
Principal Software Engineer   mike.jack...@bluequartz.net 
BlueQuartz Software   Dayton, Ohio

--

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] dmg CPack Options

[Michael Jackson]

Thanks for the heads up. The good news is that the tgz symlink issue is indeed 
solved so that is a way forward for me. The bad news is that FindBoost seems 
broken.
___
Mike Jackson  www.bluequartz.net
Principal Software Engineer   mike.jack...@bluequartz.net 
BlueQuartz Software   Dayton, Ohio

On Sep 22, 2011, at 11:40 AM, Johan Björk wrote:

> You might want to try the latest cmake 2.8.6RC, it should have fixed the 
> symlink issues with .tar.gz packaging.
> 
> -Johan
> 
> 
> On Thu, Sep 22, 2011 at 5:35 PM, Michael Jackson 
>  wrote:
> I just found that and have been playing with it but if I set it to 1 then I 
> get the following error:
> 
> CPack: Create package using DragNDrop
> CPack: Install projects
> CPack: - Run preinstall target for: DREAM3D
> CPack: - Install project: DREAM3D
> CPack: -   Install component: Applications
> CPack: -   Install component: Unspecified
> CPack: Create package
> CPack Error: Error executing: /usr/bin/hdiutil create -ov -srcfolder 
> "/Users/mjackson/Workspace/DREAM3D/Build/_CPack_Packages/Darwin/DragNDrop/ALL_IN_ONE"
>  -volname "DREAM3D-v2.1488.gfb63bc8-OSX" -format UDRW 
> "/Users/mjackson/Workspace/DREAM3D/Build/_CPack_Packages/Darwin/DragNDrop/temp.dmg"
> CPack Error: Error generating temporary disk image.
> CPack Error: Problem compressing the directory
> CPack Error: Error when generating package: DREAM3D
> make: *** [package] Error 1
> 
> This is reproducible toggling the value between 1 and 0.
> ___
> Mike Jackson  www.bluequartz.net
> Principal Software Engineer   mike.jack...@bluequartz.net
> BlueQuartz Software   Dayton, Ohio
> 
> On Sep 22, 2011, at 11:17 AM, Clinton Stimpson wrote:
> 
> >
> >
> > On Thursday, September 22, 2011 09:07:49 am Michael Jackson wrote:
> >> Is there an option to pack the entire installation folder _including_ the
> >> folder itself into the dmg disk image during CPack?
> >>
> >> I have several applications, tools, documents and such and they are all
> >> currently put "loose" in the dmg file, I would rather have and enclosing
> >> folder.
> >>
> >> I am using unix symlinks to cut down on repeated frameworks and libraries
> >> so Zip and tgz don't support symlinks correctly which is forcing me to try
> >> the "DragAndDrop" option.
> >>
> >
> > You're probably looking for this:
> > set(CPACK_INCLUDE_TOPLEVEL_DIRECTORY 1)
> >
> > --
> > Clinton Stimpson
> > Elemental Technologies, Inc
> > Computational Simulation Software, LLC
> > www.csimsoft.com
> > --
> >
> > 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
> 

--

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 set own linker?

[Martin Kupke]

Hi,

I created a toolchain file for cross compiling in my Windows XP 
environment.
To provide cross compiling functionality I set the CMAKE_SYSTEM_NAME to 
Generic.

The toolchain file contains the variables:
CMAKE_C_COMPILER set to my own wanted compiler, which is dcc.exe
CMAKE_ASM_OCU_COMPILER set to my own wanted assembler, which is das.exe
For both, assembler and compiler I created configuration files in the 
Platform folder.
Up to this point everything goes fine and as wanted, the assembler 
source files with the .s extension are compiled with das.exe and the C 
source files with the extension .c are compiled with the dcc.exe.


In the root top level CMakeLists.txt the instruction
project( EmbeddedProject C ASM_OCU)
ensures that only C compiler and ASM_OCU assembler are called (no CXX).

Even in the root top level CMakeLists.txt I set
add_executable( ${PROJECT_NAME} ${SourceFiles} )
where SourceFiles is a string containing all source files (assembler and C).

I even tried to set the CMAKE_LINKER variable to my own linker, but it 
isn't used.

Where is my fault?

Thanks,
Martin...


--

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] linker default library path /usr/local/lib on OSX

[Michael Jackson]

Use "install_name_tool" to do that assuming that who ever built the library 
used the correct linker flags to allow you to do that. If not then you are out 
of luck.
___
Mike Jackson  www.bluequartz.net
Principal Software Engineer   mike.jack...@bluequartz.net 
BlueQuartz Software   Dayton, Ohio

On Sep 22, 2011, at 11:57 AM, amine bezzarga wrote:

> Any ideas about how to override the "install_name" of /usr/local/lib on that 
> library ?
> 
> On Wed, Sep 21, 2011 at 1:52 AM, amine bezzarga  wrote:
> Yes I think I get it, I tried that but it doesn't work either:
> install_name_tool -change /usr/local/lib/libirrklang.dylib 
> ./Dependencies/IrrKLangAudioEngine/bin/macosx-gcc/ 
> ./Dependencies/IrrKLangAudioEngine/bin/macosx-gcc/libirrklang.dylib 
> 
> Can you tell me, what can I do to fix the problem ?
> 
> On Tue, Sep 20, 2011 at 2:19 AM, Michael Jackson 
>  wrote:
> Yes. Who ever built the irrklang library has set an "install_name" of 
> /usr/local/lib on that library. So it does not matter where the library is 
> located. OS X thinks it is in /usr/local/lib. 
> You need to fix how that library is compiled and linked. Does that make 
> it clear what is going on?
> 
> 
> -
> Mike Jackson www.bluequartz.net
> Principal Software Engineer   mike.jack...@bluequartz.net
> BlueQuartz Software   Dayton, Ohio
> Sent from my mobile device. 
> 
> On Sep 19, 2011, at 19:56, amine bezzarga  wrote:
> 
>> Yeah, I tried the NO_DEFAULT_PATH option but without success.
>> My target_link_library command look like this:
>> 
>> target_link_libraries(${CMAKE_PROJECT_NAME} ${OGRE_LIBRARIES} 
>> ${OGRE_PLUGIN_LIBRARIES} ${Boost_LIBRARIES} ${OIS_LIBRARIES} 
>> ${IrrKlang_LIBRARIES})
>> 
>> Here is the otool output of the sound library:
>> $ otool -L 
>> ./Dependencies/IrrKLangAudioEngine/bin/macosx-gcc/libirrklang.dylib 
>> ./Dependencies/IrrKLangAudioEngine/bin/macosx-gcc/libirrklang.dylib 
>> (architecture ppc):
>>  /usr/local/lib/libirrklang.dylib (compatibility version 1.0.0, current 
>> version 1.0.0)
>>  /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio 
>> (compatibility version 1.0.0, current version 1.0.0)
>>  /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current 
>> version 7.4.0)
>>  /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 
>> 1.0.0)
>>  /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
>> version 88.3.3)
>> ./Dependencies/IrrKLangAudioEngine/bin/macosx-gcc/libirrklang.dylib 
>> (architecture i386):
>>  /usr/local/lib/libirrklang.dylib (compatibility version 1.0.0, current 
>> version 1.0.0)
>>  /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio 
>> (compatibility version 1.0.0, current version 1.0.0)
>>  /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current 
>> version 7.4.0)
>>  /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 
>> 1.0.0)
>>  /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
>> version 88.3.3)
>> 
>> Does it help ?
>> 
>> 
>> On Mon, Sep 19, 2011 at 1:56 PM, Michael Jackson 
>>  wrote:
>> My guess is that the audio library has an install path of /usr/local/lib 
>> encoded in it. Try posting tue output of otool for the actual audio library. 
>> 
>> -
>> Mike Jackson www.bluequartz.net
>> Principal Software Engineer   mike.jack...@bluequartz.net
>> BlueQuartz Software   Dayton, Ohio
>> Sent from my mobile device. 
>> 
>> On Sep 18, 2011, at 23:38, Cristobal Navarro  wrote:
>> 
>>> ok i get your point.
>>> mmm. In others words you need something equivalent to rpath command, im 
>>> pretty sure cmake can handle this easily let me know if the following helps.
>>> 
>>> have you tried adding more options to the find_library command ??
>>> for example have you tried this (also, with the PATHS command just to be 
>>> sure):
>>> 
>>> find_library(IrrKlang_LIBRARIES irrKlang
>>> PATHS 
>>> ${CMAKE_CURRENT_SOURCE_DIR}/Dependencies/IrrKLangAudioEngine/bin/macosx-gcc
>>>  NO_DEFAULT_PATH
>>> )
>>> 
>>> And what is your "target_link_libraries" command?
>>> 
>>> 
>>> 
>>> On Sun, Sep 18, 2011 at 12:33 PM, amine bezzarga  wrote:
>>> The issue is not about finding the library at built time, event if my 
>>> library is found in 
>>> ${CMAKE_CURRENT_SOURCE_DIR}/Dependencies/IrrKLangAudioEngine/bin/macosx-gcc 
>>> and after building is done, my app is still looking for the library in 
>>> /usr/local/lib at runtime as you can see with the otools output in my first 
>>> message.
>>> 
>>> I want to find a way to tell the linker to link the library from where it 
>>> find it.
>>> Does it make sense ?
>>> 
>>> On Sun, Sep 18, 2011 at 4:29 PM, Cristobal Navarro  
>>> wrote:
>>> yes
>>> 
>>> you have to provide another option
>>> find_library( IrrKlang

Re: [CMake] linker default library path /usr/local/lib on OSX

[amine bezzarga]

Any ideas about how to override the "install_name" of /usr/local/lib on that
library ?

On Wed, Sep 21, 2011 at 1:52 AM, amine bezzarga  wrote:

> Yes I think I get it, I tried that but it doesn't work either:
> install_name_tool -change /usr/local/lib/libirrklang.dylib
> ./Dependencies/IrrKLangAudioEngine/bin/macosx-gcc/
> ./Dependencies/IrrKLangAudioEngine/bin/macosx-gcc/libirrklang.dylib
>
> Can you tell me, what can I do to fix the problem ?
>
> On Tue, Sep 20, 2011 at 2:19 AM, Michael Jackson <
> mike.jack...@bluequartz.net> wrote:
>
>> Yes. Who ever built the irrklang library has set an "install_name" of
>> /usr/local/lib on that library. So it does not matter where the library is
>> located. OS X thinks it is in /usr/local/lib.
>> You need to fix how that library is compiled and linked. Does that
>> make it clear what is going on?
>>
>>
>> -
>> Mike Jackson 
>> www.bluequartz.net
>> Principal Software Engineer   
>> mike.jack...@bluequartz.net
>> BlueQuartz Software   Dayton, Ohio
>> Sent from my mobile device.
>>
>> On Sep 19, 2011, at 19:56, amine bezzarga  wrote:
>>
>> Yeah, I tried the NO_DEFAULT_PATH option but without success.
>> My target_link_library command look like this:
>>
>> target_link_libraries(${CMAKE_PROJECT_NAME} ${OGRE_LIBRARIES}
>> ${OGRE_PLUGIN_LIBRARIES} ${Boost_LIBRARIES} ${OIS_LIBRARIES}
>> ${IrrKlang_LIBRARIES})
>>
>> Here is the otool output of the sound library:
>> $ otool -L
>> ./Dependencies/IrrKLangAudioEngine/bin/macosx-gcc/libirrklang.dylib
>> ./Dependencies/IrrKLangAudioEngine/bin/macosx-gcc/libirrklang.dylib
>> (architecture ppc):
>>  /usr/local/lib/libirrklang.dylib (compatibility version 1.0.0, current
>> version 1.0.0)
>> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio
>> (compatibility version 1.0.0, current version 1.0.0)
>>  /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version
>> 7.4.0)
>> /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version
>> 1.0.0)
>>  /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
>> 88.3.3)
>> ./Dependencies/IrrKLangAudioEngine/bin/macosx-gcc/libirrklang.dylib
>> (architecture i386):
>>  /usr/local/lib/libirrklang.dylib (compatibility version 1.0.0, current
>> version 1.0.0)
>> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio
>> (compatibility version 1.0.0, current version 1.0.0)
>>  /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version
>> 7.4.0)
>> /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version
>> 1.0.0)
>>  /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
>> 88.3.3)
>>
>> Does it help ?
>>
>>
>> On Mon, Sep 19, 2011 at 1:56 PM, Michael Jackson 
>> <
>> mike.jack...@bluequartz.net> wrote:
>>
>>> My guess is that the audio library has an install path of /usr/local/lib
>>> encoded in it. Try posting tue output of otool for the actual audio
>>> library.
>>>
>>> -
>>> Mike Jackson 
>>> 
>>> www.bluequartz.net
>>> Principal Software Engineer   
>>> 
>>> mike.jack...@bluequartz.net
>>> BlueQuartz Software   Dayton, Ohio
>>> Sent from my mobile device.
>>>
>>> On Sep 18, 2011, at 23:38, Cristobal Navarro < 
>>> axisch...@gmail.com> wrote:
>>>
>>> ok i get your point.
>>> mmm. In others words you need something equivalent to rpath command, im
>>> pretty sure cmake can handle this easily let me know if the following helps.
>>>
>>> have you tried adding more options to the find_library command ??
>>> for example have you tried this (also, with the PATHS command just to be
>>> sure):
>>>
>>> find_library(IrrKlang_LIBRARIES irrKlang
>>> PATHS
>>> ${CMAKE_CURRENT_SOURCE_DIR}/Dependencies/IrrKLangAudioEngine/bin/macosx-gcc
>>>  NO_DEFAULT_PATH
>>>  )
>>>
>>> And what is your "target_link_libraries" command?
>>>
>>>
>>>
>>> On Sun, Sep 18, 2011 at 12:33 PM, amine bezzarga < 
>>> 
>>> abezz...@gmail.com> wrote:
>>>
 The issue is not about finding the library at built time, event if my
 library is found in
 ${CMAKE_CURRENT_SOURCE_DIR}/Dependencies/IrrKLangAudioEngine/bin/macosx-gcc
  and
 after building is done, my app is still looking for the library in
 /usr/local/lib at runtime as you can see with the otools output in my first
 message.

 I want to find a way to tell the linker to link the library from where
 it find it.
 Does it make sense ?

 On Sun, Sep 18, 2011 at 4:29 PM, Cristobal Navarro 
 <
 axisch...@gmail.com> wrote:

> yes
>
> you have to provide another option
> find_library( IrrKlang_LIBRARIES irrKlang PATHS  library>  ... )
>
>
> 
> http://www.cmake.org/cmake/hel

Re: [CMake] dmg CPack Options

[Johan Björk]

You might want to try the latest cmake 2.8.6RC, it should have fixed the
symlink issues with .tar.gz packaging.

-Johan


On Thu, Sep 22, 2011 at 5:35 PM, Michael Jackson <
mike.jack...@bluequartz.net> wrote:

> I just found that and have been playing with it but if I set it to 1 then I
> get the following error:
>
> CPack: Create package using DragNDrop
> CPack: Install projects
> CPack: - Run preinstall target for: DREAM3D
> CPack: - Install project: DREAM3D
> CPack: -   Install component: Applications
> CPack: -   Install component: Unspecified
> CPack: Create package
> CPack Error: Error executing: /usr/bin/hdiutil create -ov -srcfolder
> "/Users/mjackson/Workspace/DREAM3D/Build/_CPack_Packages/Darwin/DragNDrop/ALL_IN_ONE"
> -volname "DREAM3D-v2.1488.gfb63bc8-OSX" -format UDRW
> "/Users/mjackson/Workspace/DREAM3D/Build/_CPack_Packages/Darwin/DragNDrop/temp.dmg"
> CPack Error: Error generating temporary disk image.
> CPack Error: Problem compressing the directory
> CPack Error: Error when generating package: DREAM3D
> make: *** [package] Error 1
>
> This is reproducible toggling the value between 1 and 0.
> ___
> Mike Jackson  www.bluequartz.net
> Principal Software Engineer   mike.jack...@bluequartz.net
> BlueQuartz Software   Dayton, Ohio
>
> On Sep 22, 2011, at 11:17 AM, Clinton Stimpson wrote:
>
> >
> >
> > On Thursday, September 22, 2011 09:07:49 am Michael Jackson wrote:
> >> Is there an option to pack the entire installation folder _including_
> the
> >> folder itself into the dmg disk image during CPack?
> >>
> >> I have several applications, tools, documents and such and they are all
> >> currently put "loose" in the dmg file, I would rather have and enclosing
> >> folder.
> >>
> >> I am using unix symlinks to cut down on repeated frameworks and
> libraries
> >> so Zip and tgz don't support symlinks correctly which is forcing me to
> try
> >> the "DragAndDrop" option.
> >>
> >
> > You're probably looking for this:
> > set(CPACK_INCLUDE_TOPLEVEL_DIRECTORY 1)
> >
> > --
> > Clinton Stimpson
> > Elemental Technologies, Inc
> > Computational Simulation Software, LLC
> > www.csimsoft.com
> > --
> >
> > 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
>
--

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] Post Packaging Script?

[Michael Jackson]

Is there some way to run a shell script/command/cmake script AFTER all the 
packaging is completed?
 
When I run "make package" from the command line everything goes just fine. The 
issue is that the folder _CPack_Packages is left over which contains a Symlink 
to /Applications for OS X systems. Having this link over loads Eclipse as 
Eclipse will then try to find all executables in /Applications which does not 
tend to work out well. 

  So basically I just want to delete the _CPack_Packages folder after the 
package has been generated.

Thanks
___
Mike Jackson  www.bluequartz.net
Principal Software Engineer   mike.jack...@bluequartz.net 
BlueQuartz Software   Dayton, Ohio

--

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] return value of find_library

[Yifei Li]

Hi all,

Say I have find_library(MYLIB mylib  PATHS …) ,   I don't understand why MYLIB 
sometimes is a full path to mylib and sometimes only contains 'mylib'.

Thanks

Yifei

--

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] dmg CPack Options

[Michael Jackson]

I just found that and have been playing with it but if I set it to 1 then I get 
the following error:

CPack: Create package using DragNDrop
CPack: Install projects
CPack: - Run preinstall target for: DREAM3D
CPack: - Install project: DREAM3D
CPack: -   Install component: Applications
CPack: -   Install component: Unspecified
CPack: Create package
CPack Error: Error executing: /usr/bin/hdiutil create -ov -srcfolder 
"/Users/mjackson/Workspace/DREAM3D/Build/_CPack_Packages/Darwin/DragNDrop/ALL_IN_ONE"
 -volname "DREAM3D-v2.1488.gfb63bc8-OSX" -format UDRW 
"/Users/mjackson/Workspace/DREAM3D/Build/_CPack_Packages/Darwin/DragNDrop/temp.dmg"
CPack Error: Error generating temporary disk image.
CPack Error: Problem compressing the directory
CPack Error: Error when generating package: DREAM3D
make: *** [package] Error 1

This is reproducible toggling the value between 1 and 0.
___
Mike Jackson  www.bluequartz.net
Principal Software Engineer   mike.jack...@bluequartz.net 
BlueQuartz Software   Dayton, Ohio

On Sep 22, 2011, at 11:17 AM, Clinton Stimpson wrote:

> 
> 
> On Thursday, September 22, 2011 09:07:49 am Michael Jackson wrote:
>> Is there an option to pack the entire installation folder _including_ the
>> folder itself into the dmg disk image during CPack?
>> 
>> I have several applications, tools, documents and such and they are all
>> currently put "loose" in the dmg file, I would rather have and enclosing
>> folder.
>> 
>> I am using unix symlinks to cut down on repeated frameworks and libraries
>> so Zip and tgz don't support symlinks correctly which is forcing me to try
>> the "DragAndDrop" option.
>> 
> 
> You're probably looking for this:
> set(CPACK_INCLUDE_TOPLEVEL_DIRECTORY 1)
> 
> -- 
> Clinton Stimpson
> Elemental Technologies, Inc
> Computational Simulation Software, LLC
> www.csimsoft.com
> --
> 
> 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] VS2005: CMAKE_CXX_FLAGS not used when project() is placed after definition

[Michael Hertling]

On 09/21/2011 09:26 AM, Jens Auer wrote:
>> The PROJECT() command has significant side effects, e.g. for 
>> C++ projects, it loads Modules/CMakeCXXInformation.cmake containing:
>>
>> SET (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS_INIT}" CACHE STRING
>>  "Flags used by the compiler during all build types.")
>>
>> If CMAKE_CXX_FLAGS has no value in the cache before, this 
>> command will write to the cache *and* to the current scope, 
>> see [1]. Thus, it will overwrite the value provided in the 
>> CMakeLists.txt in the first case.
>> In the second case, the CMakeLists.txt file provides the 
>> definitive value in the current scope which will be in effect 
>> afterwards.
>>
>> IMO, it's best to have PROJECT() as one of the very first 
>> commands in CMakeLists.txt files, and to only put other 
>> commands before it if one really knows about the consequences.
> This behvaior seems to be a little inconsistent. When I remember correctly, 
> the optimization switch gets set correctly in both cases, but the /EHa is 
> lost. [...]

The /EH and /O flags stem from different origins: The former from
CMAKE_CXX_FLAGS and the latter from CMAKE_CXX_FLAGS_DEBUG, e.g., cf.
Modules/Platform/Windows-cl.cmake. Therefore, if you build the debug
configuration with CMAKE_CXX_FLAGS set before PROJECT(), you will end
up with /EHsc - overwritten in CMAKE_CXX_FLAGS by PROJECT() - and /O2
normally from CMAKE_CXX_FLAGS_DEBUG, so it *seems* as if the /O2 flag
is preserved. In this regard, CMake's behavior is consistent, IMO.

> [...] I also think that overwriting the variable in the current scope is 
> unobivious and should at least be documented in the manual, but I would 
> prefer to not touch the variable or even use the current value.

The CMAKE__FLAGS[_] variables serve as a means for the
user to specify basic and configuration-related compilation flags on
the CMake command line or the GUI, and for this reason, they're all
cached with reasonable default values. Thus, it's actually you who
provides for an unobivious behavior when you overwrite them in the
CMakeLists.txt files with SET(CMAKE_CXX_FLAGS "..."). Suppose your
user configures the project with "cmake -DCMAKE_CXX_FLAGS=..."; of
course it's expected that these flags hold, but the user will see
the possibly different flags established by the CMakeLists.txt.

If you have special requirements w.r.t. compilation flags for your
project, I think it's best to provide your own default values, e.g.

SET(CMAKE_CXX_FLAGS "..." CACHE TYPE STRING "Default C++ flags")
...
PROJECT(...)

or via the -C or -D command line options, or even define a customized
configuration with suitable default values for the project, refer to
FAQ 4.16,17 for more information. In any case, respect your user's
choice as far as possible, and keep in mind that such compilation
flags are compiler-specific.

> Best regards,
>   Jens

Regards,

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

Re: [CMake] dmg CPack Options

[Clinton Stimpson]

On Thursday, September 22, 2011 09:07:49 am Michael Jackson wrote:
> Is there an option to pack the entire installation folder _including_ the
> folder itself into the dmg disk image during CPack?
> 
>  I have several applications, tools, documents and such and they are all
> currently put "loose" in the dmg file, I would rather have and enclosing
> folder.
> 
>  I am using unix symlinks to cut down on repeated frameworks and libraries
> so Zip and tgz don't support symlinks correctly which is forcing me to try
> the "DragAndDrop" option.
> 

You're probably looking for this:
set(CPACK_INCLUDE_TOPLEVEL_DIRECTORY 1)

-- 
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com
--

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] dmg CPack Options

[Michael Jackson]

Is there an option to pack the entire installation folder _including_ the 
folder itself into the dmg disk image during CPack?

 I have several applications, tools, documents and such and they are all 
currently put "loose" in the dmg file, I would rather have and enclosing folder.

 I am using unix symlinks to cut down on repeated frameworks and libraries so 
Zip and tgz don't support symlinks correctly which is forcing me to try the 
"DragAndDrop" option. 

Thanks
___
Mike Jackson  www.bluequartz.net
Principal Software Engineer   mike.jack...@bluequartz.net 
BlueQuartz Software   Dayton, Ohio

--

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] ExternalProject_Add and Dependent Targets

[Lori Pritchett-Sheats]

David Cole wrote:

On Wed, Sep 21, 2011 at 11:45 AM, Lori Pritchett-Sheats
 wrote:
  

Reading the documentation it is not clear how the DEPENDS option works in
ExternalProject_Add.

For example, I add HDF5 to my build and HDF5 depends on zlib the following
doesn't work

find_package(ZLIB)
add_library(zlib UNKNOWN IMPORTED)
set_target_properties(zlib PROPERTIES IMPORTED_LOCATION ${ZLIB_LIBRARY})

ExternalProject_Add(hdf5 DEPENDS zlib ..)

throws an error with the message 'No rule to make /zlib-done', needed by
external_projects/src/hdf5-stamp/hdf5-configure

For ExternalProject_Add, are the targets listed under the DEPENDS option
only targets that will be built with another ExternalProject_Add, not
existing libraries?




That's correct.

The first argument to ExternalProject_Add does become the name of a
custom target, though. So after the ExternalProject_Add call, you can
do:

ExternalProject_Add(hdf5 ...)

add_dependencies(hdf5 zlib)

However, in this particular case, you are finding an existing zlib and
then using an imported target to say where it is *for other
non-external project targets in the same CMake build*... For the
ExternalProject build of hdf5, you're going to have to pass down in
the location of zlib via some arguments, because the ExternalProject
build knows nothing about the context of what else is built in the
current CMake build...

So in this particular case, the hdf5 custom target does not actually
depend (in a build order sense) on the zlib target -- because the zlib
target doesn't build anything, it's just imported. So you don't
actually need the dependency... you just need to tell hdf5 where zlib
is.

Does that make sense?


HTH,
David

  


I think so. The HDF5 configuration has switch options to pass in the 
zlib include and library path, both are available once I call 
find_package(ZLIB). But if I'm building a library that depends on HDF5 I 
need to include the zlib target in the dependency definitions, correct?


If I'm understanding this correctly, after the ExternalProject_Add call, 
I need to define HDF5_INCLUDE_PATH, HDF5_LIBRARIES, since the project 
will not exist when CMake runs. Then when I create a library or 
executable that needs the HDF5 libraries for linking, I would do the 
following:


add_library(mylib ${some_source})
target_link_libraries(mylib ${HDF5_LIBRARIES} zlib)


--
Lori A. Pritchett-Sheats, PhD.
CCS-2, Computational Physics and Methods
Office: 505-665-6675
Fax: 505-665-4972

Los Alamos National Laboratory
P.O. Box 1663
MS D413
Los Alamos, NM 87544

--

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] ExternalProject_Add without download of local sources?

[Thomas Wolf]

On 15.09.2011 18:30, David Cole wrote:
> Luigi is correct:
> 
> To use an existing source directory (just use the source in its place
> without any copy operations), simply say:
> 
>   DOWNLOAD_COMMAND ""
>   SOURCE_DIR ${Log4Qt_SOURCE_DIR}
> 
> The default behavior of copying the source tree when it is specified
> via URL is present for two reasons:
>   (1) some packages require an in-source build, and copying the source
> tree is a good way to keep a clean copy of the source tree around
>   (2) it's the same as all the other URL operations: in the http case,
> it's downloaded and then extracted ("copied") into the SOURCE_DIR
> location, in a local directory case, we also chose to make the copy
> simply for ease of implementation
> 

Hi David,

Finally I got it to work. Thanks for the advice. As it turned out, you
have to be careful which other parameters you use: Getting rid of
Download or Update (in my case) commands definitions did the trick.

This makes sense, because otherwise you have to assume you want to
change/patch the sources...

Regards,
Thomas



___
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] Using Bundle Utilities on an OS X Command line Tool

[Michael Jackson]

I am trying to figure out how to possibly use BundleUtilities.cmake to fix up a 
"Unix" type install versus a .app bundle. In my situation I would like the 
following layout (Simplified)

DREAM3D/bin/MyExecutable
DREAM3D/lib/libHDF5.dylib
DREAM3D/lib/libSupport.dylib

When I run BundleUtlities I get an error that says:

 # Starting OS X Tool Fixup --
-- fixup_bundle
--   app='/Users/Shared/Toolkits/DREAM.3D/tools/H5VoxelToVtk'
--   libs=''
--   
dirs='/Users/mjackson/Workspace/DREAM3D/zRel/Bin;/Users/mjackson/Workspace/DREAM3D/zRel/Bin'
-- fixup_bundle: preparing...
-- fixup_bundle: copying...
-- 1/12: *NOT* copying '/Users/Shared/Toolkits/DREAM.3D/tools/H5VoxelToVtk'
-- 2/12: copying '/Users/Shared/Toolkits/hdf5-187/lib/libhdf5.1.8.7.dylib'
-- 3/12: copying '/Users/mjackson/Workspace/DREAM3D/zRel/Bin/libEbsdLib.dylib'
-- 4/12: copying '/Users/mjackson/Workspace/DREAM3D/zRel/Bin/libH5Support.dylib'
-- 5/12: copying 
'/Users/mjackson/Workspace/DREAM3D/zRel/Bin/libMXADataModel.dylib'
-- 6/12: copying 
'/Users/mjackson/Workspace/DREAM3D/zRel/Bin/libDREAM3DLib.dylib'
-- fixup_bundle: fixing...
-- 7/12: fixing up '/Users/Shared/Toolkits/DREAM.3D/tools/H5VoxelToVtk'
-- 8/12: fixing up '/Users/Shared/Toolkits/DREAM.3D/lib/libhdf5.1.8.7.dylib'
  exe_dotapp_dir/='/Users/Shared/Toolkits/DREAM.3D/tools/'
  item_substring='/Users/Shared/Toolkits/DREAM.3D/lib/li'
  
resolved_embedded_item='/Users/Shared/Toolkits/DREAM.3D/lib/libhdf5.1.8.7.dylib'

Install or copy the item into the bundle before calling fixup_bundle.
Or maybe there's a typo or incorrect path in one of the args to fixup_bundle?

CMake Error at 
/Users/Shared/Toolkits/CMake-2.8.5/CMake-2.8-5.app/Contents/share/cmake-2.8/Modules/BundleUtilities.cmake:568
 (message):
  cannot fixup an item that is not in the bundle...
Call Stack (most recent call first):
  
/Users/Shared/Toolkits/CMake-2.8.5/CMake-2.8-5.app/Contents/share/cmake-2.8/Modules/BundleUtilities.cmake:656
 (fixup_bundle_item)
  Tools/OSX_Scripts/H5VoxelToVtk_CompleteTool.cmake:86 (fixup_bundle)
  Tools/cmake_install.cmake:47 (INCLUDE)
  cmake_install.cmake:36 (INCLUDE)


make: *** [install] Error 1


I am hoping I am just not specifying something correctly in bundle Utilities? 
This is with CMake 2.8.5 on OS X 10.6.8.

Thanks for any help or pointers to other examples.

___
Mike Jackson  www.bluequartz.net
Principal Software Engineer   mike.jack...@bluequartz.net 
BlueQuartz Software   Dayton, Ohio

___
Powered by www.kitware.com

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

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

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

Re: [CMake] Fwd: Save stripped debugging information

[Rolf Eike Beer]

> Il 22/09/2011 10.13, Rolf Eike Beer ha scritto:
>>> Yeah, that's exactly what I had in mind. Any chance that we will see
>>> this in a future release?
>> This is usually "find someone who does it and writes tests for it".
>> Which
>> then boils down to find someone who has enough knowledge and spare time
>> to
>> do or someone that needs it and is willing to pay Kitware for doing it.

> Why don't you invoke ${CMAKE_OBJCOPY} as a post build command?

That would be a way to _get_ these debug symbol files, but not a clean way
to _install_ them. And the other reason is that this variable doesn't show
up in any CMake documentation.

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://www.cmake.org/mailman/listinfo/cmake

[CMake] Again on dependencies tree

[Marco Corvo]

Hi all,

I thought I came up with a solution for this problem, but looks like I'm 
still not doing the right thing.


My project is made of many tens of packages, everyone with its nice 
CMakeLists.txt. What I'd like to do is to have the freedom to build 
every single package, or bunches of packages, independently, that is 
without having to "add_subdirectory" for all packages every time. The 
point, just to give an idea, is that the developers of the different 
packages could checkout from the software repo just their own packages, 
which are then supposed to be built against a software release 
(libraries) which is centrally installed on a development machine.


In this framework I would like to let CMake discover the transitive 
dependencies among libraries.


To make a practical example I prepared a single package A (the one the 
developer checks out from our repo) which has an executable EXE 
depending on library libA.a, which resides in the same package (that is 
EXE and libA.a are all together in a source directory).


Yet libA.a depends on a library libB.a which, in this view, is available 
somewhere in the machine. In CMake syntax I have:


- package A CMakeLists.txt:

add_library(A src/xxx.cc)
set(LIB_LINK_LIST B)
target_link_libraries(${pkgname} ${LIB_LINK_LIST})

add_executable(EXE bins/EXE.cc)
set(BIN_LINK_LIST A)
target_link_libraries(EXE ${BIN_LINK_LIST})

- "external" library LibDeps.cmake:

add_library(B STATIC IMPORTED)
add_dependencies(B C)

- main CMakeLists.txt

include(LibDeps.cmake)
add_subdirectory(A)

In my view what I should obtain is a link command like:
g++ .. -o EXE -L/path/to/external/libs -L/path/to/local/libs -L 
-L libA.a -lB -lC


since Exe depends on A, which depends on B via target_link_libraries, 
which on its side depends on C, via add_dependencies.


Instead what I get is:
g++ .. -o EXE -L/path/to/external/libs -L/path/to/local/libs -L 
-L libA.a B-NOTFOUND


It's clear that CMake tries to resolve the deps, otherwise what I would 
get is just "libA.a -lB", but is not able to due to some trick I can't  
find.


target_link_library(B C) instead of add_dependencies(B C) doesn't work. 
I know there are ExternalProject_Add, but these are not external 
projects, just libs residing in some (well known) directories, and 
find_package, but it would be rather complicated  in case my libA.a 
depends on N other libraries.


Am I missing any CMake instructions? Or is it simply the wrong way to 
proceed?


Sorry for the long mail and thanks in advance.

Cheers,

Marco

--
Marco Corvo
SuperB experiment
CNRS - Orsay
c/o INFN - Padova   

___
Powered by www.kitware.com

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

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

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

Re: [CMake] Fwd: Save stripped debugging information

[Andrea Galeazzi]

Il 22/09/2011 10.13, Rolf Eike Beer ha scritto:

Yeah, that's exactly what I had in mind. Any chance that we will see
this in a future release?

This is usually "find someone who does it and writes tests for it". Which
then boils down to find someone who has enough knowledge and spare time to
do or someone that needs it and is willing to pay Kitware for doing it.

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://www.cmake.org/mailman/listinfo/cmake



Why don't you invoke ${CMAKE_OBJCOPY} as a post build command?
___
Powered by www.kitware.com

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

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

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

Re: [CMake] Fwd: Save stripped debugging information

[Rolf Eike Beer]

> Yeah, that's exactly what I had in mind. Any chance that we will see
> this in a future release?

This is usually "find someone who does it and writes tests for it". Which
then boils down to find someone who has enough knowledge and spare time to
do or someone that needs it and is willing to pay Kitware for doing it.

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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Save stripped debugging information

[Pawel Sikora]

On Thursday 22 of September 2011 09:37:36 Rolf Eike Beer wrote:
> > Hi,
> >
> > I'm aware of the option CMAKE_BUILD_TYPE with which I can tell if I
> > want to include debugging information or not.
> >
> > A very useful feature of the program objcopy is, to not strip
> > debugging information from a file but to split it from it so that you
> > can release a program without debugging information but can later
> > debug it if you put the split debugging files in certain directories
> > (more at
> > http://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html).
> >
> > Is there a CMake way to do this?
> 
> Sadly not. This is also annoying for e.g. MSVC builds where the debug
> infos are stored in an extra file (.pdb) anyway, but you have no good way
> to know the current location of the pdb file to install it.
> 
> I would like to see this as a fourth option to INSTALL(TARGETS):
> 
> INSTALL(TARGETS myexe mylib DEBUG_SYMBOLS /foo)
> 
> This could just copy the pdb file on MSVC builds and do the objcopy magic
> in Un*x builds.

moreover, the visual can produce two .pdb files:
- first, in build directory with full debug info.
- second, with stripped private symbols 
(http://msdn.microsoft.com/en-us/library/y87kw2fd.aspx)
  this stripped pdb is useful for release with product for automated crash 
stacktracing with dbghelp.dll.

___
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] Fwd: Save stripped debugging information

[Lukas Anzinger]

Yeah, that's exactly what I had in mind. Any chance that we will see
this in a future release?

Meanwhile I will try to find a clean way to run objdump out of CMake manually.

On Thu, Sep 22, 2011 at 09:37, Rolf Eike Beer  wrote:
> Sadly not. This is also annoying for e.g. MSVC builds where the debug
> infos are stored in an extra file (.pdb) anyway, but you have no good way
> to know the current location of the pdb file to install it.
>
> I would like to see this as a fourth option to INSTALL(TARGETS):
>
> INSTALL(TARGETS myexe mylib DEBUG_SYMBOLS /foo)
>
> This could just copy the pdb file on MSVC builds and do the objcopy magic
> in Un*x builds.
>
> 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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Save stripped debugging information

[Rolf Eike Beer]

> Hi,
>
> I'm aware of the option CMAKE_BUILD_TYPE with which I can tell if I
> want to include debugging information or not.
>
> A very useful feature of the program objcopy is, to not strip
> debugging information from a file but to split it from it so that you
> can release a program without debugging information but can later
> debug it if you put the split debugging files in certain directories
> (more at
> http://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html).
>
> Is there a CMake way to do this?

Sadly not. This is also annoying for e.g. MSVC builds where the debug
infos are stored in an extra file (.pdb) anyway, but you have no good way
to know the current location of the pdb file to install it.

I would like to see this as a fourth option to INSTALL(TARGETS):

INSTALL(TARGETS myexe mylib DEBUG_SYMBOLS /foo)

This could just copy the pdb file on MSVC builds and do the objcopy magic
in Un*x builds.

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://www.cmake.org/mailman/listinfo/cmake

[CMake] Save stripped debugging information

[Lukas Anzinger]

Hi,

I'm aware of the option CMAKE_BUILD_TYPE with which I can tell if I
want to include debugging information or not.

A very useful feature of the program objcopy is, to not strip
debugging information from a file but to split it from it so that you
can release a program without debugging information but can later
debug it if you put the split debugging files in certain directories
(more at http://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html).

Is there a CMake way to do this?

Regards,

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