Re: Fwd: [CMake] Adding cross-compiler support to CMake ... (fwd)
Michael Casadevall wrote: My intent here is not to start a flamewar between autotools and cmake, In some cases, autotools is the proper tool vs cmake due to cross-compiling (which will hopefully fixed) and the fact that you need the cmake executable to build any CMake package. autotools configure script merely needs a shell interpreter, What do you mean merely needs a shell interpreter? For a fair chunk of embedded devices out there, that's tantamount to saying that the Titanic merely needs to pull into port. There are 3 cases for embedded devices: - systems with a Bourne shell and ccmake available - systems with a Bourne shell available - systems without any kind of shell, or really any kind of resources Yes, Autoconf has more cross-compilation reach than CMake at present, but it hardly covers everything. Don't forget all those PCs with Windows installed but no Cygwin or MingW: they simply can not use the configure scripts. Of course, one can require these users to install Cygwin or MingW, but what is that different from installing CMake? Regards, Arjen ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] setting a default build type
On MSVC my CMakeLists.txt generates Debug, Release, MinSizeRel, and RelWithDebInfo build types. I want to keep all 4 of 'em. I want to select MinSizeRel as the default build, so that if an end user just fires up BUILD_ALL and does nothing else, he'll get a MinSizeRel build. The default default is Debug and that's not what I want. So, is there a mechanism to specify the default build type? I was unable to deduce it from the docs if there is one. Seems clear enough how to ship *one* build type, I'd just do (SET CMAKE_BUILD_TYPE MinSizeRel). But I want all 4 to be shipped. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] make install not works for me
Hello! I'm newbie in cmake. I'm trying use his for my small project which consist from 3 files which produce one executable file after compilation. I have cmake version 2.4-patch 3 on my Linux box. I was read two articles at the site (http://www.cmake.org/HTML/WritingCMakeLists.html and http://www.cmake.org/HTML/Examples.html) and write my own CMakeLists.txt Now my project can make and produce program. But make install not install my program: [EMAIL PROTECTED] ~/tmp/openfm]$ make install [100%] Built target openfm Install the project... -- Install configuration: -- Install configuration: So I have questions for you: where my fault ? What I should fix in my CMakeLists.txt? And why documents WritingCMakeLists.html and Examples.html not mentioned about installation and related variables/rules? Thanks in advance. -- + Slava Semushin | php-coder @ ngs.ru + ALT Linux Team | php-coder @ altlinux.ru + Expand QA Team | vsemushin @ swsoft.com ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] make install not works for me
Slava Semushin wrote: So I have questions for you: where my fault ? What I should fix in my CMakeLists.txt? And why documents WritingCMakeLists.html and I can't tell you what you have to fix without your CMakeLists.txt -- Filipe Sousa signature.asc Description: OpenPGP digital signature ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] make install not works for me
Slava Semushin wrote: What I should fix in my CMakeLists.txt? Um, you didn't send us this, so how could we tell you? And why documents WritingCMakeLists.html and Examples.html not mentioned about installation and related variables/rules? Because we're slack. We all have way too much of our own code to write, and we don't take the time to write first class documentation and tutorials. To make up for this shameless lack of discipline about coherent online documentation, we're excellent at answering questions on this mailing list. Really, just ask more questions, that's the way to go around here. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: Fwd: [CMake] Adding cross-compiler support to CMake ... (fwd)
Arjen Markus wrote: Michael Casadevall wrote: My intent here is not to start a flamewar between autotools and cmake, In some cases, autotools is the proper tool vs cmake due to cross-compiling (which will hopefully fixed) and the fact that you need the cmake executable to build any CMake package. autotools configure script merely needs a shell interpreter, What do you mean "merely" needs a shell interpreter? For a fair chunk of embedded devices out there, that's tantamount to saying that the Titanic "merely" needs to pull into port. There are 3 cases for embedded devices: - systems with a Bourne shell and ccmake available - systems with a Bourne shell available - systems without any kind of shell, or really any kind of resources Yes, Autoconf has more cross-compilation reach than CMake at present, but it hardly covers everything. Don't forget all those PCs with Windows installed but no Cygwin or MingW: they simply can not use the configure scripts. Of course, one can require these users to install Cygwin or MingW, but what is that different from installing CMake? The level of pain. Cygwin is easy. It just takes a lot more MB of downloads to have a working system, than to grab CMake. Or, uh, you can grab the CMake that's in Cygwin. :-) MinGW / MSYS has become *awful* if you're trying to get Autoconf going. I spent an entire day on it recently and almost gave up. The only thing that saved my ass was a rogue 3rd party project called mingw-install. http://sourceforge.net/projects/mingw-install It *nukes* the whole MSYS mess and puts in a bunch of stuff that actually works, with the most current versions of Autoconf and whatnot. There's a whole pile of integration issues that MSYS hasn't dealt with, they're too lazy. They're laboring under the delusion that their MinGWPort stuff actually works, when in fact it's quite broken. I don't have time to rag on them on their mailing list about it. I just use mingw-install and sing its praises. Better comment out those "rm -r" lines though! Everything worked fine once I dropped my own compiler in afterwards. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] make install not works for me
--- Filipe Sousa 2006-09-07 09:17:00 +0100 +++ Slava Semushin 2006-09-07 15:31:28 +0700 FS I can't tell you what you have to fix without your CMakeLists.txt Wow. I'm very sorry. I forgot attach CMakeLists.txt :-( --- Brandon J. Van Every 2006-09-07 01:20:55 -0700 +++ Slava Semushin 2006-09-07 15:31:28 +0700 BJVE Um, you didn't send us this, so how could we tell you? Not needed now. My friend point me to INSTALL, I read man and added one line: INSTALL (TARGETS openfm RUNTIME DESTINATION bin) Now all works as expected. I think anybody should update http://www.cmake.org/HTML/Examples.html and adds INSTALL directives to example. Without this change some newbies, like me, may puzzle. BJVE Really, just ask more questions, that's the way to go around here. Thanks. I will asking! ;-) -- + Slava Semushin | php-coder @ ngs.ru + ALT Linux Team | php-coder @ altlinux.ru + Expand QA Team | vsemushin @ swsoft.com ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: Fwd: [CMake] Adding cross-compiler support to CMake ... (fwd)
Arjen Markus wrote: Don't forget all those PCs with Windows installed but no Cygwin or MingW: they simply can not use the configure scripts. Of course, one can require these users to install Cygwin or MingW, but what is that different from installing CMake? The level of pain. Cygwin is easy. It just takes a lot more MB of downloads to have a working system, than to grab CMake. Or, uh, you can grab the CMake that's in Cygwin. :-) Hm, I was thinking more of the end-users than developers :). Installing the sources of a package and then running the ./configure file should work under both Cygwin and MinGW, but it utterly fails on a Windows box without them. MinGW / MSYS has become *awful* if you're trying to get Autoconf going. I spent an entire day on it recently and almost gave up. The only thing that saved my ass was a rogue 3rd party project called mingw-install. http://sourceforge.net/projects/mingw-install It *nukes* the whole MSYS mess and puts in a bunch of stuff that actually works, with the most current versions of Autoconf and whatnot. Thanks for the tip! I have never been able to grasp the information on the home page - what packages I need etc. A simple receipe would have done: if you are a typical user/developer, get this and this. Regards, Arjen ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] make install not works for me
Slava Semushin wrote: I think anybody should update http://www.cmake.org/HTML/Examples.html and adds INSTALL directives to example. Without this change some newbies, like me, may puzzle. I was about to say, It's a wiki. You could do that. But then I saw it's not a wiki, so you can't do that. It would be good to move all such materials to the wiki, I think. Put them in one coherent place where they can, in principle, be improved by people who find them lacking. Of course, the whole problem of getting programmers to document things, is once they've figured out what they need to know, they've lost most of the incentive to document. Most people only document when they're really worried about being understood. Like my CMake build, for instance. I can't be inscrutable, I have to get people to convert from Autoconf to CMake. BJVE Really, just ask more questions, that's the way to go around here. Thanks. I will asking! ;-) No problemo! Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] make install not works for me
Slava Semushin wrote: --- Filipe Sousa 2006-09-07 09:17:00 +0100 +++ Slava Semushin 2006-09-07 15:31:28 +0700 FS I can't tell you what you have to fix without your CMakeLists.txt Wow. I'm very sorry. I forgot attach CMakeLists.txt :-( --- Brandon J. Van Every 2006-09-07 01:20:55 -0700 +++ Slava Semushin 2006-09-07 15:31:28 +0700 BJVE Um, you didn't send us this, so how could we tell you? Not needed now. My friend point me to INSTALL, I read man and added one line: INSTALL (TARGETS openfm RUNTIME DESTINATION bin) Now all works as expected. I think anybody should update http://www.cmake.org/HTML/Examples.html and adds INSTALL directives to example. Without this change some newbies, like me, may puzzle. [EMAIL PROTECTED] ~ $ cmake --help-command install ... The TARGETS signature: INSTALL(TARGETS targets... [[ARCHIVE|LIBRARY|RUNTIME] [DESTINATION dir] [PERMISSIONS permissions...] [CONFIGURATIONS [Debug|Release|...]] [COMPONENT component] ] [...]) ... INSTALL(TARGETS myExe mySharedLib myStaticLib RUNTIME DESTINATION bin LIBRARY DESTINATION lib ARCHIVE DESTINATION lib/static) ... -- Filipe Sousa signature.asc Description: OpenPGP digital signature ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: Fwd: [CMake] Adding cross-compiler support to CMake ... (fwd)
Arjen Markus wrote: Arjen Markus wrote: Don't forget all those PCs with Windows installed but no Cygwin or MingW: they simply can not use the configure scripts. Of course, one can require these users to install Cygwin or MingW, but what is that different from installing CMake? The level of pain. Cygwin is easy. It just takes a lot more MB of downloads to have a working system, than to grab CMake. Or, uh, you can grab the CMake that's in Cygwin. :-) Hm, I was thinking more of the end-users than developers :). Only Unix people think that "end users" run ./configure scripts or CMake. In the Windows world, if you're running a compiler, you're a developer. You may be a developer who wants a painless build, but you're still a developer. The answer for an end user is CPack, not CMake. Even for most Unix developers, the answer is a modern packaging system. Only weenies want to sit around building huge stacks of libraries all day long. MinGW / MSYS has become *awful* if you're trying to get Autoconf going. I spent an entire day on it recently and almost gave up. The only thing that saved my ass was a rogue 3rd party project called mingw-install. http://sourceforge.net/projects/mingw-install It *nukes* the whole MSYS mess and puts in a bunch of stuff that actually works, with the most current versions of Autoconf and whatnot. Thanks for the tip! I have never been able to grasp the information on the home page - what packages I need etc. A simple receipe would have done: "if you are a typical user/developer, get this and this." Being similarly befuddled, I read the archives about this. It seems that at least one of the MSYS leads simply doesn't care, and won't be lifting fingers for Autoconf. Which boggles me, since I always thought the point of MSYS was to be able to run Autoconf, but I guess that's not so. I don't know what people are doing with MSYS if not using it to build GNU-ish stuff. Pretty little shell? Geez, who cares? The MSYS guys definitely don't think they're supposed to be a fullblown Unix-under-Windows like Cygwin, they think they're supposed to be a Minimal SYStem. They won't do anything which pulls them in the direction of being like Cygwin. So, what *do* they want to do? I think there's a problem of cultural definition afoot. Maybe if I lurked on their mailing list long enough, I'd figure it out and be capable of uttering the right magic words. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: Fwd: [CMake] Adding cross-compiler support to CMake ... (fwd)
Only Unix people think that end users run ./configure scripts or CMake. In the Windows world, if you're running a compiler, you're a developer. You may be a developer who wants a painless build, but you're still a developer. The answer for an end user is CPack, not CMake. Even for most Unix developers, the answer is a modern packaging system. Only weenies want to sit around building huge stacks of libraries all day long. In the PLplot project we are a long way from CPack still. But it is good to be reminded of it! Regards, Arjen ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] sysconfdir and localstatedir
Hi, What are the equivalent of sysconfdir and localstatedir ? ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var would be cmake -DCMAKE_INSTALL_PREFIX=/usr -D???=/etc --D???=/var Thanks, __ --- NOTICE --- CONFIDENTIALITY - This email and any attachments are confidential and are intended for the addressee only. If you have received this message by mistake, please contact us immediately and then delete the message from your system. You must not copy, distribute, disclose or act upon the contents of this email. Thank you. PERSONAL DATA PROTECTION (Law by Decree 30. 06.2003 n. 196) - Personal and corporate data submitted will be used in a correct, transparent and lawful manner. The data collected will be processed in paper or computerized form for the performance of contractual and lawful obligations as well as for the effective management of business relationship. Data may be disclosed, in Italy or abroad, for the purpose above mentioned to third parties which cooperate with Telsey, agents, banks, factoring companies, credit recovering companies, credit insurance companies, professional and consultants, and shipping companies. In relation to the same purposes, data may be processed by the following classes of executors or processors: management; administration department; logistics and purchase department; sales department; post sales department quality department; RD department; IT department; legal department. The data processor is Telsey S.p.A. The data subject may exercise all the rights set forth in art. 7 of Law by Decree 30. 06.2003 n. 196 as reported in in the following link http://www.telsey.it/privacy.jsp. __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] make install not works for me
Von: Brandon J. Van Every [EMAIL PROTECTED] Slava Semushin wrote: I think anybody should update http://www.cmake.org/HTML/Examples.html and adds INSTALL directives to example. Without this change some newbies, like me, may puzzle. I was about to say, It's a wiki. You could do that. But then I saw it's not a wiki, so you can't do that. It would be good to move all such materials to the wiki, I think. Put them in one coherent place where they can, in principle, be improved by people who find them lacking. Yes, this would be a good idea. Actually, just login in to the Wiki and create a new wiki page with the same contents. Of course, the whole problem of getting programmers to document things, is once they've figured out what they need to know, they've lost most of the incentive to document. Most people only document when they're really worried about being understood. That's right. Nevertheless I take from time to time I take an evening just to write some documentation, because I'm in the same position, the KDE devs should have a point where they can find good documentation. Bye Alex -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] sysconfdir and localstatedir
Original-Nachricht Datum: Thu, 7 Sep 2006 12:41:39 +0200 Von: frederic heem [EMAIL PROTECTED] An: cmake cmake@cmake.org Betreff: [CMake] sysconfdir and localstatedir Hi, What are the equivalent of sysconfdir and localstatedir ? ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var would be cmake -DCMAKE_INSTALL_PREFIX=/usr -D???=/etc --D???=/var Thanks, Usually with cmake everything is installed relativ to CMAKE_INSTALL_PREFIX. If you want different behaviour you can adjust it yourself by using the new INSTALL() command with *absolute* paths as DESTINATION. That's what we are doing for KDE4. You can do set(SYSCONFDIR /etc CACHE) and you will be able to edit it via ccmake. Bye Alex -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Patch to install dlls correctly when cross-compiling
Toni Timonen wrote: When cross-compiling windows dlls with mingw compiler using linux, the dlls are not installed to the correct location (and the import library is not installed at all). It seems that some things about the platform are fixed at runtime. The patch attached fixes this issue with INSTALL(TARGETS ..). The code should definately have been implemented your way originally. I've applied the patch. Thanks, -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ADD_SUBDIRECTORY and EXCLUDE_FROM_ALL
Stephan Tolksdorf wrote: If a subdirectory is included with EXCLUDE_FROM_ALL, targets in the subdirectory are listed in the generated Visual Studio solution, but targets recursively included in subdirectories of the subdirectory are not. Is this a bug or a feature? (I'm using CMake from CVS and VS8.) Please report this here: http://www.cmake.org/Bug Thanks, -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: AW: Re: [CMake] Linking Problems w. CMake 2.4 and MinGW32
[EMAIL PROTECTED] wrote: ADD_EXECUTABLE(foo foo.cxx) TARGET_LINK_LIBRARIES(foo bar.lib) and I got a -lbar on the link line from CMake 2.4.3 with the MSYS Makefiles and MinGW Makefiles generators. This example works for me, too. Maybe there's some issue on setting the LIbrary via FIND_LIBRARY? Use the MESSAGE command to see the value of BOOST_REGEX_LIB. Perhaps it gets set to bar.lib.lib or something. MESSAGE(CMAKE_EXTRA_LINK_EXTENSIONS=[${CMAKE_EXTRA_LINK_EXTENSIONS}]) to your code to see if the variable is set to .lib as it is supposed to be on MinGW and MSYS generators. This is true for my CMake file, too. [snip] FIND_LIBRARY(BOOST_REGEX_LIB NAMES boost_regex-gcc boost_regex-gcc-1_33_1 boost_regex-vc80-mt.lib PATHS /usr/lib /usr/local/lib C:/Boost/lib DOC Path to the boost regular expression library) LINK_LIBRARIES( ${BOOST_REGEX_LIB} ) [snip] ADD_EXECUTABLE( edi ${SRC_FILES} ) The LINK_LIBRARIES command is obsolete. Use TARGET_LINK_LIBRARIES to specifically link the library to each target that needs it: ADD_EXECUTABLE( edi ${SRC_FILES} ) TARGET_LINK_LIBRARIES(edi ${BOOST_REGEX_LIB}) -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] INCLUDE_DIRECTORIES includes two directories appended together
Ryan Phillips wrote: I am having a problem when I include INCLUDE_DIRECTORIES(${SOMEVAR}) within my project. The generated CFLAGS (under linux) include my CMAKE_SOURCE_DIR appended with my ${SOMEVAR}, ie: SOMEVAR=/usr/include/openssl/ upon compilation: -I/home/rphillips/work/project/-I/usr/include/openssl Does anyone know what is going on? I cannot duplicate this. From where is the /home/rphillips/work/project/ path coming into the include directory list? -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] setting a default build type
On 2006-09-07 00:56-0700 Brandon J. Van Every wrote: On MSVC my CMakeLists.txt generates Debug, Release, MinSizeRel, and RelWithDebInfo build types. I want to keep all 4 of 'em. I want to select MinSizeRel as the default build, so that if an end user just fires up BUILD_ALL and does nothing else, he'll get a MinSizeRel build. The default default is Debug and that's not what I want. So, is there a mechanism to specify the default build type? I was unable to deduce it from the docs if there is one. Seems clear enough how to ship *one* build type, I'd just do (SET CMAKE_BUILD_TYPE MinSizeRel). But I want all 4 to be shipped. Its a cached variable. So I think what you want is SET (CMAKE_BUILD_TYPE MinSizeRel CACHE STRING Flags used by the compiler during all build types.) That gives you the default you want plus the user should be able to override that default with a -D option or appropriate GUI action. 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 Yorick front-end to PLplot (yplot.sf.net); 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] setting a default build type
Alan W. Irwin wrote: Its a cached variable. So I think what you want is SET (CMAKE_BUILD_TYPE MinSizeRel CACHE STRING Flags used by the compiler No, Cmake (at least 2.4.2) is not generating any .suo file at all. Thus neither CMAKE_BUILD_TYPE nor CMAKE_CONFIGURATION_TYPES will help with teh default setting. Jan. -- Dipl.-Ing. Jan Woetzel -- Uni Kiel Institut f. Informatik und Praktische Mathematik Hermann-Rodewaldstr. 3 [Raum 310] 24098 Kiel/Germany -- Tel+49-431-880-4477 Fax+49-431-880-4845 Privat +49-431-802872 Mob. +49-179-2937346 -- Urlwww.mip.informatik.uni-kiel.de/~jw Email [EMAIL PROTECTED] Privat [EMAIL PROTECTED] ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] make install not works for me
Alexander Neundorf wrote: Von: "Brandon J. Van Every" [EMAIL PROTECTED] Slava Semushin wrote: I think anybody should update http://www.cmake.org/HTML/Examples.html and adds INSTALL directives to example. Without this change some newbies, like me, may puzzle. I was about to say, "It's a wiki. You could do that." But then I saw it's not a wiki, so you can't do that. It would be good to move all such materials to the wiki, I think. Put them in one coherent place where they can, in principle, be improved by people who find them lacking. Yes, this would be a good idea. Actually, just login in to the Wiki and create a new wiki page with the same contents. It still needs to be canonized by Kitware, so that users aren't looking at the wrong page. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] setting a default build type
Brad King wrote: Brandon J. Van Every wrote: On MSVC my CMakeLists.txt generates Debug, Release, MinSizeRel, and RelWithDebInfo build types. I want to keep all 4 of 'em. I want to select MinSizeRel as the default build, so that if an end user just fires up BUILD_ALL and does nothing else, he'll get a MinSizeRel build. The default default is "Debug" and that's not what I want. So, is there a mechanism to specify the default build type? I was unable to deduce it from the docs if there is one. Seems clear enough how to ship *one* build type, I'd just do (SET CMAKE_BUILD_TYPE MinSizeRel). But I want all 4 to be shipped. This would be a nice feature but I don't know how to implement it. Try generating a project and then manually editing the project files in such a way that the IDE selects a different configuration by default. Don't forget to remove the .suo and .ncb files between attempts because they store the user IDE state. That approach is not desired. People typically want CMakeList.txt under source control, not its end products, as the latter differ for every person. We don't ship .sln files to people, we tell them to install CMake. I'll make a feature request. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] setting a default build type
Brandon J. Van Every wrote: Brad King wrote: This would be a nice feature but I don't know how to implement it. Try generating a project and then manually editing the project files in such a way that the IDE selects a different configuration by default. Don't forget to remove the .suo and .ncb files between attempts because they store the user IDE state. That approach is not desired. People typically want CMakeList.txt under source control, not its end products, as the latter differ for every person. We don't ship .sln files to people, we tell them to install CMake. I was not proposing this as a solution, I was asking you to figure out how to implement it. I have no idea how to write a .sln or .vcproj file that will convince the VS IDE to come up with a non-Debug configuration by default. I just tried manually reordering the configurations to put Release first and the IDE still selected Debug at startup. Even changing the Release configuration to have the name ARelease (which comes before Debug lexicographically) didn't fix it. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] setting a default build type
On 2006-09-07 09:35-0700 Brandon J. Van Every wrote: Alan W. Irwin wrote: On 2006-09-07 00:56-0700 Brandon J. Van Every wrote: On MSVC my CMakeLists.txt generates Debug, Release, MinSizeRel, and RelWithDebInfo build types. I want to keep all 4 of 'em. I want to select MinSizeRel as the default build, so that if an end user just fires up BUILD_ALL and does nothing else, he'll get a MinSizeRel build. The default default is Debug and that's not what I want. So, is there a mechanism to specify the default build type? I was unable to deduce it from the docs if there is one. Seems clear enough how to ship *one* build type, I'd just do (SET CMAKE_BUILD_TYPE MinSizeRel). But I want all 4 to be shipped. Its a cached variable. So I think what you want is SET (CMAKE_BUILD_TYPE MinSizeRel CACHE STRING Flags used by the compiler during all build types.) That gives you the default you want plus the user should be able to override that default with a -D option or appropriate GUI action. I don't think this works for shipping 4 build types. I don't want them, by default, to all behave as the same build type. Could you explain in more detail just what you mean by shipping 4 build types? (1) Is that giving the user the option of 4 different build types with a particular default? (2) Do you want to have the user build all 4 build types in the same CMake run? (3) Something else? The first interpretation of your request is easy to supply. CMake already allows the user to specify one of a list of build types. All the above SET command does is change the default build type (which is what you asked for) while still allowing the user to choose something different in ccmake (or whatever GUI front-end they use) if they prefer a build type that is different than the default MinSizeRel. If you want your users to build all 4 build types in the same CMake run, I don't quite see the point of that. So maybe there is a third interpretation of your request which I am missing? 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 Yorick front-end to PLplot (yplot.sf.net); 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] setting a default build type
Alan W. Irwin wrote: On 2006-09-07 09:35-0700 Brandon J. Van Every wrote: Alan W. Irwin wrote: On 2006-09-07 00:56-0700 Brandon J. Van Every wrote: On MSVC my CMakeLists.txt generates Debug, Release, MinSizeRel, and RelWithDebInfo build types. I want to keep all 4 of 'em. I want to select MinSizeRel as the default build, so that if an end user just fires up BUILD_ALL and does nothing else, he'll get a MinSizeRel build. The default default is Debug and that's not what I want. So, is there a mechanism to specify the default build type? I was unable to deduce it from the docs if there is one. Seems clear enough how to ship *one* build type, I'd just do (SET CMAKE_BUILD_TYPE MinSizeRel). But I want all 4 to be shipped. Its a cached variable. So I think what you want is SET (CMAKE_BUILD_TYPE MinSizeRel CACHE STRING Flags used by the compiler during all build types.) That gives you the default you want plus the user should be able to override that default with a -D option or appropriate GUI action. I don't think this works for shipping 4 build types. I don't want them, by default, to all behave as the same build type. Could you explain in more detail just what you mean by shipping 4 build types? (1) Is that giving the user the option of 4 different build types with a particular default? Yes. What currently comes out of CMake in VS7.1 is 4 different build types that the user can select, and the default is Debug. If the user does nothing but run BUILD_ALL, she'll get a debug build. We'd rather it be a Release or MinSizeRel build. (2) Do you want to have the user build all 4 build types in the same CMake run? The user can enable this from VS7.1 if they want to. They would select Batch Build. We're not interested in doing a batch build by default. The first interpretation of your request is easy to supply. CMake already allows the user to specify one of a list of build types. All the above SET command does is change the default build type (which is what you asked for) while still allowing the user to choose something different in ccmake (or whatever GUI front-end they use) if they prefer a build type that is different than the default MinSizeRel. Ok I will try it and report back. I'm in the middle of tearing something else up at this exact moment. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Mailing lists for cvs and bugtracker
Joerg Mayer wrote: I'd like to follow development of cmake a bit more closely. In order to do that, many other open source projects have mailing lists that follow the cvs commit and the bug tracking system. Is something like that available and just not mentioned on the mailing lists page or, if not, can something like that be set up? I've created a cmake-commits list: http://www.cmake.org/HTML/MailingLists.html http://www.cmake.org/mailman/listinfo/cmake-commits The bug tracker we use does not support a mailing list as far as I know. If you're interested in specific bugs you can add yourself as a CC to them. Also commits related to bugs often reference the bug number so you'll see them on the list too. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to read a registry key?
I looks like this has something to do with the nature of the key/value. For values listed as REG_SZ (within regedit.exe), CMake can retrieve the content but for values stored as REG_EXPAND_SZ I systematically get /registry. I don't know much about the Windows registry but I did a quick survey of different computers/users in the lab and the user path can be either one which makes it difficult to implement a robust solution. Am I the first one to run into this issue? Anton On Thu, 2006-09-07 at 12:13 -0400, Anton Deguet wrote: Bill, I had some success with the key expansion but I haven't been able to do what I need. Basically, I would like to get the un-expanded content of the user path, i.e. not the expanded path (user and system) which can be found using $ENV{PATH}. I tried the following code, i.e. adding two variables, one using the other: SET(CISST_PATH ${EXECUTABLE_OUTPUT_PATH} ${LIBRARY_OUTPUT_PATH}) SET(CISST_PATH_REG_KEY HKEY_CURRENT_USER\\Environment;CISST_PATH) EXEC_PROGRAM(${CMAKE_COMMAND} ARGS -E write_regv \${CISST_PATH_REG_KEY}\ \${CISST_PATH}\) SET(OTHER_PATH_REG_KEY HKEY_CURRENT_USER\\Environment;OTHER_PATH) SET(OTHER_PATH c:/prg;%CISST_PATH%) EXEC_PROGRAM(${CMAKE_COMMAND} ARGS -E write_regv \${OTHER_PATH_REG_KEY}\ \${OTHER_PATH}\) GET_FILENAME_COMPONENT(TMP [HKEY_CURRENT_USER\ \Environment;OTHER_PATH]/dummy.dum PATH) MESSAGE(${TMP}) At that point, everything looks great and I can check the results with reg.exe, the expansion works ... Now, if I try to retrieve the user path using GET_FILENAME_COMPONENT(TMP [HKEY_CURRENT_USER\ \Environment;PATH]/dummy.dum PATH) TMP is set to /registry ... Any explanation or better solution to just retrieve the value as a string? On Wed, 2006-09-06 at 20:55 -0400, William A. Hoffman wrote: At 05:36 PM 9/6/2006, Anton Deguet wrote: Hello, I have found that using EXEC_PROGRAM with ${CMAKE_COMMAND} -E I can write/remove a key in the Windows registry but I haven't figured out how to read a key. Is there a simple solution for that? Sure, but it seems not to be documented Several commands including GET_FILENAME_COMPONENT will expand things like this: [HKEY_LOCAL_MACHINE\\SOFTWARE\\JavaSoft\\Java Development Kit\\2.0;JavaHome]/bin You can use this to read registry values. I will add some docs in the morning. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake -- Anton Deguet [EMAIL PROTECTED] ERC CISST Johns Hopkins University ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Adding cross-compiler support to CMake ...
Begin forwarded message:From: Michael Casadevall [EMAIL PROTECTED]Date: September 7, 2006 5:38:14 PM EDTTo: "William A. Hoffman" [EMAIL PROTECTED]Subject: Re: [CMake] Adding cross-compiler support to CMake ... I would disagree with that. Your using a cross-compiler, but CMake doesn't know its cross-compiling, and doesn't know how to handle exceptions for a cross-compiler. I cross-compile a LOT of packages - autotools packages are the easiest to compile in general, after you give it all the values for information it doesn't have.Anyway, I'm planning my angle of attack in programming right now on how to do this, but not knowing CMake's guts is making this a little harder.MichaelOn Sep 7, 2006, at 5:30 PM, William A. Hoffman wrote: At 04:36 PM 9/7/2006, Brad King wrote: Michael Casadevall wrote: I wish to add support for cross-compiling to CMake since its a tool Iuse a lot, and I can finally kill the last few of my projects usingautotools. To my knowledge, autotools is the only system that providescross-compiling, and poorly at that, and I've been thinking on ways toadd it to CMake. Here's what I got so far: This is one of the oldest feature requests:http://www.cmake.org/Bug/bug.php?op=showbugid=14You may wish to log into the bug tracker, add yourself as a CC for thisbug, and add comments to it.We will eventually get to adding cross-compiling support, and it wouldbe great to have some discussion available in the bug report for reference. All said about cross compiling, there are folks doing cross compilingwith CMake. CMake does not really help in any way, but it can be done.All of the try-run stuff can be stopped by setting the correct cache variablesbefore cmake is run. So, it should be not that hard to create a cache filethat has all the cmake variables needed for a cross compiler. The tricky partwould be projects that build code generation stuff during the build process.This would have to be done in a separate build right now, but with correctlywritten CMakeLists.txt files you should be able to pre-load the path to thoselocally built programs as well. At the end of the day a cross compiler isjust a compiler run from makefiles just like the ones used by cmake for non-crosscompile builds. So, you could say that CMake poorly supports cross compiling today.-Bill___CMake mailing listCMake@cmake.orghttp://www.cmake.org/mailman/listinfo/cmake = ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] See libraries
Hi, How can I display the libraries actually used during a given link process? I have to use some VTK libraries (which link just fine with CMake) using a manual makefile and I really need to see all the libraries. Thanks, -- Gheorghe Postelnicu, PhD MGH, Harvard Medical School ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] See libraries
Gheorghe Postelnicu wrote: Hi, How can I display the libraries actually used during a given link process? I have to use some VTK libraries (which link just fine with CMake) using a manual makefile and I really need to see all the libraries. I believe you are looking for: $ make VERBOSE=1 HTH Mathieu ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Adding cross-compiler support to CMake ...
At 06:42 PM 9/7/2006, Michael Casadevall wrote: 1. Never seen that. autotools should only enter cross-compiling mode if --host is set, and its different the current platform, or if both build and host are set with different values. If you look in a configure script.. rm -f a.out a.exe conftest$ac_cv_exeext b.out ac_clean_files=$ac_clean_files_save # Check the compiler produces executables we can run. If not, either # the compiler is broken, or we cross compile. echo $as_me:$LINENO: checking whether we are cross compiling 5 echo $ECHO_N checking whether we are cross compiling... $ECHO_C 6 echo $as_me:$LINENO: result: $cross_compiling 5 echo ${ECHO_T}$cross_compiling 6 That is from the configure script of gnu make 3.8.1. Looking at the other cross-compile stuff in that configure script. It seems that all the try-run stuff is automatically set to No, if it is in cross compile mode. That would not be hard to do in cmake. 2. In an earlier email which got disconnected from this one stated there would be a configuration question CROSS_COMPILE. I'll attach that email to the bottom of this one I found it: TARGET_CC ... LOCAL_CC LOCAL_CXX LOCAL_LD LOCAL_*etc* *CMAKE_SSH=ssh *CMAKE_SCP=scp TARGET_REMOTE_PATH=~ I am thinking that the normal variables could be used. One idea I had was to run cmake twice, once for local and once for target. If we marked the targets with LOCAL or TARGET we would know which ones to put in which build tree. A toplevel makefile could be created that walks into both trees in the correct order. I am aware of that method of cross-compiling, and its horrible. You also need to add lines for RANLIB, AR, and usually some other utilities and then remove TRY_RUN. I still won't call that cross- compiler support, CMake should undersatnd if its cross-compiling, and it should be, in theory, as easy as compiling natively. Also, it mucks the filenames and such. Try cross-compiling in CMake from Mac OS X to Windows. Do-able with minigw, and autotools, but it would be a nightmare for CMake based projects. You do not have to remove the TRY_RUN calls. TRY_RUN only runs once. So, if the variable is pre-loaded in the cache, then it will not run. I still don't think it would be a nightmare, things like exe extension are all cmake variables at this point. It would again require setting them correctly in an initial cache. Could you post an example of how the Mac OS X compiler can be used to create windows executables? I can give it a try and see how bad it really is. Anyway, looking through the source of CMake, this is going to a bit messy. Right now, it doesn't have a concept of multiple platforms, and the Makefile generator isn't written in a way that it would be easy to add it. I'm poking through the Module code now, and seeing how it all comes together and see specifically what needs modification now. I'm deciding if a new generator is needed, or the Unix one can be recycled with a lot of hack and slashing. Michael At the end of the day, I don't think we want two makefile generators. I don't think it will require that much hacking and slashing... It may require some refactoring. It runs the compiler with some flags and produces files, it is not that much different. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] setting a list using the -D option
Hello, How do I set the value of a list using the -D option when running cmake? For example, if I want FOO to be a list containing the letters a, b, and c, I thought I would do something like cmake ../src -DFOO:STRING=a b c I tried this but then it just treats it as a string and my foreach loop only runs once. Any input is appreciated. -darby j -- Darby J Van Uitert SCI Institute University of Utah Email: [EMAIL PROTECTED] Phone: (301) 528-8469 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] setting a list using the -D option
On 2006-09-07 21:44-0400 Darby J Van Uitert wrote: Hello, How do I set the value of a list using the -D option when running cmake? For example, if I want FOO to be a list containing the letters a, b, and c, I thought I would do something like cmake ../src -DFOO:STRING=a b c I tried this but then it just treats it as a string and my foreach loop only runs once. Any input is appreciated. -DFOO=a;b;c Delimiting list elements by semicolons within strings also works inside cmake. 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 Yorick front-end to PLplot (yplot.sf.net); 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
[CMake] qt4 with cmake's question
i succeed use cmake to build a qt4's example's imageviewer in windows,build with mingw32.the programe run with a console with cmake build ,if use qmake,the programe run without console,why?and how to forbid to show console with cmake? this is my cmakelist.txtproject(imageviewer) cmake_minimum_required(VERSION 2.4.0)find_package(Qt4 REQUIRED) INCLUDE_DIRECTORIES(${CMAKE_CURRENT_BINARY_DIR})# the next line sets up include and link directories and defines some variables that we will use. # you can modify the behavior by setting some variables, e.g.# set(QT_USE_OPENGL TRUE)# - this will cause cmake to include and link against the OpenGL module#set(QT_USE_QTMAIN TRUE)include(${QT_USE_FILE}) # the variable qtproject_SRCS contains all .cpp files of this projectset(imageviewer_SRCS main.cpp imageviewer.cpp)# tell cmake to create .moc files for all files in the variable qtproject_SRCS that require such a file. # note: this assumes that you use #include header.moc in your filesQT4_AUTOMOC(${imageviewer_SRCS})#QT4_GENERATE_MOC(${imageviewer_SRCS})ADD_DEFINITIONS(-DQT_NO_DEBUG )# create an executable file named qtproject from the source files in the variable qtproject_SRCS. add_executable(imageviewer ${imageviewer_SRCS})# link the qtproject target against the Qt libraries. which libraries exactly, is defined by the include(${QT_USE_FILE}) line above, which sets up this variable. target_link_libraries(imageviewer ${QT_LIBRARIES}) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [Chicken-users] Re: [CMake] setting a default build type
felix winkelmann wrote: On 9/7/06, Brandon J. Van Every [EMAIL PROTECTED] wrote: On MSVC my CMakeLists.txt generates Debug, Release, MinSizeRel, and RelWithDebInfo build types. I want to keep all 4 of 'em. I want to select MinSizeRel as the default build, so that if an end user just fires up BUILD_ALL and does nothing else, he'll get a MinSizeRel build. The default default is Debug and that's not what I want. So, is there a mechanism to specify the default build type? I was unable to deduce it from the docs if there is one. Seems clear enough how to ship *one* build type, I'd just do (SET CMAKE_BUILD_TYPE MinSizeRel). But I want all 4 to be shipped. Just a side note, in case my misunderstanding of the build-type triggered an unneeded feature request: I'm fine with Debug being the default for Project builds (like MSVC/Project). It's in the would be nice to have level of importance. I would rather a user do nothing and get the best optimized build. I'm sure that's true for many other projects also. I asked Brandon to make MinSizeRel the default because I didn't get that this is only supported for mentioned builds. That is to say, only MSVC has Debug, Release, MinSizeRel, and RelWithDbgInfo builds at present. I believe there's an extant feature request about making these universal. Just overriding the CFLAGS via ccmake is fine for me. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake