Re: [CMake] How send linker options for STATIC LIBRARY?

[Philip Lowman]

On Fri, Oct 9, 2009 at 4:04 PM, Aleksandr Udovenko wrote:

> On Fri, Oct 9, 2009 at 5:33 PM, Philip Lowman  wrote:
> > On Fri, Oct 9, 2009 at 4:15 AM, Aleksandr Udovenko  >
> > wrote:
> >>
> >> On Fri, Oct 9, 2009 at 10:04 AM, Philip Lowman  wrote:
> >> > On Wed, Oct 7, 2009 at 11:45 AM, Aleksandr Udovenko
> >> > 
> >> > wrote:
> >> >>
> >> >> I try cmake 2.6, 2.8 for microsoft visual studio 2005,2008.
> >> >> creating library:
> >> >>
> >> >> add_library(my_lib STATIC ${CPP_FILES})
> >> >>
> >> >> I try send some linker options by set
> >> >>
> >> >> set_target_properties(my_lib  PROPERTIES LINK_FLAGS "some_opt")
> >> >>
> >> >> or
> >> >>
> >> >> set_target_properties(my_lib  PROPERTIES LINK_FLAGS_
> >> >> "some_opt")
> >> >>
> >> >>
> >> >> it's ignored, as i understand from source code of vc7generator - it
> >> >> ignored extended and unknown option for static library but it works
> >> >> for exe and shared.
> >> >>
> >> >> How i can send my option to linker for static library?
> >> >
> >> > You might be able to use this:
> >> >
> >> >
> http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:STATIC_LIBRARY_FLAGS
> >>
> >> It is not good for me, i NOT need to set linker options globally, i
> >> need to set depend on target. STATIC_LIBRARY_FLAGS don't have 
> >> expansion.
> >
> > STATIC_LIBRARY_FLAGS is a target property and not global in scope.
> >
> > add_library(foo STATIC foo.cc)
> > set_target_properties(foo PROPERTIES STATIC_LIBRARY_FLAGS "/myflag")
> >
> > Could you elaborate on what you mean by " expansion"?
> >
> > Please reply to the list. Thanks.
>
> STATIC_LIBRARY_FLAGS has act on all target at once. For example on
> Debug and Release simultaneously.
> But i want same as CMAKE_EXE_LINKER_FLAGS_[CMAKE_BUILD_TYPE], when i
> use it i can set linker flag separately for debug and release.
> I need the same  but for STATIC library.
>

This doesn't appear to be implemented.  You could file a feature request if
there isn't one already.  I believe what you are asking for is support for
STATIC_LIBRARY_FLAGS_.  There are several target properties that
are already build-type aware, so implementing this probably wouldn't be
extremely difficult.

-- 
Philip Lowman
___
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.0 RC 3 ready for testing!

[Bill Hoffman]

CMake 2.8.0 RC 3 is now ready for people to try.
You can find the source and binaries here: http://www.cmake.org/files/v2.8/.

Here are the changes for the 2.8.0 branch so far:

Changes in CMake 2.8.0 RC 3
- CTest Added OS Platform (cpu architecture) detection support to 
windows system

- Several minor FindBoost changes to address posts on mailing list
- Resolve #9685: Fix include dir to be correct path for gnutils
- Fix color check for dependency scanning
- Remove CMP00015 for now as it breaks more things than it fixes
- Reduce duration of ctest_sleep arguments. Add SmallAndFast project. 
Replace kwsys with SmallAndFast to make CTestTest faster. (I will keep 
an eye on coverage results after this commit and make sure we still have 
equivalent ctest coverage.)

- Do not use -fPIC to link executables
- Split Borland compiler information files
- Trimmed off the newline from sw_vers output on mac, it could cause xml 
parsing errors if left in
- Check for openssl-linked option with Qt 4.4+ before making ssl a 
dependency.

- Make Complex test of CMakeLib more optional
- Modernize FindVTK module
- Fix find_package() when _DIR is wrong
- Do not collapse path of NOTFOUND values
- More robust implicit link line detection regex
- fix Xcode 30 generator
- Use the correct CMake (the freshly built one) to drive the 
CMakeWizardTest.

- Support more special characters in file(STRINGS)
- Log implicit link line detection regex
- speedup C dependency scanning even more
- Avoid non-root copies of root-only targets
- Added better OS information for Mac OS X
- Use work-around from bug 4772 for C++ and Fortran
- FortranCInterface: Mangling for Intel on Windows
- cmake-gui don't allow consecutive generates without a configure.
- Fix Preprocess test for Intel on Windows
- Teach intel compiler on windows to place .lib files and .pdb files.
- CPack: Fix bash-isms in launch script
- BUG: #0009648 Change "The following tests FAILED" message to print on 
stdout rather than stderr

- Avoid (Unix|Windows)Paths.cmake multiple include
- When getting include dirs for moc, also watch for framework includes 
and use -F instead of -I.

- Find locally installed software first
- Add '#!/bin/sh' to cygwin-package.sh
- Fix permsissions of installed SquishRunTestCase.sh
- Fix module docs to be manpage (groff) friendly
- Support GNU/kFreeBSD
- Remove old Encoding field from CMake.desktop
- FindQt3: Prefer (moc|uic)-qt3 names over (moc|uic)
- Match width of ctest "Start xx: " line to line up with the end test line
- Remove old license from FindPkgConfig.cmake module
- Test target link information invalidation
- Invalidate target link info when necessary
- Use new style header generation and get rid of OBJECT_DEPENDS in tutorial
- Fix issue #8649 - move the location of 
CPACK_NSIS_EXTRA_INSTALL_COMMANDS so that it is not excluded from 
execution when 'Do not create shortcuts' is checked.

- add the additional features for the dbus macros from KDE's FindQt4.cmake
fc9f7a5 Fix warnings in CMake source code.
- Correct some typos in error messages in the string command. Add a test 
that covers more of the code implemented in cmStringCommand.cxx, 
especially the error handlers.

- Create INTERPROCEDURAL_OPTIMIZATION build feature
- Document CMAKE_CURRENT_LIST_FILE more precisely
- Fix the documentation to say what it really does. Bug #9638
- document how the minimum version can be specified
- Fix warnings in CMake source code. Suppress rampant warnings emanating 
from Qt files.

- Add documentation for Cocoa flag and move Motif under X11 flag.

