Re: [CMake] A iconv check cmake file
Am Freitag 19 Oktober 2007 schrieb eddy xu: I have not found one module to find iconv library in cmake, so I wrote one, here is the code: # Find iconv library # # Author: Eddy Xu [EMAIL PROTECTED] # # Released under BSD license # # ICONV_INCLUDE_DIRS - where to find iconv.h, etc # ICONV_LIBRARIES - Lists of libraries when using iconv # ICONV_FOUND - True if iconv found # Look for the header file FIND_PATH( ICONV_INCLUDE_DIR NAMES iconv.h ) MARK_AS_ADVANCED( ICONV_INCLUDE_DIR ) # Look for the library FIND_LIBRARY( ICONV_LIBRARY NAMES iconv ) MARK_AS_ADVANCED( ICONV_LIBRARY ) This is not sufficient. Iconv may also be used with GNU libc and then doesn't need an additional library. Thus, you have to test for a symbol. HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake2.5 - wrong default install location for mingw
Bill Hoffman wrote:
Not really true, cygwin has its own symlinks. See here:
http://www.cygwin.com/cygwin-ug-net/using.html
That's not a symlink. That's a mount point.
And it does not effect anything I said. Just try putting such a mount
point on PATH (which is special). It will get translated automatically
whenever you call a DOS or windows app to an actual UNC or DOS path.
Also see here:
http://www.mingw.org/MinGWiki/index.php/Shells%2C%20terminals%20and%20MSYS
Again, no contradiction to what I said. cmake must run from one top
shell or console, regardless of how many are nested. That's the one you
look as reference.
That's why I said looking at the envvar is a hack, while doing it with
win32api is the proper way.
So, even if you figured out what shell you were running from, you
still could not write to /usr/local because that directory does not
exist to a windows program.
No. Did you read what I wrote?
Here's some code which may be easier. I have MSYS and a standalone Ruby
NOT compiled for msys.
$ cat /etc/fstab
c:/msys/1.0/mingw /mingw
c:/ActiveState/perl /perl
$ echo $PATH
/usr/local/bin:/mingw/bin:/bin:/perl
# here i print path from ruby
$ /C/ruby/bin/ruby.exe -e puts ENV['PATH']
C:\msys\1.0\local\bin;c:\msys\1.0\mingw\bin;C:\msys\1.0\bin;c:\ActiveState\perl
# here I find sh.exe in path
$ /C/ruby/bin/ruby.exe -e puts ENV['PATH'].split(';').find {|dir|
File.exists?( dir + '/sh.exe' ) }
C:\msys\1.0\bin
# here I get /usr/local
$ /C/ruby/bin/ruby.exe -e puts ENV['PATH'].split(';').find {|dir|
File.exists?( dir + '/sh.exe' ) } + '../local'
C:\msys\1.0\bin\..\local
Explanation:
Find 'sh.exe' in $PATH. PATH already has a DOS or UNC path from the
MSYS/CYGWIN paths, regardless of how many mount points or 'symlinks'
msys or cygwin uses.
From it, you have /usr/local by doing ../local ( or just .. if sh.exe
happens to weirdly be in (ROOT)/local/bin which you can know from the
word local in it). Under any Unix (Linux) layer, sh.exe is not supposed
to be installed ANYWHERE else and must exist in some form.
MSYS and CYGWIN *MUST* translate PATH to a windows equivalent or else
child programs would not work correctly. Other vars, like
LD_LIBRARY_PATH don't get this special treatment.
--
Gonzalo Garramuño
[EMAIL PROTECTED]
AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake2.5 - wrong default install location for mingw
On 20.10.07 06:17:56, Gonzalo Garramuño wrote: Andreas Pakulat wrote: But exactly that is not supposed to happen. Why not? Maybe I was not clear: Or maybe I didn't read that part of the thread :) cmake2.5 has a MSYS Makefile generator. Aah, ok. I take back all I said. The MSYS Makefile generator of course should follow msys standards and thus accept that this is a posix-environment with paths like /usr/local. I did -G MSYS Makefile and I got an install on $PROGRAMFILES. That's not correct. If I wanted to install in $PROGRAMFILES, there's NMake Makefiles or many of the other Windows specific generators. Or MINGW Makefiles ;) Andreas -- You look tired. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] defining preprocessor statements
Hi, How do we define a preprocessor statement - in win32 projects you usually need to see the following in the C/C++ - Preprocessor statements section: _WIN32, _WINDOWS ...etc so in the CMakeLists.txt, what syntax is used to put that into the generated project files? Thanks, Mark ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] defining preprocessor statements
Use ADD_DEFINITIONS: ADD_DEFINITIONS(-DWIN32 -DWINDOWS) - Stefan Mark Wyszomierski schrieb: Hi, How do we define a preprocessor statement - in win32 projects you usually need to see the following in the C/C++ - Preprocessor statements section: _WIN32, _WINDOWS ...etc so in the CMakeLists.txt, what syntax is used to put that into the generated project files? Thanks, Mark ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] defining preprocessor statements
Thanks Stefan. When I do that, I see the following text in the Preprocessor Definitions field (in vc++ 2005): ,WIN32,WINDOWS, I'm wondering if the leading and trailing commas will be a problem? Thanks, Mark On 10/20/07, Stefan Buschmann [EMAIL PROTECTED] wrote: Use ADD_DEFINITIONS: ADD_DEFINITIONS(-DWIN32 -DWINDOWS) - Stefan Mark Wyszomierski schrieb: Hi, How do we define a preprocessor statement - in win32 projects you usually need to see the following in the C/C++ - Preprocessor statements section: _WIN32, _WINDOWS ...etc so in the CMakeLists.txt, what syntax is used to put that into the generated project files? Thanks, Mark ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake2.5 - wrong default install location for mingw
Bill Hoffman wrote:
But hey CMake is open source, you can always add the code you want by
yourself.
Here it is... I put some questions in the comments as I'm not that
familiar with the subtleties of some cmake's commands.
You probably want to clean it up. Took me too long to write (love cmake
the make system and docs and platform and flexibility and support, but
its language syntaxtoo much pain for my taste -- i never remember
the commands).
As far as the other stuff...
BTW both cygwin and msys have a ln to create symlinks:
Again, they are NOT symlinks. In the same page you sent me it clearly
specifies that those are not symlinks but get translated to mount points
in /etc/fstab when they are dirs. When they are files, you get a
hardlink (and only if they are on NTFS!). Not the same. At least not
at all to what the Unix world or Wikipedia calls symlinks.
Only with *Windows Vista* you can get actual symlinks in windows, but
cygwin/mingw will likely not benefit from that anytime soon as they link
against an old msvcrt for legal reasons.
Either way, this is offtopic and has *nothing* to do with what I asked.
I am not going to add code into CMake that translates POSIX's paths
into windows paths.
You aren't and I did not ask for that. You are always working with
windows paths. The conversion is handled by MSYS for you in the PATH
variable AUTOMATICALLY.
CMake would have to be a MSYS app to understand MSYS paths.
No. But if you want to make FIND_PATH() and all the others also support
MSYS mount points, be my guest. That's not what I asked for, thou.
Or was all this just a trick to get me to become a cmake developer? :)
Anyway, if you want to go down that path of an MSYS cmake, rather than
linking the cygwin/mingw library, have you considered just parsing
/etc/fstab now that you know where it is as far as windows is
concerned? The big benefit of that is you maintain a single windows
cmake that can generate all types of makefiles.
--
Gonzalo Garramuño
[EMAIL PROTECTED]
AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy
Index: Modules/Platform/Windows-gcc.cmake
===
RCS file: /cvsroot/CMake/CMake/Modules/Platform/Windows-gcc.cmake,v
retrieving revision 1.19
diff -r1.19 Windows-gcc.cmake
55a56,109
FILE(TO_CMAKE_PATH $ENV{PROGRAMFILES} PROGRAMFILES )
#
# Q: Should CMAKE_PROJECT_NAME be used instead?
#
SET( PROGRAMFILES ${PROGRAMFILES}/${PROJECT_NAME} )
IF(MSYS AND CMAKE_INSTALL_PREFIX STREQUAL ${PROGRAMFILES})
# MESSAGE( STATUS Find MSYS ROOT )
#
# Attempt to locate MSYS root path by finding sh.exe
# in users' path or from environment variable MSYS_ROOT.
#
IF( NOT MSYS_ROOT )
SET( MSYS_ROOT $ENV{MSYS_ROOT} )
ENDIF( NOT MSYS_ROOT )
IF(NOT MSYS_ROOT)
FIND_PATH( MSYS_ROOT NAMES sh.exe PATHS $ENV{PATH} )
IF( NOT MSYS_ROOT )
MESSAGE( FATAL_ERROR
CMake could not determine MSYS root. Please set MSYS_ROOT )
ENDIF( NOT MSYS_ROOT)
# MESSAGE( STATUS 1 ${MSYS_ROOT} )
IF( MSYS_ROOT MATCHES .*/local/bin )
SET( MSYS_ROOT ${MSYS_ROOT}/.. )
ELSE( MSYS_ROOT MATCHES .*/local/bin )
SET( MSYS_ROOT ${MSYS_ROOT}/../local )
ENDIF( MSYS_ROOT MATCHES .*/local/bin )
# MESSAGE( STATUS 2 ${MSYS_ROOT} )
FILE(TO_CMAKE_PATH ${MSYS_ROOT} MSYS_ROOT)
# MESSAGE( STATUS 3 ${MSYS_ROOT} )
ENDIF(NOT MSYS_ROOT)
#
# CMake BUG: IS_DIRECTORY should be used, but that fails with
# ../ in path.
# Also, it would be better if we normalized the path
# first, but I could not find a function to do so.
#
IF( NOT EXISTS ${MSYS_ROOT} )
MESSAGE( FATAL_ERROR
CMake uses MSYS root ${MSYS_ROOT}. But no ${MSYS_ROOT} on disk. Please create directory or set CMAKE_INSTALL_PREFIX or MSYS_ROOT differently. )
ENDIF( NOT EXISTS ${MSYS_ROOT} )
SET( CMAKE_INSTALL_PREFIX ${MSYS_ROOT} )
ENDIF(MSYS AND CMAKE_INSTALL_PREFIX STREQUAL ${PROGRAMFILES})
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] using icu-config (or any other)
Hi there, I got a lib (icu), this lib provides also a icu-config script/binary which tells me the compiler/linker flags.. So i can use icu-config --ldflags to find out the parameter for the linker. And here comes the problem. How can i either pass these parameters to the linker, or extract the libs out of the string? --Ano ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake2.5 - wrong default install location for mingw
Gonzalo Garramuño wrote: Bill Hoffman wrote: But hey CMake is open source, you can always add the code you want by yourself. Here it is... I put some questions in the comments as I'm not that familiar with the subtleties of some cmake's commands. You probably want to clean it up. Took me too long to write (love cmake the make system and docs and platform and flexibility and support, but its language syntaxtoo much pain for my taste -- i never remember the commands). Looks like a nice patch that you can put in your cmakelist files. I still do not think it should go in CMake. I don't think that things built by cmake that are native windows things belong in the /usr/local mount point of msys. If you do, it is easy enough to change your project to install by default in anywhere you want. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] using icu-config (or any other)
On 10/20/07, Mathias Baumann [EMAIL PROTECTED] wrote: Hi there, I got a lib (icu), this lib provides also a icu-config script/binary which tells me the compiler/linker flags.. So i can use icu-config --ldflags to find out the parameter for the linker. And here comes the problem. How can i either pass these parameters to the linker, or extract the libs out of the string? EXECUTE_PROCESS? ADD_CUSTOM_COMMAND? Depends when you want the info. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake2.5 - wrong default install location for mingw
On 10/19/07, Gonzalo Garramuño [EMAIL PROTECTED] wrote: Brandon Van Every wrote: Agreed, having gone through this debate awhile ago. I would further note that MinGW doesn't require MSYS, and that one would of course expect %ProgramFiles% as the default in that case. Adding MSYS doesn't change the compiler being used, and the MSYS philosophy is as Bill said. So using %ProgramFiles% would make sense there too. Well, if you are not using MSYS with MinGW you expect MinGW to basically NOT be able do any installs. That would be the responsibility of something like DevC++ or the makefile you create. Yeah, but there are Windows Command Prompt versions of make, typically named mingw32-make. You'd expect those to install to %ProgramFiles%, they don't have any /usr/local file system associated with them. Either way, it would also be good if CMake did make a distinction about itself. I really do not like the idea of MinGW by default overwriting my (then stable) MSVC version. I agree. Make a feature request. I just lost half a day trying to restore to a stable build. I recommend Acronis TrueImage. http://www.acronis.com Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake2.5 - wrong default install location for mingw
On 10/19/07, Gonzalo Garramuño [EMAIL PROTECTED] wrote: a) All unix autotools utilities (or other libs like ffmpeg) built under mingw/msys will not install in $PROGRAMFILES, which leads to cmake's approach being totally backwards with the rest of msys. Actually, last I checked 2+ years ago, I was surprised how totally hostile the MSYS developers were to Autotools. Previously I sorta thought the entire point of MSYS was to run the Autotools but apparently they didn't think so. So, as far as I'm concerned, the behavior of Autotools does not in any way define the expectations of MSYS. It would be reasonable for the Autotools to be modified to work with native Windows installation paths as the default. However, the FSF is hostile to Windows, they want it to go away. This is a case of pretending that MSYS is and should be Unix, as opposed to a shell for Windows native development. b) cygwin's approach is sadly bloated and uses a somewhat inefficient approach Complaints about bloat fall on my deaf ears. I'm writing Autoconf GMake -- CMake translators in CMake script! :-) that also forces you to depend on cygwin.dll But yeah, the GPL is a limitation. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] using icu-config (or any other)
The problem is only how to pass the parameters to the linker.. add_custom_command does not help me in passing sth to the linker, or am i wrong here? On 10/20/07, Mathias Baumann [EMAIL PROTECTED] wrote: Hi there, I got a lib (icu), this lib provides also a icu-config script/binary which tells me the compiler/linker flags.. So i can use icu-config --ldflags to find out the parameter for the linker. And here comes the problem. How can i either pass these parameters to the linker, or extract the libs out of the string? EXECUTE_PROCESS? ADD_CUSTOM_COMMAND? Depends when you want the info. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FindImageMagick: Rewrite to support all utilities.
On 10/19/07, Alex Neundorf wrote: On Thursday 18 October 2007 21:25, Miguel A. Figueroa-Villanueva wrote: On 10/14/07, Alex Neundorf wrote: On Saturday 13 October 2007 07:17, Miguel A. Figueroa-Villanueva wrote: Hello, I've been assigned the task of maintaining the ImageMagick find module. As such, I made a rewrite to support the complete toolchain (i.e., all command line executables) and would like to ask for user feedback before committing the changes. The new module is attached for reference. Why do you use FIND_PATH() instead of FIND_PROGRAM() ? Then you wouldn't have to care for the different suffixes. Something like this should work: FIND_PROGRAM(ImageMagick_mogrify_EXECUTABLE mogrify ...) GET_FILENAME_COMPONENT(ImageMagick_EXECUTABLE_DIR ImageMagick_mogrify_EXECUTABLE PATH ) ... Then the only variable in the CACHE would be ImageMagick_mogrify_EXECUTABLE instead of ImageMagick_EXECUTABLE_DIR. Should I change ImageMagick_EXECUTABLE_DIR to ImageMagick_ROOT_DIR ?? Can you please post the new file before committing ? I have posted the new file as feature request #5919 (http://www.cmake.org/Bug/view.php?id=5919). So, that the discussion can continue on the bug tracker with whoever is interested in this. Note that I'll commit after about a week if no one comments. I have taken care to replicate the VARIABLES and CACHE VARIABLES available when using the current module in the new module for backward compatibility. Alex, there is a note in it commenting why I reverted to thinking it is best to use FIND_PATH instead of FIND_PROGRAM. --Miguel ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] using icu-config (or any other)
On 2007-10-20 22:26+0200 Mathias Baumann wrote: Hi there, I got a lib (icu), this lib provides also a icu-config script/binary which tells me the compiler/linker flags.. So i can use icu-config --ldflags to find out the parameter for the linker. And here comes the problem. How can i either pass these parameters to the linker, or extract the libs out of the string? Mathias, here is the overview of what you should do. I expect you to find the details in the cmake documentation for yourself. * EXECUTE_PROCESS to run icu-config and collect its output in a cmake variable. * STRING to parse that output into the full path of the external library. TARGET_LINK_LIBRARIES (below) does not need a full path, but I find that cmake always does the right thing in that case whereas if you use the -LDIR -licu form it won't always do the right thing (e.g., handle rpath concerns in the build tree correctly). * TARGET_LINK_LIBRARIES to make your target library depend on that external library. * Put this logic into a standard Find module, e.g., FindICU.cmake, following the proper form documented at http://www.cmake.org/cgi-bin/viewcvs.cgi/Modules/readme.txt?rev=1.12root=CMakeview=log Also have a look at http://www.cmake.org/cgi-bin/viewcvs.cgi/Modules/?root=CMake, especially the Find???.cmake modules modified by Alex in the last three months to follow the readme.txt standard. * Once you have a FindICU.cmake that works for you and which also follows the readme.txt standard, I would encourage you to donate it to CMake so others can benefit from your work and possibly even improve it. Good luck. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Patch for Eclipse generator
Quoting [EMAIL PROTECTED]: Hi, On Friday 19 October 2007 01:18, Pau Garcia i Quiles wrote: Hello, As I told yesterday, here comes a patch for the Eclipse CDT4 generator available in the current CVS version of CMake. Although I have not extensively tested it, the works fine. In addition to the in-tree build which has always worked, this patch allows you to have 'myapp' and 'myapp/build' or 'myapp' and 'myapp-build' at the same level: mydir/myapp mydir/myapp/build or mydir/myapp mydir/myapp-build The patch breaks the CMake way of doing thing, as it writes the Eclipse project files (.project and .cproject) in the source directory even in an out-of-tree build. Tomorrow I'll try to implement a new property, or look at the value of a variable, to make it possible to use the pure-CMake style (.project and .cproject in the generated-files directory) or the Eclipse-required style (.project and .cproject in the source directory). Please try it and send your comments to the list or to me. Just to make sure I understand: with this patch the two eclipse project files are always created in the source tree, right ? Right. What happens if you try to create two buildtrees for one source tree, which problems may appear ? With my current patch, it's not possible due to Eclipse limitations. The only way I can think to fix this is to create soft links to the files and folders in the source tree, then create the .project and .cproject in that folder. It'd be something like this: myhelloapp/CMakeLists.txt myhelloapp/src/CMakeLists.txt myhelloapp/src/hello.cpp myhelloapp-build/.project myhelloapp-build/.cproject myhelloapp-build/src - myhelloapp/src/hello.cpp myhelloapp-build2/.project myhelloapp-build2/.cproject myhelloapp-build2/src - myhelloapp/src/hello.cpp where - means that's a symlink. This would probably work fine on Unix platforms and probably Windows 2000 and 2003 (using linkd for the symlinks). I'd have to test this, though. If this approach is more acceptable to Kitware, as it is more CMake-ish, I'll do some research. Just tell me. This makes cvs/svn work directly on the files in this project tree, right ? Yes, again due to Eclipse limitations. But I guess this is what users expect: when I use Eclipse, I want to have my source files, resource files and CMakeLists.txt in Subversion, not my build tree. Using the symlinks approach I just devised, it might be possible to have different Subversion repositories for different build trees but, is that any useful? Does it make sense at all? Are still linked resources created ? Do you mean linked resources to the build tree? Yes, it's the first and only one. I removed the creation of the other linked resources that were created as they interfered and didn't look any useful for me (but I that might be wrong) Can the build tree be anywhere in the system or does it have to be one of the two locations named above ? What happens if it is somewhere else ? Anywhere you like it to be. It works everywhere, all three scenarios (out-of-tree, in-tree or in a subdirectory in-tree) work fine, at least for me. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Possible change in Modules/readme.txt: XXX_EXECUTABLE_DIR or XXX_ROOT_DIR
Hello, In a previous thread discussion (http://www.cmake.org/pipermail/cmake/2007-October/017020.html) the following issue arose and I'm asking this as a separate thread so it can be noticed; as suggested by Alex. There is a variable that I'm using named ImageMagick_EXECUTABLE_DIR. Initially I thought I should use ImageMagick_ROOT_DIR, but then I thought it could be misleading. When searching for a collection of utilities, such as ImageMagick's command-line executables or LaTeX set of binaries, it is often the case that you want to find the dir that contains this collection. I think this variable should be named XXX_EXECUTABLE_DIR. I don't think I should reuse the XXX_ROOT_DIR, because it can be misleading. For example, my first guess would associate the following in my windows installation: CMake_ROOT_DIR : C:/Program Files/CMake CMake_EXECUTABLE_DIR: C:/Program Files/CMake/bin If this makes sense (nobody objects to my philosophical analysis ;) ), then I will add the variable to the Modules/readme.txt as it is missing. --Miguel ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] including paths - basic
Hi Mike,
When I try CMAKE_BUILD_TYPE MATCHES Debug, it seems to never execute
the contents of that IF statement (as if I am never CMake'ing a DEBUG
build?).
I don't know if CMAKE_BUILD_TYPE is the same thing as what's in the
CMAKE_CONFIGURATION_TYPES field. I really need something like:
IF (CMAKE_CONFIGURATION_TYPE MATCHES Debug)
// include some library
ELSE
// ...
ENDIF
I'm not sure if that's the same thing?
Thanks,
Mark
On 10/19/07, Mike Jackson [EMAIL PROTECTED] wrote:
IF ( CMAKE_BUILD_TYPE MATCHES Debug )
ADD_DEFINITIONS(-DDEBUG)
ADD_DEFINITIONS(-Wall)
ENDIF ( CMAKE_BUILD_TYPE MATCHES Debug )
--
Mike Jackson Senior Research Engineer
Innovative Management Technology Services
On Oct 19, 2007, at 9:34 AM, Mark Wyszomierski wrote:
It works fine now that I try it -
Is there any way to switch on debug and release builds? Something
like:
IF (DEBUG)
include_directories(...)
ELSE (DEBUG)
include_directories(...)
ENDIF (DEBUG)
Thanks
On 10/19/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
On Thursday 18 October 2007 19:32, Mark Wyszomierski wrote:
Hi,
I'm new to cmake, it looks great. Is it possible to include
different
paths conditionally, like:
include_directories (${MY_PROJECT_SOURCE_DIR}/my_lib)
IF (WIN32)
include_directories (C:/my_stuff/lib/something)
ELSE (WIN32)
include_directories (/usr/lib/something)
ENDIF (WIN32)
The code looks good, do you have problems with it ?
Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake]: Patch for FIND_PACKAGE_HANDLE_STANDARD_ARGS
I have created a feature request #5920 for the following issue. I
won't apply the changes myself unless I'm assigned the feature, since
I don't want to abuse my cvs modules access.
On 10/19/07, Alex Neundorf wrote:
On Thursday 18 October 2007 21:25, Miguel A. Figueroa-Villanueva wrote:
- create a macro in the same line of
FIND_PACKAGE_HANDLE_STANDARD_ARGS(...), and possibly in the same file,
that checks if all components are found to set the main variable:
FIND_PACKAGE_HANDLE_STANDARD_COMPONENTS(ImageMagick)
would basically do a:
# check if all components are found to set XXX_FOUND
SET(XXX_FOUND TRUE)
FOREACH (component ${XXX_FIND_COMPONENTS})
IF (NOT XXX_${component}_FOUND)
SET(XXX_FOUND FALSE)
ENDIF (NOT XXX_${component}_FOUND)
ENDFOREACH (component)
Maybe this loop could also just be added to the
FIND_PACKAGE_HANDLE_STANDARD_ARGS() macro ?
If no components are specified, then there will be no change in behaviour,
right ?
Yes, good point. I added this loop to the
FIND_PACKAGE_HANDLE_STANDARD_ARGS macro and tested it. It seems to
work well and should have no conflicts the patch for it is in the
feature request (and the loop copied below for easier reference):
http://www.cmake.org/Bug/view.php?id=5920
--Miguel
--
Basically, the patch adds the following loop:
# check if all components are found (specified with COMPONENT|REQUIRED)
FOREACH(_CURRENT_VAR ${${_NAME}_FIND_COMPONENTS})
IF(NOT ${_NAME}_${_CURRENT_VAR}_FOUND)
SET(${_NAME_UPPER}_FOUND FALSE)
ENDIF(NOT ${_NAME}_${_CURRENT_VAR}_FOUND)
ENDFOREACH(_CURRENT_VAR)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Need FindwxWidgets OSX tester for bug 5007
Hello,
There is a bug 5007 (http://www.cmake.org/Bug/view.php?id=5007) to
which I think I have a patch for solving the issue, but I don't have
an OSX platform available for testing. I was going to apply the patch
since it seems pretty straight forward, but I'm inclined to wait until
somebody tests it.
Basically, the patch handles the -arch and -isysroot flags returned by
wx-config.
STRING(REPLACE -framework; -framework
wxWidgets_LIBRARIES ${wxWidgets_LIBRARIES})
+STRING(REPLACE -arch; -arch
+ wxWidgets_LIBRARIES ${wxWidgets_LIBRARIES})
+STRING(REPLACE -isysroot; -isysroot
+ wxWidgets_LIBRARIES ${wxWidgets_LIBRARIES})
Any help will be appreciated.
--Miguel
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
