Re: [CMake] CMake2.5 - wrong default install location for mingw
Bill Hoffman wrote: 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. Okay, I looked at the C++ code of MSYS generator. And surprise, surprise. It does EXACTLY what I said to do of searching the path (but looks for make.exe instead of sh.exe). Also it uselessly (and somewhat potentially incorrectly) parses /etc/fstab to find where mingw's bin directory is (and does not cache any of the other paths, which could indeed potentially allow FIND_PATH() and others to work with mingw paths eventually). The C++ code just forgets to set CMAKE_INSTALL_PREFIX to MSYS proper values. I'll revert this .cmake patch and I'll give you a C++ patch of it instead, as the code is much cleaner that way. And to be honest, I find the C++ code to be much more readable than the .cmake code (which is somewhat disturbing). -- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Kubuntu Edgy ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Cygwin CMake -- Support for VS.NET 2005 applications
Hi Friend(s), I'm Ravi, software engineer from India. We have a requirement for execution of .net projects in Linux kind of environment. We have chosen the cygwin for this purpose. I'm new into the world of Linux, Cygwin as well as CMAKE. I'm unable to proceed forward and got the information that CMAKE need to be installed for support of VS.NET (C# 2.0) 2005 in Cygwin. Plz correct me if i'm wrong. I have installed Cygwin with default features. Do i need to install CMAKE for the Cygwin to execute .net GUI projects? In such case plz let me know where i can find proper documentation to achieve goal in limited period of time. Thanks in advance. Regards, B. Ravi Kiran. ___ 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/21/07, Gonzalo Garramuño [EMAIL PROTECTED] wrote: Also it uselessly... ... (which is somewhat disturbing). It seems you have strong opinions on what should be correct behavior and what is good coding style. How you choose to present those opinions probably matters as to how others will act upon them. Have you accepted that /usr/local isn't going to become the default MSYS installation path? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cygwin CMake -- Support for VS.NET 2005 applications
On 10/21/07, Ravi Kiran [EMAIL PROTECTED] wrote: Hi Friend(s), I'm Ravi, software engineer from India. We have a requirement for execution of .net projects in Linux kind of environment. We have chosen the cygwin for this purpose. I'm new into the world of Linux, Cygwin as well as CMAKE. I'm unable to proceed forward and got the information that CMAKE need to be installed for support of VS.NET (C# 2.0) 2005 in Cygwin. Plz correct me if i'm wrong. There must be some misunderstanding here. CMake doesn't have anything to do with C# as far as I know. I have installed Cygwin with default features. Do i need to install CMAKE for the Cygwin to execute .net GUI projects? That would surprise the heck out of me. I think you need to go back to wherever you got your original source of information, and read it again. In such case plz let me know where i can find proper documentation to achieve goal in limited period of time. Can't help you about documentation because I think you've heard something wrong somewhere, and I don't know where. But installing CMake on Cygwin is trivial. Just download the CMake package, it's in the devel tools section of the Cygwin setup program. 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/21/07, Bill Hoffman [EMAIL PROTECTED] wrote: The only case where I would accept /usr/local as the default for make install for msys, is if someone made a native msys version of cmake that linked to the msys run time. That would be a cmake used for creating other msys applications that would install into /usr/local for msys. And the only people who need that, are the MSYS developers themselves. Or people who want to subvert the policies of the MSYS developers and go their own way, har har har! Open Source is never having to say you're sorry. Anyways, before bothering to create a MSYS CMake, it would best to ask the MSYS developers what they want. I predict they will tell you they want no such thing. Perhaps it would help if you explained your use case. Your original email said that the install overwrote your MSVC version of your software. My memory is he said it overwrote his MSVC version of CMake. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake]: Patch for FIND_PACKAGE_HANDLE_STANDARD_ARGS
On Sunday 21 October 2007 02:31, Miguel A. Figueroa-Villanueva wrote: 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. The patch looks good so far. So if components of package FOO were specified, then FOO_FOUND is only set to true if all these components have been found. This probably makes sense, but I think this is not documented in the readme in Modules/. What do others think about this ? Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Patch for Eclipse generator
Hi, On Sunday 21 October 2007 00:48, you wrote: ... 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. I.e. creating a symlink for each source file and each folder ? Hmm, creating potentially thousands of symlinks doesn't sound too good. How about that: If you run cmake in-source, everything should just work. If you run cmake out-of-source, cmake creates two eclipse projects: one project in the source tree, where you can't build anything, but which you should import in eclipse to have version control working, and the actual project in the build tree, where you build stuff (but don't have version control). The in-source version control project only would have to be created if it doesn't exist yet. What do you think about this ? Bye Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake]: Patch for FIND_PACKAGE_HANDLE_STANDARD_ARGS
On 10/21/07, Alex Neundorf wrote: On Sunday 21 October 2007 02:31, Miguel A. Figueroa-Villanueva wrote: 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. The patch looks good so far. So if components of package FOO were specified, then FOO_FOUND is only set to true if all these components have been found. This probably makes sense, but I think this is not documented in the readme in Modules/. What do others think about this ? I re-read the find_package help and the readme and although I could swear that it did say so... the closest I could find was this in the readme.txt: ... The set of components listed will also be specified in a XXX_FIND_COMPONENTS variable. This can be used by the FindXXX.cmake module to determine which sub-components of the package must be found. ... I guess it is just implied, but it is never clearly stated... So, as Alex asked: What do others think about this? --Miguel ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] find folder matching regex?
I'm trying to write a FindBlitz.cmake file for the popular Blitz++ library ( http://www.oonumerics.org/blitz/). On windows, the folder containing blitz is usually of the form C:/blitz-x.x (where x.x is a version number). I would like to say, Look for blitz/blitz.h in any folder matching C:\blitz-[0-9]*.[0-9]* or C:\Program Files\blitz-[0-9]*.[0-9]*. But from the docs it's not clear to me what the best way to do that is. The PATH_SUFFIXES option for FIND_FILE doesn't appear to work with regular expressions, and I don't see any way to iterate through all of the subfolders of a directory, so I'm not sure what to try next. Maybe I'm missing something obvious or there's a cool undocumented feature somewhere? I'm just looking at the docs at http://cmake.org/HTML/Documentation.html. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Patch for Eclipse generator
Quoting [EMAIL PROTECTED]: Hi, On Sunday 21 October 2007 00:48, you wrote: ... 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. I.e. creating a symlink for each source file and each folder ? Hmm, creating potentially thousands of symlinks doesn't sound too good. Yes. I agree it does not sound too good but we would be on-track again to the CMake-ish way of doing 100% pure out-of-tree builds. I have not considered it seriously but I think we may only need to create symlinks to the first level of files and folders, not to every file and folder inside every folder: mysourcetree/CMakeLists.txt mysourcetree/helloworld/CMakeLists.txt mysourcetree/helloworld/hello.cpp mysourcetree/cruelworld/CMakeLists.txt mysourcetree/cruelworld/cruel.txt mybuildtree/CMakeCache.txt mybuildtree/CMakefiles mybuildtree/cmake_install.cmake mybuildtree/Makefile mybuildtree/helloworld - mysourcetree/helloworld mybuildtree/cruelworld - mysourcetree/cruelworld mybuildtree/.svn - mysourcetree/.svn mybuildtree/helloworld/.svn - mysouretree/helloworld/.svn mybuildtree/cruelworld/.svn - mysouretree/cruelworld/.svn then we would run CMake as it were an in-tree build where the source files reside in mybuildtree. However, I'd need to test if creating empty .svn/CVS dirs in mysourcetree, then symlinks to them from mybuildtree would work when the project is added to Subversion or CVS later from Eclipse. Another problem with this is CMake needs to be aware of the source versioning tools which are available (Subclipse, CVS integration for Eclipse, Bazaar integration for Eclipse...). How about that: If you run cmake in-source, everything should just work. If you run cmake out-of-source, cmake creates two eclipse projects: one project in the source tree, where you can't build anything, but which you should import in eclipse to have version control working, and the actual project in the build tree, where you build stuff (but don't have version control). The in-source version control project only would have to be created if it doesn't exist yet. What do you think about this ? That might work but I don't see the point. Once CMake rapes the source tree by writing something to it, what's the point in having two projects? Could you please explain what's the benefit of having two projects, one for the source version control and another one for generating the files out-of-tree? Please note with my current patch the built files are built out-of-source, so the final result is exactly the same with your two-projects approach and with my single-project approach: compiled files go out of tree, .svn and CVS folders go in-tree. The only difference is with my single-project approach the user does not need to switch projects to build the binaries, or to svn update/commit/etc, which I think is better. -- 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
Re: [CMake] Patch for Eclipse generator
On Monday 22 October 2007 00:19, Pau Garcia i Quiles wrote: Quoting [EMAIL PROTECTED]: Hi, On Sunday 21 October 2007 00:48, you wrote: ... 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. I.e. creating a symlink for each source file and each folder ? Hmm, creating potentially thousands of symlinks doesn't sound too good. Yes. I agree it does not sound too good but we would be on-track again to the CMake-ish way of doing 100% pure out-of-tree builds. I have not considered it seriously but I think we may only need to create symlinks to the first level of files and folders, Ah, ok. But the directories will already exist as real directories in the build tree in many cases (if they contain CMakeLists.txt), so you can't symlink them. Am I missing something ? ... Could you please explain what's the benefit of having two projects, one for the source version control and another one for generating the files out-of-tree? It should be possible to have multiple build trees with eclipse projects for one source tree. Does this work with your approach ? I'm not sure creating the symbolic links won't introduce problems, e.g. when searching for headers in the include path, with the symbolic links there may be directories which are not there with other generators. Bye Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] including paths - basic
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark Wyszomierski wrote: 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? One common misconception (about CMake) is that it's always capable of doing what you think it should be doing. :) Part of the problem lies in the fact that CMake tries to support both single configuration type and multiple configuration type build tools simultaneously. The Makefile generator only supports one configuration type at a time (Debug, Release, etc.) which works out very nice as variables like CMAKE_BUILD_TYPE can be read at CMake time and used to change the configuration of the build. Take the following code for example... project(FOO) if(CMAKE_BUILD_TYPE MATCHES Debug) INCLUDE_DIRECTORIES(bar) else(CMAKE_BUILD_TYPE MATCHES Debug) INCLUDE_DIRECTORIES(top) endif(CMAKE_BUILD_TYPE MATCHES Debug) ADD_EXECUTABLE(foo foo.cc) Should do exactly what you want to do... When you set the CMAKE_BUILD_TYPE cache variable to Debug your Makefiles will add bar to the include path and vice versa if you don't define it. When you use a multiple configuration types generator like Visual Studio, however, the CMAKE_BUILD_TYPE variable will no longer exist. There is a hidden variable as you've discovered called CMAKE_CONFIGURATION_TYPES but this only describes the types of configurations which will show up in Visual Studio. There is no scripted support for dynamically changing project files to do different things using the configuration type of choice. You can introduce your own CACHE variables that change execution of CMake to do whatever you want but it would not work through the multiple build configuration feature of Visual Studio. You would basically have to use CMake to generate one solution files and then another set. There is limited support via the use of SET_TARGET_PROPERTIES to modify per configuration options that will work in Visual Studio but it's limited. Take the following which would change your generated .exe or .lib file for the target: SET_TARGET_PROPERTIES(foo PROPERTIES DEBUG_OUTPUT_NAME foodebug) SET_TARGET_PROPERTIES(foo PROPERTIES RELEASE_OUTPUT_NAME foorelease) So the short answer is, the code people post to the mailing list may or may not do what you want it to do... it all depends on what generator you are using. Sorry for any confusion, all of this probably should be documented somewhere in a CMake gotchas section. - -- Philip Lowman -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHG9vZe0tOktX6RKkRAgJdAJwOSJXBcZwWAaPvtIPRpx+n/KVfVACfQaYI WVxF4ILsE4/q3ZjZBc6vMwM= =LfyP -END PGP SIGNATURE- ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] find folder matching regex?
On 10/21/07, Joseph Garvin [EMAIL PROTECTED] wrote: and I don't see any way to iterate through all of the subfolders of a directory, FILE(GLOB ...) If the globbing expressions aren't enough for your search, then get the output, then run a STRING(REGEX ...) on them. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] including paths - basic
Thanks for the detailed answer Philip. I was able to get around this for my case by the feature included with target_libraries(debug | optimized) - luckily that's exactly what I needed. I understand what you're saying, maybe I can add an entry to the cmake wikipedia about it, Thanks, Mark On 10/21/07, Philip Lowman [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark Wyszomierski wrote: 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? One common misconception (about CMake) is that it's always capable of doing what you think it should be doing. :) Part of the problem lies in the fact that CMake tries to support both single configuration type and multiple configuration type build tools simultaneously. The Makefile generator only supports one configuration type at a time (Debug, Release, etc.) which works out very nice as variables like CMAKE_BUILD_TYPE can be read at CMake time and used to change the configuration of the build. Take the following code for example... project(FOO) if(CMAKE_BUILD_TYPE MATCHES Debug) INCLUDE_DIRECTORIES(bar) else(CMAKE_BUILD_TYPE MATCHES Debug) INCLUDE_DIRECTORIES(top) endif(CMAKE_BUILD_TYPE MATCHES Debug) ADD_EXECUTABLE(foo foo.cc) Should do exactly what you want to do... When you set the CMAKE_BUILD_TYPE cache variable to Debug your Makefiles will add bar to the include path and vice versa if you don't define it. When you use a multiple configuration types generator like Visual Studio, however, the CMAKE_BUILD_TYPE variable will no longer exist. There is a hidden variable as you've discovered called CMAKE_CONFIGURATION_TYPES but this only describes the types of configurations which will show up in Visual Studio. There is no scripted support for dynamically changing project files to do different things using the configuration type of choice. You can introduce your own CACHE variables that change execution of CMake to do whatever you want but it would not work through the multiple build configuration feature of Visual Studio. You would basically have to use CMake to generate one solution files and then another set. There is limited support via the use of SET_TARGET_PROPERTIES to modify per configuration options that will work in Visual Studio but it's limited. Take the following which would change your generated .exe or .lib file for the target: SET_TARGET_PROPERTIES(foo PROPERTIES DEBUG_OUTPUT_NAME foodebug) SET_TARGET_PROPERTIES(foo PROPERTIES RELEASE_OUTPUT_NAME foorelease) So the short answer is, the code people post to the mailing list may or may not do what you want it to do... it all depends on what generator you are using. Sorry for any confusion, all of this probably should be documented somewhere in a CMake gotchas section. - -- Philip Lowman -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHG9vZe0tOktX6RKkRAgJdAJwOSJXBcZwWAaPvtIPRpx+n/KVfVACfQaYI WVxF4ILsE4/q3ZjZBc6vMwM= =LfyP -END PGP SIGNATURE- ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Patch for Eclipse generator
On 10/21/07, Pau Garcia i Quiles wrote: Quoting Alex Neundorf: On Sunday 21 October 2007 00:48, you wrote: 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. Exactly, a limitation we should remove in Eclipse. 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: snip 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. I.e. creating a symlink for each source file and each folder ? Hmm, creating potentially thousands of symlinks doesn't sound too good. Yes. I agree it does not sound too good but we would be on-track again to the CMake-ish way of doing 100% pure out-of-tree builds. Which is the right way, of course. I have not considered it seriously but I think we may only need to create symlinks to the first level of files and folders, not to every file and folder inside every folder: snip then we would run CMake as it were an in-tree build where the source files reside in mybuildtree. However, I'd need to test if creating empty .svn/CVS dirs in mysourcetree, then symlinks to them from mybuildtree would work when the project is added to Subversion or CVS later from Eclipse. Another problem with this is CMake needs to be aware of the source versioning tools which are available (Subclipse, CVS integration for Eclipse, Bazaar integration for Eclipse...). I think this won't work, and if it does... we are bending over backwards to fix something that is not a CMake issue. More below. How about that: If you run cmake in-source, everything should just work. If you run cmake out-of-source, cmake creates two eclipse projects: one project in the source tree, where you can't build anything, but which you should import in eclipse to have version control working, and the actual project in the build tree, where you build stuff (but don't have version control). The in-source version control project only would have to be created if it doesn't exist yet. What do you think about this ? That might work but I don't see the point. Well, I definitely see the point, and I think it is a much better route than putting the build projects in the source tree... But I still disagree that this route to go... last time I checked it was trivial to create a version control project in Eclipse (very few clicks). For CMake to generate them it would need to be an option, since I might not want Eclipse to handle that. Also, CMake would need to know what type of version control it is and how to generate the project for it... All of this isn't too hard, but it isn't harder creating it manually. Once CMake rapes the source tree by writing something to it, what's the point in having two projects? Could you please explain what's the benefit of having two projects, one for the source version control and another one for generating the files out-of-tree? Please note with my current patch the built files are built out-of-source, so the final result is exactly the same with your two-projects approach and with my single-project approach: compiled files go out of tree, .svn and CVS folders go in-tree. The only difference is with my single-project approach the user does not need to switch projects to build the binaries, or to svn update/commit/etc, which I think is better. The problem here, Pau, is that CMake exists for a reason that goes beyond the specific needs of one user. I thought long and hard about Mike's comments when I was building the generator, but for a CMake generator to be implemented it has to work in a general way. Otherwise, it is not much use for people in general. People using CMake expect to be able to do out-of-source builds without a single shred of evidence in the source tree. If we were to violate that principal by putting the .project/.cproject files in the source tree, which of course I think is wrong, then still people using CMake expect to be able to have multiple build trees from the same source tree. If you can work around these issues in the CMake code, then fine. But if it is going to limit the use of CMake then maybe it is time to consider submitting a patch to Eclipse... I don't have the time to consider this at the moment, but it is the way to go. Just my other 2 cents, --Miguel ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
