[CMake] MingW Update for resource compilation.

[J Decker]

All of the examples indicating ENABLE_LANGUAGE(RC) have the compiler
set afterwards, and it turns out that the following lines work much
better...

I Added these to WIndows-GNU.cmake

SET(CMAKE_RC_COMPILER "windres")
SET(CMAKE_RC_COMPILE_OBJECT "   -O
coff -o  ")
ENABLE_LANGUAGE(RC)


by specifying -O coff, it outputs .obj format file containing the
resources, and the link works.

only thing that's really wrong with this is that  is the full
set of C definitions, and it may be different with more or less in
reality.
___
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] Watcom Support

[J Decker]

I see the reference to setting verbose there, but I don't know what
else I would edit there. ... enabling the verbosity early doesn't
help.


CMAKE>Linking C shared library sack_bag.dll

/* how do I get this command? what follows is the output from wlink,
but no command line ... same thing when I enable RC compiler, I don't
get to see the command line...*/

Open Watcom Linker Version 1.8
Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
loading object files
searching libraries
creating a Windows NT dynamic link library
CMAKE>[ 89%] Built target sack_bag



On Fri, Mar 5, 2010 at 6:42 PM, Bill Hoffman  wrote:
> J Decker wrote:
>>
>> Also... I don't know if it's an issue with watcom's wmake or cmake,
>> but setting VERBOSE=1 doesn't change anything.  Also if i set(
>> CMAKE_VERBOSE_MAKEFILE  1 ), I get the compile lines, but the link
>> lines, neither the wlink or wlib commands print;  I found the lines by
>> searching through the other files in the cmake build directory and
>> found 'bulid.make' files.
>>
>
> Edit Modules/Platform/Windows.cmake at the bottom of the file to get VERBOSE
> output for linking.
>
>
>> On Fri, Mar 5, 2010 at 3:59 PM, J Decker  wrote:
>>>
>>> On Fri, Mar 5, 2010 at 6:15 AM, Bill Hoffman 
>>> wrote:

 J Decker wrote:
>
> but then, for every project that already exists, it won't build
> correctly using watcom, because the options just aren't set in the
> generator, or 3 more flavors of generators aren't added to support
> static library, executlable and dynamic library with correct compile
> time options.
>
 It should go in Modules/Platform/Windows-wcl386.cmake.

 Just set these:
 CMAKE_EXE_LINKER_FLAGS_DEBUG_INIT
 CMAKE_SHARED_LINKER_FLAGS_INIT
 CMAKE_SHARED_LINKER_FLAGS_DEBUG_INIT

>>> I set
>>>
>>> SET (CMAKE_EXE_LINKER_FLAGS_DEBUG_INIT "debug all" )
>>> SET (CMAKE_SHARED_LINKER_FLAGS_DEBUG_INIT "debug all" )
>>>
>>> SET (CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO_INIT "debug all" )
>>> SET (CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO_INIT "debug all" )
>>>
>>> and made sure to clean my build directory, and re-ran generate with
>>> Watcom WMake  generator.  I would imagine that in
>>> CMakeFiles/project.dir/bulid.make that this line should hvae addtional
>>> options...
>>>
>>>       wlink  system nt_dll   name sack_bag.dll option caseexact  file
>>> {$(sack_bag_OBJECTS) $(sack_bag_EXTERNAL_OBJECTS)} library odbc32.lib
>>> library wsock32.lib library ws2_32.lib library opengl32.lib library
>>> odbc32.lib library winmm.lib library iphlpapi.lib library wsock32.lib
>>> library ws2_32.lib library opengl32.lib library winmm.lib library
>>> iphlpapi.lib library clbrdll.lib library plbrdll.lib  library
>>> kernel32.lib library user32.lib library gdi32.lib library winspool.lib
>>> library comdlg32.lib library advapi32.lib library shell32.lib library
>>> ole32.lib library oleaut32.lib library uuid.lib library odbc32.lib
>>> library odbccp32.lib
>>>
>>>
>>> Only thing I see in the bulid tree that mentions debug all are...
>>>
>>> CMAKE_EXE_LINKER_FLAGS_DEBUG:STRING=debug all
>>> CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO:STRING=debug all
>>> CMAKE_SHARED_LINKER_FLAGS_DEBUG:STRING=debug all
>>> CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO:STRING=debug all
>>>
>>>
>>> And nowhere else.
>>>
 See Windows-cl.cmake for an example, you will also want to set
 RELWITHDEBINFO to have the same flag.  If you can verify this works, I
 will
 merge into git master for CMake.

 -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
>>
>
>
___
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] Watcom Support

[J Decker]

Is there

CMAKE_C_FLAGS_EXE_INIT and CMAKE_C_FLAGS_SHARED_INIT ?

I also just tried exporting the blow mentioned values on 2.8.1-RC4,
with the same result.

(sory to branch conversation to 3 heads)

On Fri, Mar 5, 2010 at 6:15 AM, Bill Hoffman  wrote:
> J Decker wrote:
>>
>> but then, for every project that already exists, it won't build
>> correctly using watcom, because the options just aren't set in the
>> generator, or 3 more flavors of generators aren't added to support
>> static library, executlable and dynamic library with correct compile
>> time options.
>>
>
> It should go in Modules/Platform/Windows-wcl386.cmake.
>
> Just set these:
> CMAKE_EXE_LINKER_FLAGS_DEBUG_INIT
> CMAKE_SHARED_LINKER_FLAGS_INIT
> CMAKE_SHARED_LINKER_FLAGS_DEBUG_INIT
>
>
> See Windows-cl.cmake for an example, you will also want to set
> RELWITHDEBINFO to have the same flag.  If you can verify this works, I will
> merge into git master for CMake.
>
> -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] Watcom Support

[Bill Hoffman]

J Decker wrote:

Also... I don't know if it's an issue with watcom's wmake or cmake,
but setting VERBOSE=1 doesn't change anything.  Also if i set(
CMAKE_VERBOSE_MAKEFILE  1 ), I get the compile lines, but the link
lines, neither the wlink or wlib commands print;  I found the lines by
searching through the other files in the cmake build directory and
found 'bulid.make' files.



Edit Modules/Platform/Windows.cmake at the bottom of the file to get 
VERBOSE output for linking.




On Fri, Mar 5, 2010 at 3:59 PM, J Decker  wrote:

On Fri, Mar 5, 2010 at 6:15 AM, Bill Hoffman  wrote:

J Decker wrote:

but then, for every project that already exists, it won't build
correctly using watcom, because the options just aren't set in the
generator, or 3 more flavors of generators aren't added to support
static library, executlable and dynamic library with correct compile
time options.


It should go in Modules/Platform/Windows-wcl386.cmake.

Just set these:
CMAKE_EXE_LINKER_FLAGS_DEBUG_INIT
CMAKE_SHARED_LINKER_FLAGS_INIT
CMAKE_SHARED_LINKER_FLAGS_DEBUG_INIT


I set

SET (CMAKE_EXE_LINKER_FLAGS_DEBUG_INIT "debug all" )
SET (CMAKE_SHARED_LINKER_FLAGS_DEBUG_INIT "debug all" )

SET (CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO_INIT "debug all" )
SET (CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO_INIT "debug all" )

and made sure to clean my build directory, and re-ran generate with
Watcom WMake  generator.  I would imagine that in
CMakeFiles/project.dir/bulid.make that this line should hvae addtional
options...

   wlink  system nt_dll   name sack_bag.dll option caseexact  file
{$(sack_bag_OBJECTS) $(sack_bag_EXTERNAL_OBJECTS)} library odbc32.lib
library wsock32.lib library ws2_32.lib library opengl32.lib library
odbc32.lib library winmm.lib library iphlpapi.lib library wsock32.lib
library ws2_32.lib library opengl32.lib library winmm.lib library
iphlpapi.lib library clbrdll.lib library plbrdll.lib  library
kernel32.lib library user32.lib library gdi32.lib library winspool.lib
library comdlg32.lib library advapi32.lib library shell32.lib library
ole32.lib library oleaut32.lib library uuid.lib library odbc32.lib
library odbccp32.lib


Only thing I see in the bulid tree that mentions debug all are...

CMAKE_EXE_LINKER_FLAGS_DEBUG:STRING=debug all
CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO:STRING=debug all
CMAKE_SHARED_LINKER_FLAGS_DEBUG:STRING=debug all
CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO:STRING=debug all


And nowhere else.


See Windows-cl.cmake for an example, you will also want to set
RELWITHDEBINFO to have the same flag.  If you can verify this works, I will
merge into git master for CMake.

-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



___
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] Watcom Support

[J Decker]

Also... I don't know if it's an issue with watcom's wmake or cmake,
but setting VERBOSE=1 doesn't change anything.  Also if i set(
CMAKE_VERBOSE_MAKEFILE  1 ), I get the compile lines, but the link
lines, neither the wlink or wlib commands print;  I found the lines by
searching through the other files in the cmake build directory and
found 'bulid.make' files.