Changes in CMake 2.8.0 RC 2
- Fix FindQt4 so that QtHelp depends on QtNetwork
- Add missing copyright notice to CMake.cmake module
- Add alternative _UTILITY targets to all VS solutions
- FindGTest.cmake some bugfixes, also added public function for closer
integration btwn GoogleTest & CTest, contributed by Dan Blezek.
- Eliminate ExternalProject's use of CMAKE_CFG_INTDIR subdir for
Makefile generators. It was causing problems with parallel make -j
invocations. Keep it for multi-configuration build systems so that Debug
and Release stamp files remain separate.
- Fix for bug #9611, some more paths for OpenJDK.
- Fix get_filename_component() registry view with wow64
- Fix warnings in CMake source code.
- Fix module definition file reference for VS6 NMake
- Fix for bug #9611 do not hard code archs for search paths of java,
look at the machine type.
- Fix bug#9619 add a link to module maintainers page in readme.txt for
Modules
- Add cmake-help-command function to emacs-mode
- Add initial XL C compiler flags for safer builds
- Split XL compiler information files
- Fix default install prefix on Haiku
- Fix use of module .def files for MS tools
- Add StringProperty options includeing /def: for VS 10 flag table
- Convert copyright to OSI BSD and clean up licenses
- ENH: Added ctest test coverage for a test timeout
- CTest honors test timeouts again.
- Remove ctest_submit from CTestTestParallel
- Fix shared library creat

Re: [CMake] CMake 2.8.0 RC 2 ready for testing!

[Pau Garcia i Quiles]

On Sat, Oct 10, 2009 at 12:03 AM, Eric Noulard  wrote:
> 2009/10/9 Bill Hoffman :
>> Orion Poplawski wrote:
>>>
>>> That was it.  Moving to out of tree worked.
>>>
>> I just verified that -j N>1 fails with those tests when doing in-source
>> builds.  This can be fixed by adding some more test depends into CMake, or
>> disabling in-source builds
>
> +1 for being able to properly disabling in-source build
> for any project including CMake itself :-)
> See:
> http://public.kitware.com/Bug/view.php?id=6672

A few days ago I proposed a different approach:

PROJECT( myproj OUTOFSOURCE )

That would force out-of-source builds.

That, and more feature suggestions, in
http://article.gmane.org/gmane.comp.kde.devel.buildsystem/4787

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
___
Powered by www.kitware.com

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

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

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

Re: [CMake] Wrong flags in fortran project when use c library

[Kelly (KT) Thompson]

On Fri, Oct 9, 2009 at 12:49 PM, Bill Hoffman wrote:

> Kelly (KT) Thompson wrote:
>
>  On Fri, Oct 9, 2009 at 6:15 AM, Sebas > spas...@gmail.com>> wrote:
>>
>>I send a example where happen explained before ( I have similar
>>struct in my Program). I include too the VS2008 project generate by
>>cmake. In the Fortran Project be can seen that use /W3 /Zm1000 /GR
>>/RTC1 /TP Flags that don't work with ifort.
>>I use CMake 2.8 rc2 (but happen same in 2.6 and 2.7)
>>
>>Thanks.
>>
>>Sebastian
>>
>>
>> Sebastian,
>>
>> You are mixing C, C++ and Fortran sources in a single project.  This does
>> not work well in general and particularly in CMake.  I was able to
>> restructure your sample code so that it will build with NMake Makefile
>> (Visual Studio 2008 SP1 and Intel Visual Fortran 11).
>>
>> Key points:
>>
>> 1. all C++ code goes into a single directory and produces a single
>> library.  The CMakeLists.txt has the project name CPPLibrary2.
>>
>> 2. each C library is built only from C sources. The CMakeLists.txt files
>> are given the project name CLibrary and CLibrary2.
>>
>> 3. the Fortran is also isolated into a single directory and the local
>> CMakeLists.txt file only deals with the Fortran.
>>
>> 4. CMake needs help knowing how to build mixed language targets that must
>> be compiled with the Fortran compiler.  In the Fortran CMakeLists.txt I had
>> to set_target properties for LINKER_LANGUAGE.
>>
>> 5. When mixing C and Fortran on the Windows platform you must use the same
>> type of runtime libraries (/MT or /MD).  The default Fortran build uses /MT,
>> so I had to set these to /MD (Fortran_FLAGS)
>>
>> 6. When interfacing C++ and Fortran code, you must mark the C++ function
>> as extern "C" to avoid name mangling issues.  The Fortran also expects the
>> C++ symbol name to be all caps.  You can use Fortran's ISO_C_BINDING to get
>> around this platform issue.
>>
>> There are many changes required to your sample build so I decided that a
>> zip file would be the best way to return the project to you.
>>
>>  Thanks for the work around.  However, this should work a bit smoother,
> Sebastian can you create a bug report and attach your example?
>
> Thanks.
>
> -Bill
>
>
Bill,

It is my understanding that each CMake target must be 'language pure"  The
following example will work (and is less complex).  This example assumes
that all sources are in a single directory (see below).  Because Sebastian
had separate directories for each language, I assumed that was important for
his build setup and tried to be faithful to that layout.

I think the key feature that was missing from his original setup was:

  set_target_properties( FortranProgram PROPERTIES LINKER_LANGUAGE Fortran )

Without that that statement, CMake will build FortranProgram.obj correctly,
but then try to generate the .exe by calling the MSVC linker (using the link
flags for C).

-kt

## Single directory equivalent CMakeLists.txt:

CMAKE_MINIMUM_REQUIRED(VERSION 2.6)
PROJECT( FortranProgram C CXX Fortran )

# Find local headers
INCLUDE_DIRECTORIES( ${PROJECT_SOURCE_DIR} )

# Library CLibrary2
ADD_LIBRARY( CLibrary2 CLibrary2.c )

# Library CPPLibrary
ADD_LIBRARY( CPPLibrary2 CPPLibrary2.cpp )

# Library: CLibrary
ADD_LIBRARY( CLibrary CLibrary.c )
TARGET_LINK_LIBRARIES( CLibrary CLibrary2 CPPLibrary2 )

# Fortran
ADD_EXECUTABLE( FortranProgramExe FortranProgram.f90 )
TARGET_LINK_LIBRARIES( FortranProgramExe CLibrary CLibrary2 CPPLibrary2 )

set(CMAKE_Fortran_FLAGS_DEBUG   "/Od /DDEBUG /MDd" )
set(CMAKE_Fortran_FLAGS_RELEASE "/O2 /Ob2 /DNDEBUG /MD" )
set(CMAKE_Fortran_FLAGS_MINSIZEREL "/Os /DNDEBUG /MD" )
set(CMAKE_Fortran_FLAGS_RELWITHDEBINFO "/O2 /Ob2 /DDEBUG /MD" )

