Re: [CMake] How to make the target_link_libraries link different library in different build type.

2010-05-16 Thread Michael Wild 

On 17. May, 2010, at 4:25 , SONGFY wrote:

>The target_link_libraries has any three tag to distinguish different build 
> type:debug|optimized|general.
>But what I need is to specify different library in different build type, 
> for example I have three custom build type: debug, release, shipping. And I 
> want these configurations link to different version of library for example 
> A_d.lib, A_r,lib and A_s.lib.
>How can I do this?
>Thank you.

Create an IMPORTED target, especially note the target properties 
IMPORTED_CONFIGURATIONS, IMPORTED_LOCATION_ and 
IMPORTED_IMPLIB_. If the configuration names don't match, there's 
MAP_IMPORTED_CONFIG_.

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

[CMake] How to make the target_link_libraries link different library in different build type.

2010-05-16 Thread SONGFY 
The target_link_libraries has any three tag to distinguish different build 
type:debug|optimized|general.
But what I need is to specify different library in different build type, 
for example I have three custom build type: debug, release, shipping. And I 
want these configurations link to different version of library for example 
A_d.lib, A_r,lib and A_s.lib.
How can I do this?
Thank you.___
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] External projects and imported targets

2010-05-16 Thread Timothy M. Shead 
On 05/16/2010 01:01 PM, Marcus D. Hanwell wrote:

> OK, may be others on the list may have other experiences they will
> share. After having spent quite a bit of time working on packaging for a
> Linux distro, and using CMake's external projects I see many parallels.
> 
> The external project allows us to establish inter-package dependencies,
> and from there build order. Traditional targets assume that project is
> building everything, or that it was already built and found. So two
> levels are necessary, and external projects allow us to do cross
> platform packaging for our particular projects.
> 
> I would certainly be interested in what others who have been using
> external project have found, but it seems to me that mixing external
> projects and traditional targets is unlikely to work well, at least with
> what is available to us right now.

I can think of several reasons to use External Projects: to target a
platform that doesn't have package management at all (Windows, OSX), to
target a platform that's missing a required package (Ubuntu doesn't have
package X), or to target a platform where a required package exists, but
isn't configured the way you want (Ubuntu has package X, but it was
built without feature Y that your package requires).  It's interesting
that all of these cases come back to packaging issues, and it's clear
that your packaging analogy provides a good framework for thinking about
how to best use External Projects.  In fact, all of these use cases
involve "usurping" work that would normally be done by distros.
Interesting way of looking at it.

Cheers,
Tim
<>___
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] Unit tests, but not CTest

2010-05-16 Thread Magnus Therning 
On 14/05/10 22:28, Michael Hertling wrote:
> On 05/14/2010 08:24 AM, Magnus Therning wrote:
[...]
>> Thanks for this analysis, it makes the problem a lot clearer to me.  One
>> thing it doesn't clarify is how ADD_CUSTOM_COMMAND( TARGET ... POST_BUILD )
>> could *ever* be useful. [...]
> 
> ADD_CUSTOM_COMMAND(TARGET ...) enhances the commands associated with the
> named target, i.e. you can hook into that target's build process:
> 
> CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
> 
> PROJECT(CUSTOM_COMMAND_DEMO C)
> 
> FILE(WRITE main.c "void main(){}")
> ADD_EXECUTABLE(exe main.c)
> 
> ADD_CUSTOM_COMMAND(TARGET exe PRE_BUILD COMMAND echo "Pre build")
> ADD_CUSTOM_COMMAND(TARGET exe POST_BUILD COMMAND echo "Post build")
> 
> After cmaking, look at the end of CMakeFiles/exe.dir/build.make:
> 
> [...]
> exe: CMakeFiles/exe.dir/main.c.o
> exe: CMakeFiles/exe.dir/build.make
> exe: CMakeFiles/exe.dir/link.txt
> @$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --red
> --bold "Linking C executable exe"
> echo Pre\ build
> $(CMAKE_COMMAND) -E cmake_link_script
> CMakeFiles/exe.dir/link.txt --verbose=$(VERBOSE)
> echo Post\ build
> [...]
> 
> Thus, ADD_CUSTOM_COMMAND(TARGET ...) doesn't modify the dependencies of the
> named target but the associated commands. So, it provides a general
> possibility to have arbitrary commands run when a target is (re)built.

Ah, sorry, I managed to use the wrong word, "useful" when I really should have
written "used".  I can see its usefulness, indeed I *wanted* to use it myself.
However, earlier in this thread it became apparent that
add_custom_command( OUTPUT foo ... ) can't be used together with
add_custom_command( TARGET foo POST_BUILD ... ); the latter would *never* be
executed.  It was also apparent that add_custom_target( foo ... ) can't be
used with add_custom_command( TARGET foo POST_BUILD ...); the latter would
then *always* be executed.

Now you say that if I use add_executable( foo ... ) then I can use
add_custom_command( TARGET foo POST_BUILD ... ).  So, what does
add_executable( ... ) do?

I was under the impression that add_executable( ... ) deep down wasn't much
more than a wrapper around add_custom_command( OUTPUT ... ) (since that is the
only way I know to get anything built through the CMake scripts).  However now
you've made me think that add_executable( ... ) is a bit magical.  If that's
the case, then how does one go about adding full support for a language (i.e.
so that add_executable( ... ) can be used for that language) using nothing but
CMake scripts?

>> [...] I'm still to see an example of any buildable target that
>> such a post-build command can be connected to and only triggered on 
>> (re)build.
> 
> Imagine your add_ocaml_executable() using ADD_EXECUTABLE() instead of
> ADD_CUSTOM_COMMAND(OUTPUT ...); in this case, you would have a, say,
> fully-fledged CMake target which additional commands can be attached to by
> ADD_CUSTOM_COMMAND(TARGET ...), and indeed, that is a suitable place for
> your automated unit testing. Obviously, CMake's file-level targets defined
> by ADD_CUSTOM_COMMAND(OUTPUT ...) are not sufficient for this purpose
> although they appear as usual Make targets if others depend on them, but so,
> you've to specify the desired commands right in the
> ADD_CUSTOM_COMMAND(OUTPUT ...). Perhaps, this would be worth a feature
> request.

This seems to support my line of reasoning above, i.e. that adding full
language support for new language (i.e. making it possible to use
add_executable( ... ) on OCaml sources) isn't possible using CMake scripts
alone.  Is that correct?

/M

-- 
Magnus Therning(OpenPGP: 0xAB4DFBA4)
magnus＠therning．org  Jabber: magnus＠therning．org
http://therning.org/magnus identi.ca|twitter: magthe



signature.asc
Description: OpenPGP digital signature
___
Powered by www.kitware.com

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

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

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

Re: [CMake] External projects and imported targets

2010-05-16 Thread Marcus D. Hanwell 
On Sun, May 16, 2010 at 2:47 PM, Timothy M. Shead  wrote:

> On 05/16/2010 12:36 PM, Marcus D. Hanwell wrote:
> > On Sun, May 16, 2010 at 2:26 PM, Timothy M. Shead  > > wrote:
> >
> > On 05/16/2010 12:11 PM, Marcus D. Hanwell wrote:
> > > On Sun, May 16, 2010 at 12:48 PM, Timothy M. Shead
> > mailto:tsh...@k-3d.com>
> > > >> wrote:
> > >
> > > I'd like to do the following:
> > >
> > >  # Build external project A
> > >  ExternalProject_Add(A ...)
> > >
> > >  # Import target B, which is exported by A in AConfig.cmake
> > >  ExternalProject_Get_Property(A, BINARY_DIR)
> > >  set(A_DIR ${BINARY_DIR})
> > >  find_package(A)
> > >
> > >  # Link with B
> > >  add_library(C ...)
> > >  target_link_libraries(C B)
> > >
> > > Of course, this doesn't work because the external project
> > hasn't been
> > > built yet at configure-time, so AConfig.cmake doesn't exist.
> >  Which
> > > leads me to the following:
> > >
> > > Hi,
> > >
> > > If I understand your question correctly, then adding DEPENDS A to
> your
> > > ExternalProject_Add(B...) call will ensure that A has been built
> > when B
> > > is configured, thus satisfying your need to find A's exported
> targets.
> > > Using the dependencies between external projects it is possible to
> > > control the build order, so that A's config file will be present
> > before
> > > B attempts a configure step.
> >
> > That wasn't quite what I was describing - "B" isn't another external
> > project, it's a library that's built by external project "A".
>  Because A
> > hasn't been built (isn't even downloaded yet) at configure time, I
> can't
> > use find_package to benefit from A's internal understanding of where
> > its' outputs are located.  Basically, I want the simplest possible
> > add_library(... IMPORTED) call possible, one that doesn't end-up
> > duplicating all of the platform-specific logic that CMake normally
> takes
> > care of.  Since my last post, I've switched to the following, which
> > works on Linux and seems like it could work on Windows:
> >
> >  ADD_LIBRARY(B SHARED IMPORTED)
> >  SET_TARGET_PROPERTIES(B PROPERTIES
> >IMPORTED_LOCATION
> > "${BINARY_DIR}/path/to/libB${CMAKE_SHARED_LIBRARY_SUFFIX}"
> >   IMPORTED_IMPLIB "${BINARY_DIR}/path/to/libB.lib"
> >  )
> >
> >
> > Ah, I understand now. This is one of the major reasons to avoid mixing
> > external projects and traditional targets in the same build. I would
> > solve that by adding another external project in the build, that would
> > depend on A, and so A would be there at configure time and no guessing
> > would be necessary.
> >
> > Is there any particular reason why you cannot use that pattern in your
> > case? Otherwise you can quickly end up writing a lot of code to predict
> > where things will be, and that could be quite a fragile approach if the
> > targets changed in a new release.
>
> It's not impossible, but I had hoped to avoid the extra level of
> indirection.  I'm really just feeling-out the pros-and-cons of various
> approaches.
>
> OK, may be others on the list may have other experiences they will share.
After having spent quite a bit of time working on packaging for a Linux
distro, and using CMake's external projects I see many parallels.

The external project allows us to establish inter-package dependencies, and
from there build order. Traditional targets assume that project is building
everything, or that it was already built and found. So two levels are
necessary, and external projects allow us to do cross platform packaging for
our particular projects.

I would certainly be interested in what others who have been using external
project have found, but it seems to me that mixing external projects and
traditional targets is unlikely to work well, at least with what is
available to us right now.

Thanks,

Marcus
___
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] External projects and imported targets

2010-05-16 Thread Timothy M. Shead 
On 05/16/2010 12:36 PM, Marcus D. Hanwell wrote:
> On Sun, May 16, 2010 at 2:26 PM, Timothy M. Shead  > wrote:
> 
> On 05/16/2010 12:11 PM, Marcus D. Hanwell wrote:
> > On Sun, May 16, 2010 at 12:48 PM, Timothy M. Shead
> mailto:tsh...@k-3d.com>
> > >> wrote:
> >
> > I'd like to do the following:
> >
> >  # Build external project A
> >  ExternalProject_Add(A ...)
> >
> >  # Import target B, which is exported by A in AConfig.cmake
> >  ExternalProject_Get_Property(A, BINARY_DIR)
> >  set(A_DIR ${BINARY_DIR})
> >  find_package(A)
> >
> >  # Link with B
> >  add_library(C ...)
> >  target_link_libraries(C B)
> >
> > Of course, this doesn't work because the external project
> hasn't been
> > built yet at configure-time, so AConfig.cmake doesn't exist.
>  Which
> > leads me to the following:
> >
> > Hi,
> >
> > If I understand your question correctly, then adding DEPENDS A to your
> > ExternalProject_Add(B...) call will ensure that A has been built
> when B
> > is configured, thus satisfying your need to find A's exported targets.
> > Using the dependencies between external projects it is possible to
> > control the build order, so that A's config file will be present
> before
> > B attempts a configure step.
> 
> That wasn't quite what I was describing - "B" isn't another external
> project, it's a library that's built by external project "A".  Because A
> hasn't been built (isn't even downloaded yet) at configure time, I can't
> use find_package to benefit from A's internal understanding of where
> its' outputs are located.  Basically, I want the simplest possible
> add_library(... IMPORTED) call possible, one that doesn't end-up
> duplicating all of the platform-specific logic that CMake normally takes
> care of.  Since my last post, I've switched to the following, which
> works on Linux and seems like it could work on Windows:
> 
>  ADD_LIBRARY(B SHARED IMPORTED)
>  SET_TARGET_PROPERTIES(B PROPERTIES
>IMPORTED_LOCATION
> "${BINARY_DIR}/path/to/libB${CMAKE_SHARED_LIBRARY_SUFFIX}"
>   IMPORTED_IMPLIB "${BINARY_DIR}/path/to/libB.lib"
>  )
> 
> 
> Ah, I understand now. This is one of the major reasons to avoid mixing
> external projects and traditional targets in the same build. I would
> solve that by adding another external project in the build, that would
> depend on A, and so A would be there at configure time and no guessing
> would be necessary.
> 
> Is there any particular reason why you cannot use that pattern in your
> case? Otherwise you can quickly end up writing a lot of code to predict
> where things will be, and that could be quite a fragile approach if the
> targets changed in a new release.

