Re: [CMake] Placing debug and release version of the same library in single installer?

2007-03-13 Thread Tristan Carel

On 3/13/07, Kedzierski,  Artur CIV NAVSURFWARCENDIV CORONA
[EMAIL PROTECTED] wrote:




Hi,

I am creating a package (using CPack) of one of our libraries.
On Window side, I would like to be able to place Debug and Release
versions of that library in the single installer. Any idea on how to do
that?
Thank You.


Hi Artur,

In the CMake mailing-list archive:
http://www.cmake.org/pipermail/cmake/2006-November/011970.html
I have used it since, it works well.

--
Tristan Carel
Music with dinner is an insult both to the cook and the violinist.
http://www.tristan-carel.com
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake


[CMake] Re: FindSDL.cmake and mingw / msys

2007-03-13 Thread PA Galmes

On 2/24/07, PA Galmes [EMAIL PROTECTED] wrote:


Hello,

I've been playing for some days with cmake, and I have
to say that I quite love the way it works. But while trying
to compile a sourceforge project under Windows using
MSYS, I run into a problem.

I do not know if the problem is related to the
CMakeLists.txt that I did not wrote correctly or to an
issue into the FindSDL.cmake. That's why I write here.



I reported an issue about this:
http://www.cmake.org/Bug/bug.php?op=showbugid=4539pos=0

Could anyone help me determine where the problem comes from?

Regards,

--

Pierre-André Galmes
Free Software consultant
StarXpert - www.starxpert.fr
6, rue Eugène Varlin - 75010 Paris
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Re: FindSDL.cmake and mingw / msys

2007-03-13 Thread Werner Smekal

Hi,

reading the bug report, the problem is:

# MinGW needs an additional library, mwindows
# It's total link flags should look like -lmingw32 -lSDLmain -lSDL 
-lmwindows

# (Actually on second look, I think it only needs one of the m* libraries.)
IF(MINGW)
 SET(MINGW32_LIBRARY mingw32 CACHE STRING mwindows for MinGW)
ENDIF(MINGW)

MSYS!=MINGW for CMake for good reasons. The best solution would be to 
use the MinGW compiler within normal Windows CLI, since it's so much 
faster than MSYS, you won't regret it. Another solution would be to 
change the lines above to


IF(MINGW AND MSYS)
 SET(MINGW32_LIBRARY mingw32 CACHE STRING mwindows for MinGW)
ENDIF(MINGW AND MSYS)

and similar code in  FindSDL.cmake. This should work  than.

Regards,
Werner


PA Galmes wrote:



On 2/24/07, *PA Galmes* [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED] wrote:


Hello,

I've been playing for some days with cmake, and I have
to say that I quite love the way it works. But while trying
to compile a sourceforge project under Windows using
MSYS, I run into a problem.

I do not know if the problem is related to the
CMakeLists.txt that I did not wrote correctly or to an
issue into the FindSDL.cmake . That's why I write here.

 
I reported an issue about this:
http://www.cmake.org/Bug/bug.php?op=showbugid=4539pos=0 
http://www.cmake.org/Bug/bug.php?op=showbugid=4539pos=0
 
Could anyone help me determine where the problem comes from?
 
Regards,


-- 
Pierre-André Galmes

Free Software consultant
StarXpert - www.starxpert.fr http://www.starxpert.fr
6, rue Eugène Varlin - 75010 Paris 




___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake



--
Dipl. Ing. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria

email: [EMAIL PROTECTED]
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

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake


Re: [CMake] Re: How to nuke a directory (for 'make clean')?

2007-03-13 Thread Philippe Poilbarbe

Matthew Woehlke a écrit :
(Sorry if this double-posts, gmane appears to have rejected it the 
first time due to server system load.)


Alexander Neundorf wrote:

...
I didn't test, but you could try SET_DIRECTORY_PROPERTIES( 
ADDITIONAL_MAKE_CLEAN_FILES ) , but I'm not sure it also works with 
directories. You could also create a using 
ADD_CUSTOM_TARGET(doxyclean ... ) which calls cmake -E ... to remove 
the directory and make this target depend on the clean target.