IF( MSVC_IDE )
  set_target_properties( FortranProgramExe
PROPERTIES
  LINKER_LANGUAGE Fortran
  LINK_FLAGS "/SUBSYSTEM:CONSOLE"
  OUTPUT_NAME FortranProgram
  )
ELSEIF( WIN32 )
  set_target_properties( FortranProgramExe
PROPERTIES
  LINKER_LANGUAGE Fortran
  OUTPUT_NAME FortranProgram
  )
ENDIF()
___
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.0 RC 2 ready for testing!

[Eric Noulard]

2009/10/9 Bill Hoffman :
> Orion Poplawski wrote:
>>
>> That was it.  Moving to out of tree worked.
>>
> I just verified that -j N>1 fails with those tests when doing in-source
> builds.  This can be fixed by adding some more test depends into CMake, or
> disabling in-source builds

+1 for being able to properly disabling in-source build
for any project including CMake itself :-)
See:
http://public.kitware.com/Bug/view.php?id=6672


-- 
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] CMake 2.8.0 RC 2 ready for testing!

[Bill Hoffman]

Orion Poplawski wrote:

On 10/08/2009 08:56 PM, Bill Hoffman wrote:

Bill Hoffman wrote:

Did you do an in-source build? That might be the problem, we almost
always test out of source.


That was it.  Moving to out of tree worked.

I just verified that -j N>1 fails with those tests when doing in-source 
builds.  This can be fixed by adding some more test depends into CMake, 
or disabling in-source builds


-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] CMake 2.8.0 RC 2 ready for testing!

[Orion Poplawski]

On 10/08/2009 08:56 PM, Bill Hoffman wrote:

Bill Hoffman wrote:

Did you do an in-source build? That might be the problem, we almost
always test out of source.


That was it.  Moving to out of tree worked.

--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.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

Re: [CMake] How send linker options for STATIC LIBRARY?

[Aleksandr Udovenko]

On Fri, Oct 9, 2009 at 5:33 PM, Philip Lowman  wrote:
> On Fri, Oct 9, 2009 at 4:15 AM, Aleksandr Udovenko 
> wrote:
>>
>> On Fri, Oct 9, 2009 at 10:04 AM, Philip Lowman  wrote:
>> > On Wed, Oct 7, 2009 at 11:45 AM, Aleksandr Udovenko
>> > 
>> > wrote:
>> >>
>> >> I try cmake 2.6, 2.8 for microsoft visual studio 2005,2008.
>> >> creating library:
>> >>
>> >> add_library(my_lib STATIC ${CPP_FILES})
>> >>
>> >> I try send some linker options by set
>> >>
>> >> set_target_properties(my_lib  PROPERTIES LINK_FLAGS "some_opt")
>> >>
>> >> or
>> >>
>> >> set_target_properties(my_lib  PROPERTIES LINK_FLAGS_
>> >> "some_opt")
>> >>
>> >>
>> >> it's ignored, as i understand from source code of vc7generator - it
>> >> ignored extended and unknown option for static library but it works
>> >> for exe and shared.
>> >>
>> >> How i can send my option to linker for static library?
>> >
>> > You might be able to use this:
>> >
>> > http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:STATIC_LIBRARY_FLAGS
>>
>> It is not good for me, i NOT need to set linker options globally, i
>> need to set depend on target. STATIC_LIBRARY_FLAGS don't have 
>> expansion.
>
> STATIC_LIBRARY_FLAGS is a target property and not global in scope.
>
> add_library(foo STATIC foo.cc)
> set_target_properties(foo PROPERTIES STATIC_LIBRARY_FLAGS "/myflag")
>
> Could you elaborate on what you mean by " expansion"?
>
> Please reply to the list. Thanks.
>
> --
> Philip Lowman
>
STATIC_LIBRARY_FLAGS has act on all target at once. For example on
Debug and Release simultaneously.
But i want same as CMAKE_EXE_LINKER_FLAGS_[CMAKE_BUILD_TYPE], when i
use it i can set linker flag separately for debug and release.
I need the same  but for STATIC library.
___
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] Wrong flags in fortran project when use c library

[Bill Hoffman]

Kelly (KT) Thompson wrote:
On Fri, Oct 9, 2009 at 6:15 AM, Sebas > wrote:


I send a example where happen explained before ( I have similar
struct in my Program). I include too the VS2008 project generate by
cmake. In the Fortran Project be can seen that use /W3 /Zm1000 /GR
/RTC1 /TP Flags that don't work with ifort.
I use CMake 2.8 rc2 (but happen same in 2.6 and 2.7)

Thanks.

Sebastian


Sebastian,

You are mixing C, C++ and Fortran sources in a single project.  This 
does not work well in general and particularly in CMake.  I was able to 
restructure your sample code so that it will build with NMake Makefile 
(Visual Studio 2008 SP1 and Intel Visual Fortran 11).


Key points:

1. all C++ code goes into a single directory and produces a single 
library.  The CMakeLists.txt has the project name CPPLibrary2.


2. each C library is built only from C sources. The CMakeLists.txt files 
are given the project name CLibrary and CLibrary2.


3. the Fortran is also isolated into a single directory and the local 
CMakeLists.txt file only deals with the Fortran.


4. CMake needs help knowing how to build mixed language targets that 
must be compiled with the Fortran compiler.  In the Fortran 
CMakeLists.txt I had to set_target properties for LINKER_LANGUAGE.


5. When mixing C and Fortran on the Windows platform you must use the 
same type of runtime libraries (/MT or /MD).  The default Fortran build 
uses /MT, so I had to set these to /MD (Fortran_FLAGS)


6. When interfacing C++ and Fortran code, you must mark the C++ function 
as extern "C" to avoid name mangling issues.  The Fortran also expects 
the C++ symbol name to be all caps.  You can use Fortran's ISO_C_BINDING 
to get around this platform issue.


There are many changes required to your sample build so I decided that a 
zip file would be the best way to return the project to you.


Thanks for the work around.  However, this should work a bit smoother, 
Sebastian can you create a bug report and attach your example?


Thanks.

-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] Finding Blas

[Bill Hoffman]

Shepherd, Jason F wrote:

Hi all,
 
I'm currently using Cmake 2.8b.  I'm trying to add a requirement (based 
on another conditional statement) to find the LAPACK and BLAS packages 
to VTK's Infovis capabilities.  I've added the following lines to my 
CMakeLists.txt
 
  FIND_PACKAGE(BLAS REQUIRED)

  FIND_PACKAGE(LAPACK REQUIRED)
 
But, this results in the following error:
 
CMake Error at C:/Program Files/CMake 
2.8/share/cmake-2.8/Modules/FindBLAS.cmake:31 (message):

  FindBLAS is Fortran-only so Fortran must be enabled.
Call Stack (most recent call first):
  VTK/Infovis/CMakeLists.txt:227 (FIND_PACKAGE)
 
However, I'm trying to do this with the new cmake-enabled clapack-3.2.1 
which doesn't require any fortran.  Is there a better way to find the 
correct blas and lapack packages that bypasses the fortran-only requirement?
 

Yes you can do this:

find_package(clapack)

The new clpack uses the new package stuff from CMake complete with 
imported targets.


Even has a dashboard:

http://my.cdash.org/index.php?project=CLAPACK


-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

[CMake] Finding Blas

[Shepherd, Jason F]

Hi all,

I'm currently using Cmake 2.8b.  I'm trying to add a requirement (based on 
another conditional statement) to find the LAPACK and BLAS packages to VTK's 
Infovis capabilities.  I've added the following lines to my CMakeLists.txt

  FIND_PACKAGE(BLAS REQUIRED)
  FIND_PACKAGE(LAPACK REQUIRED)

But, this results in the following error:

CMake Error at C:/Program Files/CMake 
2.8/share/cmake-2.8/Modules/FindBLAS.cmake:31 (message):
  FindBLAS is Fortran-only so Fortran must be enabled.
Call Stack (most recent call first):
  VTK/Infovis/CMakeLists.txt:227 (FIND_PACKAGE)

However, I'm trying to do this with the new cmake-enabled clapack-3.2.1 which 
doesn't require any fortran.  Is there a better way to find the correct blas 
and lapack packages that bypasses the fortran-only requirement?

Thanks,

Jason Shepherd


___
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] Book for 2.8 ?

[Bill Hoffman]

Pau Garcia i Quiles wrote:

Hello,

Any plans to publish a new edition of the book for CMake, CTest,
CPack, etc 2.8 ?


Yes, we are working on a new edition.

-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

[CMake] Book for 2.8 ?

[Pau Garcia i Quiles]

Hello,

Any plans to publish a new edition of the book for CMake, CTest,
CPack, etc 2.8 ?

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
___
Powered by www.kitware.com

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

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

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

Re: [CMake] Overloading the install make rule

[Dixon, Shane]

Eric, 

That might work.  The catch is that the difference isn't in the executable, but 
in the .dll that gets installed with it.  I have a cryptoki-hw.dll and a 
cryptoki-sw.dll.  Since Windows doesn't allow me to use RPATH at all, at 
runtime it runs whatever .dll is sitting in the same folder as the .exe.  I 
might be able to do as you suggest and move the two .exe's into two different 
folders to keep the .dll's separate.

--
Shane Dixon
Linux Engineer
Atmel Corporation 


-Original Message-
From: Eric Noulard [mailto:eric.noul...@gmail.com] 
Sent: Friday, October 09, 2009 12:51 AM
To: Dixon, Shane
Cc: cmake@cmake.org
Subject: Re: [CMake] Overloading the install make rule

2009/10/8 Dixon, Shane :
> I have two different version of my program: one that runs in simulation mode, 
> and the other that runs in "real" mode.  Right now I just select which I want 
> using an option -DEMULATION_MODE=ON or -DEMULATION_MODE=OFF.  The flag is 
> checked later and generates an installer (NSIS) that has -emul or -real at 
> the end so I know which I'm installing.
>
> My question is whether I can overload the install target to "install/real" 
> and "install/emul" with "install" just pointing to emul as a safe default.
>
> Additionally I'd like to be able to setup NSIS so that when I install, I can 
> select which version is installed at runtime there.
>
> Is all or any of this possible?

May be you can just generate 2 differents executables from the same source:
 yourprog-emul
 yourprog-real

This can be done easily using something like:

add_executable(yourprog-emul ${SOURCE})
target_link_libraries(yourprog-emul ${LIBS}) 
set_target_properties(yourprog-emul PROPERTIES COMPILE_FLAGS
"-DEMULATION_MODE=ON")


add_executable(yourprog-real ${SOURCE})
target_link_libraries(yourprog-real ${LIBS}) 
set_target_properties(yourprog-real PROPERTIES COMPILE_FLAGS
"-DEMULATION_MODE=OFF")

then you install both target using COMPONENT install(target yourprog-real 
DESTINATION 
 COMPONENT  RealMode)

install(target yourprog-emul DESTINATION 
 COMPONENT  EmulMode)

Since you are using NSIS, you should be able to select component from the NSIS 
installer at install time, see:
http://www.itk.org/Wiki/CMake:Component_Install_With_CPack

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

[CMake] Added Recipes section to Cmake Wiki

[Dixon, Shane]

I have a blog on linux.com where I was adding CMake recipes so that I could 
have a catalog of CMake recipes to refer back to when doing later projects.  I 
figured that this is something probably best kept in the wiki, so I added a 
"Recipes" section to the main CMake wiki:

http://www.cmake.org/Wiki/CMake#Recipes

I just did a straight copy and paste from my blog.  I'll probably flesh these 
out a little more later, but if anyone has a recipe they want to share, please 
add it.

--
Shane
Linux Engineer
Atmel Corporation
___
Powered by www.kitware.com

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

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

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

Re: [CMake] Why FindBoost messaging not unified?

[Philip Lowman]

On Fri, Oct 9, 2009 at 6:05 AM, Fabio Fracassi wrote:

> Philip Lowman schrieb:
>
>> If you have any other CMake related suggestions please feel free to
>> accompany your mailing list posts with a feature request and/or patch on the
>> bugtracker if you have the time.
>>
>>
>> http://public.kitware.com/cgi-bin/viewcvs.cgi/Modules/FindBoost.cmake?root=CMake&view=log<
>> http://public.kitware.com/cgi-bin/viewcvs.cgi/Modules/FindBoost.cmake?root=CMake&view=log
>> >
>>
>>  I have always wondered why FindBoost doesn't add some speculative future
> Versions into _Boost_KNOWN_VERSIONS so that at least the Boost versions that
> are likely to appear during the lifecycle of the current CMake version are
> found without resorting to user supplied Boost_ADDITIONAL_VERSIONS. There is
> no harm in searching for versions that are never going to be released
> (except maybe longer search time), is there?
>
> I was thinking of something along the lines of the attached patch.
> Or is this a horrible idea?
>