It's not impossible, but I had hoped to avoid the extra level of
indirection.  I'm really just feeling-out the pros-and-cons of various
approaches.

Cheers,
Tim
<>___
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] External projects and imported targets

2010-05-16 Thread Marcus D. Hanwell 
On Sun, May 16, 2010 at 2:26 PM, Timothy M. Shead  wrote:

> On 05/16/2010 12:11 PM, Marcus D. Hanwell wrote:
> > On Sun, May 16, 2010 at 12:48 PM, Timothy M. Shead  > > wrote:
> >
> > I'd like to do the following:
> >
> >  # Build external project A
> >  ExternalProject_Add(A ...)
> >
> >  # Import target B, which is exported by A in AConfig.cmake
> >  ExternalProject_Get_Property(A, BINARY_DIR)
> >  set(A_DIR ${BINARY_DIR})
> >  find_package(A)
> >
> >  # Link with B
> >  add_library(C ...)
> >  target_link_libraries(C B)
> >
> > Of course, this doesn't work because the external project hasn't been
> > built yet at configure-time, so AConfig.cmake doesn't exist.  Which
> > leads me to the following:
> >
> > Hi,
> >
> > If I understand your question correctly, then adding DEPENDS A to your
> > ExternalProject_Add(B...) call will ensure that A has been built when B
> > is configured, thus satisfying your need to find A's exported targets.
> > Using the dependencies between external projects it is possible to
> > control the build order, so that A's config file will be present before
> > B attempts a configure step.
>
> That wasn't quite what I was describing - "B" isn't another external
> project, it's a library that's built by external project "A".  Because A
> hasn't been built (isn't even downloaded yet) at configure time, I can't
> use find_package to benefit from A's internal understanding of where
> its' outputs are located.  Basically, I want the simplest possible
> add_library(... IMPORTED) call possible, one that doesn't end-up
> duplicating all of the platform-specific logic that CMake normally takes
> care of.  Since my last post, I've switched to the following, which
> works on Linux and seems like it could work on Windows:
>
>  ADD_LIBRARY(B SHARED IMPORTED)
>  SET_TARGET_PROPERTIES(B PROPERTIES
>IMPORTED_LOCATION
> "${BINARY_DIR}/path/to/libB${CMAKE_SHARED_LIBRARY_SUFFIX}"
>   IMPORTED_IMPLIB "${BINARY_DIR}/path/to/libB.lib"
>  )
>

Ah, I understand now. This is one of the major reasons to avoid mixing
external projects and traditional targets in the same build. I would solve
that by adding another external project in the build, that would depend on
A, and so A would be there at configure time and no guessing would be
necessary.

Is there any particular reason why you cannot use that pattern in your case?
Otherwise you can quickly end up writing a lot of code to predict where
things will be, and that could be quite a fragile approach if the targets
changed in a new release.

Marcus
___
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] External projects and imported targets