On Fri, Mar 5, 2010 at 3:59 PM, J Decker  wrote:
> On Fri, Mar 5, 2010 at 6:15 AM, Bill Hoffman  wrote:
>> J Decker wrote:
>>>
>>> but then, for every project that already exists, it won't build
>>> correctly using watcom, because the options just aren't set in the
>>> generator, or 3 more flavors of generators aren't added to support
>>> static library, executlable and dynamic library with correct compile
>>> time options.
>>>
>>
>> It should go in Modules/Platform/Windows-wcl386.cmake.
>>
>> Just set these:
>> CMAKE_EXE_LINKER_FLAGS_DEBUG_INIT
>> CMAKE_SHARED_LINKER_FLAGS_INIT
>> CMAKE_SHARED_LINKER_FLAGS_DEBUG_INIT
>>
>
> I set
>
> SET (CMAKE_EXE_LINKER_FLAGS_DEBUG_INIT "debug all" )
> SET (CMAKE_SHARED_LINKER_FLAGS_DEBUG_INIT "debug all" )
>
> SET (CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO_INIT "debug all" )
> SET (CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO_INIT "debug all" )
>
> and made sure to clean my build directory, and re-ran generate with
> Watcom WMake  generator.  I would imagine that in
> CMakeFiles/project.dir/bulid.make that this line should hvae addtional
> options...
>
>        wlink  system nt_dll   name sack_bag.dll option caseexact  file
> {$(sack_bag_OBJECTS) $(sack_bag_EXTERNAL_OBJECTS)} library odbc32.lib
> library wsock32.lib library ws2_32.lib library opengl32.lib library
> odbc32.lib library winmm.lib library iphlpapi.lib library wsock32.lib
> library ws2_32.lib library opengl32.lib library winmm.lib library
> iphlpapi.lib library clbrdll.lib library plbrdll.lib  library
> kernel32.lib library user32.lib library gdi32.lib library winspool.lib
> library comdlg32.lib library advapi32.lib library shell32.lib library
> ole32.lib library oleaut32.lib library uuid.lib library odbc32.lib
> library odbccp32.lib
>
>
> Only thing I see in the bulid tree that mentions debug all are...
>
> CMAKE_EXE_LINKER_FLAGS_DEBUG:STRING=debug all
> CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO:STRING=debug all
> CMAKE_SHARED_LINKER_FLAGS_DEBUG:STRING=debug all
> CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO:STRING=debug all
>
>
> And nowhere else.
>
>>
>> See Windows-cl.cmake for an example, you will also want to set
>> RELWITHDEBINFO to have the same flag.  If you can verify this works, I will
>> merge into git master for CMake.
>>
>> -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] RecipeAddUninstallTarget fix

[Mateusz Loskot]

Hi,

I think that the regex replace command presented
in the RecipeAddUninstallTarget wiki is not correct.

It is:

STRING(REGEX REPLACE " " ";" files "${files}")

but it should read

STRING(REGEX REPLACE "\n" ";" files "${files}")


The current version of the command does not make the script
iterating over lists of files, but performs causes a single iteration

-- Uninstalling /home/mloskot/usr/include/geos/geos.h
/home/mloskot/usr/include/geos/platform.h
/home/mloskot/usr/bin/geos-config

Corrected version gives output like this:

-- Uninstalling /home/mloskot/usr/include/geos/geos.h
-- Uninstalling /home/mloskot/usr/include/geos/platform.h
-- Uninstalling /home/mloskot/usr/bin/geos-config

Am I correct?


[1] http://www.cmake.org/Wiki/RecipeAddUninstallTarget
-- 
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.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] Watcom Support

[J Decker]

On Fri, Mar 5, 2010 at 6:15 AM, Bill Hoffman  wrote:
> J Decker wrote:
>>
>> but then, for every project that already exists, it won't build
>> correctly using watcom, because the options just aren't set in the
>> generator, or 3 more flavors of generators aren't added to support
>> static library, executlable and dynamic library with correct compile
>> time options.
>>
>
> It should go in Modules/Platform/Windows-wcl386.cmake.
>
> Just set these:
> CMAKE_EXE_LINKER_FLAGS_DEBUG_INIT
> CMAKE_SHARED_LINKER_FLAGS_INIT
> CMAKE_SHARED_LINKER_FLAGS_DEBUG_INIT
>

I set

SET (CMAKE_EXE_LINKER_FLAGS_DEBUG_INIT "debug all" )
SET (CMAKE_SHARED_LINKER_FLAGS_DEBUG_INIT "debug all" )

SET (CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO_INIT "debug all" )
SET (CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO_INIT "debug all" )

and made sure to clean my build directory, and re-ran generate with
Watcom WMake  generator.  I would imagine that in
CMakeFiles/project.dir/bulid.make that this line should hvae addtional
options...

wlink  system nt_dll   name sack_bag.dll option caseexact  file
{$(sack_bag_OBJECTS) $(sack_bag_EXTERNAL_OBJECTS)} library odbc32.lib
library wsock32.lib library ws2_32.lib library opengl32.lib library
odbc32.lib library winmm.lib library iphlpapi.lib library wsock32.lib
library ws2_32.lib library opengl32.lib library winmm.lib library
iphlpapi.lib library clbrdll.lib library plbrdll.lib  library
kernel32.lib library user32.lib library gdi32.lib library winspool.lib
library comdlg32.lib library advapi32.lib library shell32.lib library
ole32.lib library oleaut32.lib library uuid.lib library odbc32.lib
library odbccp32.lib


Only thing I see in the bulid tree that mentions debug all are...

CMAKE_EXE_LINKER_FLAGS_DEBUG:STRING=debug all
CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO:STRING=debug all
CMAKE_SHARED_LINKER_FLAGS_DEBUG:STRING=debug all
CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO:STRING=debug all


And nowhere else.

>
> See Windows-cl.cmake for an example, you will also want to set
> RELWITHDEBINFO to have the same flag.  If you can verify this works, I will
> merge into git master for CMake.
>
> -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] Best way to Generate String

[Aaron_Wright]

Is this the best way to generate a comment bar, such as this:



or this:



or this:



IF(OUTPUT_FILE_EXT MATCHES "^\\.h|\\.cpp$")
   SET(COMMENT_CHARACTER "/")
ELSEIF(OUTPUT_FILE_EXT MATCHES "^\\.sql$")
   SET(COMMENT_CHARACTER "-")
ELSEIF(OUTPUT_FILE_EXT MATCHES "^\\.nsi|\\.nsh$")
   SET(COMMENT_CHARACTER "#")
ELSE()
   MESSAGE(WARNING "Unknown file type")
ENDIF()

STRING(RANDOM LENGTH 80 ALPHABET "${COMMENT_CHARACTER}" COMMENT_BAR)

The only reason I ask is that is seems weird to use the STRING(RANDOM 
function to get this done.
-
Aaron Wright
___
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.1 RC 4 is ready to try

[Eric Noulard]

2010/3/5 Bill Hoffman :
> Eric Noulard wrote:
>>
>> 2010/3/5 Bill Hoffman :
>>>
>>> CMake 2.8.1 RC 4 is ready to try:
>>>
>>> http://www.cmake.org/files/v2.8/?C=M;O=D
>>>
>>> Please try your projects with it.   If you find any issues, let me know.
>>> I think this is about it.  So, if I don't hear anything by Monday, this
>>> is
>>> going to be 2.8.1.
>>
>> Not really a show-stopper since I have no problem using this RC
>> but I do have a problem "Building it" on 2 linux boxes
>> (first is Ubuntu 9.10 and the other is Fedora 11) using gcc 4.4.1:
>>
>> Same error:
>> Linking CXX executable cmsysTestsCxx
>> [ 10%] Built target cmsysTestsCxx
>> [ 13%] Built target cmzlib
>> [ 14%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/base64.o
>> In file included from /usr/include/stdlib.h:320,
>>                 from
>> /home/usdtim/Erk/CMake/CMake-gitted/Utilities/cmcurl/base64.c:37:
>> /usr/include/sys/types.h:110: error: conflicting types for ‘ssize_t’
>> /home/usdtim/Erk/CMake/CMake-gitted/build/Utilities/cmcurl/config.h:727:
>> note: previous declaration of ‘ssize_t’ was here
>> make[2]: *** [Utilities/cmcurl/CMakeFiles/cmcurl.dir/base64.o] Erreur 1
>> make[1]: *** [Utilities/cmcurl/CMakeFiles/cmcurl.dir/all] Erreur 2
>> make: *** [all] Erreur 2
>>
>>
>> If I comment-out the offending (re)define in cmcurl/config.h.in
>> I can compile and use with no noticeable trouble.
>>
>>
> How are you building it?

Yes I do.

> Do other versions of CMake have this issue? Sounds
> like a try-compile test failed.

HEAD has the same issue.
I did not tried previous version [yet]

the culprit seems to be that
generated (configured)

Utilities/cmcurl/config.h

does the following:
#ifndef SIZEOF_SSIZE_T
# if SIZEOF_LONG == SIZEOF_SIZE_T
   typedef long ssize_t;
# elif SIZEOF_LONG_LONG == SIZEOF_SIZE_T
   typedef long long ssize_t;
# elif SIZEOF___INT64 == SIZEOF_SIZE_T
   typedef __int64 ssize_t;
# else
   typedef int ssize_t;
# endif

however, in this case CheckTypeSize macro obviously fails to find the
size of the type "ssize_t":

/* The size of `size_t', as computed by sizeof. */
#define SIZEOF_SIZE_T 4

/* The size of `ssize_t', as computed by sizeof. */


/* The size of `time_t', as computed by sizeof. */
#define SIZEOF_TIME_T 4

However  is defining the type...

I'll give 2.8.0 and 2.6.4 a compile try and give you feedback.


-- 
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.1 RC 4 is ready to try

[Bill Hoffman]

Eric Noulard wrote:

2010/3/5 Bill Hoffman :

CMake 2.8.1 RC 4 is ready to try:

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

Please try your projects with it.   If you find any issues, let me know.
I think this is about it.  So, if I don't hear anything by Monday, this is
going to be 2.8.1.


Not really a show-stopper since I have no problem using this RC
but I do have a problem "Building it" on 2 linux boxes
(first is Ubuntu 9.10 and the other is Fedora 11) using gcc 4.4.1:

Same error:
Linking CXX executable cmsysTestsCxx
[ 10%] Built target cmsysTestsCxx
[ 13%] Built target cmzlib
[ 14%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/base64.o
In file included from /usr/include/stdlib.h:320,
 from
/home/usdtim/Erk/CMake/CMake-gitted/Utilities/cmcurl/base64.c:37:
/usr/include/sys/types.h:110: error: conflicting types for ‘ssize_t’
/home/usdtim/Erk/CMake/CMake-gitted/build/Utilities/cmcurl/config.h:727:
note: previous declaration of ‘ssize_t’ was here
make[2]: *** [Utilities/cmcurl/CMakeFiles/cmcurl.dir/base64.o] Erreur 1
make[1]: *** [Utilities/cmcurl/CMakeFiles/cmcurl.dir/all] Erreur 2
make: *** [all] Erreur 2


If I comment-out the offending (re)define in cmcurl/config.h.in
I can compile and use with no noticeable trouble.


How are you building it?  Do other versions of CMake have this issue? 
Sounds like a try-compile test failed.


-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.1 RC 4 is ready to try

[Eric Noulard]

2010/3/5 Bill Hoffman :
> CMake 2.8.1 RC 4 is ready to try:
>
> http://www.cmake.org/files/v2.8/?C=M;O=D
>
> Please try your projects with it.   If you find any issues, let me know.
> I think this is about it.  So, if I don't hear anything by Monday, this is
> going to be 2.8.1.

Not really a show-stopper since I have no problem using this RC
but I do have a problem "Building it" on 2 linux boxes
(first is Ubuntu 9.10 and the other is Fedora 11) using gcc 4.4.1:

Same error:
Linking CXX executable cmsysTestsCxx
[ 10%] Built target cmsysTestsCxx
[ 13%] Built target cmzlib
[ 14%] Building C object Utilities/cmcurl/CMakeFiles/cmcurl.dir/base64.o
In file included from /usr/include/stdlib.h:320,
 from
/home/usdtim/Erk/CMake/CMake-gitted/Utilities/cmcurl/base64.c:37:
/usr/include/sys/types.h:110: error: conflicting types for ‘ssize_t’
/home/usdtim/Erk/CMake/CMake-gitted/build/Utilities/cmcurl/config.h:727:
note: previous declaration of ‘ssize_t’ was here
make[2]: *** [Utilities/cmcurl/CMakeFiles/cmcurl.dir/base64.o] Erreur 1
make[1]: *** [Utilities/cmcurl/CMakeFiles/cmcurl.dir/all] Erreur 2
make: *** [all] Erreur 2


If I comment-out the offending (re)define in cmcurl/config.h.in
I can compile and use with no noticeable trouble.


-- 
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] Strange search order of CMakeCache.txt

[Eric Noulard]

2010/3/5 kent williams :
> I recently had to help out a CMake newbie, who had run CMake in the
> source directory.  Then he re-read the instructions on build setup for
> our programs, and did it the right way -- i.e. he configured a build
> directory for an out of source build.
>
> Problem is, if you run CMake and configure the source directory, CMake
> will assume you want an in-source build, even if you try and configure
> an out-of-source build directory. So you get this mystifying behavior.

[...]

I run into this many time with users which are not CMake aware,
thus I did file a bug report:
http://public.kitware.com/Bug/view.php?id=6672

Anyone wanting to try a patch for this...
-- 
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] Strange search order of CMakeCache.txt

[kent williams]

I recently had to help out a CMake newbie, who had run CMake in the
source directory.  Then he re-read the instructions on build setup for
our programs, and did it the right way -- i.e. he configured a build
directory for an out of source build.

Problem is, if you run CMake and configure the source directory, CMake
will assume you want an in-source build, even if you try and configure
an out-of-source build directory. So you get this mystifying behavior.

# sourcedir is 'test', in same directory as test-build

cd test   # source dir
cmake   # whoops, configured in the source directory!
cd ../test-build# come to senses, go to out-of-srouce build.
cmake ../test  # try configuring for out of source build
make # now you get a "Makefile not found" error!

In order to get rid of the problem you have to delete CMakeCache.txt
in the source directory -- at a minimum -- before you can configure
the out-of-source build.  I ended up going through the source code
trying to get rid of CMake droppings, which are numerous!
___
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.1 RC 4 is ready to try

[Bill Hoffman]

CMake 2.8.1 RC 4 is ready to try:

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

Please try your projects with it.   If you find any issues, let me know.
I think this is about it.  So, if I don't hear anything by Monday, this 
is going to be 2.8.1.


Thanks.

Here are the changes:
Changes in CMake 2.8.1 RC 4
- CTest: Do not hide test GUI windows (fixes 2.8.0 regression)
- Documentation: Clarify CMAKE_MODULE_PATH variable
- FindQt4: Add support for QtDeclartive module
- FortranCInterface: Fix PathScale detection
- Suppress GNU flag -fPIC on Windows (fixes 2.8.1-rc1 regression)

Changes in CMake 2.8.1 RC 3
- Add CMAKE_XCODE_ATTRIBUTE_ interface to set compiler (#9125)
- Fix Eclipse files for targets in subdirectories (#9978)
- Fix custom command rule hashes to avoid extra rebuilds
- Print non-make generator name in initial compiler test

Changes in CMake 2.8.1 RC 2
- CPack: Avoid deleting long PATH values with NSIS (#10257)
- CTest: Fix and test cost-based test scheduler
- CTest: Fix and test git updates for case of out-dated index
- CTest: Fix regression caused by fix for (#2336) in rc1
- CTest: Setup command-line dashboard support with Git
- FindCUDA: Improve docs, use -rpath on Apple, fix dependency scanning
- Fix OS X deployment-target and sysroot defaults (#9959,#9898,#10155)
- Recognize the Compaq Fortran compiler

Changes in CMake 2.8.1 RC 1
- Add "NMake Makefiles JOM" generator
- Add PathScale compiler support
- Add per-configuration OUTPUT_DIRECTORY properties
- Add per-target OSX_ARCHITECTURES property
- check_type_size(): Handle mixed-size universal binaries
- CPack: Document Mac generators
- CPack: Improve RPM spec files
- Create CMAKE_FORCE_Fortran_COMPILER for cross-compiling
- CTest: Add --http1.0 command-line option
- CTest: Add --timeout command-line option
- CTest: Do not munge UTF-8 output in XML files
- CTest: Document CTEST_USE_LAUNCHERS option
- CTest: Fix killing of whole test process trees
- CTest: Handle failure of running invalid executables
- CTest: Honor the -C arg to ctest (#2336)
- CTest: Improve host system introspection
- CTest: Optionally randomize test order (--schedule-random)
- CTest: Skip tests with unsatisfied REQUIRED_FILES test property
- CTest: Submit arbitrary results with ATTACHED_FILES test property
- ctest_build(): Enhance signature
- ctest_start(): Add APPEND option
- ctest_start(): Move CTEST_CHECKOUT_COMMAND from ctest_update
- ctest_update(): Submit global tree revision in Update.xml
- Cygwin: Do not export all symbols from DLLs (#10122)
- Cygwin: Name DLLs with SOVERSION, not VERSION (#10122)
- Detect 32/64-bit Windows with Intel compiler
- Eclipse generator enhancements
- ExternalProject: Add TIMEOUT parameter
- FindCUDA: Respect CUDA version differences
- FindCURL: Find import libraries on Windows
- FindDCMTK: Look in more places
- FindGTest: Handle spaces better (#10065)
- FindGTK2: Look in fink locations on Mac OS X
- FindHDF5: Follow find-module API conventions
- FindJava: Support for versioned find
- FindJNI: Honor find_package() REQUIRED and QUIET options
- FindMPI: Improve Windows support
- FindOpenSSL: Fix MinGW support
- FindPythonLibs: Look in config for static library
- FindQt4: Misc enhancements, sync with KDE vesion
- FindRuby: Fix version convention on Windows
- FindX11: Improve documentation
- Fortran: Detect address size (#10119)
- FortranCInterface: Honor user flags
- Improve VS 2010 beta2 support
- link_directories(): Treat relative paths consistently (CMP0015)
- Modernize FindLibXslt and FindLibXml.cmake
- Refactor platform info to simplify adding new compilers
- Support cross-compiling versioned DLLs
- UseQt4: Provide dependencies only for static Qt (#10021)
- Address issues:
  #2336, #3571, #5041, #7541, #8725, #9011, #9042, #9054, #9163,
  #9171, #9450, #9697, #9764, #9782, #9792, #9862, #9894, #9913,
  #9916, #9917, #9918, #9949, #9965, #9970, #9982, #9985, #10003,
  #10014, #10021, #10032, #10055, #10060, #10065, #10114, #10119,
  #10122, #10126, #10136.

-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] C++ with BLAS

[Matt Terry]

is linking to shared libraries acceptable?  if so, you should be able
to link to libblas.so and you'll get the dependencies automatically.

On Fri, Mar 5, 2010 at 3:47 AM, Michael Wild  wrote:
>
> On 5. Mar, 2010, at 9:25 , Nico Schlömer wrote:
>
>> Hi,
>>
>> I build my C++ application here with CMake which works rather fine,
>> except for one minor glitch:
>> The application needs to link against BLAS, which I specify as
>>
>> TARGET_LINK_LIBRARIES( /path/to/blas/libblas.a )
>>
>> This gets included alright, but libblas -- written in Fortran -- in
>> turn needs symbols from libgfortran.a. This library, however, is never
>> automatically included; I have to manually specify it.
>>
>> Any way to automate this?
>>
>> Cheers,
>> Nico
>
>
> CMake can't possibly know it needs libgfortran.a, since a static library is 
> just a "zip-file" of object files. Either specify the libgfortran.a library 
> in the target_link_libraries call, or use gfortran as your linker by adding 
> Fortran to your project() call and then setting the LINKER_LANGUAGE to 
> Fortran. Of course, you still need to make sure that the Fortran compiler 
> that CMake finds actually is gfortran...
>
>
> 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
>
___
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] Can CMAKE_BINARY_DIR be realiable used before PROJECT()

[David Cole]

It would seem so...

CMakeLists.txt:
=
MESSAGE("before PROJECT")
MESSAGE("CMAKE_SOURCE_DIR=${CMAKE_SOURCE_DIR}")
MESSAGE("CMAKE_BINARY_DIR=${CMAKE_BINARY_DIR}")

PROJECT(hey NONE)

MESSAGE("after PROJECT")
MESSAGE("CMAKE_SOURCE_DIR=${CMAKE_SOURCE_DIR}")
MESSAGE("CMAKE_BINARY_DIR=${CMAKE_BINARY_DIR}")


Running that file with CMake 2.6.4 yields something like:
before PROJECT

CMAKE_SOURCE_DIR=C:/Users/davidcole/Desktop/b

CMAKE_BINARY_DIR=C:/Users/davidcole/Desktop/b/b

after PROJECT

CMAKE_SOURCE_DIR=C:/Users/davidcole/Desktop/b

CMAKE_BINARY_DIR=C:/Users/davidcole/Desktop/b/b



Similarly with 2.8.1-rc3:
before PROJECT

CMAKE_SOURCE_DIR=C:/Users/davidcole/Desktop/b

CMAKE_BINARY_DIR=C:/Users/davidcole/Desktop/b/c

after PROJECT

CMAKE_SOURCE_DIR=C:/Users/davidcole/Desktop/b

CMAKE_BINARY_DIR=C:/Users/davidcole/Desktop/b/c





On Fri, Mar 5, 2010 at 6:11 AM, Marcel Loose  wrote:

> Hi all,
>
> Can you rely on the value of CMAKE_BINARY_DIR (and CMAKE_SOURCE_DIR for
> that matter) before the PROJECT() statement has been seen by CMake?
>
> Best regards,
> Marcel Loose.
>
>
> ___
> 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] find_path for multiple files

[Ryan Pavlik]

You should be able to set the variables to be "internal" cache variables
after-the-fact - see
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#section_Properties%20on%20Cache%20Entries

That would at least keep them entirely out of the gui, even in advanced
mode.

Ryan

On Thu, Mar 4, 2010 at 4:27 PM, Guillaume Duhamel <
guillaume.duha...@gmail.com> wrote:

> I ended up writing my own macro to do the job:
> http://code.google.com/p/soupcon/source/browse/trunk/findxul/FMP.cmake
> there's also some usage example in my FindXUL module:
> http://code.google.com/p/soupcon/source/browse/trunk/findxul/FindXUL.cmake
>
> That's a bit more complex than what I described as it's able to find
> multiple groups of files in multiple groups of possible paths +
> path_suffixes.
> That's my first time at writing CMake modules so I guess I did a number of
> things wrong, but at least it's working enough to compile my XUL based app
> on linux / mac / windows :)
>
> There's at least one thing I really don't like about that macro though, it
> generates too many variables in the cache. There's NxM find_path calls (with
> N being the number of file to find and M the number of path groups), each
> one generating a cache variable and those variable are just "temporary"
> variables.
> Is there any way to clean those useless cache variables?
>
> Guillaume
>
>
> ___
> 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
>



-- 
Ryan Pavlik
HCI Graduate Student
Virtual Reality Applications Center
Iowa State University

rpav...@iastate.edu
http://academic.cleardefinition.com
Internal VRAC/HCI Site: http://tinyurl.com/rpavlik
___
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] OS X, SDL, Frameworks and Libraries

[Michael Jackson]

This is actually ironic. The SDL.framework is actually ready to be  
used in a bundle in its default state which seems to be the exception  
to the rule. Typically the install_path embedded in the dylib or  
framework is either just the name of the library OR the complete path  
to the library/framework. So basically there needs to be an additional  
check in the BundleUtilities.cmake file to look for an install_path  
that begins with @executable_path or @loader_path and basically ignore  
the next few steps where the install_path is fixed up and copied into  
the bundle location. So look in the BundleUtilities.cmake file and see  
if you can patch it up.


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


On Mar 5, 2010, at 8:39 AM, Francisco Requena wrote:


As on my previous my post, I got a bundle with SDL.framework embeeded.
On OS X, you can either use .framework and .dylib binaries. So, I  
got to use the BundleUtilities macro.


If CMake doesn't find the .framework, all works ok: I get 3  
libraries (libSDL..) on Content/MacOS folder.
If CMake finds the .framework, it just doesn't know (or it seems)  
how to handle it. What can I do?


Here's the CMakeLists.txt:

cmake_minimum_required(VERSION 2.8)

project(openvolt)

set(APP_NAME OpenVolt)

include(FindSDL)
include(FindOpenGL)

include_directories(${SDL_INCLUDE_DIR})

add_executable(${APP_NAME} MACOSX_BUNDLE main.cpp)

target_link_libraries(${APP_NAME} ${SDL_LIBRARY} ${OPENGL_LIBRARIES})

string(REPLACE "-framework Cocoa" "" DIRS ${SDL_LIBRARY})
install(CODE "
  include(BundleUtilities)
  fixup_bundle(\"${openvolt_BINARY_DIR}/${APP_NAME}.app\" \"\" \"$ 
{DIRS}\")

" COMPONENT Runtime)


And here's the output when I do 'make install':

[100%] Built target OpenVolt
Install the project...
-- Install configuration: ""
-- fixup_bundle
--   app='/Users/frarees/openvolt/build/OpenVolt.app'
--   libs=''
--   dirs='/Library/Frameworks/SDL.framework'
-- fixup_bundle: preparing...
-- warning: embedded item does not exist '/Users/frarees/openvolt/ 
build/OpenVolt.app/Contents/Frameworks/SDL.framework/Versions/1.3/SDL'

--
warning: cannot resolve item '@executable_path/../Frameworks/ 
SDL.framework/Versions/1.3/SDL'


  possible problems:
need more directories?
need to use InstallRequiredSystemLibraries?
run in install tree instead of build tree?

-- warning: embedded item does not exist '/Users/frarees/openvolt/ 
build/OpenVolt.app/Contents/Frameworks/SDL.framework/Versions/1.3/SDL'

--
warning: cannot resolve item '@executable_path/../Frameworks/ 
SDL.framework/Versions/1.3/SDL'


  possible problems:
need more directories?
need to use InstallRequiredSystemLibraries?
run in install tree instead of build tree?

-- fixup_bundle: copying...
-- 1/4: *NOT* copying '/Users/frarees/openvolt/build/OpenVolt.app/ 
Contents/MacOS/OpenVolt'
-- 2/4: copying '@executable_path/../Frameworks/SDL.framework/ 
Versions/1.3/SDL'

-- fixup_bundle: fixing...
-- 3/4: fixing up '/Users/frarees/openvolt/build/OpenVolt.app/ 
Contents/MacOS/OpenVolt'
-- 4/4: fixing up '/Users/frarees/openvolt/build/OpenVolt.app/ 
Contents/Frameworks/SDL.framework/Versions/1.3/SDL'

-- fixup_bundle: cleaning up...
-- fixup_bundle: verifying...
--  
= 
= 
= 
= 
= 
==

-- Analyzing app='/Users/frarees/openvolt/build/OpenVolt.app'
-- bundle='/Users/frarees/openvolt/build/OpenVolt.app'
-- executable='/Users/frarees/openvolt/build/OpenVolt.app/Contents/ 
MacOS/OpenVolt'

-- valid='1'
-- executable file 1: /Users/frarees/openvolt/build/OpenVolt.app/ 
Contents/MacOS/OpenVolt
-- warning: embedded item does not exist '/Users/frarees/openvolt/ 
build/OpenVolt.app/Contents/Frameworks/SDL.framework/Versions/1.3/SDL'

--
warning: cannot resolve item '@executable_path/../Frameworks/ 
SDL.framework/Versions/1.3/SDL'


  possible problems:
need more directories?
need to use InstallRequiredSystemLibraries?
run in install tree instead of build tree?

-- verified='1'
-- info='Verified 1 executable files in '/Users/frarees/openvolt/ 
build/OpenVolt.app''

--
-- verified='1'
-- info=''
--
-- fixup_bundle: done

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

Re: [CMake] Strange search order of CMakeCache.txt

[Bill Hoffman]

Marcel Loose wrote:


I would definitely like to get a warning when CMake finds a cache file
in what it thinks should be the source directory. It would have saved me
an hour of debugging. OTOH, now that I know of this "strange" behaviour,
I might be able to tackle these kinds of problems quicker.



It does say where the build files were written as the last message that 
is printed out



cmake ../src
...
-- Configuring done
-- Generating done
-- Build files have been written to: C:/hoffman/My Builds/src

If that is what they wanted (an in source build), CMake can not warn 
about it.



-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] Watcom Support

[Bill Hoffman]

J Decker wrote:

but then, for every project that already exists, it won't build
correctly using watcom, because the options just aren't set in the
generator, or 3 more flavors of generators aren't added to support
static library, executlable and dynamic library with correct compile
time options.



It should go in Modules/Platform/Windows-wcl386.cmake.

Just set these:
CMAKE_EXE_LINKER_FLAGS_DEBUG_INIT
CMAKE_SHARED_LINKER_FLAGS_INIT
CMAKE_SHARED_LINKER_FLAGS_DEBUG_INIT


See Windows-cl.cmake for an example, you will also want to set 
RELWITHDEBINFO to have the same flag.  If you can verify this works, I 
will merge into git master for CMake.


-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] OS X, embedding Frameworks and generator problems

[Werner Smekal]

Hi Francisco,

for the SDL Framework (downloaded from libsdl.org) you don't need the
bundleUtilities, so don't use it (in fact it doesn't work as you also
found out). If you just don't copy anything, then the app should just
work (assumed, that you SDL Framework is either in /Libraries/Framework
or /Users/user/Libraries/Framework.

Test this. Run the created app. Does it work?

To create an app bundle with framework included, run cmake like that

cmake -DCMAKE_INSTALL_PREFIX=installdir path-to-src

and in CMakeLists.txt add this INSTALL(Directory ..) commands I send you
earlier.

Now when you run "make", an app is created without the Framework. Does
it run? When you do now "make install" an app will be created in
installdir, where the Framework should be included. Does it run? if yes,
copy it to another computer where no SDL is installed and try again.

HTH,
Werner

On 3/5/10 12:58 PM, Francisco Requena wrote:
> Yes, I tried, but without success. 
> 
> My resulting file is: 
> 
> cmake_minimum_required(VERSION 2.8)
> 
> project(openvolt)
> 
> set(APP_NAME "OpenVolt")
> 
> include(FindSDL)
> string(REPLACE "-framework Cocoa" "" SDL_LIBRARY ${SDL_LIBRARY})
> include(FindOpenGL)
> include(BundleUtilities)
> 
> include_directories(${SDL_INCLUDE_DIR})
> 
> add_executable(${APP_NAME} MACOSX_BUNDLE main.cpp)
> 
> target_link_libraries(${APP_NAME} ${SDL_LIBRARY} SDLmain)
> 
> if(APPLE)
>   install(DIRECTORY ${SDL_LIBRARY} DESTINATION
> ${APP_NAME}.app/Contents/Frameworks)
> endif(APPLE)
> 
> However, it doesn't copies the framework. It just does nothing. 
> 
> 2010/3/5 Michael Wild mailto:them...@gmail.com>>
> 
> As Werner Smekal already mentioned
> (http://www.cmake.org/pipermail/cmake/2010-March/035636.html), for
> SDL it is apparently not necessary to use BundleUtilities. Have you
> tried this?
> 
> Michael
> 
> 
> On 5. Mar, 2010, at 12:50 , Francisco Requena wrote:
> 
> > However, I can't get it working. My aim is to make an standalone .app
> > bundle, distributable with SDL embedded. How should I use
> BundleUtilities to
> > get rid of this?
> >
> > Thanks.
> >
> > 2010/3/5 Michael Wild mailto:them...@gmail.com>>
> >
> >> http://www.cmake.org/Wiki/BundleUtilitiesExample
> >>
> >> Michael
> >>
> >> On 5. Mar, 2010, at 9:40 , Francisco Requena wrote:
> >>
> >>> So how do I embeed a framework on an OS X bundle?
> >>> Jjgod Jiang has the same problem here:
> >>> http://www.cmake.org/pipermail/cmake/2009-September/031713.html
> >>>
> >>> 2010/3/5 David Cole  >
> >>>
>  SDL_library is not a source file, so don't call:
>  set_source_files_properties
>  on it...
> 
>  That should eliminate the spurious content copy attempt...
> 
> 
>  On Thu, Mar 4, 2010 at 6:17 PM, Francisco Requena
> mailto:the@gmail.com>
> >>> wrote:
> 
> > Hi,
> >
> > I'm trying to develop a simple application using SDL on OS X.
> Here's my
> > CMakeLists.txt:
> >
> > cmake_minimum_required(VERSION 2.8)
> >
> > project(newapp)
> >
> > include(FindSDL)
> > include(FindOpenGL)
> >
> > include_directories(${SDL_INCLUDE_DIR})
> >
> > string(REPLACE "-framework Cocoa" "" SDL_LIBRARY ${SDL_LIBRARY})
> >
> > set_source_files_properties(${SDL_LIBRARY} PROPERTIES
> > MACOSX_PACKAGE_LOCATION Frameworks)
> >
> > add_executable(myapp MACOSX_BUNDLE main.cpp ${SDL_LIBRARY})
> >
> > target_link_libraries(myapp ${SDL_LIBRARY} SDLmain "-framework
> Cocoa")
> >
> > Then I do:
> > cmake
> > make
> >
> > And that's what I get:
> > Error copying file "/Library/Frameworks/SDL.framework" to
> > "myapp.app/Contents/Frameworks/SDL.framework".
> > make[2]: *** [myapp.app/Contents/Frameworks/SDL.framework] Error 1
> > make[1]: *** [CMakeFiles/myapp.dir/all] Error 2
> > make: *** [all] Error 2
> >
> > However, if I do:
> > cmake -G Xcode
> >
> > And then I open the generated Xcode project and do compile, all is
> >> working
> > properly.
> > What should I do?
> > It's just a bug?
> >
> > Thanks,
> > Franciso Requena.
> >
> >
> > I use the lastest CMake version (git cloned). It's 2.9.20100304.
> > ___
> > 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

Re: [CMake] Strange search order of CMakeCache.txt

[Marcel Loose]

On Fri, 2010-03-05 at 14:27 +0100, Michael Wild wrote:
> On 5. Mar, 2010, at 14:19 , Marcel Loose wrote:
> 
> > Hi all,
> > 
> > I just spent an hour debugging a very strange phenomenon running
CMake
> > on Mac OS-X, which in the end turned out to be trivial, but
completely
> > unexpected for me.
> > 
> > The problem was caused by the fact that CMake had accidentally been
run
> > once from the source directory. When running CMake in an empty
binary
> > directory it seemed to somehow fail to set CMAKE_BINARY_DIR
correctly.
> > 
> > Cause of the problem turned out to be the order in which CMake
searches
> > for the CMakeCache.txt file: first in the directory containing the
> > CMakeLists.txt file (CMAKE_SOURCE_DIR), then in the (binary)
directory
> > that CMake is being run from (CMAKE_BINARY_DIR). 
> > 
> > Wouldn't it be more logical to start in the binary directory and
then
> > look in the source directory? Or, probably even better, completely
> > ignore the source directory when searching for the cache file.
> > 
> > Best regards,
> > Marcel Loose.
> 
> It is not very intuitive (but very useful) that CMake first assumes
the directory argument to be a binary tree, and only then looks for a
CMakeLists.txt. E.g.:
> 
> 
> mkdir -p path/to/build-tree
> cd path/to/build-tree
> cmake path/to/source-tree
> # now want to change some setting, don't have to remember/type
source-tree path
> ccmake .
> make
> 
> On the other hand, it can be quite confusing behavior if an
"accidental" CMakeCache.txt is present in the source tree... Perhaps
CMake should add a safety check and emit a warning if a cache exists in
the current working directory that references the same source tree as
the cache in the directory specified on the command line...
> 
> 
> Michael

Hi Michael,

I never knew you could use path/to/build-tree as argument to cmake, but
re-reading the docs reveals that feature.

I would definitely like to get a warning when CMake finds a cache file
in what it thinks should be the source directory. It would have saved me
an hour of debugging. OTOH, now that I know of this "strange" behaviour,
I might be able to tackle these kinds of problems quicker.

Best regards,
Marcel Loose.


___
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] OS X, SDL, Frameworks and Libraries

[Francisco Requena]

As on my previous my post, I got a bundle with SDL.framework embeeded.
On OS X, you can either use .framework and .dylib binaries. So, I got to use
the BundleUtilities macro.

If CMake doesn't find the .framework, all works ok: I get 3 libraries
(libSDL..) on Content/MacOS folder.
If CMake finds the .framework, it just doesn't know (or it seems) how to
handle it. What can I do?

Here's the CMakeLists.txt:

cmake_minimum_required(VERSION 2.8)

project(openvolt)

set(APP_NAME OpenVolt)

include(FindSDL)
include(FindOpenGL)

include_directories(${SDL_INCLUDE_DIR})

add_executable(${APP_NAME} MACOSX_BUNDLE main.cpp)

target_link_libraries(${APP_NAME} ${SDL_LIBRARY} ${OPENGL_LIBRARIES})

string(REPLACE "-framework Cocoa" "" DIRS ${SDL_LIBRARY})
install(CODE "
  include(BundleUtilities)
  fixup_bundle(\"${openvolt_BINARY_DIR}/${APP_NAME}.app\" \"\" \"${DIRS}\")
" COMPONENT Runtime)


And here's the output when I do 'make install':

[100%] Built target OpenVolt
Install the project...
-- Install configuration: ""
-- fixup_bundle
--   app='/Users/frarees/openvolt/build/OpenVolt.app'
--   libs=''
--   dirs='/Library/Frameworks/SDL.framework'
-- fixup_bundle: preparing...
-- warning: embedded item does not exist
'/Users/frarees/openvolt/build/OpenVolt.app/Contents/Frameworks/SDL.framework/Versions/1.3/SDL'
-- 
warning: cannot resolve item
'@executable_path/../Frameworks/SDL.framework/Versions/1.3/SDL'

  possible problems:
need more directories?
need to use InstallRequiredSystemLibraries?
run in install tree instead of build tree?

-- warning: embedded item does not exist
'/Users/frarees/openvolt/build/OpenVolt.app/Contents/Frameworks/SDL.framework/Versions/1.3/SDL'
-- 
warning: cannot resolve item
'@executable_path/../Frameworks/SDL.framework/Versions/1.3/SDL'

  possible problems:
need more directories?
need to use InstallRequiredSystemLibraries?
run in install tree instead of build tree?

-- fixup_bundle: copying...
-- 1/4: *NOT* copying
'/Users/frarees/openvolt/build/OpenVolt.app/Contents/MacOS/OpenVolt'
-- 2/4: copying
'@executable_path/../Frameworks/SDL.framework/Versions/1.3/SDL'
-- fixup_bundle: fixing...
-- 3/4: fixing up
'/Users/frarees/openvolt/build/OpenVolt.app/Contents/MacOS/OpenVolt'
-- 4/4: fixing up
'/Users/frarees/openvolt/build/OpenVolt.app/Contents/Frameworks/SDL.framework/Versions/1.3/SDL'
-- fixup_bundle: cleaning up...
-- fixup_bundle: verifying...
-- 
===
-- Analyzing app='/Users/frarees/openvolt/build/OpenVolt.app'
-- bundle='/Users/frarees/openvolt/build/OpenVolt.app'
-- 
executable='/Users/frarees/openvolt/build/OpenVolt.app/Contents/MacOS/OpenVolt'
-- valid='1'
-- executable file 1:
/Users/frarees/openvolt/build/OpenVolt.app/Contents/MacOS/OpenVolt
-- warning: embedded item does not exist
'/Users/frarees/openvolt/build/OpenVolt.app/Contents/Frameworks/SDL.framework/Versions/1.3/SDL'
-- 
warning: cannot resolve item
'@executable_path/../Frameworks/SDL.framework/Versions/1.3/SDL'

  possible problems:
need more directories?
need to use InstallRequiredSystemLibraries?
run in install tree instead of build tree?

-- verified='1'
-- info='Verified 1 executable files in
'/Users/frarees/openvolt/build/OpenVolt.app''
-- 
-- verified='1'
-- info=''
-- 
-- fixup_bundle: done
___
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] Strange search order of CMakeCache.txt

[Michael Wild]

On 5. Mar, 2010, at 14:19 , Marcel Loose wrote:

> Hi all,
> 
> I just spent an hour debugging a very strange phenomenon running CMake
> on Mac OS-X, which in the end turned out to be trivial, but completely
> unexpected for me.
> 
> The problem was caused by the fact that CMake had accidentally been run
> once from the source directory. When running CMake in an empty binary
> directory it seemed to somehow fail to set CMAKE_BINARY_DIR correctly.
> 
> Cause of the problem turned out to be the order in which CMake searches
> for the CMakeCache.txt file: first in the directory containing the
> CMakeLists.txt file (CMAKE_SOURCE_DIR), then in the (binary) directory
> that CMake is being run from (CMAKE_BINARY_DIR). 
> 
> Wouldn't it be more logical to start in the binary directory and then
> look in the source directory? Or, probably even better, completely
> ignore the source directory when searching for the cache file.
> 
> Best regards,
> Marcel Loose.

It is not very intuitive (but very useful) that CMake first assumes the 
directory argument to be a binary tree, and only then looks for a 
CMakeLists.txt. E.g.:


mkdir -p path/to/build-tree
cd path/to/build-tree
cmake path/to/source-tree
# now want to change some setting, don't have to remember/type source-tree path
ccmake .
make

On the other hand, it can be quite confusing behavior if an "accidental" 
CMakeCache.txt is present in the source tree... Perhaps CMake should add a 
safety check and emit a warning if a cache exists in the current working 
directory that references the same source tree as the cache in the directory 
specified on the command line...


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] Strange search order of CMakeCache.txt

[Marcel Loose]

Hi all,

I just spent an hour debugging a very strange phenomenon running CMake
on Mac OS-X, which in the end turned out to be trivial, but completely
unexpected for me.

The problem was caused by the fact that CMake had accidentally been run
once from the source directory. When running CMake in an empty binary
directory it seemed to somehow fail to set CMAKE_BINARY_DIR correctly.

Cause of the problem turned out to be the order in which CMake searches
for the CMakeCache.txt file: first in the directory containing the
CMakeLists.txt file (CMAKE_SOURCE_DIR), then in the (binary) directory
that CMake is being run from (CMAKE_BINARY_DIR). 

Wouldn't it be more logical to start in the binary directory and then
look in the source directory? Or, probably even better, completely
ignore the source directory when searching for the cache file.

Best regards,
Marcel Loose.


___
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] OS X, embedding Frameworks and generator problems

[Michael Wild]

Did you run "make install"?

Michael

On 5. Mar, 2010, at 12:58 , Francisco Requena wrote:

> Yes, I tried, but without success.
> 
> My resulting file is:
> 
> cmake_minimum_required(VERSION 2.8)
> 
> project(openvolt)
> 
> set(APP_NAME "OpenVolt")
> 
> include(FindSDL)
> string(REPLACE "-framework Cocoa" "" SDL_LIBRARY ${SDL_LIBRARY})
> include(FindOpenGL)
> include(BundleUtilities)
> 
> include_directories(${SDL_INCLUDE_DIR})
> 
> add_executable(${APP_NAME} MACOSX_BUNDLE main.cpp)
> 
> target_link_libraries(${APP_NAME} ${SDL_LIBRARY} SDLmain)
> 
> if(APPLE)
>  install(DIRECTORY ${SDL_LIBRARY} DESTINATION
> ${APP_NAME}.app/Contents/Frameworks)
> endif(APPLE)
> 
> However, it doesn't copies the framework. It just does nothing.
> 
> 2010/3/5 Michael Wild 
> 
>> As Werner Smekal already mentioned (
>> http://www.cmake.org/pipermail/cmake/2010-March/035636.html), for SDL it
>> is apparently not necessary to use BundleUtilities. Have you tried this?
>> 
>> Michael
>> 
>> 
>> On 5. Mar, 2010, at 12:50 , Francisco Requena wrote:
>> 
>>> However, I can't get it working. My aim is to make an standalone .app
>>> bundle, distributable with SDL embedded. How should I use BundleUtilities
>> to
>>> get rid of this?
>>> 
>>> Thanks.
>>> 
>>> 2010/3/5 Michael Wild 
>>> 
 http://www.cmake.org/Wiki/BundleUtilitiesExample
 
 Michael
 
 On 5. Mar, 2010, at 9:40 , Francisco Requena wrote:
 
> So how do I embeed a framework on an OS X bundle?
> Jjgod Jiang has the same problem here:
> http://www.cmake.org/pipermail/cmake/2009-September/031713.html
> 
> 2010/3/5 David Cole 
> 
>> SDL_library is not a source file, so don't call:
>> set_source_files_properties
>> on it...
>> 
>> That should eliminate the spurious content copy attempt...
>> 
>> 
>> On Thu, Mar 4, 2010 at 6:17 PM, Francisco Requena  wrote:
>> 
>>> Hi,
>>> 
>>> I'm trying to develop a simple application using SDL on OS X. Here's
>> my
>>> CMakeLists.txt:
>>> 
>>> cmake_minimum_required(VERSION 2.8)
>>> 
>>> project(newapp)
>>> 
>>> include(FindSDL)
>>> include(FindOpenGL)
>>> 
>>> include_directories(${SDL_INCLUDE_DIR})
>>> 
>>> string(REPLACE "-framework Cocoa" "" SDL_LIBRARY ${SDL_LIBRARY})
>>> 
>>> set_source_files_properties(${SDL_LIBRARY} PROPERTIES
>>> MACOSX_PACKAGE_LOCATION Frameworks)
>>> 
>>> add_executable(myapp MACOSX_BUNDLE main.cpp ${SDL_LIBRARY})
>>> 
>>> target_link_libraries(myapp ${SDL_LIBRARY} SDLmain "-framework
>> Cocoa")
>>> 
>>> Then I do:
>>> cmake
>>> make
>>> 
>>> And that's what I get:
>>> Error copying file "/Library/Frameworks/SDL.framework" to
>>> "myapp.app/Contents/Frameworks/SDL.framework".
>>> make[2]: *** [myapp.app/Contents/Frameworks/SDL.framework] Error 1
>>> make[1]: *** [CMakeFiles/myapp.dir/all] Error 2
>>> make: *** [all] Error 2
>>> 
>>> However, if I do:
>>> cmake -G Xcode
>>> 
>>> And then I open the generated Xcode project and do compile, all is
 working
>>> properly.
>>> What should I do?
>>> It's just a bug?
>>> 
>>> Thanks,
>>> Franciso Requena.
>>> 
>>> 
>>> I use the lastest CMake version (git cloned). It's 2.9.20100304.
>>> ___
>>> 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

Re: [CMake] OS X, embedding Frameworks and generator problems

[Francisco Requena]

Yes, I tried, but without success.

My resulting file is:

cmake_minimum_required(VERSION 2.8)

project(openvolt)

set(APP_NAME "OpenVolt")

include(FindSDL)
string(REPLACE "-framework Cocoa" "" SDL_LIBRARY ${SDL_LIBRARY})
include(FindOpenGL)
include(BundleUtilities)

include_directories(${SDL_INCLUDE_DIR})

add_executable(${APP_NAME} MACOSX_BUNDLE main.cpp)

target_link_libraries(${APP_NAME} ${SDL_LIBRARY} SDLmain)

if(APPLE)
  install(DIRECTORY ${SDL_LIBRARY} DESTINATION
${APP_NAME}.app/Contents/Frameworks)
endif(APPLE)

However, it doesn't copies the framework. It just does nothing.

2010/3/5 Michael Wild 

> As Werner Smekal already mentioned (
> http://www.cmake.org/pipermail/cmake/2010-March/035636.html), for SDL it
> is apparently not necessary to use BundleUtilities. Have you tried this?
>
> Michael
>
>
> On 5. Mar, 2010, at 12:50 , Francisco Requena wrote:
>
> > However, I can't get it working. My aim is to make an standalone .app
> > bundle, distributable with SDL embedded. How should I use BundleUtilities
> to
> > get rid of this?
> >
> > Thanks.
> >
> > 2010/3/5 Michael Wild 
> >
> >> http://www.cmake.org/Wiki/BundleUtilitiesExample
> >>
> >> Michael
> >>
> >> On 5. Mar, 2010, at 9:40 , Francisco Requena wrote:
> >>
> >>> So how do I embeed a framework on an OS X bundle?
> >>> Jjgod Jiang has the same problem here:
> >>> http://www.cmake.org/pipermail/cmake/2009-September/031713.html
> >>>
> >>> 2010/3/5 David Cole 
> >>>
>  SDL_library is not a source file, so don't call:
>  set_source_files_properties
>  on it...
> 
>  That should eliminate the spurious content copy attempt...
> 
> 
>  On Thu, Mar 4, 2010 at 6:17 PM, Francisco Requena  >>> wrote:
> 
> > Hi,
> >
> > I'm trying to develop a simple application using SDL on OS X. Here's
> my
> > CMakeLists.txt:
> >
> > cmake_minimum_required(VERSION 2.8)
> >
> > project(newapp)
> >
> > include(FindSDL)
> > include(FindOpenGL)
> >
> > include_directories(${SDL_INCLUDE_DIR})
> >
> > string(REPLACE "-framework Cocoa" "" SDL_LIBRARY ${SDL_LIBRARY})
> >
> > set_source_files_properties(${SDL_LIBRARY} PROPERTIES
> > MACOSX_PACKAGE_LOCATION Frameworks)
> >
> > add_executable(myapp MACOSX_BUNDLE main.cpp ${SDL_LIBRARY})
> >
> > target_link_libraries(myapp ${SDL_LIBRARY} SDLmain "-framework
> Cocoa")
> >
> > Then I do:
> > cmake
> > make
> >
> > And that's what I get:
> > Error copying file "/Library/Frameworks/SDL.framework" to
> > "myapp.app/Contents/Frameworks/SDL.framework".
> > make[2]: *** [myapp.app/Contents/Frameworks/SDL.framework] Error 1
> > make[1]: *** [CMakeFiles/myapp.dir/all] Error 2
> > make: *** [all] Error 2
> >
> > However, if I do:
> > cmake -G Xcode
> >
> > And then I open the generated Xcode project and do compile, all is
> >> working
> > properly.
> > What should I do?
> > It's just a bug?
> >
> > Thanks,
> > Franciso Requena.
> >
> >
> > I use the lastest CMake version (git cloned). It's 2.9.20100304.
> > ___
> > 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

Re: [CMake] OS X, embedding Frameworks and generator problems

[Michael Wild]

As Werner Smekal already mentioned 
(http://www.cmake.org/pipermail/cmake/2010-March/035636.html), for SDL it is 
apparently not necessary to use BundleUtilities. Have you tried this?

Michael


On 5. Mar, 2010, at 12:50 , Francisco Requena wrote:

> However, I can't get it working. My aim is to make an standalone .app
> bundle, distributable with SDL embedded. How should I use BundleUtilities to
> get rid of this?
> 
> Thanks.
> 
> 2010/3/5 Michael Wild 
> 
>> http://www.cmake.org/Wiki/BundleUtilitiesExample
>> 
>> Michael
>> 
>> On 5. Mar, 2010, at 9:40 , Francisco Requena wrote:
>> 
>>> So how do I embeed a framework on an OS X bundle?
>>> Jjgod Jiang has the same problem here:
>>> http://www.cmake.org/pipermail/cmake/2009-September/031713.html
>>> 
>>> 2010/3/5 David Cole 
>>> 
 SDL_library is not a source file, so don't call:
 set_source_files_properties
 on it...
 
 That should eliminate the spurious content copy attempt...
 
 
 On Thu, Mar 4, 2010 at 6:17 PM, Francisco Requena >> wrote:
 
> Hi,
> 
> I'm trying to develop a simple application using SDL on OS X. Here's my
> CMakeLists.txt:
> 
> cmake_minimum_required(VERSION 2.8)
> 
> project(newapp)
> 
> include(FindSDL)
> include(FindOpenGL)
> 
> include_directories(${SDL_INCLUDE_DIR})
> 
> string(REPLACE "-framework Cocoa" "" SDL_LIBRARY ${SDL_LIBRARY})
> 
> set_source_files_properties(${SDL_LIBRARY} PROPERTIES
> MACOSX_PACKAGE_LOCATION Frameworks)
> 
> add_executable(myapp MACOSX_BUNDLE main.cpp ${SDL_LIBRARY})
> 
> target_link_libraries(myapp ${SDL_LIBRARY} SDLmain "-framework Cocoa")
> 
> Then I do:
> cmake
> make
> 
> And that's what I get:
> Error copying file "/Library/Frameworks/SDL.framework" to
> "myapp.app/Contents/Frameworks/SDL.framework".
> make[2]: *** [myapp.app/Contents/Frameworks/SDL.framework] Error 1
> make[1]: *** [CMakeFiles/myapp.dir/all] Error 2
> make: *** [all] Error 2
> 
> However, if I do:
> cmake -G Xcode
> 
> And then I open the generated Xcode project and do compile, all is
>> working
> properly.
> What should I do?
> It's just a bug?
> 
> Thanks,
> Franciso Requena.
> 
> 
> I use the lastest CMake version (git cloned). It's 2.9.20100304.
> ___
> 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

Re: [CMake] OS X, embedding Frameworks and generator problems

[Francisco Requena]

However, I can't get it working. My aim is to make an standalone .app
bundle, distributable with SDL embedded. How should I use BundleUtilities to
get rid of this?

Thanks.

2010/3/5 Michael Wild 

> http://www.cmake.org/Wiki/BundleUtilitiesExample
>
> Michael
>
> On 5. Mar, 2010, at 9:40 , Francisco Requena wrote:
>
> > So how do I embeed a framework on an OS X bundle?
> > Jjgod Jiang has the same problem here:
> > http://www.cmake.org/pipermail/cmake/2009-September/031713.html
> >
> > 2010/3/5 David Cole 
> >
> >> SDL_library is not a source file, so don't call:
> >>  set_source_files_properties
> >> on it...
> >>
> >> That should eliminate the spurious content copy attempt...
> >>
> >>
> >> On Thu, Mar 4, 2010 at 6:17 PM, Francisco Requena  >wrote:
> >>
> >>> Hi,
> >>>
> >>> I'm trying to develop a simple application using SDL on OS X. Here's my
> >>> CMakeLists.txt:
> >>>
> >>> cmake_minimum_required(VERSION 2.8)
> >>>
> >>> project(newapp)
> >>>
> >>> include(FindSDL)
> >>> include(FindOpenGL)
> >>>
> >>> include_directories(${SDL_INCLUDE_DIR})
> >>>
> >>> string(REPLACE "-framework Cocoa" "" SDL_LIBRARY ${SDL_LIBRARY})
> >>>
> >>> set_source_files_properties(${SDL_LIBRARY} PROPERTIES
> >>> MACOSX_PACKAGE_LOCATION Frameworks)
> >>>
> >>> add_executable(myapp MACOSX_BUNDLE main.cpp ${SDL_LIBRARY})
> >>>
> >>> target_link_libraries(myapp ${SDL_LIBRARY} SDLmain "-framework Cocoa")
> >>>
> >>> Then I do:
> >>> cmake
> >>> make
> >>>
> >>> And that's what I get:
> >>> Error copying file "/Library/Frameworks/SDL.framework" to
> >>> "myapp.app/Contents/Frameworks/SDL.framework".
> >>> make[2]: *** [myapp.app/Contents/Frameworks/SDL.framework] Error 1
> >>> make[1]: *** [CMakeFiles/myapp.dir/all] Error 2
> >>> make: *** [all] Error 2
> >>>
> >>> However, if I do:
> >>> cmake -G Xcode
> >>>
> >>> And then I open the generated Xcode project and do compile, all is
> working
> >>> properly.
> >>> What should I do?
> >>> It's just a bug?
> >>>
> >>> Thanks,
> >>> Franciso Requena.
> >>>
> >>>
> >>> I use the lastest CMake version (git cloned). It's 2.9.20100304.
> >>> ___
> >>> 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

Re: [CMake] Linking external static libraries into dlls

[Christoph Höger]

Am Donnerstag, den 04.03.2010, 10:49 -0800 schrieb Tyler Roscoe:
> On Thu, Mar 04, 2010 at 06:30:02PM +0100, Christoph Höger wrote:
> > I am currently trying to link a DLL with the netcdf_c++ static library
> > in the hope I will not have to redistribute netcdf itself. (I thought
> > the DLL could contain the needed code itself).
> 
> This should work. Be careful, though. I think symbols from the static
> lib will only show up in your DLL if code in your DLL uses those symbols
> -- that is, not all symbols from the static lib are automatically
> imported into your DLL. This is all IIRC.

That would be fine, the only intention is to redistribute this DLL
without the static library attached.

> > target_library_add({${myLib} ${netcdf_c++.lib})
> 
> This is not a CMake command and google has never heard of it. If this is
> a macro in your CMake system, we'll need to see its contents before we
> can comment on it.

Ups, sorry, I meant target_link_libraries it was getting a little late
yesterday.


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
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] Can CMAKE_BINARY_DIR be realiable used before PROJECT()

[Marcel Loose]

Hi all,

Can you rely on the value of CMAKE_BINARY_DIR (and CMAKE_SOURCE_DIR for
that matter) before the PROJECT() statement has been seen by CMake?

Best regards,
Marcel Loose.


___
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] C++ with BLAS

[Michael Wild]

On 5. Mar, 2010, at 9:25 , Nico Schlömer wrote:

> Hi,
> 
> I build my C++ application here with CMake which works rather fine,
> except for one minor glitch:
> The application needs to link against BLAS, which I specify as
> 
> TARGET_LINK_LIBRARIES( /path/to/blas/libblas.a )
> 
> This gets included alright, but libblas -- written in Fortran -- in
> turn needs symbols from libgfortran.a. This library, however, is never
> automatically included; I have to manually specify it.
> 
> Any way to automate this?
> 
> Cheers,
> Nico


CMake can't possibly know it needs libgfortran.a, since a static library is 
just a "zip-file" of object files. Either specify the libgfortran.a library in 
the target_link_libraries call, or use gfortran as your linker by adding 
Fortran to your project() call and then setting the LINKER_LANGUAGE to Fortran. 
Of course, you still need to make sure that the Fortran compiler that CMake 
finds actually is gfortran...


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] C++ with BLAS

[Nico Schlömer]

Hi,

I build my C++ application here with CMake which works rather fine,
except for one minor glitch:
The application needs to link against BLAS, which I specify as

TARGET_LINK_LIBRARIES( /path/to/blas/libblas.a )

This gets included alright, but libblas -- written in Fortran -- in
turn needs symbols from libgfortran.a. This library, however, is never
automatically included; I have to manually specify it.

Any way to automate this?

Cheers,
Nico
___
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] OS X, embedding Frameworks and generator problems

[Werner Smekal]

For the SDL Framework it is sufficient to just copy it during the
installation process, e.g. I do

# copy SDL frameworks into app bundle for Mac OS X
if(APPLE)
INSTALL(DIRECTORY /Users/smekal/Library/Frameworks/SDL.framework
DESTINATION 
hex-a-hop.app/Contents/Frameworks)
INSTALL(DIRECTORY /Users/smekal/Library/Frameworks/SDL_mixer.framework
DESTINATION 
hex-a-hop.app/Contents/Frameworks)
INSTALL(DIRECTORY /Users/smekal/Library/Frameworks/SDL_ttf.framework
DESTINATION 
hex-a-hop.app/Contents/Frameworks)
endif(APPLE)

BundeUtilites won't work (as posted before), since the SDL libraries
already have "@executable/../Framework/..." as a reference (use otool -L
on the SDL library) and BundleUtilities then doesn't know where to find
the SDL library (since if the executable is linked to that library it
uses the reference found in the library). But you also don't need to
copy the SDL Framework if you just want to run the app on your
development machine, since if the library isn't found in the app it
looks in /Library and /Users/user/Library to find the framework. But if
you want to give the app to someone else, you need to just copy the SDL
framework in the right place - best done during the install step. This
is a special case, usually BundleUtilities does a perfect job.

HTH,
Werner


On 3/5/10 9:40 AM, Francisco Requena wrote:
> So how do I embeed a framework on an OS X bundle?
> Jjgod Jiang has the same problem
> here: http://www.cmake.org/pipermail/cmake/2009-September/031713.html
> 
> 2010/3/5 David Cole mailto:david.c...@kitware.com>>
> 
> SDL_library is not a source file, so don't call:
>   set_source_files_properties
> on it...
> 
> That should eliminate the spurious content copy attempt...
> 
> 
> On Thu, Mar 4, 2010 at 6:17 PM, Francisco Requena  > wrote:
> 
> Hi, 
> 
> I'm trying to develop a simple application using SDL on OS X.
> Here's my CMakeLists.txt: 
> 
> cmake_minimum_required(VERSION 2.8)
> 
> project(newapp)
> 
> include(FindSDL)
> include(FindOpenGL)
> 
> include_directories(${SDL_INCLUDE_DIR})
> 
> string(REPLACE "-framework Cocoa" "" SDL_LIBRARY ${SDL_LIBRARY})
> 
> set_source_files_properties(${SDL_LIBRARY} PROPERTIES
> MACOSX_PACKAGE_LOCATION Frameworks)
> 
> add_executable(myapp MACOSX_BUNDLE main.cpp ${SDL_LIBRARY})
> 
> target_link_libraries(myapp ${SDL_LIBRARY} SDLmain "-framework
> Cocoa")
> 
> Then I do: 
> cmake
> make
> 
> And that's what I get: 
> Error copying file "/Library/Frameworks/SDL.framework" to
> "myapp.app/Contents/Frameworks/SDL.framework".
> make[2]: *** [myapp.app/Contents/Frameworks/SDL.framework] Error 1
> make[1]: *** [CMakeFiles/myapp.dir/all] Error 2
> make: *** [all] Error 2
> 
> However, if I do: 
> cmake -G Xcode
> 
> And then I open the generated Xcode project and do compile, all
> is working properly. 
> What should I do?
> It's just a bug?
> 
> Thanks,
> Franciso Requena. 
> 
> 
> I use the lastest CMake version (git cloned). It's 2.9.20100304.
> ___
> 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

-- 
Dr. Werner Smekal
Institut fuer Angewandte Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10/134
A-1040 Wien
Austria
DVR-Nr: 0005886

email: sme...@iap.tuwien.ac.at  (GPG: EDCAF4A79)
web:   http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office)
   +43-(0)1-58801-13469 (laboratory)
fax:   +43-(0)1-58801-13499
___
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] OS X, embedding Frameworks and generator problems

[Michael Wild]

http://www.cmake.org/Wiki/BundleUtilitiesExample

Michael

On 5. Mar, 2010, at 9:40 , Francisco Requena wrote:

> So how do I embeed a framework on an OS X bundle?
> Jjgod Jiang has the same problem here:
> http://www.cmake.org/pipermail/cmake/2009-September/031713.html
> 
> 2010/3/5 David Cole 
> 
>> SDL_library is not a source file, so don't call:
>>  set_source_files_properties
>> on it...
>> 
>> That should eliminate the spurious content copy attempt...
>> 
>> 
>> On Thu, Mar 4, 2010 at 6:17 PM, Francisco Requena wrote:
>> 
>>> Hi,
>>> 
>>> I'm trying to develop a simple application using SDL on OS X. Here's my
>>> CMakeLists.txt:
>>> 
>>> cmake_minimum_required(VERSION 2.8)
>>> 
>>> project(newapp)
>>> 
>>> include(FindSDL)
>>> include(FindOpenGL)
>>> 
>>> include_directories(${SDL_INCLUDE_DIR})
>>> 
>>> string(REPLACE "-framework Cocoa" "" SDL_LIBRARY ${SDL_LIBRARY})
>>> 
>>> set_source_files_properties(${SDL_LIBRARY} PROPERTIES
>>> MACOSX_PACKAGE_LOCATION Frameworks)
>>> 
>>> add_executable(myapp MACOSX_BUNDLE main.cpp ${SDL_LIBRARY})
>>> 
>>> target_link_libraries(myapp ${SDL_LIBRARY} SDLmain "-framework Cocoa")
>>> 
>>> Then I do:
>>> cmake
>>> make
>>> 
>>> And that's what I get:
>>> Error copying file "/Library/Frameworks/SDL.framework" to
>>> "myapp.app/Contents/Frameworks/SDL.framework".
>>> make[2]: *** [myapp.app/Contents/Frameworks/SDL.framework] Error 1
>>> make[1]: *** [CMakeFiles/myapp.dir/all] Error 2
>>> make: *** [all] Error 2
>>> 
>>> However, if I do:
>>> cmake -G Xcode
>>> 
>>> And then I open the generated Xcode project and do compile, all is working
>>> properly.
>>> What should I do?
>>> It's just a bug?
>>> 
>>> Thanks,
>>> Franciso Requena.
>>> 
>>> 
>>> I use the lastest CMake version (git cloned). It's 2.9.20100304.
>>> ___
>>> 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

Re: [CMake] OS X, embedding Frameworks and generator problems

[Francisco Requena]

So how do I embeed a framework on an OS X bundle?
Jjgod Jiang has the same problem here:
http://www.cmake.org/pipermail/cmake/2009-September/031713.html

2010/3/5 David Cole 

> SDL_library is not a source file, so don't call:
>   set_source_files_properties
> on it...
>
> That should eliminate the spurious content copy attempt...
>
>
> On Thu, Mar 4, 2010 at 6:17 PM, Francisco Requena wrote:
>
>> Hi,
>>
>> I'm trying to develop a simple application using SDL on OS X. Here's my
>> CMakeLists.txt:
>>
>> cmake_minimum_required(VERSION 2.8)
>>
>> project(newapp)
>>
>> include(FindSDL)
>> include(FindOpenGL)
>>
>> include_directories(${SDL_INCLUDE_DIR})
>>
>> string(REPLACE "-framework Cocoa" "" SDL_LIBRARY ${SDL_LIBRARY})
>>
>> set_source_files_properties(${SDL_LIBRARY} PROPERTIES
>> MACOSX_PACKAGE_LOCATION Frameworks)
>>
>> add_executable(myapp MACOSX_BUNDLE main.cpp ${SDL_LIBRARY})
>>
>> target_link_libraries(myapp ${SDL_LIBRARY} SDLmain "-framework Cocoa")
>>
>> Then I do:
>> cmake
>> make
>>
>> And that's what I get:
>> Error copying file "/Library/Frameworks/SDL.framework" to
>> "myapp.app/Contents/Frameworks/SDL.framework".
>> make[2]: *** [myapp.app/Contents/Frameworks/SDL.framework] Error 1
>> make[1]: *** [CMakeFiles/myapp.dir/all] Error 2
>> make: *** [all] Error 2
>>
>> However, if I do:
>> cmake -G Xcode
>>
>> And then I open the generated Xcode project and do compile, all is working
>> properly.
>> What should I do?
>> It's just a bug?
>>
>> Thanks,
>> Franciso Requena.
>>
>>
>> I use the lastest CMake version (git cloned). It's 2.9.20100304.
>> ___
>> 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