The whole Boost_ADDITIONAL_VERSIONS thing is a kludge and I think a better
solution is needed which is why I have refrained from kludging it even more
by guessing at future version numbers.  I'm not sure if this was the
original approach of the writers of FindBoost or if they had something else
in mind, however.

There's nothing preventing you from doing this yourself using
Boost_ADDITIONAL_VERSIONS though. You might even be able to come up with a
way to do it using the MATH() command and a for-loop.  I'm not sure how many
versions you would have to add before noticing a slowdown.  Probably quite a
bit.

What's really needed is find_path/find_library/etc. searches with versioned
filename support.  This could solve problems in many find modules where
libraries (or directories in the case of Boost) contain version numbers.  At
one point I was working on a patch for this and would like to get back to it
one day when I have more time (unless someone else feels like tackling the
problem sooner).

http://public.kitware.com/Bug/view.php?id=8396

-- 
Philip Lowman
___
Powered by www.kitware.com

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

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

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

Re: [CMake] How send linker options for STATIC LIBRARY?

[Philip Lowman]

On Fri, Oct 9, 2009 at 4:15 AM, Aleksandr Udovenko wrote:

> On Fri, Oct 9, 2009 at 10:04 AM, Philip Lowman  wrote:
> > On Wed, Oct 7, 2009 at 11:45 AM, Aleksandr Udovenko <
> udovenk...@gmail.com>
> > wrote:
> >>
> >> I try cmake 2.6, 2.8 for microsoft visual studio 2005,2008.
> >> creating library:
> >>
> >> add_library(my_lib STATIC ${CPP_FILES})
> >>
> >> I try send some linker options by set
> >>
> >> set_target_properties(my_lib  PROPERTIES LINK_FLAGS "some_opt")
> >>
> >> or
> >>
> >> set_target_properties(my_lib  PROPERTIES LINK_FLAGS_
> >> "some_opt")
> >>
> >>
> >> it's ignored, as i understand from source code of vc7generator - it
> >> ignored extended and unknown option for static library but it works
> >> for exe and shared.
> >>
> >> How i can send my option to linker for static library?
> >
> > You might be able to use this:
> >
> http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:STATIC_LIBRARY_FLAGS
>
> It is not good for me, i NOT need to set linker options globally, i
> need to set depend on target. STATIC_LIBRARY_FLAGS don't have 
> expansion.
>

STATIC_LIBRARY_FLAGS is a target property and not global in scope.

add_library(foo STATIC foo.cc)
set_target_properties(foo PROPERTIES STATIC_LIBRARY_FLAGS "/myflag")

Could you elaborate on what you mean by " expansion"?

Please reply to the list. Thanks.

-- 
Philip Lowman
___
Powered by www.kitware.com

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

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

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

Re: [CMake] Why FindBoost messaging not unified?

[Michael Jackson]

I'll admit up front that I have NOT tried out the latest CVS Cmake BUT  
something that I sometimes have add into the FindBoost are outputs  
that print all the variant names of the boost library that CMake is  
trying to search for with the BOOST_DEBUG enabled. I think this would  
be useful for when the mailing list has to help debug some one else's  
boost installation (as happens often). Any chance of getting more  
DEBUG messages added into the FindBoost.cmake ?
   Things like where cmake is searching for boost, what library names  
it is using, did it find environment variables. Things like that. Just  
a thought.


Mike Jackson  mike.jack...@bluequartz.net

On Oct 9, 2009, at 1:43 AM, Philip Lowman wrote:

On Tue, Sep 29, 2009 at 6:04 PM, Mateusz Loskot   
wrote:

3. The only way to get error is to explicitly use REQUIRED option

FIND_PACKAGE(Boost 1.36 REQUIRED)

but for FIND_PACKAGE(ZLIB) as explained in point 2. above
it is not necessary to explicitly specify REQUIRED option
and error is printed.

I tested the original version of FindBoost from CMake 2.6 as well as
today version from CVS. No difference regarding this issue.

I used ZLIB as example but most of FindXXX macros work this way,

In my opinion behaviours of FindBoost is inconsistent in comparison
to other standard macros.

Mateusz,

You're right, this is inconsistent.  I've just fixed FindBoost in  
CVS to output the following to STATUS if Boost is not found:


-- Could NOT find Boost

I also added an option which if enabled outputs the more detailed  
error message (outputted in REQUIRED mode) below this line.


If you have any other CMake related suggestions please feel free to  
accompany your mailing list posts with a feature request and/or  
patch on the bugtracker if you have the time.


http://public.kitware.com/cgi-bin/viewcvs.cgi/Modules/FindBoost.cmake?root=CMake&view=log

--
Philip Lowman
___
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] Depending on all and custom targets

[Marcel Loose]

Hi  Jens,

It's not a bug. Quoting from the docs for add_custom_target:

  Dependencies listed with the DEPENDS argument may reference files and
  outputs of custom commands created with ADD_CUSTOM_COMMAND.

The problem is that your target 'extras' doesn't create any files. By
saying "add_custom_target(complete DEPENDS extras)" you're telling CMake
that target 'complete' depends on the _file_ 'extras'.

The correct way to do this is to use add_dependencies:

add_custom_target(complete)
add_dependencies(complete extras)

HTH,
Marcel Loose.