2010-05-16 Thread Timothy M. Shead 
On 05/16/2010 12:11 PM, Marcus D. Hanwell wrote:
> On Sun, May 16, 2010 at 12:48 PM, Timothy M. Shead  > wrote:
> 
> I'd like to do the following:
> 
>  # Build external project A
>  ExternalProject_Add(A ...)
> 
>  # Import target B, which is exported by A in AConfig.cmake
>  ExternalProject_Get_Property(A, BINARY_DIR)
>  set(A_DIR ${BINARY_DIR})
>  find_package(A)
> 
>  # Link with B
>  add_library(C ...)
>  target_link_libraries(C B)
> 
> Of course, this doesn't work because the external project hasn't been
> built yet at configure-time, so AConfig.cmake doesn't exist.  Which
> leads me to the following:
> 
> Hi,
> 
> If I understand your question correctly, then adding DEPENDS A to your
> ExternalProject_Add(B...) call will ensure that A has been built when B
> is configured, thus satisfying your need to find A's exported targets.
> Using the dependencies between external projects it is possible to
> control the build order, so that A's config file will be present before
> B attempts a configure step.

That wasn't quite what I was describing - "B" isn't another external
project, it's a library that's built by external project "A".  Because A
hasn't been built (isn't even downloaded yet) at configure time, I can't
use find_package to benefit from A's internal understanding of where
its' outputs are located.  Basically, I want the simplest possible
add_library(... IMPORTED) call possible, one that doesn't end-up
duplicating all of the platform-specific logic that CMake normally takes
care of.  Since my last post, I've switched to the following, which
works on Linux and seems like it could work on Windows:

  ADD_LIBRARY(B SHARED IMPORTED)
  SET_TARGET_PROPERTIES(B PROPERTIES
IMPORTED_LOCATION
"${BINARY_DIR}/path/to/libB${CMAKE_SHARED_LIBRARY_SUFFIX}"
   IMPORTED_IMPLIB "${BINARY_DIR}/path/to/libB.lib"
  )

Cheers,
Tim
<>___
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] External projects and imported targets

2010-05-16 Thread Marcus D. Hanwell 
On Sun, May 16, 2010 at 12:48 PM, Timothy M. Shead  wrote:

> I'd like to do the following:
>
>  # Build external project A
>  ExternalProject_Add(A ...)
>
>  # Import target B, which is exported by A in AConfig.cmake
>  ExternalProject_Get_Property(A, BINARY_DIR)
>  set(A_DIR ${BINARY_DIR})
>  find_package(A)
>
>  # Link with B
>  add_library(C ...)
>  target_link_libraries(C B)
>
> Of course, this doesn't work because the external project hasn't been
> built yet at configure-time, so AConfig.cmake doesn't exist.  Which
> leads me to the following:
>
> Hi,

If I understand your question correctly, then adding DEPENDS A to your
ExternalProject_Add(B...) call will ensure that A has been built when B is
configured, thus satisfying your need to find A's exported targets. Using
the dependencies between external projects it is possible to control the
build order, so that A's config file will be present before B attempts a
configure step.

Hope that helps, I will take a look at this case in a moment and do some
test builds.

Thanks,

Marcus
___
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] External projects and imported targets

2010-05-16 Thread Timothy M. Shead 
I'd like to do the following:

  # Build external project A
  ExternalProject_Add(A ...)

  # Import target B, which is exported by A in AConfig.cmake
  ExternalProject_Get_Property(A, BINARY_DIR)
  set(A_DIR ${BINARY_DIR})
  find_package(A)

  # Link with B
  add_library(C ...)
  target_link_libraries(C B)

Of course, this doesn't work because the external project hasn't been
built yet at configure-time, so AConfig.cmake doesn't exist.  Which
leads me to the following:

  # Build external project A
  ExternalProject_Add(A ...)

  # Setup target B, which will be build as part of A
  add_library(B SHARED IMPORTED)
  set_target_properties(B PROPERTIES
IMPORTED_LOCATION "${BINARY_DIR}/path/to/B.so.x.y"
IMPORTED_SONAME "B.so.x"
)

  # Link with B
  add_library(C ...)
  target_link_libraries(C B)

which is dissatisfying, since it means I have to get intimate with the
way project A's libraries are named, whether they're .dlls, .sos,
.dylibs, etc.

I'm wondering if there are any suggestions or best practices on how to
simplify this.

Cheers,
Tim
<>___
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