[CMake] Re: add_definitions string values
Hi, I didn't figure out how to solve the problem below. Could someone tell me any solution for that or where I can read about handling of literal strings in Cmake scripts, please? thanks, Welter Welter Luigi Silva wrote: I'm trying to have a definition with a string value, say, foo. However, when I tried the following command: add_definitions(-DFOO=foo) and used FOO in my source file -- in a command like printf(%s\n, FOO) -- I got 'foo' without the quotes, which is not a valid string literal, as I wished it was. I've also tried the command bellow but it did not work as well: add_definitions(-DFOO=\foo\) So, how do I define this correctly in a CMakeList.txt file? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] visual studio 2005 solution folders
Hi David,
I've recently implemented a simple method to add a solution folder to Visual
Studio projects. It basicly creates a solution-folder named CMAKE and
adds some CMake-generated projects to it. The source code sample below needs
to be added to cmGlobalVisualStudio71Generator::WriteSLNFile(), e.g. just
before the call to WriteSLNFooter(fout):
-- code --
// Add a solution-folder CMAKE and put all CMake-generated projects in it
fout Project(\{2150E333-8FDC-42A3-9474-1A3956D46DE8}\) = \CMAKE\,
\CMAKE\, {;
this-CreateGUID(CMAKE);
fout this-GetGUID(CMAKE) }\n;
fout EndProject\n;
fout \tGlobalSection(NestedProjects) = preSolution\n;
fout \t\t{ this-GetGUID(ALL_BUILD) } = {
this-GetGUID(CMAKE) }\n;
fout \t\t{ this-GetGUID(ZERO_CHECK) } = {
this-GetGUID(CMAKE) }\n;
fout \t\t{ this-GetGUID(PACKAGE)} = {
this-GetGUID(CMAKE) }\n;
fout \t\t{ this-GetGUID(INSTALL)} = {
this-GetGUID(CMAKE) }\n;
fout \tEndGlobalSection\n;
-- end-of-code --
This is of course no general solution but if you cannot wait, this should
get you started.
Cheers!
Marco
Hi,
Is there a way in CMake to create solution folders. The VS 2005 IDE
allows the nesting of projects inside of solution folders. This is
handy for solution files that contain perhaps dozens of projects.
Is it possible to do this in CMake??
There has been a bug filed for this @
http://www.vtk.org/Bug/bug.php?op=votebugid=3796 back in 2006 but it
still appears to be open...does anyone know if this feature will be
implemented through CMake?
Cheers,
David
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Documentation strategy
On Wednesday 20 June 2007 21:09, Robert J. Hansen wrote: Brandon Van Every wrote: ... No, they were planning to port huge chunks of libraries to Windows. Yes, exactly. Please note that planning to port huge chunks of libraries to Windows means they were not yet ported to Windows. It was a UNIX-only project. They were not maintaining horrible hand rolled Visual Studio builds. The top 5 reasons why KDE switched to cmake: 5.) autotools doesn't support MSVC 4.) scons didn't provide a good configure framework 3.) both autotools and scons had problems on OSX 2.) we got very good support from the cmake developers and the number one reason: 1.) only a handful of people understood the KDE autotools system and even these people didn't like it and wrote their own (unsermake) and of course, cmake (basically) just worked (we found some bugs in the process, which were fixed then). Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: add_definitions string values
Hi, Eric Noulard wrote: You've already got answers on the list from Alexander, Filip and Bill http://www.cmake.org/pipermail/cmake/2007-June/014606.html http://www.cmake.org/pipermail/cmake/2007-June/014611.html http://www.cmake.org/pipermail/cmake/2007-June/014615.html Oops, you're right. I'm sorry! I just realized these answers were inside digests of the same day I sent my question. do you read the list? Should I? (just kiding...). Well, I receive the periodic digests and probably missed the answers because I read them in a hurry and was kinda blind! You may additionnally read this Wiki item for the usage of #cmakedefine as recommended by Bill. http://www.cmake.org/Wiki/CMake_HowToDoPlatformChecks thank you and all others for the feedback! Welter ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Documentation strategy
On 6/20/07, Robert J. Hansen [EMAIL PROTECTED] wrote: Brandon Van Every wrote: Counting on people to buy books to do evaluations is bad strategy. I'm not talking strategy. I'm simply saying that your broad claim that I am; note the subject line. Strategy is about broad patterns of behavior. will, when prodded by peers. If you're the only guy with the CMake book, and you're waiting for it, and it's about your schedule and your ways of masking the shipping delay, and you being an assigned person to deal with it in the 1st place, there are lotsa extra barriers. I can't parse this sentence. It's long and run-on but properly constructed. Is English not your 1st language? Note the implicit then, i.e. [then] there are lotsa extra barriers. The projects that see CMake as a slam dunk, are the ones that did an Autoconf build for the Unix stuff, and also had to maintain some horrible hand rolled Visual Studio build, typically with .BAT files. At the time KDE converted to CMake it was a UNIX-only project, and they considered CMake to be a slam dunk. No, they were planning to port huge chunks of libraries to Windows. Yes, exactly. Please note that planning to port huge chunks of libraries to Windows means they were not yet ported to Windows. It was a UNIX-only project. No, when you are definitely planning to port to Windows, and picking tools on that basis, you are not doing a Unix-only project anymore. You are at the planning stage of a cross-platform project. They were not maintaining horrible hand rolled Visual Studio builds. Yes, they were smart enough to avoid that. CMake is still a slam dunk for people who weren't smart enough to avoid that. Again, I think you are arguing too broadly. I'm not sure what point you're really trying to make here, other than you don't like it when people make sweeping generalizations. I'll try rephrasing the spirit of the argument: - huge numbers of people don't and won't buy books to do evaluations - there's a lot of competition out there for modern build systems - without passable free docs, CMake will not become a de facto standard. - intelligent early adopters don't create de facto standards. The masses do. - CMake does not have a good method for getting the community to write the docs. - if CMake doesn't choose to solve this problem, other build tools will. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Documentation strategy
On 6/21/07, Philippe Fremy [EMAIL PROTECTED] wrote: To see an example of a project taking advantage of doxygen for general documentation, you can check Yzis - http://doc.yzis.org . Doxygen is certainly a broadly accepted standard in open source. I just don't know if anyone has done wiki -- Doxygen in an off-the-shelf reproducible way. I'm not sure wikis are the answer either. I do add things to the wiki, but I don't think wikis really cause a lot of people to make significant doc contributions. Given the current quality of the doc, I think it would work better if the cmake doc would simply be imported into the wiki, so that people can improve it. Then you run into the problem of how do we ship wiki docs? That's the real question. Given the content of the wiki now, it would already be a valuable addition to ship with the existing documentation. This has a history in the bug tracker, which you can read about at bug #3757, ship FAQ as part of documentation. At that time, Kitware said it's too much work to maintain a shipped FAQ or other wiki information. I agree that without an infrastructure to handle wiki -- docs, it is too much work. We got URLs to the wiki in the documentation, at the very end of the docs. This works fine for Unix man pages, where they're the last thing you see as you scroll the man page, and it's in the expected place for that sort of information in a man page. It is not fine when reading the docs in a HTML browser on Windows. It's at the very end of the docs and will almost never be read. I entered a content bug some time ago, #3907 Windows start menu links for online documentation. That's a logical place that Windows users go to look for docs. I've entered a new one, #5225 put wiki URLs at top and bottom of docs. What people really want is docs that work well with their chosen IDE. Before that, a slightly more generic documentation of CMake concepts would be welcome. Quoting and variables is for example a topic that is not really covered anywhere. For me, the behavior was quite strange (different than what I expected). I had to rely on lot of experimentations to understand what CMake is doing. Yep. That's bug #3676, Table of Contents for documentation. Recently, Bill and I had a long, private discussion about all the content bugs, and what is to be done about them. My conclusion is that Kitware doesn't have the resources to address these things, and the community has to find a way to do it. The process for modifying the docs is too cumbersome for the community at present. The community has to devise a better infrastructure, or this situation will persist indefinitely. That's probably covered in the book, but I find it strange that you need a book to be able to use an open source tool like CMake. Maybe I am too used to high quality documentation ? Not at all. The vast majority of mature commercial products out there, open source ones included, have high quality electronic documentation. CMake can either provide that like everyone else does, or fall by the wayside over time. There's too much competition out there for people to accept this situation indefinitely. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cmake with Eclipse
Hi, CMake cvs now makes adding generators for IDEs which work with external makefiles easier. There is a new class cmExternalMakefileProjectGenerator, which can be subclassed and be used to create project files for your prefered IDE. This is currently done that way with the KDevelop generator (for UNIX). The UNIX Makefile generator generates all the makefiles as usual, and after that the KDevelop generator runs and creates the xml project files for kdevelop which basically set up the directories, targets and source files part of this project. Since Eclipse supports also projects with existing makefiles, it should be not hard to write such an generator for this kind of Eclipse projects. Then you could simply run cmake -GMingw Makefile - Eclipse and you will get everything set up for Eclipse. If you are interested, it would be nice if you could go ahead and try it and ask if you have questions. Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cmake with Eclipse
Not sure if I am going to get the time to try it out in the near future, though it is good to see a generator for eclipse. Not sure if there will be any changes needed when Eclipse 3.3/CDT4.0 finally arrive in the next few weeks. Nice Effort though. Keep up the good work. -- Mike Jackson Senior Research Engineer Innovative Management Technology Services On Jun 21, 2007, at 1:25 PM, Alexander Neundorf wrote: Hi, CMake cvs now makes adding generators for IDEs which work with external makefiles easier. There is a new class cmExternalMakefileProjectGenerator, which can be subclassed and be used to create project files for your prefered IDE. This is currently done that way with the KDevelop generator (for UNIX). The UNIX Makefile generator generates all the makefiles as usual, and after that the KDevelop generator runs and creates the xml project files for kdevelop which basically set up the directories, targets and source files part of this project. Since Eclipse supports also projects with existing makefiles, it should be not hard to write such an generator for this kind of Eclipse projects. Then you could simply run cmake -GMingw Makefile - Eclipse and you will get everything set up for Eclipse. If you are interested, it would be nice if you could go ahead and try it and ask if you have questions. Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Documentation strategy
Brandon Van Every wrote: My conclusion is that Kitware doesn't have the resources to address these things, and the community has to find a way to do it. If I understood correctly, kitware does not do any money off CMake. They just need CMake to be good and usable, so that they can make money with their other products. That makes it difficult for them to indeed commit resources to that kind of problem. It's unfortunate. The community has to devise a better infrastructure, or this situation will persist indefinitely. That's probably covered in the book, but I find it strange that you need a book to be able to use an open source tool like CMake. Maybe I am too used to high quality documentation ? Not at all. The vast majority of mature commercial products out there, open source ones included, have high quality electronic documentation. CMake can either provide that like everyone else does, or fall by the wayside over time. There's too much competition out there for people to accept this situation indefinitely. You are burying CMake a bit quickly. How many build source tools out there are easy to use, can generate Visual Studio projects or Makefiles, are fully cross-platform and work well ? I am no expert, but I understand that CMake is the only one out there that meet all these requirements. Most other build tools are usually a replacement of make. Good replacement for most of them, but replacing make does not generate a Visual Studio project. regards, Philippe ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Documentation strategy
I am; note the subject line. That is not enough to make me talk about it. My concern is not what you call a 'documentation strategy'. I think that's tail chasing, mostly. My concern is what I see as a tendency towards overbroad generalizations on your part. It's long and run-on but properly constructed. Is English not your 1st language? Note the implicit then, i.e. [then] there are lotsa extra barriers. When told that one is being unclear, it's usually better make things clear than to argue you're being perfectly clear. Also, run-on sentence construction is considered a grammatical error, which means that it's not properly constructed. The projects that see CMake as a slam dunk, are the ones that did an Autoconf build for the Unix stuff, and also had to maintain some horrible hand rolled Visual Studio build, typically with .BAT files. No, when you are definitely planning to port to Windows, and picking tools on that basis, you are not doing a Unix-only project anymore. You are at the planning stage of a cross-platform project. Please compare what you said, which I said was overly broad, with what you are now saying, which is substantially different. I have said what I intended to say, and for that reason I think I'm finished here. Please stop being overly broad; it just undercuts what you're trying to argue. -- Robert J. Hansen [EMAIL PROTECTED] Most people are never thought about after they're gone. 'I wonder where Rob got the plutonium?' is better than most get. -- Phil Munson ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Documentation strategy
On 6/21/07, Robert J. Hansen [EMAIL PROTECTED] wrote: I am; note the subject line. That is not enough to make me talk about it. My concern is not what you call a 'documentation strategy'. I think that's tail chasing, mostly. So you think this whole wiki -- docs discussion, and somehow improving the quality of the docs by community effort, with a better process, is a bad idea? Or just not a compelling idea? The sky won't fall if we completely ignore it and proceed with business as usual? The rest I will address privately. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Documentation strategy
On Thursday 21 June 2007 16:56, Brandon Van Every wrote: On 6/21/07, Robert J. Hansen [EMAIL PROTECTED] wrote: I am; note the subject line. That is not enough to make me talk about it. My concern is not what you call a 'documentation strategy'. I think that's tail chasing, mostly. So you think this whole wiki -- docs discussion, and somehow http://wiki.docbook.org/topic/Wt2Db + some more scripting should probably do quite a lot. Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