On Fri, 2009-10-09 at 12:47 +0200, jens persson wrote:
> 2009/10/9 Eric Noulard :
> > 2009/10/9 jens persson :
> >> I get the impression that I have two problems: depending on a
> >> custom_target and depending on all.
> >
> > Dependency from builtin target is currently unsupported.
> > see:
> > http://public.kitware.com/Bug/view.php?id=8438
> 
> OK, that settled then, I'll create my on taget my_all or something
> like that then :-)
> 
> >
> > I think dependency from "extras" should work did you try with
> > only "extras" and not "all"?
> 
> Yes I get the following error:
> 
> $ make complete
> [100%] Built target bar
> [100%] Built target extras
> make[3]: *** No rule to make target `extras', needed by
> `CMakeFiles/complete'.  Stop.
> make[2]: *** [CMakeFiles/complete.dir/all] Error 2
> make[1]: *** [CMakeFiles/complete.dir/rule] Error 2
> make: *** [complete] Error 2
> 
> 
> With this CMakeLists.txt file:
> 
> PROJECT (tester)
> CMAKE_MINIMUM_REQUIRED (VERSION 2.6)
> CMAKE_POLICY (VERSION 2.6)
> 
> add_executable(bar
> bar.c
> )
> add_custom_target(extras
> DEPENDS bar
> )
> add_custom_target(complete
> DEPENDS extras
> )
> 
> 
> I've tried to look into the makefiles but could not find the solution.
> 
> I have included the verbose output of make at the end of this mail
> 
> It seems that the file CMakeFiles/complete.dir/build.make references
> the extras target that is defined in CMakeFiles/extras.dir/build.make
> 
> Probably a bug. Will report it later.
> 
> /jp
> 
> 
> $ VERBOSE=1 make complete
> /usr/bin/cmake -H/home/sejenpe/tmp/cmake-tester/complete
> -B/home/sejenpe/tmp/cmake-tester/complete --check-build-system
> CMakeFiles/Makefile.cmake 0
> make -f CMakeFiles/Makefile2 complete
> make[1]: Entering directory `/home/sejenpe/tmp/cmake-tester/complete'
> /usr/bin/cmake -H/home/sejenpe/tmp/cmake-tester/complete
> -B/home/sejenpe/tmp/cmake-tester/complete --check-build-system
> CMakeFiles/Makefile.cmake 0
> /usr/bin/cmake -E cmake_progress_start
> /home/sejenpe/tmp/cmake-tester/complete/CMakeFiles 1
> make -f CMakeFiles/Makefile2 CMakeFiles/complete.dir/all
> make[2]: Entering directory `/home/sejenpe/tmp/cmake-tester/complete'
> make -f CMakeFiles/bar.dir/build.make CMakeFiles/bar.dir/depend
> make[3]: Entering directory `/home/sejenpe/tmp/cmake-tester/complete'
> cd /home/sejenpe/tmp/cmake-tester/complete && /usr/bin/cmake -E
> cmake_depends "Unix Makefiles" /home/sejenpe/tmp/cmake-tester/complete
> /home/sejenpe/tmp/cmake-tester/complete
> /home/sejenpe/tmp/cmake-tester/complete
> /home/sejenpe/tmp/cmake-tester/complete
> /home/sejenpe/tmp/cmake-tester/complete/CMakeFiles/bar.dir/DependInfo.cmake
> --color=
> make[3]: Leaving directory `/home/sejenpe/tmp/cmake-tester/complete'
> make -f CMakeFiles/bar.dir/build.make CMakeFiles/bar.dir/build
> make[3]: Entering directory `/home/sejenpe/tmp/cmake-tester/complete'
> make[3]: Nothing to be done for `CMakeFiles/bar.dir/build'.
> make[3]: Leaving directory `/home/sejenpe/tmp/cmake-tester/complete'
> /usr/bin/cmake -E cmake_progress_report
> /home/sejenpe/tmp/cmake-tester/complete/CMakeFiles  1
> [100%] Built target bar
> make -f CMakeFiles/extras.dir/build.make CMakeFiles/extras.dir/depend
> make[3]: Entering directory `/home/sejenpe/tmp/cmake-tester/complete'
> cd /home/sejenpe/tmp/cmake-tester/complete && /usr/bin/cmake -E
> cmake_depends "Unix Makefiles" /home/sejenpe/tmp/cmake-tester/complete
> /home/sejenpe/tmp/cmake-tester/complete
> /home/sejenpe/tmp/cmake-tester/complete
> /home/sejenpe/tmp/cmake-tester/complete
> /home/sejenpe/tmp/cmake-tester/complete/CMakeFiles/extras.dir/DependInfo.cmake
> --color=
> make[3]: Leaving directory `/home/sejenpe/tmp/cmake-tester/complete'
> make -f CMakeFiles/extras.dir/build.make CMakeFiles/extras.dir/build
> make[3]: Entering directory `/home/sejenpe/tmp/cmake-tester/complete'
> make[3]: Nothing to be done for `CMakeFiles/extras.dir/build'.
> make[3]: Leaving directory `/home/sejenpe/tmp/cmake-tester/complete'
> /usr/bin/cmake -E cmake_progress_report
> /home/sejenpe/tmp/cmake-tester/complete/CMakeFiles
> [100%] Built target extras
> make -f CMakeFiles/complete.dir/build.make CMakeFiles/complete.dir/depend
> make[3]: Entering directory `/home/sejenpe/tmp/cmake-tester/complete'
> cd /home/sejenpe/tmp/cmake-tester/complete && /usr/bin/cmake -E
> cmake_depends "Unix Makefiles" /home/sejenpe/tmp/cmake-tester/complete
> /home/sejenpe/tmp/cmake-tester/com

Re: [CMake] Depending on all and custom targets

[Eric Noulard]

2009/10/9 jens persson :
>>
>> I think dependency from "extras" should work did you try with
>> only "extras" and not "all"?
>
> Yes I get the following error:
>
> $ make complete
> [100%] Built target bar
> [100%] Built target extras
> make[3]: *** No rule to make target `extras', needed by
> `CMakeFiles/complete'.  Stop.
> make[2]: *** [CMakeFiles/complete.dir/all] Error 2
> make[1]: *** [CMakeFiles/complete.dir/rule] Error 2
> make: *** [complete] Error 2
>
>
> With this CMakeLists.txt file:
>
> PROJECT (tester)
> CMAKE_MINIMUM_REQUIRED (VERSION 2.6)
> CMAKE_POLICY (VERSION 2.6)
>
> add_executable(bar
>        bar.c
> )
> add_custom_target(extras
>        DEPENDS bar
> )
> add_custom_target(complete
>        DEPENDS extras
> )
>
>
> I've tried to look into the makefiles but could not find the solution.

Better look in to the documentation first :-)
From
cmake --help-command add_custom_target

"Dependencies listed with the DEPENDS argument may reference files and
outputs of custom commands created with ADD_CUSTOM_COMMAND."

the DEPENDS argument of ADD_CUSTOM_TARGET is here to cope
with the fact that CMake cannot compute dependency precisely because
it's a CUSTOM target whose input is unknown to CMake.

thus you cannot use that to specify top-level target dependencies.
You should use add_dependencies for that.

Working CMakeLists.txt should looks like:

PROJECT (tester)
CMAKE_MINIMUM_REQUIRED (VERSION 2.6)
CMAKE_POLICY (VERSION 2.6)

add_executable(bar
   bar.c
)
add_custom_target(extras)
add_dependencies(extras bar)
add_custom_target(complete)
add_dependencies(complete extras)

> Probably a bug. Will report it later.

Finally I don't think this is a bug.

-- 
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] Depending on all and custom targets

[jens persson]

2009/10/9 Eric Noulard :
> 2009/10/9 jens persson :
>> I get the impression that I have two problems: depending on a
>> custom_target and depending on all.
>
> Dependency from builtin target is currently unsupported.
> see:
> http://public.kitware.com/Bug/view.php?id=8438

OK, that settled then, I'll create my on taget my_all or something
like that then :-)

>
> I think dependency from "extras" should work did you try with
> only "extras" and not "all"?

Yes I get the following error:

$ make complete
[100%] Built target bar
[100%] Built target extras
make[3]: *** No rule to make target `extras', needed by
`CMakeFiles/complete'.  Stop.
make[2]: *** [CMakeFiles/complete.dir/all] Error 2
make[1]: *** [CMakeFiles/complete.dir/rule] Error 2
make: *** [complete] Error 2


With this CMakeLists.txt file:

PROJECT (tester)
CMAKE_MINIMUM_REQUIRED (VERSION 2.6)
CMAKE_POLICY (VERSION 2.6)

add_executable(bar
bar.c
)
add_custom_target(extras
DEPENDS bar
)
add_custom_target(complete
DEPENDS extras
)


I've tried to look into the makefiles but could not find the solution.

I have included the verbose output of make at the end of this mail

It seems that the file CMakeFiles/complete.dir/build.make references
the extras target that is defined in CMakeFiles/extras.dir/build.make

Probably a bug. Will report it later.

/jp


$ VERBOSE=1 make complete
/usr/bin/cmake -H/home/sejenpe/tmp/cmake-tester/complete
-B/home/sejenpe/tmp/cmake-tester/complete --check-build-system
CMakeFiles/Makefile.cmake 0
make -f CMakeFiles/Makefile2 complete
make[1]: Entering directory `/home/sejenpe/tmp/cmake-tester/complete'
/usr/bin/cmake -H/home/sejenpe/tmp/cmake-tester/complete
-B/home/sejenpe/tmp/cmake-tester/complete --check-build-system
CMakeFiles/Makefile.cmake 0
/usr/bin/cmake -E cmake_progress_start
/home/sejenpe/tmp/cmake-tester/complete/CMakeFiles 1
make -f CMakeFiles/Makefile2 CMakeFiles/complete.dir/all
make[2]: Entering directory `/home/sejenpe/tmp/cmake-tester/complete'
make -f CMakeFiles/bar.dir/build.make CMakeFiles/bar.dir/depend
make[3]: Entering directory `/home/sejenpe/tmp/cmake-tester/complete'
cd /home/sejenpe/tmp/cmake-tester/complete && /usr/bin/cmake -E
cmake_depends "Unix Makefiles" /home/sejenpe/tmp/cmake-tester/complete
/home/sejenpe/tmp/cmake-tester/complete
/home/sejenpe/tmp/cmake-tester/complete
/home/sejenpe/tmp/cmake-tester/complete
/home/sejenpe/tmp/cmake-tester/complete/CMakeFiles/bar.dir/DependInfo.cmake
--color=
make[3]: Leaving directory `/home/sejenpe/tmp/cmake-tester/complete'
make -f CMakeFiles/bar.dir/build.make CMakeFiles/bar.dir/build
make[3]: Entering directory `/home/sejenpe/tmp/cmake-tester/complete'
make[3]: Nothing to be done for `CMakeFiles/bar.dir/build'.
make[3]: Leaving directory `/home/sejenpe/tmp/cmake-tester/complete'
/usr/bin/cmake -E cmake_progress_report
/home/sejenpe/tmp/cmake-tester/complete/CMakeFiles  1
[100%] Built target bar
make -f CMakeFiles/extras.dir/build.make CMakeFiles/extras.dir/depend
make[3]: Entering directory `/home/sejenpe/tmp/cmake-tester/complete'
cd /home/sejenpe/tmp/cmake-tester/complete && /usr/bin/cmake -E
cmake_depends "Unix Makefiles" /home/sejenpe/tmp/cmake-tester/complete
/home/sejenpe/tmp/cmake-tester/complete
/home/sejenpe/tmp/cmake-tester/complete
/home/sejenpe/tmp/cmake-tester/complete
/home/sejenpe/tmp/cmake-tester/complete/CMakeFiles/extras.dir/DependInfo.cmake
--color=
make[3]: Leaving directory `/home/sejenpe/tmp/cmake-tester/complete'
make -f CMakeFiles/extras.dir/build.make CMakeFiles/extras.dir/build
make[3]: Entering directory `/home/sejenpe/tmp/cmake-tester/complete'
make[3]: Nothing to be done for `CMakeFiles/extras.dir/build'.
make[3]: Leaving directory `/home/sejenpe/tmp/cmake-tester/complete'
/usr/bin/cmake -E cmake_progress_report
/home/sejenpe/tmp/cmake-tester/complete/CMakeFiles
[100%] Built target extras
make -f CMakeFiles/complete.dir/build.make CMakeFiles/complete.dir/depend
make[3]: Entering directory `/home/sejenpe/tmp/cmake-tester/complete'
cd /home/sejenpe/tmp/cmake-tester/complete && /usr/bin/cmake -E
cmake_depends "Unix Makefiles" /home/sejenpe/tmp/cmake-tester/complete
/home/sejenpe/tmp/cmake-tester/complete
/home/sejenpe/tmp/cmake-tester/complete
/home/sejenpe/tmp/cmake-tester/complete
/home/sejenpe/tmp/cmake-tester/complete/CMakeFiles/complete.dir/DependInfo.cmake
--color=
make[3]: Leaving directory `/home/sejenpe/tmp/cmake-tester/complete'
make -f CMakeFiles/complete.dir/build.make CMakeFiles/complete.dir/build
make[3]: Entering directory `/home/sejenpe/tmp/cmake-tester/complete'
make[3]: *** No rule to make target `extras', needed by
`CMakeFiles/complete'.  Stop.
make[3]: Leaving directory `/home/sejenpe/tmp/cmake-tester/complete'
make[2]: *** [CMakeFiles/complete.dir/all] Error 2
make[2]: Leaving directory `/home/sejenpe/tmp/cmake-tester/complete'
make[1]: *** [CMakeFiles/complete.dir/rule] Error 2
make[1]: Leaving directory `/home/sejenpe/tmp/cmake-tester/complete'
make: *** [complete] Error 2


-- 
j

Re: [CMake] Depending on all and custom targets

[Eric Noulard]

2009/10/9 jens persson :

> add_custom_target(extras
>        DEPENDS bar
> )
>
> which builds foo when running make all and bar when make extras
>
> I have tried to simply add:
> add_custom_target(complete
>        DEPENDS extras all
> )
>
> which gives the following error:

[...]

> I get the impression that I have two problems: depending on a
> custom_target and depending on all.

Dependency from builtin target is currently unsupported.
see:
http://public.kitware.com/Bug/view.php?id=8438

I think dependency from "extras" should work did you try with
only "extras" and not "all"?

-- 
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] Why FindBoost messaging not unified?

[Fabio Fracassi]

Philip Lowman schrieb:
If you have any other CMake related suggestions please feel free to 
accompany your mailing list posts with a feature request and/or patch 
on the bugtracker if you have the time.


http://public.kitware.com/cgi-bin/viewcvs.cgi/Modules/FindBoost.cmake?root=CMake&view=log 



I have always wondered why FindBoost doesn't add some speculative future 
Versions into _Boost_KNOWN_VERSIONS so that at least the Boost versions 
that are likely to appear during the lifecycle of the current CMake 
version are found without resorting to user supplied 
Boost_ADDITIONAL_VERSIONS. There is no harm in searching for versions 
that are never going to be released (except maybe longer search time), 
is there?


I was thinking of something along the lines of the attached patch.
Or is this a horrible idea?

regards

Fabio

--- a/FindBoost.cmake
+++ b/FindBoost.cmake
@@ -285,10 +285,21 @@ if(Boost_FIND_VERSION_EXACT)
else(Boost_FIND_VERSION_EXACT)
  # The user has not requested an exact version.  Among known
  # versions, find those that are acceptable to the user request.
+ 
+  # To make this a bit more "furure-proof" we speculate a bit on

+  # what versions of boost might be released in the future
+  # Of course these versions should be moved to _Boost_KNOWN_VERSIONS
+  # proper once they are released, or pruned when it is clear that they
+  # are not going to come out.
+  set(_Boost_FUTURE_VERSIONS
+"1.40.1" "1.41.0" "1.41" "1.41.1" "1.42.0" "1.42" "1.42.1"
+"1.43.0" "1.43" "1.43.1" "1.44.0" "1.44" "1.44.1")
+
  set(_Boost_KNOWN_VERSIONS ${Boost_ADDITIONAL_VERSIONS}
"1.40.0" "1.40" "1.39.0" "1.39" "1.38.0" "1.38" "1.37.0" "1.37"
"1.36.1" "1.36.0" "1.36" "1.35.1" "1.35.0" "1.35" "1.34.1" "1.34.0"
-"1.34" "1.33.1" "1.33.0" "1.33")
+"1.34" "1.33.1" "1.33.0" "1.33"
+${_Boost_FUTURE_VERSIONS})
  set(_boost_TEST_VERSIONS)
  if(Boost_FIND_VERSION)
set(_Boost_FIND_VERSION_SHORT 
"${Boost_FIND_VERSION_MAJOR}.${Boost_FIND_VERSION_MINOR}")

--
___
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] Depending on all and custom targets

[jens persson]

Hello again,

I have some targets that are not build by default (using
EXCLUDE_FROM_ALL), these are build when a special target called
extras.

Now I want to add a target that builds both all and extras, but cant
seem to get it to work. For discussion I have these rules:

PROJECT (tester)
CMAKE_MINIMUM_REQUIRED (VERSION 2.6)
CMAKE_POLICY (VERSION 2.6)

add_executable(foo
foo.c
)
add_executable(bar
bar.c
)
set_target_properties(bar
PROPERTIES EXCLUDE_FROM_ALL True
)
add_custom_target(extras
DEPENDS bar
)

which builds foo when running make all and bar when make extras

I have tried to simply add:
add_custom_target(complete
DEPENDS extras all
)

which gives the following error:
$ make complete
[100%] Built target bar
[100%] Built target extras
make[3]: *** No rule to make target `extras', needed by
`CMakeFiles/complete'.  Stop.
make[2]: *** [CMakeFiles/complete.dir/all] Error 2
make[1]: *** [CMakeFiles/complete.dir/rule] Error 2
make: *** [complete] Error 2

When removing extras from the DEPENDS line I get:
$ make complete
make[3]: *** No rule to make target `all', needed by
`CMakeFiles/complete'.  Stop.
make[2]: *** [CMakeFiles/complete.dir/all] Error 2
make[1]: *** [CMakeFiles/complete.dir/rule] Error 2
make: *** [complete] Error 2

I get the impression that I have two problems: depending on a
custom_target and depending on all.

Anyone know of a solution?

I'm running cmake version 2.6-patch 2 with make 3.81on a ubuntu 9.04
box  (all installed from ubuntu standard repositories)

Best regards and happy weekend
/jp
-- 
jens persson

Mäster Olofsväg 24
S-224 66 LUND;SWEDEN
___
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] Adding a buildstep to all targets

[Hendrik Sattler]

Zitat von jens persson :

I'm trying to convert an old home grown buildsystem based on make to
cmake and one of the requisites[1] is that I need to build each
executable in two versions, one with debug symbols and one without. I
have solved it now with a add_custom_command call for every target
like this

[...]

Is there a way to do this that I haven't found yet?


Use the RelWithDebInfo build type and install once using the install  
target and once using the install/strip target. No need to do anything  
in your CMakeLists.txt, then. Maybe the CMAKE_INSTALL_PREFIX (or some  
custom own variable) should differ between both install calls.


HS


___
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] Adding a buildstep to all targets

[jens persson]

Hello,

I'm trying to convert an old home grown buildsystem based on make to
cmake and one of the requisites[1] is that I need to build each
executable in two versions, one with debug symbols and one without. I
have solved it now with a add_custom_command call for every target
like this

add_custom_command(TARGET test
  COMMAND cp ../../bin/test ../../bin/test_debug
  COMMAND strip ../../bin/test
)

but it feels a bit repetitive and it would be nice to do something like

add_custom_command(TARGET *
  COMMAND cp $(CMAKE_TARGET) $CMAKE_TARGET)_debug
  COMMAND strip $(CMAKE_TARGET)
)

Is there a way to do this that I haven't found yet?

Best regards
/jp


[1] don't get me started on why, but it is needed...
-- 
jens persson

Mäster Olofsväg 24
S-224 66 LUND;SWEDEN
___
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 RC2 - Visual Studio 2010 Generator - No header files

[Tim Anil]

Hi,
It seems that the "Visual Studio 2010" generator doesn't include the header
files under the "Header Files" virtual directory in Visual Studio. The
sources files are correctly displayed under "Source Files". The .h files
were listed in the add_libray() or add_executable(). This works well with
the "Visual Studio 2008" generator.
Is it a known limitation of the "Visual Studio 2010" generator ?
Thanks.
___
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