No, it doesn't... I already tried this:

SET_DIRECTORY_PROPERTIES(PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES doc/)

...and it doesn't work. Maybe this should be a bug/RFE?


At now, I have done this with a ADD_CUSTOM_TARGET(distclean)
which depends on clean and launches a perl script doing the
job (named with a .pl extension in order to be seen as
a script even on windows).

I did also post a feature request (2937) in order to be able to delete
a directory with a command line option of cmake -E. It allows
being able to delete a directory in the same portable way,
as done with the script above but without a perl dependency.
It has just been implemented: the mail for a closed status has
been sent today :) . The command is cmake -E remove_directory
which removes the directory and all its content (files/subdirs).

And maybe the ability of deleting directories from
ADDITIONAL_MAKE_CLEAN_FILES have been
implemented (which would be consistent).

--
Philippe Poilbarbe
CLS - Space Oceanography Division
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake


Re: [CMake] Re: FindSDL.cmake and mingw / msys

2007-03-13 Thread PA Galmes

On 3/13/07, Werner Smekal [EMAIL PROTECTED] wrote:


Hi,



Hi Wermer




reading the bug report, the problem is:

# MinGW needs an additional library, mwindows
# It's total link flags should look like -lmingw32 -lSDLmain -lSDL
-lmwindows
# (Actually on second look, I think it only needs one of the m*
libraries.)
IF(MINGW)
SET(MINGW32_LIBRARY mingw32 CACHE STRING mwindows for MinGW)
ENDIF(MINGW)

MSYS!=MINGW for CMake for good reasons. The best solution would be to
use the MinGW compiler within normal Windows CLI, since it's so much
faster than MSYS, you won't regret it. Another solution would be to
change the lines above to

IF(MINGW AND MSYS)
SET(MINGW32_LIBRARY mingw32 CACHE STRING mwindows for MinGW)
ENDIF(MINGW AND MSYS)

and similar code in  FindSDL.cmake. This should work  than.



Thanks for the comments. I need to try that and I will come back to you with
the results
of my experiments.

If you are right, shouldn't those modifications be included in a next
release of the FindSDL.cmake?

Regards,




--
Pierre-André Galmes
Free Software consultant
StarXpert - www.starxpert.fr
6, rue Eugène Varlin - 75010 Paris
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Re: How to nuke a directory (for 'make clean')?

2007-03-13 Thread Matthew Woehlke

Philippe Poilbarbe wrote:

Matthew Woehlke a écrit :

Alexander Neundorf wrote:
I already tried this:

SET_DIRECTORY_PROPERTIES(PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES doc/)

...and it doesn't work. Maybe this should be a bug/RFE?


At now, I have done this with a ADD_CUSTOM_TARGET(distclean)
which depends on clean and launches a perl script doing the
job (named with a .pl extension in order to be seen as
a script even on windows).

I did also post a feature request (2937) in order to be able to delete
a directory with a command line option of cmake -E. It allows
being able to delete a directory in the same portable way,
as done with the script above but without a perl dependency.
It has just been implemented: the mail for a closed status has
been sent today :) . The command is cmake -E remove_directory
which removes the directory and all its content (files/subdirs).

And maybe the ability of deleting directories from
ADDITIONAL_MAKE_CLEAN_FILES have been
implemented (which would be consistent).


Ok, thanks for the info. I'll watch for an updated version.

--
Matthew
HIPPOS feel unacknowledged. HIPPOS get angry.
 PRAISE HIPPOS
HIPPOS seem somewhat placated.

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake


[CMake] Problems with Qt MOC and conditional compilation.

2007-03-13 Thread Tim Sutton

Hi all

Can someone help me with getting conditionally #defined code blog to
compile using cmake?
My CmakeLists.txt file has: ADD_DEFINITIONS(-DWITH_QGIS) and I have
some code blocks in .h and .cpp that conditionally compile based on
this e.g.

#ifdef WITH_QGIS
   foo...
