Re: [CMake] Directory creation problem with MACOSX_BUNDLE

Hi Peter, I am working on this, but I would still ask you to put a bug in a CMake bug tracker, just to have a record: http://www.cmake.org/Bug Andy Peter Carr wrote: Hi, I'm running into problems using the MACOSX_BUNDLE parameter with ADD_EXECUTABLE. For some reason, I'm getting the

Re: [CMake] cmake: broke compatibility between 2.2 and 2.4

So, the problem was that some Unix shells were having trouble with long command lines. So, we made it a cmake script to do the linking. I forgot that folks used back tic commands to run pkconfig. However, that is a bad thing to do anywayIt does not work with Xcode projects, it does not

Re: [CMake] INSTALL command doesn't behave as documented

Le Mon, 21 Aug 2006 16:02:41 +0200, Brad King [EMAIL PROTECTED] a écrit: Please submit bug reports here: http://www.cmake.org/Bug Done. see bug 3644. Thomas ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] make clean intermediate files

James Bigler wrote: If I have a rule that generates some intermediate files, how do I add those files to the list that get removed when I do a make clean? I'm assuming you're talking about intermediate files when building a custom command. If they are listed as the OUTPUT of the custom command

[CMake] Re: OpenSceneGraph and CMake

E. Wing wrote: Anyway, I would really like to improve this current Makefile scheme if possible so it is more a one step build without the user having to intervene with setting environment paths or 'installing'. Is that even technically possible in the underlying build dependencies? For

Re: [CMake] Re: OpenSceneGraph and CMake

It is probably possible as long as the directory structure is adhered to.. that is the big thing.. Then we can just build in the paths to the CMake files. Not the best solution, but would work. Mike On 8/21/06, Brandon J. Van Every [EMAIL PROTECTED] wrote: E. Wing wrote: Anyway, I would

[CMake] Re: OpenSceneGraph and CMake

Anyway, I would really like to improve this current Makefile scheme if possible so it is more a one step build without the user having to intervene with setting environment paths or 'installing'. Is that even technically possible in the underlying build dependencies? Yes, I believe this is

[CMake] Re: OpenSceneGraph and CMake

But that's OSG. Says nothing about OpenThreads and Producer. I'm saying, write a CMake script that installs OpenThreads and Producer in a way they're expected to be installed. There's really no value in CMakeifying a build that the library maintainers themselves aren't going to support. All

[CMake] Static and shared libraries with the same name

I am trying to create a static, and a shared library, where both have the same name and both share the same source code. I was recommended previously to use this sort of code: ADD_LIBRARY(foo SHARED ${FOO_SRCS}) ADD_LIBRARY(foos STATIC ${FOO_SRCS}) SET_TARGET_PROPERTIES(foos PROPERTIES

Re: [CMake] Static and shared libraries with the same name

Jorge Rodriguez wrote: That's not right! It should only clean libfoo.a! Looks like I can't accomplish this that way. What else can I do? This is a known bug in CMake 2.4.3. You will need CMake CVS if you want it to go away. If you're stuck with CMake 2.4.3, you can use symlinks or

Re: [CMake] Static and shared libraries with the same name

Brandon J. Van Every wrote: This is a known bug in CMake 2.4.3. You will need CMake CVS if you want it to go away. If you're stuck with CMake 2.4.3, you can use symlinks or straight copies of library stubs as workarounds. Peruse the archives, I've posted examples on what to do. Great!