On Wed, Jun 17, 2009 at 11:39:00AM -0400, Brad King wrote:
> previous post we didn't think any real project could be using the
> behavior and thought this change was just a bug fix to help new
> projects avoid subtle problems. That's why we didn't bother with
> a policy.
I guess I should have stu
Tyler Roscoe wrote:
Even if it were a policy, any project that tries to do this would get
the warning. Yes, it could temporarily avoid the warning by setting
the policy to OLD, but it should *still* be updated to the NEW
behavior! Again, policies are not used for choosing among desirable
behavi
On Tue, Jun 16, 2009 at 05:54:01PM -0600, Clinton Stimpson wrote:
> your existing CMake files by relying on CMAKE_HOME_DIRECTORY or
> something like that.
>
> So for lib1/lib2
> if(NOT CMAKE_HOME_DIRECTORY MATCHES "${CMAKE_CURRENT_SOURCE_DIR}")
> add_subdirectory(../commonlib commonlib)
> endif(
On Wed, Jun 17, 2009 at 09:07:19AM -0400, Brad King wrote:
> # Top/CMakeLists.txt
> add_subdirectory(A)
> add_subdirectory(B)
>
> # A/CMakeLists.txt
> set(foo 1)
> add_subdirectory(../C ../C)
>
> # B/CMakeLists.txt
> set(foo 0)
> add_subdirectory(../C ../C)
>
> # C/CMakeLists
> Cc: Tyler Roscoe; David Cole; Bill Hoffman; cmake@cmake.org
> Betreff: Re: [CMake] Avoiding error when using add_subdirectory twice on same
> path (CMake 2.6.4)
>
> [approach using package meta-data files to control build]
> > This approach minimizes the orchestrating effort and al
[approach using package meta-data files to control build]
> This approach minimizes the orchestrating effort and allows
> developers to work on their part of an package without worrying
> about unrelated projects.
Take a look at this thread:
http://www.cmake.org/pipermail/cmake/2009-May/029239
--
> -Ursprüngliche Nachricht-
> Von: Tyler Roscoe [mailto:ty...@cryptio.net]
> Gesendet: Mittwoch, 17. Juni 2009 01:06
> An: David Cole
> Cc: Bill Hoffman; Brad King; Floca Ralf Omar; cmake@cmake.org
> Betreff: Re: [
Tyler Roscoe wrote:
On Tue, Jun 16, 2009 at 07:19:52PM -0400, Michael Jackson wrote:
myApp:
project(myApp)
add_subdirectory(commonLib)
add_subdirectory(lib1)
add_subdirectory(lib2)
add_executable(myApp ${files})
target_link_libraries(myApp lib1 lib2)
lib1/lib2:
project(lib1)
add_librar
On Tue, Jun 16, 2009 at 07:19:52PM -0400, Michael Jackson wrote:
> myApp:
>
> project(myApp)
>
> add_subdirectory(commonLib)
> add_subdirectory(lib1)
> add_subdirectory(lib2)
>
> add_executable(myApp ${files})
> target_link_libraries(myApp lib1 lib2)
>
>
> lib1/lib2:
>
> project(lib1)
>
> ad
myApp:
project(myApp)
add_subdirectory(commonLib)
add_subdirectory(lib1)
add_subdirectory(lib2)
add_executable(myApp ${files})
target_link_libraries(myApp lib1 lib2)
lib1/lib2:
project(lib1)
add_library(lib1 ${files})
target_link_libraries(lib1 commonLib)
I am doing exactly this currently
On Tue, Jun 16, 2009 at 06:49:38PM -0400, David Cole wrote:
> What is your CMake code for this "diamond dependency" case?
The case as layed out is hypothetical, of course, but I'm thinking
something like this:
myApp:
project(myApp)
add_subdirectory(lib1)
add_subdirectory(lib2)
add_executable(m
What is your CMake code for this "diamond dependency" case?
Is there a separate directory for each of the libs involved?
Whichever CMakeLists file glues them all together should be able to
add_subdirectory just once on each of them Why do you need two
add_subdirectory calls for commonLib?
O
On Tue, Jun 16, 2009 at 06:04:17PM -0400, Bill Hoffman wrote:
> This was never expected to work, and CMake creates "bad" makefiles in
> versions of CMake prior to this. Basically, CMake was over-writing the
> makefiles as many times as the directory was there. This causes very
> odd things to
Tyler Roscoe wrote:
On Tue, Jun 16, 2009 at 07:41:20PM +0200, Floca Ralf Omar wrote:
using CMake 2.6.4 to build one of our projects an error occurred due to
the repeated usage of add_subdirectory on the same path.
In former versions of CMake the repeated usage was accepted and worked
fine.
I'
On Tue, Jun 16, 2009 at 07:41:20PM +0200, Floca Ralf Omar wrote:
> using CMake 2.6.4 to build one of our projects an error occurred due to
> the repeated usage of add_subdirectory on the same path.
>
> In former versions of CMake the repeated usage was accepted and worked
> fine.
I'm in the same
Hello,
using CMake 2.6.4 to build one of our projects an error occurred due to
the repeated usage of add_subdirectory on the same path.
In former versions of CMake the repeated usage was accepted and worked
fine.
The referenced project has the following scripting steps:
1. The source tree
16 matches
Mail list logo