#endif

The problem I have is that only the ifdefs in the .cpp are properly
being entered into  compiled, while in the .h the code is skipped. My
theory is this is because the -DWITH_QGIS is not being passed along to
MOC when it is run on the header file.

87 #ifdef WITH_QGIS
88   void zoomInMode();
89   void zoomOutMode();
  etc...
99 #endif

If I comment out the ifdef, MOC runs and my Qt slots work properly.
Has anyone encountered a similar issue? I am using cmake version
2.4-patch 5 on ubuntu feisty. When compiled with qmake the same code
works fine so I am thinking this is coming back to the way that cmake
is calling moc?

Many thanks!

--
--
Tim Sutton

Visit http://qgis.org for a great Open Source GIS
Home Page: http://linfiniti.com
Skype: timlinux
MSN: [EMAIL PROTECTED]
Yahoo: [EMAIL PROTECTED]
Jabber: timlinux
Irc: timlinux on #qgis at freenode.net
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake


Re: [CMake] Re: FindSDL.cmake and mingw / msys

2007-03-13 Thread PA Galmes




On 3/13/07, Werner Smekal [EMAIL PROTECTED] wrote:

 Hi,


Hi Wermer



 reading the bug report, the problem is:

 # MinGW needs an additional library, mwindows
 # It's total link flags should look like -lmingw32 -lSDLmain -lSDL
 -lmwindows
 # (Actually on second look, I think it only needs one of the m*
 libraries.)
 IF(MINGW)
 SET(MINGW32_LIBRARY mingw32 CACHE STRING mwindows for MinGW)
 ENDIF(MINGW)

 MSYS!=MINGW for CMake for good reasons. The best solution would be to
 use the MinGW compiler within normal Windows CLI, since it's so much
 faster than MSYS, you won't regret it.



Ok, so I just tested you proposal. What I did:

- launched CMake,
- selected MINGW,
- configured a few variables (QT_QMAKE_EXECUTABLE, SDLIMAGE_INCLUDE_DIR,
SDLIMAGE_LIBRARY, SDL_INCLUDE_DIR, SDLMAIN_LIBRARY).
- generated the makefiles.

- click on start menu, and click on the launcher.
- launched cmd (I suppose that this is what you called Windows CLI)
- went to the directory
- launched mingw32-make.exe

And the error is the same as before. The build.make is the same as before
(I copied the linking part at the end of this mail).
Any idea?

I would like to check the value of the variables in the FindSDL.cmake (like
MINGW...) when I try to compile
my program. Is this possible?

Can the problem be relevant to the fact that I am using the MINGW version
coming with Qt ?





Another solution would be to
 change the lines above to

 IF(MINGW AND MSYS)
 SET(MINGW32_LIBRARY mingw32 CACHE STRING mwindows for MinGW)
 ENDIF(MINGW AND MSYS)

 and similar code in  FindSDL.cmake. This should work  than.





Currently, I suppose that the first issue is not related to that, as even
with
MINGW it does not work...

Any idea?



the build.make:

# External object files for target bloodybeard
bloodybeard_EXTERNAL_OBJECTS =

bloodybeard.exe: CMakeFiles/bloodybeard.dir/main.obj
bloodybeard.exe: CMakeFiles/bloodybeard.dir/qGameEngine.obj
bloodybeard.exe: CMakeFiles/bloodybeard.dir/moc_qGameEngine.obj
bloodybeard.exe: lib/SDL_image.lib
bloodybeard.exe: lib/libSDLmain.a
bloodybeard.exe: C:/Qt/4.2.1/lib/libQtCore4.a
bloodybeard.exe: CMakeFiles/bloodybeard.dir/build.make
@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --red --bold
Linking CXX executable bloodybeard.exe
$(CMAKE_COMMAND) -P CMakeFiles\bloodybeard.dir\cmake_clean_target.cmake
C:\MinGW\bin\g++.exe   $(bloodybeard_OBJECTS)
$(bloodybeard_EXTERNAL_OBJECTS)  -o
bloodybeard.exe-Wl,--major-image-version,0,--minor-image-version,0
-Le:\dev\bloodybeard\bloodybeard\trunk\src\lib -Lc:\Qt\4.2.1\lib -lSDL_image
-Wl,-Bstatic -lSDLmain -lQtCore4 -Wl,-Bdynamic -lWs2_32


--
Pierre-André Galmes
Free Software consultant
StarXpert - www.starxpert.fr
6, rue Eugène Varlin - 75010 Paris
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Add a .obj file to a library

2007-03-13 Thread Anton Deguet
I tried a couple more things.   Since the paths were compounded I  
assumed this was because I could only add files defined with a  
relative path (wrt the source directory).   So I tried to convert the  
absolute path into a relative path using:


FILE(RELATIVE_PATH
  FILE_IN_RELATIVE_PATH
  ${CMAKE_CURRENT_SOURCE_DIR}
  ${FILE_IN_ABSOLUTE_PATH})

This works only if the source directory and the directory containing  
the .obj file are on the same drive.  In my case, the obj file in on  
C: while my source directory is on N:   and I don't know if one can  
define a relative path between two drives on Windows.


I there a way to tag a source file as defined with absolute path?

Anton


On Mar 9, 2007, at 12:15 PM, Anton Deguet wrote:


Hello,

I am trying to add a pre-compiled object in a library.  I am  
generating a solution for  Microsoft Visual Studio .net 2003  
using CMake 2.4.5.   I used FIND_FILE to locate the .obj file and  
then simply add it to the list of source files for my library.   I  
found a couple of reference on the web related to this problem so I  
was hopeful.


It doesn't work as is because CMake prepends the current source  
path to my file name (which already contains a full path).   So I  
get a message stating that C:/current-source-path/C:/path-to-my- 
obj/file.obj can not be found.   Is there an easy way to tell  
CMake to not prepend the current source path?


Also, all examples found on the web referred to .o files but not  
.obj files.  I am pretty sure that CMake can handle this  
difference but I just wanted verify.


Thanks,

Anton



---
Anton Deguet, Research Engineer, ERC-CISST, Johns Hopkins University
[EMAIL PROTECTED], 410-516-5261
iChat only: [EMAIL PROTECTED]



___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Problems with Qt MOC and conditional compilation.

2007-03-13 Thread Filipe Sousa

Tim Sutton wrote:

Hi all

Can someone help me with getting conditionally #defined code blog to
compile using cmake?
My CmakeLists.txt file has: ADD_DEFINITIONS(-DWITH_QGIS) and I have
some code blocks in .h and .cpp that conditionally compile based on
this e.g.

#ifdef WITH_QGIS
foo...
#endif

The problem I have is that only the ifdefs in the .cpp are properly
being entered into  compiled, while in the .h the code is skipped. My
theory is this is because the -DWITH_QGIS is not being passed along to
MOC when it is run on the header file.

 87 #ifdef WITH_QGIS
 88   void zoomInMode();
 89   void zoomOutMode();
   etc...
 99 #endif

If I comment out the ifdef, MOC runs and my Qt slots work properly.
Has anyone encountered a similar issue? I am using cmake version
2.4-patch 5 on ubuntu feisty. When compiled with qmake the same code
works fine so I am thinking this is coming back to the way that cmake
is calling moc?

Many thanks!


I've been looking into to the code and the preprocessor definitions is 
missing


Add this code after QT4_GET_MOC_INC_DIRS(moc_includes) to the macro 
QT4_WRAP_CPP (FinfQt4.cmake) and see if it works:


GET_DIRECTORY_PROPERTY(_flags DEFINITIONS)
SEPARATE_ARGUMENTS(_flags)
LIST(APPEND moc_includes ${_flags})

I didn't test
--
Filipe Sousa


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake


[CMake] Re: FindSDL.cmake and mingw / msys

2007-03-13 Thread E. Wing

Hi Werner,
I was curious if you saw any other glaring problems with the
FindSDL.cmake module, particularly with the Msys and MinGW stuff? I
put most of that together by trial and error without really any
understanding of it (like what do mingw32 and mwindows libraries
provide). And obviously I never separated Msys and MinGW. (I never
managed to get MinGW to do anything useful for me without Msys.)

Thanks,
Eric



From: Werner Smekal [EMAIL PROTECTED]
Subject: Re: [CMake] Re: FindSDL.cmake and mingw / msys
To: PA Galmes [EMAIL PROTECTED]
Cc: cmake@cmake.org
Message-ID: [EMAIL PROTECTED]
Content-Type: text/plain; charset=UTF-8; format=flowed

Hi,

reading the bug report, the problem is:

# MinGW needs an additional library, mwindows
# It's total link flags should look like -lmingw32 -lSDLmain -lSDL
-lmwindows
# (Actually on second look, I think it only needs one of the m* libraries.)
IF(MINGW)
  SET(MINGW32_LIBRARY mingw32 CACHE STRING mwindows for MinGW)
ENDIF(MINGW)

MSYS!=MINGW for CMake for good reasons. The best solution would be to
use the MinGW compiler within normal Windows CLI, since it's so much
faster than MSYS, you won't regret it. Another solution would be to
change the lines above to

IF(MINGW AND MSYS)
  SET(MINGW32_LIBRARY mingw32 CACHE STRING mwindows for MinGW)
ENDIF(MINGW AND MSYS)

and similar code in  FindSDL.cmake. This should work  than.

Regards,
Werner


PA Galmes wrote:

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake


[CMake] How to set sensible Universal Binary options in OS X by default

2007-03-13 Thread E. Wing

So I would like to set the Universal Binary options as the default for
my project when on Apple. The issue is the options need to be
different for different versions of OS X.
In 10.4, I want to build ppc;i386. The SDK path must be set to 10.4u.
In 10.5, I want to build ppc;i386;ppc64;x86_64. I'm presuming the SDK
path should be set to a 10.5 thing.
In 10.3 and lower, Universal Binaries can't be built so none of this applies.

Is there an elegant way to do this? My not so elegant solution/thought
is to check OS X version numbers and case the thing. But how can I
detect the OS version number with CMake? The Darwin version number
isn't reliable for this case since Darwin may be upgraded
independently of the OS X version. (There is a corner case too where
it would help to know the Xcode version installed. 2.0 didn't have
Universal Binary support; the support was introduced in 2.1. But I
might not worry about this case if it's too hard.)

(It would be kind of nice if CMake would automatically pick these
defaults on the appropriate system. It's easier to for a user to
delete the options than figure out what the appropriate switches are.)

Thanks,
Eric
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake


Re: [CMake] Problems with Qt MOC and conditional compilation.

2007-03-13 Thread Tim Sutton

Hi Filipe

Many thanks for your response. I altered FindQt4 to look like this:

734   MACRO (QT4_WRAP_CPP outfiles )
735 # get include dirs
736 QT4_GET_MOC_INC_DIRS(moc_includes)
737
738 #Added by Tim at the suggestion of Filipe Sousa on the cmake
mailing list
739 #so that compiler flags get passed to moc properly
740 GET_DIRECTORY_PROPERTY(_flags DEFINITIONS)
741 SEPARATE_ARGUMENTS(_flags)
742 LIST(APPEND moc_includes ${_flags})
743
744 FOREACH (it ${ARGN})
745   GET_FILENAME_COMPONENT(it ${it} ABSOLUTE)
746   GET_FILENAME_COMPONENT(outfile ${it} NAME_WE)
747
748   SET(outfile ${CMAKE_CURRENT_BINARY_DIR}/moc_${outfile}.cxx)
749   ADD_CUSTOM_COMMAND(OUTPUT ${outfile}
750 COMMAND ${QT_MOC_EXECUTABLE}
751 ARGS ${moc_includes} -o ${outfile} ${it}
752 DEPENDS ${it})
753   SET(${outfiles} ${${outfiles}} ${outfile})
754 ENDFOREACH(it)
755
756   ENDMACRO (QT4_WRAP_CPP)

When I try to compile (using make VERBOSE=1) now I get the following error:

[ 51%] Generating moc_omgmainwindow.cxx
cd /home/timlinux/dev/cpp/openModellerDesktop/build/src/gui 
/usr/bin/moc-qt4 -I /usr/include/qt4 -I /usr/include/qt4/Qt3Support -I
/usr/include/qt4/QtSvg -I /usr/include/qt4/QtGui -I
/usr/include/qt4/QtXml -I /usr/include/qt4/QtNetwork -I
/usr/include/qt4/QtCore -DWITH_QGIS -DOMG_NO_EXPERIMENTAL -DQT_SHARED
-DQT_3SUPPORT_LIB -DQT3_SUPPORT -DQT_SVG_LIB -DQT_GUI_LIB -DQT_XML_LIB
-DQT_NETWORK_LIB -DQT_CORE_LIB -Wall -Werror -DCORE_EXPORT=
-DPLUGIN_EXPORT= -DGUI_EXPORT= -o
/home/timlinux/dev/cpp/openModellerDesktop/build/src/gui/moc_omgmainwindow.cxx
/home/timlinux/dev/cpp/openModellerDesktop/src/gui/omgmainwindow.h
moc: Invalid argument
Usage: moc [options] header-file
 -ofile   write output to file rather than stdout
 -Idiradd dir to the include path for header files
 -E preprocess only; do not generate meta object code
 -Dmacro[=def]  define macro, with optional definition
 -Umacro  undefine macro
 -i do not generate an #include statement
 -ppath   path prefix for included file
 -f[file] force #include, optional file name
 -nwdo not display warnings
 -v display version of moc
make[2]: *** [src/gui/moc_omgmainwindow.cxx] Error 1
make[2]: Leaving directory `/home/timlinux/dev/cpp/openModellerDesktop/build'
make[1]: *** [src/gui/CMakeFiles/openModellerDesktop.dir/all] Error 2
make[1]: Leaving directory `/home/timlinux/dev/cpp/openModellerDesktop/build'
make: *** [all] Error 2

I tried manually editing the above and running it to include only
'-DFoo' options e.g.:

cd /home/timlinux/dev/cpp/openModellerDesktop/build/src/gui 
/usr/bin/moc-qt4 -DWITH_QGIS -DOMG_NO_EXPERIMENTAL -DQT_SHARED
-DQT_3SUPPORT_LIB -DQT3_SUPPORT -DQT_SVG_LIB -DQT_GUI_LIB -DQT_XML_LIB
-DQT_NETWORK_LIB -DQT_CORE_LIB -DCORE_EXPORT= -DPLUGIN_EXPORT=
-DGUI_EXPORT= -o
/home/timlinux/dev/cpp/openModellerDesktop/build/src/gui/moc_omgmainwindow.cxx
/home/timlinux/dev/cpp/openModellerDesktop/src/gui/omgmainwindow.h

And moc ran successfully and when I did a make install the program
behaved correctly with slots defined in the header working as
expected.

I'm just not familiar enough with cmake to know how to adjust your
macro update so it only includes -D options and not -w etc.

Regards

Tim

--
--
Tim Sutton

Visit http://qgis.org for a great Open Source GIS
Home Page: http://linfiniti.com
Skype: timlinux
MSN: [EMAIL PROTECTED]
Yahoo: [EMAIL PROTECTED]
Jabber: timlinux
Irc: timlinux on #qgis at freenode.net
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake


Re: [CMake] Re: FindSDL.cmake and mingw / msys

2007-03-13 Thread E. Wing

From: PA Galmes [EMAIL PROTECTED]


Looking at your bug report, SDL_LIBRARY shouldn't be empty. This is
your problem. For Windows, you need at least SDLmain and SDL. I'm not
sure why these variables are empty. It could be a bug in the script.
Did you manually set the SDL_LIBRARY in your CMakeSetup or did it
auto-find the value?

-Eric
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake


Re: [CMake] How to set sensible Universal Binary options in OS X by default

2007-03-13 Thread Bill Hoffman

E. Wing wrote:

So I would like to set the Universal Binary options as the default for
my project when on Apple. The issue is the options need to be
different for different versions of OS X.
In 10.4, I want to build ppc;i386. The SDK path must be set to 10.4u.
In 10.5, I want to build ppc;i386;ppc64;x86_64. I'm presuming the SDK
path should be set to a 10.5 thing.
In 10.3 and lower, Universal Binaries can't be built so none of this 
applies.


Is there an elegant way to do this? My not so elegant solution/thought
is to check OS X version numbers and case the thing. But how can I
detect the OS version number with CMake? The Darwin version number
isn't reliable for this case since Darwin may be upgraded
independently of the OS X version. (There is a corner case too where
it would help to know the Xcode version installed. 2.0 didn't have
Universal Binary support; the support was introduced in 2.1. But I
might not worry about this case if it's too hard.)

(It would be kind of nice if CMake would automatically pick these
defaults on the appropriate system. It's easier to for a user to
delete the options than figure out what the appropriate switches are.)

The current approach is to detect the SDK path on the machine.
If 10.4u is on the machine then put the variable OSX_ARCHS in
the cache, if not then it must be an older xcode or OS.  You could
do the same thing with your project.  IF(EXISTS ...)

-Bill


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake


[CMake] CMake and profiling...

2007-03-13 Thread Asmodehn Shade
Hi everyone,

I am currently in the process of starting to profile my software.
It builds with cmake on unix, linux, and windows, more or less nicely ;)
Assuming that I only want to use g++ with gprof right now, I wonder if there 
was a way to do that smartly in CMake,
other than resetting the CXX_FLAGS and LINKER_FLAGS around all my 
CMakeLists.txt...
I got projects and subprojects, and dependencies around with some tests...

Is there already some functions handling that in CMake ?
although its not in the documentation, I wonder :
- Is there something doable about that in a multi platform way ?
- should I handle every profiler on different platform myself with some custom 
FindProfiler UseProfiler and so on ?
- other solutions ?

I am not aware of any profiler that can go well with cmake, but I thought I 
just ask, in case someone knows something about it ;)

Thanks a lot everyone ;)

Keep it on !!!

--
Asmodehn
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake


Re: [CMake] Re: FindSDL.cmake and mingw / msys

2007-03-13 Thread Werner Smekal

Hi Pierre,

okay, I looked at FindSDL.cmake more carefully. First I think you should 
make sure that SDL is actually found. You should have something like 
this in you cmakeLists.txt:


find_package(SDL)
if( NOT SDL_FOUND )
   message( Warning: SDL not found )
endif( NOT SDL_FOUND )

or since you need it anyway for your package:

find_package(SDL REQUIRED)

than cmake stops if SDL isn't found (actually not, since FindSDL.cmake 
misses this feature :).


Anyway, from what I see, you set the path SDLMAIN_LIBRARY, but libsdl.a 
is not found, since you don't tell it where to find it. it is much 
better to use environment variables here, e.g.


set CMAKE_LIBRARY_PATH=c:\sdl\lib
set CMAKE_INCLUDE_PATH=c:\sdl\include
cmake ..

or for msys

export CMAKE_LIBRARY_PATH=pathtosdl/lib
export CMAKE_INCLUDE_PATH=pathtosdl/include
cmake ..

Than if cmake looks for includes (any kind) it also searches in 
CMAKE_INCLUDE_PATH and if it looks for libraries (any kind) it searches 
in also CMAKE_LIBRARY_PATH. FindSDL.cmake should than find automatically 
the sdl headers and the libraries, I assume they are in the same 
directory. If not you could set it like that:


export CMAKE_LIBRARY_PATH=pathtosdl/lib/main:pathtosdl/lib/image

But still you need to change BOTH (!) IF(MINGW) clauses to IF(MINGW 
AND MSYS) if you want to use msys.


HTH,
Werner

PA Galmes wrote:
 
- launched CMake,

- selected MINGW,
- configured a few variables (QT_QMAKE_EXECUTABLE, 
SDLIMAGE_INCLUDE_DIR, SDLIMAGE_LIBRARY, SDL_INCLUDE_DIR, SDLMAIN_LIBRARY).

- generated the makefiles.
 
- click on start menu, and click on the launcher.

- launched cmd (I suppose that this is what you called Windows CLI)
- went to the directory
- launched mingw32-make.exe
 
And the error is the same as before. The build.make is the same as 
before (I copied the linking part at the end of this mail).

Any idea?
 
I would like to check the value of the variables in the FindSDL.cmake 
(like MINGW...) when I try to compile

my program. Is this possible?
 
Can the problem be relevant to the fact that I am using the MINGW 
version coming with Qt ?
 
 
 


Another solution would be to
change the lines above to

IF(MINGW AND MSYS)
SET(MINGW32_LIBRARY mingw32 CACHE STRING mwindows for MinGW)
ENDIF(MINGW AND MSYS)

and similar code in  FindSDL.cmake. This should work  than.

 

 
Currently, I suppose that the first issue is not related to that, as 
even with

MINGW it does not work...
 
Any idea?
 


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake


Re: [CMake] CMake and profiling...

2007-03-13 Thread Brandon J. Van Every

Asmodehn Shade wrote:

Hi everyone,

I am currently in the process of starting to profile my software.
It builds with cmake on unix, linux, and windows, more or less nicely ;)
Assuming that I only want to use g++ with gprof right now, I wonder if there 
was a way to do that smartly in CMake,
other than resetting the CXX_FLAGS and LINKER_FLAGS around all my 
CMakeLists.txt...
  


You need to clean up your CMAKE_CXX_FLAGS and so forth so they are set 
in 1 user controllable place.




Is there already some functions handling that in CMake ?
  


Not for profiling.  Not for optimization either, other than Release 
giving you sane defaults.  Nothing for CPU architecture specification 
either. 




- should I handle every profiler on different platform myself with some custom 
FindProfiler UseProfiler and so on ?
  


Do you actually need to profile on all platforms, or is this 
theoretical?  If it's theoretical, I'd say skip the busywork.



Cheers,
Brandon Van Every

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake


Re: [CMake] CMake and profiling...

2007-03-13 Thread Filipe Sousa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Brandon J. Van Every wrote:
 Asmodehn Shade wrote:
 Hi everyone,

 I am currently in the process of starting to profile my software.
 It builds with cmake on unix, linux, and windows, more or less nicely ;)
 Assuming that I only want to use g++ with gprof right now, I wonder if there 
 was a way to do that smartly in CMake,
 other than resetting the CXX_FLAGS and LINKER_FLAGS around all my 
 CMakeLists.txt...
   
 
 You need to clean up your CMAKE_CXX_FLAGS and so forth so they are set 
 in 1 user controllable place.

It's possible to create a new set of flags through CMAKE_BUILD_YTPE

SET(CMAKE_BUILD_TYPE Profile)
SET(CMAKE_CXX_FLAGS_PROFILE ...)
SET(CMAKE_C_FLAGS_PROFILE ...)

 Is there already some functions handling that in CMake ?
   
 
 Not for profiling.  Not for optimization either, other than Release 
 giving you sane defaults.  Nothing for CPU architecture specification 
 either. 
 
 
 - should I handle every profiler on different platform myself with some 
 custom FindProfiler UseProfiler and so on ?
   
 
 Do you actually need to profile on all platforms, or is this 
 theoretical?  If it's theoretical, I'd say skip the busywork.
 
 
 Cheers,
 Brandon Van Every
 
 ___
 CMake mailing list
 CMake@cmake.org
 http://www.cmake.org/mailman/listinfo/cmake
 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFF9yL7bQdNYqwwwCwRAk1pAJ9L3EKbBVPHN7wvxQZCzB/IwU//0ACglwUC
72EGxmUCXUwVb4DQ7mILNhc=
=ZO9O
-END PGP SIGNATURE-
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake