Re: [CMake] Re: CMake script vs. Lua
On 2007-12-14 18:54-0200 Rodolfo Schulz de Lima wrote: [...]What I mostly miss in CMake is a nicer syntax. I look to a cmake script and it YELLS at me, with all those upper cased letters. As a point of information that depends to a certain extent on what style of CMake scripting you decide to use. For example, every cmake command or macro command name is case insensitive so I routinely call them with lower case. I haven't commented before on this thread because I am no language expert, but I lean toward the conservative side; that is I am pretty much happy with CMake the way it is (despite my recent bitching about dependencies, :-)). Obviously, scope is an issue for CMake 2.4.x, but that apparently is now fixed in the cvs version, and I am sure dependencies will be fixed as well IF a large fraction of the CMake community gets tired of the two kinds of dependencies we have now. But if that doesn't get fixed, I can live with it. One of the huge advantages of the CMake scripting that I don't believe has been emphasized enough in this discussion is it is a small, very easy to learn language. I like it that way, and I believe that quality attracts others to CMake as well. 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] Parallel builds do not work correctly when using "cmake -E copy" to copy files
On 2007-12-14 09:53-0800 Alan W. Irwin wrote: Obviously, CMake 2.4.x users are stuck with these file dependency issues and their workarounds, but for obvious reasons and especially for the parallel build case I hope the complete rework of the CMake dependency system that has been mentioned previously on list will remove these limitations. Well, it turns out I had to add four different target dependencies to the CMake-based PLplot build system to get rid of the parallel build problems I was having on my Core Duo box. One of them was pretty subtle so I missed it for my first review of the dependencies. Nevertheless, these changes were not as extensive as I thought they would be so there is some hope that I didn't miss anything that will show up as strange parallel build problems for PLplot on other machines. I am still interested in the answer to the question below. Alan Is that complete rework actually going to happen for 2.6.x or is it currently just a gleam in the CMake developer's eyes? ______ 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] Parallel builds do not work correctly when using "cmake -E copy" to copy files
On 2007-12-15 12:57-0500 Brad King wrote: Alan W. Irwin wrote: Well, it turns out I had to add four different target dependencies to the CMake-based PLplot build system to get rid of the parallel build problems I was having on my Core Duo box. One of them was pretty subtle so I missed it for my first review of the dependencies. Nevertheless, these changes were not as extensive as I thought they would be so there is some hope that I didn't miss anything that will show up as strange parallel build problems for PLplot on other machines. Great, I'm glad you got it working. Well, I thought so, but my previous test was without the (docbook) documentation build. Now, that I have included that, the parallel build errors out. For the last few hours I have been going through the complicated dependencies in our documentation build, but I just cannot see what is causing the trouble. Perhaps if I sleep on it, it will become obvious tomorrow. Is that complete rework actually going to happen for 2.6.x or is it currently just a gleam in the CMake developer's eyes? To what message are you referring? I was sure I remembered a discussion of reworking the CMake depends system on this list in the past year, but I have been unable to find it so perhaps I was misremembering (or perhaps my searching skills are not good enough). So let me rephrase the question. Are the CMake developers happy with the present state of the dependencies system or are you considering some major changes there because of such issues as the difficulties in getting parallel builds to work properly for projects like PLplot which (necessarily) have complicated chains of dependencies? 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] FIND_FILE Issue
On 2007-12-17 14:55+0530 Surya Kiran Gullapalli wrote:
Hello all,
I'm a newbie to Cmake and I'm having trouble in FIND_FILE.
I'm using FIND_FILE in a loop like this.
SET (${THIS_FILE} INTERNAL "Temporary Variable" FORCE)
# I Tried this one also
# SET (THIS_FILE INTERNAL "Temporary variable" FORCE). But this one
threw errors.
FOREACH (ofile ${FILES})
FIND_FILE (THIS_FILE ${ofile} PATHS ${path1} ${path2} ${path3})
MESSAGE (${THIS_FILE})
# I've used MARK_AS_ADVANCED (CLEAR THIS_FILE), but the result was the same.
ENDFOREACH (ofile)
FInd_file runs for the first time and if the file is found it sets the
variable THIS_FILE and it is cached. For the second time, FIND_FILE
does not gets executed due to the presence of cached variable
THIS_FILE. So in the end I end up with only one file.
Questions.
1. How do i clear a cached variable ?
2. How do i tell CMAKE not to write the variable to Cache ?
3. How do i use FIND_FILE to locate multiple files (like the one I've
explained above)?
Try setting to -NOTFOUND (i.e., set(THIS_FILE THIS_FILE-NOTFOUND)
before each FIND_FILE in the loop. For some additional documentation of
-NOTFOUND see the FIND_FILE documentation.
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] BOOL type
To supplement Brandon's Boolean wishlist, I would like to see some way to specify a non-default precedence of Boolean operators. Most languages use parentheses for this, and ideally that would be true for CMake as well. Then a test of Boolean inequality of A and B would be IF((A AND NOT B) OR (NOT A AND B)) and a test for Boolean equality of A and B would be IF((NOT A OR B) AND (A OR NOT B)) Perhaps CMake already has this feature but it is not documented? 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] OO and/or IDEs
On 2007-12-17 20:30-0500 Brandon Van Every wrote: When I peruse http://www.ohloh.net/tags/make I notice that most of the Popular! make-like tools have a particular implementation language associated with them. If you want a make written in Java, you use Ant. If you want it in Ruby, you use Rake. If you want it in C/C++, you use either CMake or GNU Autoconf + GMake. Correction about Autoconf with some additional comments about autotools. Autoconf requires m4 and shell scripting (both of which are exposed to the user), automake requires perl (hidden from the user with the public interface a unique extension of make), libtool is implemented as a giant (and slow!) shell script with a small number of command-line options for that shell script. autotools tries to use the lowest common denominator of all make systems so it will work on any Unix platform rather than the unique capabilities of native make systems such as GNU make. In sum, as virtually everyone on the Linux side of things realizes by now, autotools is a technical mess. BUT autotools were first to market in the Linux world so there are still a large number of Linux projects that continue with autotools. However, my guess based on obvious technical superiority, the possibility of porting to windows (not all Linux projects are like Chicken!), and the huge advertisement the KDE adoption gave to CMake is that the current CMake share of Linux projects is strongly growing at the expense of autotools. Furthermore, it is obvious from traffic on this list that a large and growing number of windows projects are beginning to use CMake as well. Brandon, because of this strong growth, I disagree with your emphasis on the importance of strategic decisions now for CMake. Those were done a long time ago, and people and projects are strongly voting with their feet despite (and this is an extremely important consideration) virtually everybody absolutely hating to change build systems. So long as the CMake developers steer a steady course and don't shoot themselves in the foot with some stupid decision, their strong growth will continue, and as a result I think they we be _the_ major build system in the decades to come. Thus, my own feeling is CMake developers and users can quit worrying about market share since the future is bright indeed on that score almost regardless of what they do. Instead, they should totally concentrate on technical improvements that don't disturb things too much and which make CMake build systems simply easier to design and maintain. I am talking about such things as cross-compiling, module improvements (including standardization), scoping, improved regex, and even Boolean precedence. The first three are already in the CVS version of CMake and the rest have been recently discussed positively on list with at least a chance to get into CVS. In sum, the CMake developers have something they can be proud of, that pride will continue to drive them to make some modest improvements like listed above, and so long as they don't make any irrevocable mistakes in such changes their current large growth rate assures them of world domination for both Linux and windows build systems. :-) Just my $0.02. 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] OO and/or IDEs
On 2007-12-17 23:02-0500 Brandon Van Every wrote: I guess you have no fear of a Disruptive Technology biting you in the ass. That is correct. Disruptive technology by definition is overwhelmingly superior, and I like such technology and don't fear it in the least. Also, I am comfortable with change so therefore I tend to be an early adopter of disruptive technology. But life is short so I don't adopt new technology unless there is a real and overwhelming case (not just marketspeak) that it is _much_ better than what I am using. For me, CMake was disruptive technology (overwhelmingly superior) compared to autotools, and therefore it was a no-brainer decision for me because of my comfort with change. If/when I adopt my next build system it must be similarly overwhelmingly superior to CMake. But right now, I am pretty satisfied with CMake and cannot imagine when the next build-system revolution will strike. Some here have guessed three years, but my own feeling is it will be _much_ longer. Anyhow, changing your strategy to deal with disruptive technological changes is a waste of time at best; by definition disruptive technology changes are extremely hard to predict and therefore there is no change in strategy that will stop them. OTOH, discussing possible incremental changes to CMake such as improved regex is well worthwhile because of better service to users and the pride that goes with that. But I don't think such changes are going to affect when the CMake tipping point occurs. I think that tipping point has already happened based on the rate of CMake adoption in a software area (build systems) where everybody ordinarily dislikes change. 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] ADD_SUBDIRECTORY
On 2007-12-20 17:09-0600 George Neill wrote: ... or do I just shut up and continue using the dang ADD_CUSTOM_TARGET() function :) Well, don't shut up. :-) However, if you have created targets lib1, lib2, lib3 with the EXCLUDE_FROM_ALL attribute, in various subdirectories and want one special make target that builds all of them, then use add_custom_target(libs) add_dependencies(libs lib1, lib2, lib3) Since there is no ALL attribute on libs, and you have used the EXCLUDE_FROM_ALL attribute when building lib1, etc., "make all" will not build lib1, etc. but "make libs" will. If there are lots of such libraries that differ from one configuration to the next, the above procedure can easily be automated to use a list of libraries that is created by the configuration. I haven't been paying that much attention to this thread, but since it's had a number of posts I assume you have been advised to do the above before. Usually, you will find the advice on this list is pretty good. :-) 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] Re: Target flags depending on compilation of another target
On 2007-12-21 10:14-0200 Rodolfo Lima wrote: Jesper Eskilson escreveu: Not generally, no. However, if you know that you'll be using Make with a bourne-shell to build you can sneak in things like "`cat somefile.txt`" into your CMAKE_CXX_FLAGS, and have your custom target write flags to "somefile.txt". This technique is commonly used in Unix makefiles to allow compiler-flags to be generated "on-the-fly" by a utility program. Wow, that's what McGyver would do if he were a programmer. Thank you! With Visual C I think I can write a 'here document' and add with @flags.txt, isn't it? Is there any way to make cmake support things like this? A common use case would be like... one of your targets is a custom target which compiles wxWidgets (for instance). When it gets installed, it creates a bash script (wx-config) which, when run, returns proper compiler and linker flags. Those flags are used by another target that has wxWidgets as dependency. Have a look at the internals of FindwxWidgets.cmake that comes with CMake-2.4.7. It uses wx-config for the case where wxwidgets is already externally installed. It should be straightforward to adapt this module for the case where you are building wxwidgets internally. For PLplot we implement the compiler flags returned by FindwxWidgets.cmakewith using the SET_SOURCE_FILES_PROPERTIES COMPILE_FLAGS property. Furthermore, we have historically put the linker flags returned by that module directly into a TARGET_LINK_LIBRARIES command. However, a better way to do it is to parse the link flags string into full pathnames for libraries that are specified for TARGET_LINK_LIBRARIES and linking options that are not related to library location that are specified with the LINK_FLAGS property of SET_TARGET_PROPERTIES. 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] Re: Re: Target flags depending on compilation of anothertarget
On 2007-12-21 18:14-0200 Rodolfo Schulz de Lima wrote: Have a look at the internals of FindwxWidgets.cmake that comes with CMake-2.4.7. It uses wx-config for the case where wxwidgets is already externally installed. It should be straightforward to adapt this module for the case where you are building wxwidgets internally. I cannot use wx-config when I don't have wxWidgets installed because it doesn't exists. You are right. I was confusing cmake time with build time. However, what is to stop you building your own version of wxwidgets as an external project? Then cmake; make, etc., would have to be run once to build wxwidgets and once for your project. If that turned out to be too complicated for your users, you could put those commands in one overall script to simplify their builds. For PLplot we implement the compiler flags returned by FindwxWidgets.cmakewith using the SET_SOURCE_FILES_PROPERTIES COMPILE_FLAGS FindwxWidgets actually does this parsing, while UsewxWidgets.cmake assigns the variables to cmake's variables, you shouldn't have to do it by hand. I believe you misunderstood. We only want to use the wxwidgets compile flags and link flags on a (extremely small) subset of our source files and targets. So we have to use the appropriate CMake commands to set that up. It sounds like you may not have that requirement. 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] Re: Re: Re: Target flags depending on compilation ofanothertarget
On 2007-12-21 19:23-0200 Rodolfo Schulz de Lima wrote: You are right. I was confusing cmake time with build time. However, what is to stop you building your own version of wxwidgets as an external project? Then cmake; make, etc., would have to be run once to build wxwidgets and once for your project. If that turned out to be too complicated for your users, you could put those commands in one overall script to simplify their builds. Yes, I could do it, but I'm striving to make it simpler. Once my developer gets in his machine, he would: 1) pull out sources from subversion, this would also download all external dependencies (through property svn:externals, for the svn-inclined) 2) do cmake . 3) make -j2 4) ... 5) be rich and score some chicks I'm dealing with a lot of external libraries... boost, wxWidgets, freetype, ftgl, openAL, lib3ds, libjpeg, glew, lua and luabind. Building those by hand is a pain, and didn't I mention that it should work with Visual Studio, mingw32 on Windows, mingw32 on Linux and good old gcc? Thanks to cmake my recipe is the same no matter the environment my developers decides to use. So that's why I'm trying to do this way. Understood, but repeating steps 2 and 3 (once for wxwidgets which your developer just downloaded as part of the overall download and once for the rest) doesn't complicate the build very much. Of course, repeating step 5 might complicate your life... :-) With a script I'd have to have at least 2, one for linux (bash, etc...) and for windows (braindead batch processing). No personal experience myself, but the PLplot bare windows (i.e., no Cygwin, or MinGW) developers tell me there is a bash for windows that they can install. So ctest (which in our case runs shell scripts) is cross-platform for PLplot iff the windows user has installed bash. However, instead of requiring bash on all platforms, just repeating steps 2 and 3 is probably simpler in your case. 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] Re: call a configure command
On 2007-12-22 17:16-0200 Rodolfo Schulz de Lima wrote:
Write a CMake script containing the configure command. Invoke it at
build time using ADD_CUSTOM_COMMAND COMMAND ${CMAKE_COMMAND} -P
myscript . Of course, this isn't going to configure anything. :-)
Are you just trying to perform text substitutions or something?
If he's trying to compile an external package from within cmake, I usually do
this by adding add_custom_command(OUTPUT ${srcdir}/Makefile COMMAND
${srcdir}/configure ...) to the CMakeFile.txt, create another one to invoke
'make' dependent of the ${srcdir}/Makefile of the last add_custom_command,
and finally use add_custom_target to create a target that initiates the whole
shebang, having as depedency the output of the last add_custom_command.
Hmm, Rod, those additional details about what you are doing have given me a
follow-up idea for the wx-config problem we previously discussed.
Note, you don't have to do any of the above with add_custom_command. In
principle, you could also do those external builds with execute_process.
The difference, of course, is execute_process runs at CMake time so that
solves the issue we discussed before of wx-config from your build of
wxwidgets not being available at CMake time for the rest of your build.
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] usign doxygen with cmake
On 2007-12-26 09:37+0200 Ramazan Girgin wrote: Hi, How can auto generate doxygen html file in cmake ?Is there any example project about this? The normal way to do something "custom" like this is to use add_custom_command (with full PATHNAME OUTPUT signature), with an empty (no command) add_custom_target which file depends on that OUTPUT file. See http://lasi.svn.sourceforge.net/viewvc/lasi/trunk/ for one example of dealing with doxygen. I don't claim the treatment of doxygen there is ideal since I am not that familiar with doxygen, and I was just interpreting what a previous autotooled build system did with it, but that whole libLASI project is a good example of a CMake build system at least in the sense that it is small, and thus easy to understand in its entirety. 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] Re: Migration to subversion
On 2008-01-04 07:17-0800 E. Wing wrote: My 2 cents. Distributed [version control system] is the right way to go in my opinion. I don't completely agree. Centralized repositories have proved useful for lots of software development projects (e.g., the 160,000+ free software projects at SourceForge). Of course, centralized repos don't work very well if projects (such as the Linux kernel) have huge numbers of active developers, but most software projects (such as CMake) will never have more than a handful of active developers, and for such projects a centralized repository makes a lot of sense. Thus, it is probably a given that CMake will always use a centralized repository. I assume that does not rule out git or Mercurial. For example, from the git-svn crash course at http://git.or.cz/course/svn.html, it appears that git has the capability to use a centralized repository (the so-called bare repository), and I presume that is the case for Mercurial as well. So the choice between cvs, svn, git, and Mercurial really boils down to how impressed the CMake developers are with the particular implementation of a version control system with a centralized repository. My own personal experience has been I used CVS for years (at first because that was all that was available at SF, but then after they deployed the svn alternative there it was just inertia even though there were many aspects of cvs I did not like). However, last year I participated in one project that used svn, and that nice experience convinced me rather quickly to switch all my projects to svn because cvs just sucks in comparison with svn. Currently, I am almost completely satisfied with svn, and I think it would be an excellent choice for CMake as well. However, I admit to having no development experience with git or Mercurial. Is there anything compelling (e.g., fewer bugs, better documentation, more useful features aside from distributed?) about either over svn for projects like CMake that use a centralized repo? 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: [Spam] Re: [CMake] Re: Migration to subversion
On 2008-01-04 22:38- James Mansion wrote: Gonzalo Garramu�o wrote: In summary, once you use git, if you are like me, you'll realize that you've been doing source version control wrong all these years *sigh*. Does git work on Win32? As already mentioned earlier in this thread, git is available for Cygwin (see http://cygwin.com/packages/git/), and for those who prefer the MinGW development environment, I just now discovered a git version that apparently can be built using MinGW (see http://repo.or.cz/w/git/mingw.git and http://repo.or.cz/w/git/mingw.git?a=blob_plain;f=README.MinGW;hb=master). Also, Mercurial (mentioned as another alternative to git on this thread) is python-based so it should run on just about any platform. 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] cmake 2.4.8 RC 10
On 2008-01-09 12:51-0500 Bill Hoffman wrote: Bill Hoffman wrote: Did you decide to remove the 'ability to select install location for mac'? opps, I forgot RC 11... OK, RC 11 is up now, and the mac install location stuff is now gone. If I don't here anything more, I will make the official 2.4.8 on Thursday or Friday. Hi Bill: The tar.gz and tar.Z form of the source package for RC 11 seems to be missing at http://www.cmake.org/files/v2.4/ . 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] cmake 2.4.8 RC 10
On 2008-01-09 11:25-0800 Alan W. Irwin wrote: Hi Bill: The tar.gz and tar.Z form of the source package for RC 11 seems to be missing at http://www.cmake.org/files/v2.4/ . I tried to work around that issue by using cmake-2.4.8-RC-11.zip. The Linux unzip command seemed to work without obvious problems, but I discovered that the resulting bootstrap script did not have execute permission. Anyhow, I assume other permissions are also wrong for the unzipped results so I am going to quit and wait for the *.tar.gz form from you (hopefully with correct permissions). 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] cmake 2.4.8 RC 10
On 2008-01-09 15:16-0500 Bill Hoffman wrote: On 2008-01-09 11:25-0800 Alan W. Irwin wrote: Hi Bill: The tar.gz and tar.Z form of the source package for RC 11 seems to be missing at http://www.cmake.org/files/v2.4/ . [...] OK, all the files should be there now. The .zip won't work because it has bad line feeds for linux. Thanks, Bill. I understand Alex already arranged to do nightly builds of PLplot as a routine test of CMake changes, but I believe that is just one platform, and it is probably just a test for the CVS HEAD version of CMake and a fixed version of PLplot. Anyway, just in case anything fell between the cracks for your tests, I just now built RC 11 using the ./bootstrap script and tried a build of the svn trunk version of PLplot using that resulting RC 11 version of CMake. Everything was fine for the cmake build and the PLplot build, and ctest for PLplot was 100 per cent. These good results are for my particular (Debian testing) platform. 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] cmake 2.4.8 RC 10
On 2008-01-09 16:17-0500 Bill Hoffman wrote: Alan W. Irwin wrote: Anyway, just in case anything fell between the cracks for your tests, I just now built RC 11 using the ./bootstrap script and tried a build of the svn trunk version of PLplot using that resulting RC 11 version of CMake. Everything was fine for the cmake build and the PLplot build, and ctest for PLplot was 100 per cent. These good results are for my particular (Debian testing) platform. Thanks, very much for testing this. I am happy to hear it works. I guess on the cygwin project they give out gold stars. If we had gold stars for CMake, you would get one. :) Thanks, Bill, for that nice comment. Made my day and also made my wife's day! Of course, the real stars of this show are the CMake developers themselves, but many CMake users like me are glad to help where we can with feedback because CMake has proved so useful to us. 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] Newbie question: generated header file howto
On 2008-01-11 08:05+1100 Pacesie wrote: If I want to generate document files as part of the build, should I first create an ADD_CUSTOM_TARGET then have it depends on the generated files defined by ADD_CUSTOM_COMMAND? ( It would be nice if file generation can be defined as a target so the extra step is not needed. ) You can generate the files by the appropriate custom target command, but that will get executed for every "make" command so normally custom targets are done without any associated command, and instead file depend on custom commands (which are only run if the output file actually needs updating). Do the targets always run by the order that they are defined in CMakeLists (unless there are dependency) ? So that if I want to be sure a target is run before all others, I define it first in CMakeLists? If order is important between your various targets, enforce that with a target dependency. 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] Why SET() not support regular expression ?
On 2008-01-18 13:43+0100 Yang, Y. wrote: Hi all. I just use CMake for two week. And I found it's very good tool. However, I just wonder that why in CMake the SET not support regular expression. For example, SET( MY_SRCS mydir/*.c) if CMake can do this, I don't have to modify the CMakeLists.txt every time when I add new files to mydir. Search for the FILE(GLOB signature in the CMake documentation. 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
[CMake] $ENV usage and documentation
I would like to be able to read arbitrary environment variables from within
cmake. The 2.4.8 documentation only refers to $ENV once as "$ENV{PATH}" in
an extremely narrow context (the TO_CMAKE_PATH signature of the FILE command).
However, when I tried, e.g.,
SET(pc_path "$ENV{PKG_CONFIG_PATH}")
it seemed to work. Is this usage supported in general?
The current documentation has a number of different references to ENV.
It refers to
$ENV{PATH}
one place (in a narrow context as noted above),
ENV var
several places, but in extremely specific contexts (which I presume could be
replaced by $ENV{var})
and
ENV{PATH}
in one place (an example showing how to use SET to write
the PATH environment variable).
Please document $ENV for reading and ENV for writing arbitrary environment
variables in at least the CVS version. A logical place for this general
documentation might be the SET command since as noted above that already
gives an example for writing the PATH environment variable.
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] $ENV usage and documentation
On 2008-01-27 22:28-0500 Brandon Van Every wrote:
On Jan 27, 2008 8:34 PM, Alan W. Irwin <[EMAIL PROTECTED]> wrote:
I would like to be able to read arbitrary environment variables from within
cmake. The 2.4.8 documentation only refers to $ENV once as "$ENV{PATH}" in
an extremely narrow context (the TO_CMAKE_PATH signature of the FILE command).
However, when I tried, e.g.,
SET(pc_path "$ENV{PKG_CONFIG_PATH}")
it seemed to work. Is this usage supported in general?
As far as I know. You can test all these things out with trivial
scripts to prove that they work or don't work.
Yes, that is exactly what I have done, but the question remains is this some
side effect that might be removed later or is the code meant to work that
way, i.e., is it a supported use?
It would be best if you file a (documentation, text) bug report for
this. Preferably with the wordsmithing you think should be used, and
where it should be used, based on what you have determined works
properly. I've been doing this for various documentation
embellishments in recent months, and they are getting acted upon and
closed.
Well, it does sound like you have been successful with that approach so I
may adopt it, but generally I am quite hesitant to go through formal bug
reporting for stuff that can be fixed much faster than the time spent on bug
triage. IOW, I hope CMake developers read this list and when they see small
issues reported they fix it immediately rather than fooling around with bug
reports, assigning somebody to deal with it, etc. Finally, there is no
point in me suggesting new documentation wording when questions like the
above are still outstanding.
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] Questions related to PkgConfig
On 2008-01-28 19:45-0800 Radu Serban wrote:
Hi,
I have a couple of questions related to using pkg-config in CMake:
1) Using information returned by the macro pkg_check_module from
FindPkgConfig.cmake
This should be straightforward but I just cannot get it to work. Say I create
my own library "mylib" which depends on a module "cvodes" which comes with a
cvodes.pc file. Adding pkg_check_modules(CVODES cvodes) in CMakelists.txt
correctly extracts all the information from cvodes.pc and sets the variables:
===
cvodes pkgconfig results:
===
PKG_CONFIG_FOUND 1
PKG_CONFIG_EXECUTABLE /usr/bin/pkg-config
CVODES_FOUND 1
CVODES_LIBRARIES sundials_cvodes;sundials_nvecserial;sundials_nvecparallel;m
CVODES_LIBRARY_DIRS /home/radu/CODES/NREL/lib
CVODES_LDFLAGS
-L/home/radu/CODES/NREL/lib;-lsundials_cvodes;-lsundials_nvecserial;-lsundials_nvecparallel;-lm
CVODES_LDFLAGS_OTHERS
CVODES_INCLUDE_DIRS /home/radu/CODES/NREL/include
CVODES_CFLAGS -I/home/radu/CODES/NREL/include
CVODES_CFLAGS_OTHERS
I then use include_directories(${CVODES_INCLUDE_DIRS}) and successfully build
the library mylib.
But then I'd like to build an example which must be linked with mylib and all
CVODES libraries and this is where I got stuck... How do I use the above
information? I have
ADD_EXECUTABLE(testS testS.c)
TARGET_LINK_LIBRARIES(testS as2)
but how about the CVODES libraries? What's the proper way of linking the
target testS to these libraries? I tried unsuccessfully all sort of
combinations using TARGET_LINK_LIBRARIES and SET_TARGET_PROPERTIES...
The above commands should be all you need. CMake is smart enough to keep
track of linking information for each library and use that for each
executable linked to that library. So it has all the information it needs
to use the correct linking model for any given platform. So I suggest you
test the linking yourself (e.g., with the "ldd -r" command if you have a
Linux platform) and/or run "make VERBOSE=1" to make sure the linking was set
up correctly by CMake.
2) Creating a *.pc file for a project.
Suppose my project creates a library "mylib" which requires the BLAS library.
Since I do not have a blas.pc file, I simply use some FindBLAS.cmake file
which finds the BLAS library as /usr/lib/libblas.so. When I create mylib.pc I
cannot use something like "Requires: blas" because there is no blas.pc so I
need to add the BLAS libraries under the "Libs" keyword. Does CMake provide a
way of generating the proper string to be added to "Libs:"?
Use TARGET_LINK_LIBRARIES which can accept target names for CMake-generated
libraries as above, full pathnames of external libraries such as libblas, or
even -L and -l options for specifying libraries (not recommended since rpath
does not work right for the build tree in this case). Those
various possibilities have never been documented, but the PLplot build (for
example) depends on this behaviour for 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 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] Unexpected behavior testing boolean expressions
On 2008-01-30 19:36-0700 Timothy M. Shead wrote:
[...]This produces expected results for all of the documented "boolean"
values: YES, NO, TRUE, FALSE, ON, OFF, etc. However, if I pass one of
those values to a macro:
macro(test var)
if(${var})
message("true")
else(${var})
message("false")
endif(${var})
endmacro(test)
test(1)
test(0)
test(YES)
test(NO)
test(TRUE)
test(FALSE)
test(ON)
test(OFF)
Things look pretty strange to me:
true
false
false
false
false
false
false
false
... only "1" tests true! Can anyone shed some light on where I'm going
wrong?
When running up against problems like this I use message within the macro to
see exactly what is going on. My guess is YES, etc., are being interpreted
as (undefined) variable names so you should try quotes, e.g., test("YES") or
else
set(x YES)
test(x)
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] 4th Edition CMake book now in stock
On 2008-02-05 14:04-0500 Ken Martin wrote: The 4th edition CMake books have arrived and you can order them from http://kitware.com/products/cmakebook.html They should show up on Amazon in the near future as well. A summary table of contents is included below. I looked at that site, and there was no mention of an electronic (PDF) version. I far prefer that format since it is friendlier to trees, takes up no space in my office, is much easier to search, and I can adjust the size of the text when my eyes get tired. From the CMake promotion aspect, the more the license on an electronic version gives freedom to the user the better. For example, "Version Control with Subversion" is a free (both in the sense of cost and user freedom) book (at http://svnbook.red-bean.com/) which very much encourages version control users to use subversion. To take an example from further afield, Baen publishing promotes their books and authors with complete electronic versions of SciFi novels of their most popular authors (such as David Weber). The versions are free of cost and the only restriction on user freedom is you are not allowed to sell the electronic version to anybody else. Judging by the popularity of Baen authors and the discussion of this promotion on their web site, the idea has been a huge success. If you are concerned with short-term money rather than long-term promotion of CMake and the potential money that might come from that, then you will probably want to distribute an electronic version of your book with reduced user freedom. I think such a restricted version would be acceptable so long as at minimum the user was free to make backup copies for their own use. Regardless of license, I believe you could sell quite a few electronic versions of your book so long as the reduced production cost (no printing cost, no shipping cost except bandwidth) of the electronic version was acknowledged in the price. 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] 4th Edition CMake book now in stock
On 2008-02-05 17:08-0500 Brandon Van Every wrote: On Feb 5, 2008 4:28 PM, Alan W. Irwin <[EMAIL PROTECTED]> wrote: I looked at that site, and there was no mention of an electronic (PDF) version. I far prefer that format since it is friendlier to trees, takes up no space in my office, is much easier to search, and I can adjust the size of the text when my eyes get tired. Here's to dead trees! They rest my eyes, they carry to any physical location I wish. Brandon, I can visualize you strongly arguing for the quill pen when the first printing presses came out. :-) If you are concerned with short-term money rather than long-term promotion of CMake and the potential money that might come from that, then you will probably want to distribute an electronic version of your book with reduced user freedom. I think such a restricted version would be acceptable so long as at minimum the user was free to make backup copies for their own use. My opinion is that Kitware doesn't need to provide the entire book in an easily pirated medium. Please think of what real piracy implies (rape, murder, looting, slavery) before using the term so casually. Of course, Hollywood and the RIAA likes to use such overblown terms for use of any of their products in any way they don't like (whether legal or not), but that doesn't mean you have to ape their misuse of the language. I think what you really meant to say was "an easily copied medium", i.e., an electronic format. However, my opinion is it is a bad business choice for KitWare to ignore the electronic book market for this book, and I would like to hear what they have to say about that since that is likely the only format in which I would buy this book. 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] 4th Edition CMake book now in stock
On 2008-02-05 19:50-0500 Brandon Van Every wrote: Please think of what real piracy implies (rape, murder, looting, slavery) before using the term so casually. "Piracy" is a technical term that everyone in the software industry is familiar with, and that most consumers are now familiar with as well, thanks to their something-for-nothing habits with MP3s, DVDs, and P2Ps. Familiarity does not mean everybody is content with the term. Instead, in my view such language is part of a giant sell job to be pejorative about _all_ copying no matter for what legal purpose, and this has bad practical consequences for all computer users. In Canada (and many other parts of the world) you cannot buy CD blanks for computer backup without paying a levy to the music industry. And those guys used the extremely large amount of money collected primarily to lobby the government to raise the levy and extend it to more items such as ordinary computers. (After all a computer _might_ be used for some nefarious music copying activity). So far, sanity has prevailed in Canada on refusing such extensions, but in the long term if the computer industry does not wake up to this threat, their profits will all go to the music industry. For another example, there have been North American cases of ISP's trying to block file copying between computers because they are worried some of it might be illegal copying. In my view that is like tearing up the streets since there have been used for a bank robbery getaway cars in the past and will be so used in the future. The fact is streets are too useful for legitimate use to tear up because of illegal use and the same is true of file copying over the internet. From the terminology you use, it appears you have bought into the idea that copying is uniformly bad. If you don't mean to make that impression, don't use the pejorative term "pirated" when you really mean "copied". If you insist on using the term "pirated", then all I can say is you haven't thought through the consequences for the computer industry of stopping all legitimate copying. Of course, Hollywood and the RIAA likes to use such overblown terms for use of any of their products in any way they don't like (whether legal or not), Hardly. Those are new kids on the block. I don't care since that is beside the point. Finally, Brandon, I assume you disagree with some/all of the above since we obviously live in different realities, but will you for once grant someone else the courtesy of the last word in a given thread? You rarely do that, and it is frankly irritating behaviour. Of course, my friends will tell me something about kettle, pot, and black ( :-)), but I am aware of the issue for myself and I am trying to deal with it so this is the last I will respond to you in this thread even if you decide to grab the last word for yourself once again. Moving back to the original topic, I would still really appreciate the KitWare guys commenting on whether they have plans to sell an electronic version of their book for those of us who strongly prefer that format. 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] Parallel builds do not work correctly when using "cmake -E copy" to copy files
On 2007-12-14 09:53-0800 Alan W. Irwin wrote: On 2007-12-14 10:32-0500 Brad King wrote: CMake employs a 2-level make recursion system that is independent of the directory structure. The first level never builds anything...it just evaluates target-level dependencies with phony targets. That determines the order in which targets must be built. The second level is the build.make for each target. This is where file-level dependencies are evaluated. In your example the file1...fileN rules are showing up in target1's build.make and target2's build.make but they should never be evaluated in the second target. They are pulled in through the additional_file rule's dependencies on them (see below), but they should always be up to date if target2 doesn't build until after target1 finishes. Then only the additional_file rule will be invoked. However if there is no dependency from target2->target1 then both build.make files may be built simultaneously and you get race conditions causing the double evaluations. CMake traces through the dependencies of custom commands in each target. When it is constructing target2 it doesn't know that target1 will also provide rules for the files. If you place the targets in different directories it would not be able to make this extra connection, but then the build would not work correctly unless you add the target-level dependency. Any further explanation here will just duplicate my previous message so I'll stop. That's fine. Your combined explanation now makes sense and completely confirms my working hypothesis that the make recursion system of CMake is responsible for the parallel build issues I was encountering. I hope I can work around these PLplot parallel build issues (note the double copy issue was only the most obvious one) by using extra target dependencies. The problem is that parallel build issues tend to appear and disappear depending on load, the N level (for -j N), and hardware. Thus, even if a whole flock of PLplot developers confirm success for parallel builds, there could be some subtle dependency issue left that we have missed, and some user down the road is going to come up with a combination of load, N, and hardware that triggers the parallel build problem because of that dependency issue. As a PLplot developer, I don't like being in such an uncertain position! I thought it important to resurrect this two-month old thread because today I _finally_ got success (at least no obvious issues, see comment below) with parallel builds of PLplot on my particular platform. That's the good news. The bad news is it took so much effort. Plplot is not that big a piece of software, but there are a large number of different components with complex dependencies between them. Therefore I had several tries in the two months to get parallel builds to work that failed miserably. This last successful effort of getting "make -J N" to work for many different N values took at least several days of isolating the problem by enabling/disabling various PLplot components until I was finally able to find and fix the last two dependency issues that showed up on my system. Even worse news is I caught the last problem only by accident. That problem only showed up intermittently for N = 4 for a very specific PLplot configuration. N=2 and N=8 never showed any problems for that configuration for my two-processor hardware! So from that experience it is unlikely I caught all issues. To help to sort out such difficult dependency issues with CMake (which affect parallel builds on Unix system and I understand also certain kinds of builds on Windows), I have a feature request I would like to discuss here before I make a formal feature request on the kitware bug system. Could we have a cmake command-line option to evaluate/diagnose the complete list of file and target dependencies as understood by cmake? You could start with a print out of complete target dependency chains and file dependency chains as cmake understands them. As part of that printout it would be useful to highlight files or targets that are built with few dependencies since that might be a sign of missing dependencies. And also highlight chains of file depends that include files that are part of other chains of file depends. You could put in some error analysis as well (in case two targets which do not target-depend on each other file-depend on the same file, for example.) Anyhow, as I went through this dependency hell for PLplot I kept wishing for such a diagnostic tool, and I think it would be useful for others as well that are dealing with projects like PLplot with complex dependency chains spread over quite a few different directories. What do you think? Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affi
Re: [CMake] Parallel builds do not work correctly when using "cmake -E copy" to copy files
On 2008-02-06 21:05-0500 Bill Hoffman wrote: Could we have a cmake command-line option to evaluate/diagnose the complete list of file and target dependencies as understood by cmake? You could start with a print out of complete target dependency chains and file dependency chains as cmake understands them. As part of that printout it would be useful to highlight files or targets that are built with few dependencies since that might be a sign of missing dependencies. And also highlight chains of file depends that include files that are part of other chains of file depends. You could put in some error analysis as well (in case two targets which do not target-depend on each other file-depend on the same file, for example.) Anyhow, as I went through this dependency hell for PLplot I kept wishing for such a diagnostic tool, and I think it would be useful for others as well that are dealing with projects like PLplot with complex dependency chains spread over quite a few different directories. What do you think? You could try this: cmake --graphviz=[file] = Generate graphviz of dependencies. It will only show the target level stuff. It would be another project to get the file level depend stuff to show up. The problem is that is done at build time and not a cmake time. My first interpretation was "that" referred to graphviz, but in fact the file was produced at cmake time, and it was a simple matter to process it by hand using the "dot" command-line tool (even though I had never heard of that tool or graphviz before). "gv" has errors for both the ps and pdf results, but I think that is because the latest gv is extra careful about non-standard ps and pdf files. xpdf could understand the pdf output, but I have to say the result is black with dependency lines to a frightening extent. I can send the pdf file to Brad and/or you off-list if either of you is interested in being frightened by the PLplot dependencies as well. :-) Seriously, I am fairly impressed with the graphviz result, and adding in the file depends would add a lot of value to the result. If your "that" refers to file depends instead of graphviz, I don't understand your comment since surely file depend information is available at cmake time? 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] Parallel builds do not work correctly when using "cmake -E copy" to copy files
On 2008-02-06 21:04-0500 Brad King wrote: Alan W. Irwin wrote: On 2007-12-14 09:53-0800 Alan W. Irwin wrote: On 2007-12-14 10:32-0500 Brad King wrote: CMake employs a 2-level make recursion system that is independent of the directory structure. The first level never builds anything...it just evaluates target-level dependencies with phony targets. That determines the order in which targets must be built. The second level is the build.make for each target. This is where file-level dependencies are evaluated. In your example the file1...fileN rules are showing up in target1's build.make and target2's build.make but they should never be evaluated in the second target. They are pulled in through the additional_file rule's dependencies on them (see below), but they should always be up to date if target2 doesn't build until after target1 finishes. Then only the additional_file rule will be invoked. However if there is no dependency from target2->target1 then both build.make files may be built simultaneously and you get race conditions causing the double evaluations. CMake traces through the dependencies of custom commands in each target. When it is constructing target2 it doesn't know that target1 will also provide rules for the files. If you place the targets in different directories it would not be able to make this extra connection, but then the build would not work correctly unless you add the target-level dependency. Any further explanation here will just duplicate my previous message so I'll stop. That's fine. Your combined explanation now makes sense and completely confirms my working hypothesis that the make recursion system of CMake is responsible for the parallel build issues I was encountering. I hope I can work around these PLplot parallel build issues (note the double copy issue was only the most obvious one) by using extra target dependencies. The problem is that parallel build issues tend to appear and disappear depending on load, the N level (for -j N), and hardware. Thus, even if a whole flock of PLplot developers confirm success for parallel builds, there could be some subtle dependency issue left that we have missed, and some user down the road is going to come up with a combination of load, N, and hardware that triggers the parallel build problem because of that dependency issue. As a PLplot developer, I don't like being in such an uncertain position! I thought it important to resurrect this two-month old thread because today I _finally_ got success (at least no obvious issues, see comment below) with parallel builds of PLplot on my particular platform. That's the good news. The bad news is it took so much effort. Plplot is not that big a piece of software, but there are a large number of different components with complex dependencies between them. Therefore I had several tries in the two months to get parallel builds to work that failed miserably. This last successful effort of getting "make -J N" to work for many different N values took at least several days of isolating the problem by enabling/disabling various PLplot components until I was finally able to find and fix the last two dependency issues that showed up on my system. Even worse news is I caught the last problem only by accident. That problem only showed up intermittently for N = 4 for a very specific PLplot configuration. N=2 and N=8 never showed any problems for that configuration for my two-processor hardware! So from that experience it is unlikely I caught all issues. To help to sort out such difficult dependency issues with CMake (which affect parallel builds on Unix system and I understand also certain kinds of builds on Windows), I have a feature request I would like to discuss here before I make a formal feature request on the kitware bug system. I already made one for this: http://public.kitware.com/Bug/view.php?id=6285 That is great that you are considering automatically putting in target depends if two targets depend on the same file. That new feature would address the original issue that started this thread, and I am all in favour of this feature for that reason. However, during my dependency hell I discovered other issues with the PLplot depends such as missing dependencies between custom commands. Those missing dependencies didn't matter for the non-parallel build case because the order of the custom commands was deliberately chosen (back in our autotools days and simply copied to our CMake build system without much thought) so that the files were built in the correct order, but of course that doesn't happen for parallel builds. So some sort of output that emphasizes targets or files without many depends (which mean they are suspects for missing dependencies) is needed as well. Bill's idea of adding file depends to the graphviz output file would probably sat
Re: [CMake] Parallel builds do not work correctly when using "cmake -E copy" to copy files
On 2008-02-06 22:37-0500 Bill Hoffman wrote: Alan W. Irwin wrote: No file level depends are done mostly a build time. This is a performance issue. Some generators like VS IDE do file level depends by themselves. With the makefiles cmake computes the depends, but at build time not cmake time. The custom command stuff output input is known at cmake time, and maybe enough for what you want. Probably, since it is usually there where the build-system developer makes mistakes in the dependencies. But if you have a file foo.c with #include , cmake does not know that foo.c depends on foo.h until build time. Right, but hopefully those automatically generated depends would be ok. 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] Wee question about CMake developer etiquette
On 2008-02-10 11:27+0800 KHMan wrote: Hi all, I have a small question to pose to you guys (ladies and gentlemen alike) on etiquette: Is it normal for a CMake developer to jump into another mailing list and generally act in an obnoxious manner and act aggressively or provocatively? Based on my experience here, I completely doubt it. Normally this is a friendly list, and I find the small but dedicated band of CMake developers helpful to me and many others. There are a number of disagreements here (what healthy open-source software does not have a variety of opinions about it?), but they are usually solved amicably. I wonder if your list has run into one over-the-top CMake user rather than an actual CMake developer? 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] preprocessor def
On 2008-02-15 21:31- Harsha Sri-Narayana wrote: I have this code in a cpp file #ifdef USE_GLEW #include #endif I have this in a cmakelists.txt file: SET_TARGET_PROPERTIES(rtf PROPERTIES LINKER_LANGUAGE CXX COMPILE_FLAGS "USE_GLEW" ) This doesn't work, couldn't anyone show me what I've done wrong? In the documentation it says, "The COMPILE_FLAGS property sets additional compiler flags used to build sources within the target. It may also be used to pass additional preprocessor definitions." [1] I am allowed to change the cpp source code if that's the best solution, but I would rather a solution could be found from within the cmakelists.txt file. Try COMPILE_FLAGS "-DUSE_GLEW". Also, use make VERBOSE=1 to see the actual compilation flags that are being used in the build. 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] parallel builds for ctest
On 2008-02-15 18:44-0500 David Cole wrote: One of the VTK dashboards does it by giving a custom MAKECOMMAND to the initial cache:MAKECOMMAND:STRING=/usr/bin/make -i -j 2 See here for the full script: http://www.vtk.org/Testing/Sites/hythloth.kitware/Linux-gcc41/20080215-0300-Nightly/Notes.html David, I may be leaping to conclusions here, but it appears from what you have said that it is a reasonable hypothesis that the ctest commmand works through the cmake generator backend. When that is "make" (the default for Unix systems), then it further appears you can use a parallel version of make. That would be a wonderful feature to have for ctest. However, assuming the above suppositions are all true, I don't particularly like the somewhat clumsy hardwired mechanism above which won't work very well for machines with more than two processors or for systems where you want to do your tests in parallel, but you might not want to do your build in parallel (since parallel builds are difficult to get right with cmake for projects with complicated dependencies). One way to do this smoothly is allow ctest to pass any arguments to the backend that the user desires. Also, didn't "make test" work for early versions of cmake-2.4.x? I find it is a no-op now. (I was thinking that "make -j N test" might be a slick way to get parallel tests.) 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] parallel builds for ctest
On 2008-02-16 12:38-0500 Bill Hoffman wrote: [...]parallel ctest is on the todo list for this year. Most likely it will be ctest -j N. We can not depend on the make system to do the parallel stuff, and ctest -j would be useful for all generators. That's excellent news! The execution of the PLplot tests actually take about the same time to run as (non-parallel) building of PLplot itself. Now we are doing our builds in parallel, convenient parallel testing will be most welcome as well, and I look forward to trying out that new ctest functionality once you are ready. 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] add_dependencies question
On 2008-02-19 11:38-0500 Nico Galoppo wrote:
Hi,
I'm trying to get a 'demo' program inside my project tree to link in
(and depend on) one of the built libraries from the same project tree.
I'm having trouble getting the build process for the demo app to
detect updates of the library. I've tried ADD_DEPENDENCIES() but to no
avail. This is what the tree looks like (partially)
fem/
-fem/
--src/
--include/
-fem_io/
--src/
--include
-demos/
--blendmaterials/
---src/
In toplevel fem/CMakeLists.txt
PROJECT(fem)
...
SET(CMAKE_DEBUG_POSTFIX "d")
SET(FEM_LIBS fem)
SET(FEM_LIBS_DEBUG femd)
In fem/fem/CMakeLists.txt
...
ADD_LIBRARY(fem ${FEM_LIBRARY_SOURCES} ${FEM_LIBRARY_HEADERS})
In fem/demos/blendmaterials/src/CMakeLists.txt:
...
ADD_EXECUTABLE(blendmaterials ${sources} ${headers})
ADD_DEPENDENCIES(blendmaterials fem fem_io)
TARGET_LINK_LIBRARIES(blendmaterials optimized ${FEM_LIBS} debug
${FEM_LIBS_DEBUG})
Your ADD_DEPENDENCIES is inconsistent for the debug case. I suggest you
just drop it. Also, try experimenting with a simpler example without
optimized or debug, e.g.,
TARGET_LINK_LIBRARIES(blendmaterials ${FEM_LIBS})
In my experience, that (without the ADD_DEPENDENCIES) should just work. If
you still have problems, then I would reduce it down to a really simple
"hello-world" complete CMake test case that others here can try. It's
amazing how often I have prepared one of those for the CMake list to
illustrate a point only to find that the really simple example worked, and
the problem in the more complicated code was something else entirely such as
a mispelled variable or scope problem. BTW, liberal use of MESSAGE is a good
way to debug such problems which are often tough to spot by eyeballing the
CMake code.
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] Pass variables to sub directory CMakeLists.txt
On 2008-02-21 08:25+0100 Vandenbroucke Sander wrote:
Hi,
I want to pass a variable to CMakeLists.txt's in sub directories:
Top directory CMakeLists.txt:
set( VAR1 "" )
add_subdirectory (subdir1)
add_subdirectory (subdir2)
Each subdir CMakeLists.txt:
...
set( VAR1 "${VAR1} extend_var1" )
...
I use VAR1 later on in the linker.
How can I make this work?
The reason why this does not work in the present form is you are attempting
to pass VAR1 up from subdir1 to top-level, before passing it down again to
subdir2 from the top-level. Passing variables down is fine, but passing
variables from subdirectories to their parent normally does not occur with
CMake.
From recent discussion on this list you should use the
GET_DIRECTORY_PROPERTY command to pass variable information to parent
directories. So instead of the above use the following (subject to some
uncertainty since I have no practical experience with this method).
Top directory CMakeLists.txt:
set( VAR1 "" )
add_subdirectory (subdir1)
get_directory_property(VAR1 DIRECTORY subdir1 VARIABLES VAR1)
add_subdirectory (subdir2)
get_directory_property(VAR1 DIRECTORY subdir2 VARIABLES VAR1)
...
Anyhow, you get the general idea subject to some uncertainty on my part of
what the exact syntax for GET_DIRECTORY_PROPERTY should be. Perhaps I am
just too sleepy at this time in the morning, but that particular
documentation seems to be a bit unclear to me. So if the above syntax
doesn't work (which you can confirm by using the MESSAGE command), then you
may have to adjust it a bit.
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] How to prevent relinking targets with shared libraries
On 2008-02-21 21:57+0100 blinkeye wrote: [...]At the moment I'm just creating plain .so libs, without any version number (so far I didn't happen to come across a shared library tutorial with cmake), maybe this is the problem? Does cmake support such a versioning and would that resolve the relinking? There is full support for shared libraries (at least on my Linux platform). Look at the documentation of SET_TARGET_PROPERTIES (especially where it mentions VERSION, SOVERSION, and RPATH.) HTH. 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] Enable warnings
On 2008-02-25 11:53+0100 BlinkEye wrote: On Mon, February 25, 2008 11:11, dizzy wrote: That looks fairly unportable (how do you make sure your compiler supports those flags? if it doesn't it won't compile at all which is not probably what you want since you are using cmake I supose you want it portable). I prefer first to detect supported compiler arguments with CheckCXXCompilerFlag() and if yes add it to the CFLAGS of targets using SET_TARGET_PROPERTIES(target PROPERTIES COMPILE_FLAGS ...) (and if one wants to share several flags among many targets, put the flags in some variables and expand the variables in the SET_TARGET_PROPERTIES commands). That's not very portable, true. But you understand the problem of the OP, do you? He's new to cmake and he was asking on how to set compiler specific flags. Even though your answers not wrong it doesn't help him at all. And no, cmake isn't used just because it's portable. However, portability is often an important issue so it's certainly legitimate to discuss it (especially when others besides the OP will be reviewing this thread). I agree with dizzy that coding a bunch of compiler flags into CMake scripts is a mistake for all projects that care about portability. A solution that has not been mentioned so far in this thread but which I far prefer to any other is to use the CC environment variable to set both the compiler and its options before cmake is invoked, e.g., export CC='gcc -O2' 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 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] Python installation files on linux
On 2008-02-27 19:32+0100 Cedric Pinson wrote: Hi, i am new to cmake and i would like to use it to make a python module, but i don't know how to get the version of python installed on the system, how to select where the files should be installed considering the version of python ... I come from autotools and i would like to switch, cmake is very useful to write rules/conditional compilation... but for installing files like python module it seems not easy. Maybe i missed something. Any clue to do what i want ? You can use EXECUTE_PROCESS and python distutils to obtain python attributes. See http://plplot.svn.sourceforge.net/viewvc/plplot/trunk/cmake/modules/python.cmake for an example of this approach for determining the installation directory. (Note, we don't bother to obtain the explicit python version, but it would certainly be possible to do that with this general approach.) You may also like to look in trunk/bindings/python and trunk/bindings/swig-support to see how we build a python interface to the PLplot core C library. Finally, trunk/examples/python also has lots of plotting examples done with our python interface to PLplot. 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] Brandon Van Every
On 2008-03-04 19:36-0300 Rodolfo Schulz de Lima wrote: Bill Hoffman escreveu: This is a difficult decision for me. I have never been forced into a situation like this. However, Brandon's posts to this list have been disruptive to the community and myself. I have therefore come to the conclusion that Brandon needs to be kicked off the list. Well... from a Marketing Standpoint (tm), his reputation will be screwed if someone googles for 'brandon van every cmake'. Although I must confess that I find his rather verbose and insistent style too tiring and boring for my taste, he sometimes raised some valid questions. IMHO, banning is for somebody that wants to create havoc explicitly, spamming, etc. His problem seems to be a lack of social skills (as Sebastian wrote). But he seemed in the last couple of messages that he would 'settle' down, therefore I vote for giving him another chance. I also get tired and bored by Brandon's posts. Furthermore, some of his completely off-topic comments and general negativity about any ideas other than his own, and his complete inability to give someone else the last word have offended me and others in the past. OTOH, Brandon has given practical help to quite a few CMake users so it is a difficult decision for Bill to make (as he said). The personal rule of thumb I have evolved recently is to delete (sight unseen) all of Brandon's posts on a given topic after the first one, and so far that works reasonably well for me. Anyhow, dispite all the irritations my opinion is Brandon's posts have not really been disruptive enough to warrant keeping him permanently off the list so I would also vote to give him another chance (if I had a vote and assuming Brandon expressed willingness to change his style if he regained the privilege to post to this list again). 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] make package_source and binary subdir of source
To summarize, Erk's current proposal is to implement
set_source_files_properties(file1 file2
PROPERTIES CPACK_PACKAGE_SOURCE true)
and
CPACK_SOURCE_ADD_FILES "list of regular_expressions"
for inclusion and
set_source_files_properties(file1 file2
PROPERTIES CPACK_PACKAGE_SOURCE false)
for exclusion to supplement the current
CPACK_SOURCE_IGNORE_FILES "list of regular_expressions"
for exclusion.
I think these ideas are good ones. In particular, I have a couple of
projects where I add generated documentation to the source tarball,
and it is pretty ugly to contaminate the source tree by copying the
generated documentation back to it so it can be included in the source
tarball. Thus, it would be great to use CPACK_SOURCE_ADD_FILES to add
some files that are generated in the build tree to the source package.
I think the following has been assumed by Erk, but I want to explicitly
state for the record that we should stick to the current result which is the
source package is made up of everything in the source tree by default. This
maintains backwards compatibility and also is a pretty good default since it
is often a good approximation to what is wanted in the source package.
Finally, the inclusion rules should override the exclusion rules if there
is a conflict between them. For example, this would allow those who want to
be completely explicit about what files are included to get rid of the
default by
set(CPACK_SOURCE_IGNORE_FILES "^${PROJECT_SOURCE_DIR}/")
but then add back whatever files they want to cherry pick from the source
tree using CPACK_SOURCE_ADD_FILES or PROPERTIES CPACK_PACKAGE_SOURCE.
Thoughts?
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
[CMake] make test
On 2008-03-13 21:18-0400 David Cole wrote: For it to work, there has to be an "ENABLE_TESTING()" in the top level CMakeLists.txt file. And at least one ADD_TEST somewhere in the tree... "make test" should be equivalent to running "ctest" in the top level binary directory. (Or any sub-directory for that matter.) Your reply and Rodolfo's subsequent success story inspired me to try and find out why "make test" has always given zero results for PLplot while ctest works fine. It turns out there is some sort of clash between "make test" and our subdirectory name called test. If I temporarily change our test subdirectory name to something different, "make test" works for PLplot for the first time. We have been using the test subdirectory name for years so my preference is not to change it, and I expect that is also a common subdirectory name for other projects. Is there some way CMake can be changed so there is no such clash with such an obvious project subdirectory name? I suspect that CMake has simply forgotten to make the generated Makefile "test" target PHONY (which gets rid of name clashes between Makefile targets and files). Another concern with the current "make test" is it does not depend on the default "all" target. That is a bad oversight IMO, since the current situation is you will be running out-of-date tests after some code fixup unless you remember to run "make" before "make test". 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
[CMake] Obtaining improved GNU make performance on Makefiles generated by cmake
The GNU make documentation states the following: Since it knows that phony targets do not name actual files that could be remade from other files, make skips the implicit rule search for phony targets This is why declaring a target phony is good for [make] performance Also, Using .PHONY' is more explicit and more efficient. However, other versions of make' do not support .PHONY'; thus FORCE (an arbitrarily named rule with no prerequisites or rules) appears in many makefiles. As part of another investigation I searched a Linux build tree created by cmake (2.4.8) and was surprised to find no reference to .PHONY. Instead, the makefile generator on Linux is using the same method as FORCE idea above, i.e., a rule called cmake_force with no prerequisites or commands to serve as a prerequisite to rules that must be run every time. CMake is missing a bet on Linux systems to reduce Makefile overhead since it is using this cmake_force approach rather than the preferred more efficient.PHONY approach for rules that must be run every time. Since the Makefiles generated by cmake have an extremely large number of such rules, Makefile latency may be significantly reduced by this method on Linux (GNU make) systems. If the cmake developers here like this idea (or at least don't strongly dislike it), I will go ahead and make a feature request so it doesn't get lost. 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] Obtaining improved GNU make performance on Makefiles generated by cmake
On 2008-03-17 21:22-0400 Bill Hoffman wrote: Alan W. Irwin wrote: The GNU make documentation states the following: Since it knows that phony targets do not name actual files that could be remade from other files, make skips the implicit rule search for phony targets This is why declaring a target phony is good for [make] performance Also, Using .PHONY' is more explicit and more efficient. However, other versions of make' do not support .PHONY'; thus FORCE (an arbitrarily named rule with no prerequisites or rules) appears in many makefiles. As part of another investigation I searched a Linux build tree created by cmake (2.4.8) and was surprised to find no reference to .PHONY. Instead, the makefile generator on Linux is using the same method as FORCE idea above, i.e., a rule called cmake_force with no prerequisites or commands to serve as a prerequisite to rules that must be run every time. CMake is missing a bet on Linux systems to reduce Makefile overhead since it is using this cmake_force approach rather than the preferred more efficient.PHONY approach for rules that must be run every time. Since the Makefiles generated by cmake have an extremely large number of such rules, Makefile latency may be significantly reduced by this method on Linux (GNU make) systems. If the cmake developers here like this idea (or at least don't strongly dislike it), I will go ahead and make a feature request so it doesn't get lost. CMake is written to generic make, and I don't think we would want to add something that only worked with gmake. The trouble is the make you are using can change after CMake is run, so we can not even test for the version of make being used. I guess if it was a big enough performance gain, we could add some sort of option to allow for this. However, I would want to make sure that there would be a good payback. So far the cmake makefiles outperform the autotools ones quite well, and performance has not been an issue. Do you think you are having a performance problem? autotools runs the libtool shell script for _every_ compile or link to decide on build options. That script is huge (it weighs in at 200K or so). With built-in shell-script latency like that, any added latency from the autotools-generated Makefile is probably going to be completely undetectable. So to answer your last question in general, I am satisfied with CMake build performance when compared with autotools, but that's not really saying much because your comparing with the huge latancy of the libtool shell script. Of course, autotools has been the traditional standard of comparison, but it is probably time to move on from that and instead the goal should be to decrease the latency of builds that have been configured with CMake if it is straightforward to do so. To get a lot more specific about your question, the PLplot build has a latency (time to do a second make after the first one is completed with everything built on a 2.4GHz Linux box) of the following: time make >& /dev/null real0m1.338s user0m0.748s sys 0m0.700s (I also checked what was diverted to /dev/null in the above to limit output to confirm nothing was built by the above [second] make command). If I then touch the source code for our simplest example (a small C executable which links to our core library), here is the result I get [EMAIL PROTECTED]> time make >& /dev/null real0m1.413s user0m0.704s sys 0m0.796s (I also confirmed that the small C executable and only that PLplot software component was built after the touch command.) In this case, the build time without latency is 1.413-1.338 = 0.075 seconds. Another way to say this is the latency completely dominates using up 95 per cent of the total time. If the latency weren't there, you would get a factor of 20 improvement in speed. (This result presumes perfect repeatable timing which is not the case, but nevertheless it is clear the total build time for the PLplot build system is dominated by latency for this case of a simple executable with rather a small number of lines of code that links to our core library.) I then tried the experiment of touching one of our bigger C source code files that is built for our core library. It involves a file with many more lines of code then the simple example and also involves the relinking of the library and relinking of the many examples and other libraries that link to our core library. So this is a much more realistic test of a typical PLplot developer cycle. [EMAIL PROTECTED]> time make >& /dev/null real0m8.670s user0m6.080s sys 0m2.612s So in this case the build time without latency is 8.670-1.338 = 7.332 seconds. or another way to say this is the latency is roughly 20 per cent of the total time and if it were not there you would get a 20 per cent improvement in speed. I personally hate lat
Re: [CMake] CMake C++/ADA
On 2008-03-18 10:55+0100 Castan romain wrote: Hello! I must do a project for my university. This project is composed of three part, one in C, one in Ada and one C++(Qt for Ui) I would like to know how i have to write my "CMakelists.txt". If you have some example of "CMakeLists.txt", or ideas for solve my problem of language compatibility. I am working on getting Ada (actually gnat) language support into Ada. For a first pass at this see various files which you can browse at http://plplot.svn.sourceforge.net/viewvc/plplot/trunk/. The raw Ada language support is in the four files cmake/modules/CMake*Ada* (At the moment, I am working on a second generation of those to be part of CMake itself, and for now you should just put them into your local CMake modules file). For specific PLplot Ada needs we set up needed CMake variables in cmake/modules/*ada*, use the results to build a library of Ada bindings to our core C PLplot library in bindings/ada, and create some Ada examples that are linked to that Ada bindings library (and therefore indirectly to our core C library) in examples/ada. Hope this information is of some help to you, and don't hesitate to get back to me if you have any further questions about Ada support in 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 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] CMake C++/ADA
On 2008-03-18 09:46-0700 Alan W. Irwin wrote: I am working on getting Ada (actually gnat) language support into Ada. Ugh, I was half asleep. That should read I am working on getting Ada (actually gnat) language support into _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 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] Obtaining improved GNU make performance on Makefiles generated by cmake
On 2008-03-18 10:06-0400 Bill Hoffman wrote: I played around with make -d and -p and found that the .SUFFIXES rule that was supposed to be removing the implicit rules for gmake was not working for everything. SCCS and RCS were being checked for a bunch of stuff. Anyway, try this and see if it improves the issue you were seeing: $ cvs commit -m "ENH: try to improve make speed by getting rid of some implicit rules that were still around." cmLocalUnixMakefileGenerator3.cxx /cvsroot/CMake/CMake/Source/cmLocalUnixMakefileGenerator3.cxx,v <-- cmLocalUnixMakefileGenerator3.cxx new revision: 1.241; previous revision: 1.240 Hi Bill: It's going to take a while because I am running into problems configuring and building PLplot with the cvs version of CMake. Some if not all of this is our fault. For example, the cvs version of CMake has warned about non-unique target names which is an issue I definitely want to address. Also, the PLplot build fails, but I want to get rid of the cmake warnings before investigating that build issue any further. 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] Obtaining improved GNU make performance on Makefiles generated by cmake
On 2008-03-20 12:50-0400 Bill Hoffman wrote: Alan W. Irwin wrote: On 2008-03-18 10:06-0400 Bill Hoffman wrote: I played around with make -d and -p and found that the .SUFFIXES rule that was supposed to be removing the implicit rules for gmake was not working for everything. SCCS and RCS were being checked for a bunch of stuff. Anyway, try this and see if it improves the issue you were seeing: $ cvs commit -m "ENH: try to improve make speed by getting rid of some implicit rules that were still around." cmLocalUnixMakefileGenerator3.cxx /cvsroot/CMake/CMake/Source/cmLocalUnixMakefileGenerator3.cxx,v <-- cmLocalUnixMakefileGenerator3.cxx new revision: 1.241; previous revision: 1.240 Hi Bill: It's going to take a while because I am running into problems configuring and building PLplot with the cvs version of CMake. Some if not all of this is our fault. For example, the cvs version of CMake has warned about non-unique target names which is an issue I definitely want to address. Also, the PLplot build fails, but I want to get rid of the cmake warnings before investigating that build issue any further. Before you fix PLplot, I would be interested in knowing why it does not build with CVS CMake warnings and all. What OS/compiler are you having trouble with? Where/how can I download PLplot and try it myself. I have already fixed the non-unique target names since we definitely want unique ones. Also, instead of specifying the math library as "m" now (on non-Windows systems), I now search for it properly to get its full path name. The two remaining areas of concern are fortran 95 (where I suspect one of our horrible workarounds to make fortran 95 work on 2.4.8 is interfering with the proper fortran 95 support in Cmake cvs), and wxwidgets. Here is the full warning message about the wxwidgets problem: CMake Warning (dev) at bindings/wxwidgets/CMakeLists.txt:49 (add_library): Policy CMP0003 is not set: Libraries linked via full path no longer produce linker search paths. Run "cmake --help-policy CMP0003" for policy details. Use the cmake_policy command to set the policy and suppress this warning. The easiest way to avoid this warning is to set policy CMP0003 to NEW and try to build the project. If any libraries in the second list below cannot be found then either convert them to be specified with a full path or use the link_directories command to add the missing linker search path. Target "plplotwxwidgetsd" links to some items by full path not located in any linker search directory added by a link_directories command: /home/software/plplot_cvs/HEAD/build_cvs/bindings/c++/libplplotcxxd.so.9.3.0 /home/software/plplot_cvs/HEAD/build_cvs/src/libplplotd.so.9.5.0 /home/software/plplot_cvs/HEAD/build_cvs/lib/csa/libcsirocsa.so.0.0.1 /home/software/plplot_cvs/HEAD/build_cvs/lib/nn/libcsironn.so.0.0.1 This is okay but it also links to some items with no path known: -pthread, -lwx_gtk2u_xrc-2.6, -lwx_gtk2u_qa-2.6, -lwx_gtk2u_html-2.6 -lwx_gtk2u_adv-2.6, -lwx_gtk2u_core-2.6, -lwx_baseu_xml-2.6 -lwx_baseu_net-2.6, -lwx_baseu-2.6 This may be okay too because the linker will search for the libraries in the second list. However, finding them may depend on linker search paths earlier CMake versions added as an implementation detail for linking to the libraries in the first list. For compatibility CMake is including the extra linker search paths, but policy CMP0003 should be set by the project. This warning is for project developers. Use -Wno-dev to suppress it. Later I get build problems with anything wxwidgets related so clearly the above warning about using -l options rather than full pathname of the wxwidgtets libraries should be taken seriously. Apparently, there is something I can set with cmake_policy to get the old linking behaviour that accepts the above linker flags, but cmake_policy is not documented for 2.4.8. If this means it does not exist there, would you suggest I make its use dependent on whether CMAKE_CACHE_MINOR_VERSION is greater than 4 or not? BTW, CMAKE_BACKWARDS_COMPATIBILITY (the other variable I was thinking of using) is 2.4 for the cvs version. Is that correct or should that be 2.7? I should also emphasize that any detection of CMake version I would use now for the wxwidgets case would just be temporary because I want to switch to absolute library PATHS for that ASAP. (In fact, I thought I had already made such a switch so the warnings about that from CMake cvs are quite useful.) However, I may need such a test for CMake version for the fortran case since we really do need the horrible workaround I mentioned above for our fortran 95 interface to work properly for 2.4.8. You may not want to try PLplot until I have settled some of these issues, but in case you really do want to immediately try what I am working on, the svn trunk version of the code
[CMake] PLplot issues with the cvs version of CMake
Hi Bill: I changed the subject line to something more appropriate and will get back to the original subject of generated Makefile efficiency in due course. On 2008-03-20 16:46-0400 Bill Hoffman wrote: I guess we failed with the message "The easiest way to avoid this warning is to set policy CMP0003 to NEW and try to build the project. " No, that's fine, and I understood that message's implications about the lack of full library paths in the wxwidgets component of PLplot. IF(COMMAND CMAKE_POLICY) CMAKE_POLICY(SET CMP0003 NEW) ENDIF(COMMAND CMAKE_POLICY) Thanks for that method of setting policy for the cmake cvs version in such a way that it does not interfere with cmake-2.4.8 builds. However, I am only go to need that temporarily until I complete the switch to full library paths. I want those in any case for the 2.4.8 version of CMake since that allows setting rpath appropriately if the library is in a non-standard install location. What do you recommend for detecting CMake version (to remove an ugly Fortran workaround required for 2.4.x only if I am using the cvs version of CMake)? If your project still links with that change, then you are good. If it can not find a library, then you either need to full path that library or add a link_directories call to give the path for the library that can not be found. That said, I tried to build plplot and I got errors with wxWidgets that looked like there were missing -I stuff. So, the command line had stuff like -I-D_WXSOMETHING, so the -D was lost and it caused an error. I have not yet tracked down where the empty -I stuff is coming from in plplot. Thanks for pointing out that empty -I. I will track down why the cvs version of CMake does that (while 2.4.8 does not) and get back to you. In any case, it sounds like this PLplot/CMake cvs problem has nothing to do with the above issue with libraries specified without their full path name. 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] PLplot issues with the cvs version of CMake (wxwidgets)
On 2008-03-20 15:04-0700 Alan W. Irwin wrote:
Thanks for pointing out that empty -I. I will track down why the cvs
version of CMake does that (while 2.4.8 does not) and get back to you. In
any case, it sounds like this PLplot/CMake cvs problem has nothing to do
with the above issue with libraries specified without their full path name.
The difference is caused because FindwxWidgets delivers
wxWidgets_DEFINITIONS as a blank delimited string for 2.4.8 and as a list
for the cvs version. PLplot had the following problematic code which depended
on the blank delimitation:
string(REGEX REPLACE ";" " -I"
wxwidgets_COMPILE_FLAGS
"-I${wxWidgets_INCLUDE_DIRS} ${wxWidgets_DEFINITIONS}"
)
For 2.4.8 this simply appended wxWidgets_DEFINITIONS to the transformed
wxWidgets_INCLUDE_DIRS list since wxWidgets_DEFINITIONS was blank delimited.
For the cvs version, wxWidgets_DEFINITIONS (now a list) got transformed as
well.
The PLplot fix is the following code:
string(REGEX REPLACE ";" " -I"
wxwidgets_COMPILE_FLAGS
"-I${wxWidgets_INCLUDE_DIRS}"
)
# For case (cvs version of CMake as of 2008-03-23, but not cmake-2.4.8)
# when wxWidgets_DEFINITIONS is a list.
string(REGEX REPLACE ";" " "
wxwidgets_COMPILE_FLAGS
${wxwidgets_COMPILE_FLAGS}
" ${wxWidgets_DEFINITIONS}"
)
I would like to make some generalizations about modules and backwards
compatiblity that have been sparked by this issue.
In general, I applaud moving from blank-delimited results to lists as has
happened for wxWidgets_DEFINITIONS, but this issue was caused by a backwards
incompatibility in FindwxWidgets.cmake that caught PLplot (before the above
fix which works for both blank-delimited and list versions of
wxWidgets_DEFINITIONS) and which _might_ catch others. That said, my own
feeling is that rigid insistence on backwards compatibility for modules is a
strait-jacket for further module development _for the present release model_
(where the modules are released as part of the CMake release).
To get around this problem, I believe that modules should have their own
independent releases. That should allow PLplot, for example, to
conveniently move to the CVS version of CMake while still using the 2.4.8
modules (which should still work because rigid backwards compatibility is
built into the non-module part of CMake). By definition, if a project
always used the 2.4.8 modules, no backwards incompatiblities would be
introduced by the modules. OTOH, with this suggested change in how modules
are released, module maintainers can go ahead and improve things without
worrying about strict backwards compability, and if a project like PLplot
decides to move to later module versions we are free to do so if we are
willing to pay the price of adjustments to our code as above.
In sum, Bill, I hope you consider making separate module releases to
absolutely insure backwards module compatibility for those who stick with a
particular module release while being allowed to change cmake version. This
would also have the simultanous benefit of freeing the module developers to
get on with improving the modules without enforcing strict backwards
compatibility.
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] PLplot issues with the cvs version of CMake (wxwidgets)
On 2008-03-23 16:58-0400 Miguel A. Figueroa-Villanueva wrote: On Sun, Mar 23, 2008 at 3:46 PM, Alan W. Irwin wrote: The difference is caused because FindwxWidgets delivers wxWidgets_DEFINITIONS as a blank delimited string for 2.4.8 and as a list for the cvs version. Hello Alan, Sorry for the confusion. This change was made as a bug fix to resolve a problem reported to the list. Can't remember the error that was generated, but it was possibly to handle spaces in definitions (i.e., -DFOO="A space containing string") or some of the other variables. You can see the patch applied at: http://www.cmake.org/cgi-bin/viewcvs.cgi/Modules/FindwxWidgets.cmake?root=CMake&r1=1.7&r2=1.8 Yes, it appears to be a classic case of it being impossible to address one important issue without creating a backwards incompatibility. The problem is that it seems you are using (abusing?) the use of the interface variables. That is, you are not using ADD_DEFINITIONS and INCLUDE_DIRECTORIES, but building the compile flags directly? Yes. The problem with INCLUDE_DIRECTORIES (and ADD_DEFINITIONS?) is they apply to everything built in that directory. I far prefer to use explicit compile flags for each shared object I am building in that directory. [out of order for clarity] In sum, Bill, I hope you consider making separate module releases to absolutely insure backwards module compatibility for those who stick with a particular module release while being allowed to change cmake version. This would also have the simultanous benefit of freeing the module developers to get on with improving the modules without enforcing strict backwards compatibility. Although I understand what you are pointing out, I'm not sure that this is good in the sense that there is a maintainence overhead added. It would be some extra work to set this up for the first time, but if automated properly, I don't think there would be a lot of on-going work once this was set up. [...]That said, I do believe the find modules should have a process to deprecate variables and evolve... I'm just not sure if we want an independent release schedule. Just my $.02... I agree with the general goal of allowing the modules to evolve in a reasonable way (such as the change you made) so long as we provide some mechanism to assure backwards compatibility. My understanding of how Bill currently handles this issue is he is ultra-cautious about making any changes to modules _that are released_. In practice this may mean your greatly improved FindwxWidgets.cmake in cvs will not get into the next release because of the above demonstrated backwards incompatibility. That would be a real shame, and I would like to find some other method of freezing the modules such as providing easy access to previous module releases. I don't care about the details so long as something is done about this issue other than the current virtual freeze on module changes that are allowed to get into releases. 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] PLplot issues with the cvs version of CMake (Fortran 95)
Hi Bill:
The Fortran 95 issue turned out to be that the default location for Fortran
95 modules has been moved from the top-level ${CMAKE_BINARY_DIR} to the more
logical subdirectory (in our case ${CMAKE_BINARY_DIR}/bindings/f95) where
the associated fortran library was created in the build tree. For PLplot
this required an INCLUDE_DIRECTORIES change (to build Fortran 95 examples
using the generated module files) as well as a change in build-tree location
for the generated Fortran modules that we install.
Since these changes are CMake version dependent, I used the following
command to distinguish the 2.4.x version from later versions:
if(CMAKE_CACHE_MAJOR_VERSION EQUAL 2 AND CMAKE_CACHE_MINOR_VERSION EQUAL 4)
This method appears to work (I get good results now for both the 2.4.8 and
cvs versions of CMake), but if there is a better way to distinguish CMake
versions from within cmake, please let me know.
Although this build-tree location change for the generated fortran modules
is a backwards incompatibility, I recommend you just accept that
incompatibility for your next release. Fortran support in 2.4.8 basically
sucks so I believe any CMake Fortran user would be happy to adopt a new
version with Fortran properly supported for the small expense of adjusting
for the backwards incompatibility created by adopting a much more logical
location for the generated module files.
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] PLplot issues with the cvs version of CMake (Fortran 95)
On 2008-03-23 20:57-0400 Bill Hoffman wrote: if(CMAKE_CACHE_MAJOR_VERSION EQUAL 2 AND CMAKE_CACHE_MINOR_VERSION EQUAL 4) CMAKE_MAJOR_VERSION and CMAKE_MINOR_VERSION should be set: Thanks for that reminder. I have now made the change and those variables work fine (without confusing issues with possible cache inconsistencies). Although this build-tree location change for the generated fortran modules is a backwards incompatibility, I recommend you just accept that incompatibility for your next release. Fortran support in 2.4.8 basically sucks so I believe any CMake Fortran user would be happy to adopt a new version with Fortran properly supported for the small expense of adjusting for the backwards incompatibility created by adopting a much more logical location for the generated module files. Where did the modules go in 2.4.8? top-level build tree which is not a logical location and the subject of a wish-list bug report IIRC. That location should not be propagated. The cmake cvs location of the subdirectory in the build tree where the associated library is built is a much more logical location. 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] Obtaining improved GNU make performance on Makefiles generated by cmake
On 2008-03-18 10:06-0400 Bill Hoffman wrote: Bill Hoffman wrote: We used to have something that removed many implicit rules. I think that got lost in some version of CMake, it is hard to test... I did find that there is a command line option to gmake, -r that turns off implicit rules. I am seeing a speed up with gmake -r. Would it work to turn off all implicit rules instead of the .PHONY stuff? CMake does not use any implicit rules anyway. I think the only way to turn them off is to redefine them as empty rules. This works for all make, and not just gmake. I am trying to figure out what implicit rules need to be turned off and how to turn them off. Any ideas? I played around with make -d and -p and found that the .SUFFIXES rule that was supposed to be removing the implicit rules for gmake was not working for everything. SCCS and RCS were being checked for a bunch of stuff. Anyway, try this and see if it improves the issue you were seeing: $ cvs commit -m "ENH: try to improve make speed by getting rid of some implicit rules that were still around." cmLocalUnixMakefileGenerator3.cxx /cvsroot/CMake/CMake/Source/cmLocalUnixMakefileGenerator3.cxx,v <-- cmLocalUnixMakefileGenerator3.cxx new revision: 1.241; previous revision: 1.240 Hi Bill: Plplot now builds for the cvs version of CMake so I am finally in a position to continue this thread. Here is the 2.4.8 latency for the current version of PLplot [EMAIL PROTECTED]> time make >& /dev/null real0m1.454s user0m0.800s sys 0m0.724s By repeating this command, I get variations of typically 0.01 seconds in this result. (I also confirmed the command did not actually build anything new, i.e. it is a true measure of Makefile latency.) For cmake version 2.7-20080320 (that cvs update done after the above commit) the latency has been increased (by 60 per cent) to real0m2.319s user0m1.356s sys 0m1.068s Again, I confirmed it was a true measure of the Makefile latency. I also did some tests with the -r option for GNU make. For 2.4.8 the latency is reduced by a factor of 1.5 to [EMAIL PROTECTED]> time make -r >& /dev/null real0m0.970s user0m0.636s sys 0m0.568s That would indicate there is a lot to be gained by the .PHONY target for the non-file rules in generated GNU Makefiles. For the cvs version of CMake the latency is reduced hardly at all by the -r option [EMAIL PROTECTED]> time make -r >& /dev/null real0m2.287s user0m1.324s sys 0m0.964s In sum, the current result for the cvs version of cmake seems to create builds with significantly increased latency compared to 2.4.8. The -r option greatly increases this disparity. I think this is an important enough result that further tests of "make" latency for other software projects are important to confirm these results. Question for Alex Nuendorf: Alex, I imagine the KDE latency is much larger than PLplot's since your build has _a lot_ more dependencies to check. Are the current KDE builds in good enough shape so that repeat make commands measure true Makefile latency rather than some issue with unneeded compilation, linking, or whatever? If so, I would be very interested in your latency results for cmake-2.4.8 versus the cvs version of 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 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] Obtaining improved GNU make performance on Makefiles generated by cmake
On 2008-03-24 10:27-0400 Bill Hoffman wrote: One more warning about adding your own -I flags... I think this will break the dependency scanner of CMake, and the depends will be wrong if you do not use include_directories. Our use case is we have a directory where our many different device drivers are built with wildly varying compilation flag (both -I and -D) requirements. So it seemed natural to use SET_SOURCE_FILES_PROPERTIES( ... PROPERTIES COMPILE_FLAGS ...) to handle each device driver separately rather than using ADD_DEFINITIONS and INCLUDE_DIRECTORIES. The method appears to work fine, but I haven't tested the case where some external library header has been changed to see if CMake responds properly. I will probably just stick with the present method until CMake adds the feature of per-target ADD_DEFINITIONS and INCLUDE_DIRECTORIES (assuming they do handle the external dependency case correctly). For PLplot headers scattered all over our build tree for our various libraries we do use INCLUDE_DIRECTORIES to find them so all the internal dependencies should be correct. 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] Obtaining improved GNU make performance on Makefiles generated by cmake
On 2008-03-24 10:33-0400 Bill Hoffman wrote: OK, I talked with Brad, and found out the difference from 2.4.8 and CVS. When make runs in a CMake project, the first thing it does is run cmake to check the depend information. It looks for missing header files, and other checks to see if CMake should re-run or not. In 2.4.8, CMake would do this globally for the whole project. These made a delay as CMake checked all the depends for the whole project. CMake now checks each targets header files separately. This means two things. First, if you are only building one target, then it should be much faster as all the headers for the entire project are not checked. Second, the initial delay for the project is much less, but over all time may increase some as the check is now done for each target and shared headers maybe double checked. That sounds like a good working hypothesis for the substantially increased latency of the cvs version, but you should probably confirm that analysis with some -d runs to make absolutely sure. If that hypothesis is confirmed, and if your judgement is most developers simply type "make" the majority of the time (which is what I tend to do) without bothering with individual targets, then you may want to reconsider that change because of the substantially increased latency penalty associated with it. That said, I have checked in a change to get PHONY targets into CMake, as it should not break other makes. This should help some, and it should fix the make test problem when you had a directory called test. "make test" sparked this investigation, but I have long since solved that issue by renaming our test subdirectory as plplot_test since we are a cross-platform product where some of our Unix users do not have access to GNU make. So the emphasis for most of this thread has simply focussed on the important issue of reducing the latency for GNU make users, and I really appreciate your attempts to address that issue. Unfortunately, the results for your newly implemented .PHONY support for GNU make are disappointing for some unknown reason. Just to review, the PLplot make latency for cmake 2.4.8 is [EMAIL PROTECTED]> time make >& /dev/null real0m1.454s user0m0.800s sys 0m0.724s and for cmake version 2.7-20080320 is is real0m2.319s user0m1.356s sys 0m1.068s with timing errors of +/- 0.01 s or so for each measurement. For cmake version 2.7-20080324 (which includes your .PHONY changes as I checked with actual results in the build-tree Makefiles) that latency has been increased by a small amount that appears to be above the timing errors. [EMAIL PROTECTED]> time make >& /dev/null real0m2.375s user0m1.444s sys 0m1.028s I notice cmake_force is still in the generated Makefiles for cmake 2.7-20080324. It's count is reduced compared to the number of .PHONY instances. [EMAIL PROTECTED]> find -type f |xargs grep cmake_force |wc -l 824 [EMAIL PROTECTED]> find -type f |xargs grep .PHONY |wc -l 5849 Both the above commands were executed from the top of the build tree. You should be able to eliminate cmake_force altogether for GNU make since .PHONY duplicates its function. My guess from the count above is that will make a noticable difference. I think it requires a CMake and make guru to find out what is really going on using a through investigation comparing cmake 2.4.8 with cmake 2.7-20080320 and cmake 2.7-20080324 with the make -d option. I am not that guru (all I know is that make -d outputs an enormous number of results which are hard for me to understand), but if one of the CMake developers wants to investigate further, PLplot should be a reasonably accessible test bed for such investigations. Note with PLplot there are a large number of options to simplify the build. For example, you easily can eliminate all the non-C language interfaces and/or the devices to simplify comparisons. You should probably check other projects as well including a simple "hello-world" project if timing errors don't completely swamp the results in that case. 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] Obtaining improved GNU make performance on Makefiles generated by cmake
Hi Bill: I just now tested (with the build on one of the PLplot C examples) the assertion that specific targets will have less latency with the new approach. Here are the results. [EMAIL PROTECTED]> make x10c [ 0%] Built target plhershey-unicode-gen [ 0%] Built target plhershey-unicode.h_built [ 0%] Built target csirocsa [ 16%] Built target csironn [100%] Built target plplotd [100%] Built target x10c As you can see from this, the number of dependencies is fairly small. Furthermore, the VERBOSE=1 results indicate there are no actual commands being run by the above so this is a measure of true latency. Here are the corresponding latency results: 2.4.8: [EMAIL PROTECTED]> time make x10c >& /dev/null real0m0.217s user0m0.160s sys 0m0.068s 2.7-20080324: [EMAIL PROTECTED]> time make x10c >& /dev/null real0m0.209s user0m0.168s sys 0m0.036s Repeat runs indicate for this special case with a small number of dependencies, the timing errors are typically +/- 0.002 s. The conclusion therefore is the cvs version wins on latency for a specific target by a marginal amount that is just above the timing noise. On 2008-03-24 15:28-0400 Bill Hoffman wrote: OK, so for a small project like PLplot, where it does a make in 1 to 2 seconds if nothing needs to be done, this stuff really does does not matter that much. As for the new way cmake does the depend stuff, I think the new approach is much better for larger projects like KDE/ParaView. Large projects have the most serious potential latency problems (could be minutes rather than seconds if the number of dependencies is very high) so I agree they should be the ones driving latency improvements rather than PLplot. The only advantage of using PLplot for such tests is the initial build can be done in less than a minute so doing differential comparisons between various CMake versions is easy to do. In any case, it's fundamentally important not to guess about latency because reducing latency is generally a hard problem. Thus, before the next release I hope somebody steps forward with actual latency numbers for specific targets and the "all" target for large projects like KDE/ParaView. But it currently doesn't look good since the indications from the PLplot tests (which so far is the only hard data that has been reported) is the latency for "make all" will be substantially worse while the latency for specific targets with a lot fewer dependencies then "all" are only marginally better for the cvs version compared to 2.4.8. The principal conclusion I want to emphasize is the PLplot latency results are just an indication of what to expect in general, and what we need is hard latency numbers for big projects like KDE, ParaView, etc., (where latency issues should be more severe than in the PLplot case). That's the only way we can move forward with any further attempts to substantially improve latency. I have previously asked Alex to do the KDE case. Bill, would you be willing to measure latency for ParaView for cmake 2.4.8 and the present cvs version of 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 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] Obtaining improved GNU make performance on Makefiles generated by cmake
On 2008-03-25 14:28-0400 Bill Hoffman wrote: --- build all of paraview with nothing needing a build: 2.6 make 15.21s user 5.55s system 74% cpu 28.049 total make 15.44s user 5.35s system 98% cpu 21.073 total user+system = 20.76s and 20.79s for the two runs. 2.4 make 14.40s user 5.09s system 59% cpu 32.793 total make 14.73s user 4.74s system 98% cpu 19.684 total user+system = 19.49s and 19.47s for the two runs --- build a target that only depends on only one other target. 2.6 make vtkCommon 0.43s user 0.08s system 99% cpu 0.513 total make vtkCommon 0.44s user 0.08s system 99% cpu 0.522 total make vtkCommon 0.41s user 0.10s system 99% cpu 0.515 total user+system = 0.51s, 0.52s, and 0.51s for the three runs. 2.4 make vtkCommon 3.32s user 5.70s system 99% cpu 9.025 total make vtkCommon 3.24s user 5.81s system 99% cpu 9.059 total user+system = 9.02s and 9.05s for the two runs --- Build a target that depends on 60 other targets 2.6 make vtkPVServerManager 9.70s user 3.04s system 99% cpu 12.754 total make vtkPVServerManager 9.64s user 2.91s system 99% cpu 12.569 total user+system = 12.74s and 12.55s for the two runs. 2.4 make vtkPVServerManager 11.40s user 6.38s system 99% cpu 17.955 total make vtkPVServerManager 11.19s user 6.58s system 99% cpu 17.774 total user+system = 17.78s and 17.77s for the two runs. In summary, I would say 2.6 or CVS is better. We only loose less than a second out of 15 on the total, and we gain 2 or 3 on single targets. I agree with your general conclusion, but the specifics need amendment (which actually strengthens your case). The sum of user+system times is the most relevant number since that will be the actual time the user will have to wait if the system is otherwise idle. Thus, I have calculated that number above (which also shows the good consistency of your repeated measurements). From those numbers it appears a 1-depend target latency is better by ~8.5s, a 60-depend target latency is better by ~5.0s, and a full build latency is worse by ~1.2s consistent with the idea that the updated Makefile generator produces more efficient results for targets with few dependencies, but as the number of dependencies is increased, more duplicate work is done by the new method until for full builds the results are actually worse than the old (2.4.8) version. This qualitative summary also holds for the PLplot results although the upsides of the new method are marginal with an obvious downside for the full build. Despite these discrepancies in quantitative results paraview's needs should prevail since that project has substantially larger latency than PLplot. Thanks, Bill, for running these paraview latency tests. My view is they should decide the matter unless KDE or some other project with similar or larger latency to paraview disagrees with the paraview results you obtained. 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] [CMake/CPack] empty debian package
On 2008-03-28 00:51+0100 Alexander Neundorf wrote: If you use install() with an absolute path DESTDIR is still honored on "make install". But I just tried and while it works with "make install", it doesn't when creating the packages, not only for deb, but lso for the other formats. This may be worth a feature request (or a patch :-). This actually sounds more like a cpack bug with absolute paths. Yes, that was reported by me as bug http://public.kitware.com/Bug/view.php?id=4993 in May last year. There is actually a simple patch to get absolute paths to work for CPack (see above bug report), but no action has been taken on that yet. 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] make test
On 2008-03-14 13:04-0700 Alan W. Irwin wrote: Another concern with the current "make test" is it does not depend on the default "all" target. That is a bad oversight IMO, since the current situation is you will be running out-of-date tests after some code fixup unless you remember to run "make" before "make test". I just was reminded I reported this as bug http://public.kitware.com/Bug/view.php?id=4615 in March last year. No action yet. 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] handing dependencies in multi-file CMake setup?
On 2008-03-28 15:27+0100 �~Akos Maróy wrote: I'm wondering how is it possible to have CMake handle dependencies in a setup where multiple CMakeFiles.txt files are used, and there's a top-level CMake file including them with add_subdirectory() I tried to use the add_dependencies() statement, but that only 'sees' targets that are defined in that very CMakeFiles.txt file. So it can't be used either in one of the project CMakeFiles, nor in the top-level CMakeFiles. Actually, ADD_DEPENDENCIES does see targets _that have been defined in prior cmake processing_. Thus, if you process your directories in the appropriate order with ADD_SUBDIRECTORY so that targets have already been defined when you refer to them with ADD_DEPENDENCIES, it should just work. 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] New FindMPI module has some backward-compatibility problems
On 2008-03-28 15:50-0400 Bill Hoffman wrote: Doug Gregor wrote: I've been notified of some backward-compatibility issues in the FindMPI module, and have some other tweaks on hand to make it work better for more installations. I plan to finalize these changes this weekend. However, am I too late to fix this for the CMake 2.6.0 release? No, I am aware of the changes and am waiting for them. :) As a side note to module maintainers, this release has shown something. To maintain backwards compatibility for a module, you can never change a cache variable into a non-cache variable. If you had: FOO_LIBRARY CACHE and, you changed to FOO_LIBRARIES # new variable name set(FOO_LIBRARY somevar) # try to maintain the old name The problem is automated builds that pre-load the cache or use command line -D stuff will get clobbered by the set. For example: cmake -DFOO_LIBRARY=/my/path/to/lib.a The set(FOO_LIBRARY somevar) kills this cache value, and the build breaks. This is the reason that the current RC-5 did not have ccmake in it. Could you get around this issue by maintaining backwards compatibility another way? I am thinking of IF(NOT FOO_LIBRARY) set(FOO_LIBRARY somevar) ENDIF(NOT FOO_LIBRARY) Or is there a better away of getting around this cached variable issue? 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] make test
On 2008-03-28 20:59+0100 Alexander Neundorf wrote: On Friday 28 March 2008, Alan W. Irwin wrote: On 2008-03-14 13:04-0700 Alan W. Irwin wrote: Another concern with the current "make test" is it does not depend on the default "all" target. That is a bad oversight IMO, since the current situation is you will be running out-of-date tests after some code fixup unless you remember to run "make" before "make test". I just was reminded I reported this as bug http://public.kitware.com/Bug/view.php?id=4615 in March last year. No action yet. Actually I would recommend to run ctest directly, you can do much more with it. Sure, I agree ctest has some additional options that are useful in certain circumstances, but that is a side issue since "make test" does run ctest in a way (runs all tests) that is useful for many users. Thus, the assumption of the bug report is "make test" is here to stay and it is concerned with having the correct dependencies for "make test". Of course, if you want to remove "make test" altogether, that is a different story. Then it's also more obvious that it doesn't depend on all I am probably missing something because I don't understand this comment. All of the PLplot tests depend on libraries and test examples being built in the build tree, and I would think that would be true of most other projects. Thus, if you have failed to run "make all" before running ctest by hand you will get an error (if you are starting with a clean build tree) or potentially out-of-date tests (which is more serious since the effect is more subtle) if you are working with an existing build. In fact, if the CMake developers agree to implement "test" depending on "all", this would be a motivation for using "make test" rather than running the ctest command by hand. Alex, is your concern that "all" is too comprehensive a dependency? In that case, you could change ADD_TEST to allow setting specific dependencies that would be honored by "make test", but that might be overkill. 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] make test
On 2008-03-28 22:31+0100 Alexander Neundorf wrote: I think simply having test depend on all may be a bit slow. I agree that is a concern for bigger projects like paraview with half-minute "make all" latency (as recently demonstrated by Bill) so it appears our goal should be to have a DEPENDS option for ADD_TEST to allow users to add dependencies for specific targets/files. I have put a note to that effect at http://public.kitware.com/Bug/view.php?id=4615. I also would like if the targets would be current on "make test". Last summer I discussed with Brad about that and it isn't as easy as it may seem. (e.g. it would also be nice if targets which are OPTIONAL would be automatically built if the test which uses them is executed). I hope this complication does not delay the implementation of a DEPENDS option for ADD_TEST too much. 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] (no subject)
On 2008-03-31 11:36+0200 [EMAIL PROTECTED] wrote:
Hello cmake users.
I choose cmake to build a big project. This project contains Fortran 77 (the
most numerous), C, and C++ source files, and only one executable built from all
source files.
It works well with gnu g77 compiler. But with Absoft compiler, the option -fPIC
is used at linking without i ask it. So I get an error : ERROR: Unrecognized
arguments: -fPIC I do not find this option in Absoft compiler documentation. I
would like to remove -fPIC in linking option but i do not know how.
Any idea ? Thanks in advance for any answer.
best regards Christophe
Try
SET(CMAKE_SHARED_LIBRARY_Fortran_FLAGS "")
I am not sure that will work, but I notice that variable is set to "-fPIC"
quite a few places in /Modules/Platform where CMake stores customizations
for particular compilers/linkers.
The problem with setting the CMAKE_SHARED_LIBRARY_Fortran_FLAGS variable is
it only works if you always use the absoft compiler. A much better approach
would be to have a quick look at the *Fortran* files in /Modules to see
how Fortran compiler/linker customization is set up then follow those rules
to set up your own absoft-specific customization file.
PLplot does this as follows:
# Location where PLplot cmake build system first looks for cmake modules.
set(CMAKE_MODULE_PATH ${PROJECT_SOURCE_DIR}/cmake/modules)
We then put our two specific compiler customizations in
cmake/modules/Platform/. These are customization files for windows
compilers and nothing to do with absoft, but you could similarly make your
absoft CMake customizations in your own software project this way.
Once you are satisfied with your absoft customization, then I would urge you
to donate your file to CMake so others will benefit as well. (IIRC, Arjen
Markus did this for his two PLplot windows compiler customization files for
PLplot a couple of years ago, but apparently the results were lost in the
CMake bug tracker so we will probably make the attempt to donate that work
again once we have verified it works for CMake cvs)
N.B. CMake 2.4.8 Fortran support really sucks (you will require a number of
ugly Fortran workarounds if you use 2.4.8) so I advise you strongly to use
the CMake cvs version (which I checked above for absoft customizations) or
else the recently released CMake 2.6.0 Beta.
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] FOSDEM Talk on CMake is available
On 2008-04-02 16:29+0200 Pau Garcia i Quiles wrote: Quoting Alberto Luaces <[EMAIL PROTECTED]>: Wow, many thanks for these slides! There is an updated version, which adds Alexanders's comments: http://www.elpauer.org/stuff/learning_cmake.pdf I had a quick read through that pdf, and, in general, I liked it. However, I do have some suggestions for improvement. (1) I thought the discussion of the important variables needed expanding a bit (more than just mentioning their names). (2) The cpack section needs expansion (especially since cpack is so poorly documented elsewhere). (3) I thought your comment "Try to avoid it, as it is not always installed" about pkg-config needs some rephrasing since pkg-config is the Linux gold standard for how Linux software packages publish compile and link flags for their project, and many Mac OS X software packages use it as well. Thus, pkg-config is absolutely required for projects like PLplot to discover those flags for external dependencies. As more and more Linux projects are ported to other platforms, pkg-config will become ever more important on those other platforms as well. The pkg-config developers have already anticipated this cross-platform need. It is available on Unix/Linux/Mac OS X and also windows. For the latter case it has a number of special options for dealing with windows idiosyncrasies such as the special form of windows paths. (There was a prior thread here on pkg-config for windows, and the windows-only developers at that time confirmed that the tool ran without obvious problems on windows, but they were completely unaware of those special options for the windows case [as I was at the time as well].) In sum, pkg-config is already widely used on the Linux/Mac OS X side of things and there doesn't seem to be any fundamental reason to discourage the use of pkg-config on windows even though most windows-only developers are currently completely unaware of how useful pkg-config can be. 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
[CMake] Mostly O.T. Need advice on Mac OS X compatibility version for libraries
We have generally adopted a zero initial major version (SOVERSION in CMake terms) for PLplot libraries, and that major version persists for many of our smaller libraries because there have been no API changes for those libraries since their inception. However, it has just come to my attention from a fink developer who very much disliked zero major version numbers and from reading http://www.finkproject.org/doc/porting/shared.php?phpLang=en that the major version number must be non-zero for Mac OS X libraries. Otherwise, it appears to be interpreted as "some kind of wildcard value". (Whatever that means.) Note, I don't have access to a Mac OS X platform to do any testing of what happens for a SOVERSION specified as zero, but I assume from the fink developer's response that CMake simply translates it to an invalid (according to the above URL) zero major version number for Mac OS X libraries which in turn causes some kind of linking issue for that platform. I don't really have any understanding of Mac OS X linking requirements so I would appreciate comments on this issue from those who do have such understanding. I realize this issue is mostly off-topic, but there are a lot of Mac OS X experts here who presumably know about this issue, and the issue is important for deciding what the minimum SOVERSION should be on cross-platform (Mac OS X) libraries that are built with CMake. For example, if this does turn out to be a serious issue for Mac OS X, should CMake give a warning if SOVERSION is ever less than 1? 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] FOSDEM Talk on CMake is available
On 2008-04-02 18:19-0700 E. Wing wrote: [Alan said] In sum, pkg-config is already widely used on the Linux/Mac OS X side of things and there doesn't seem to be any fundamental reason to discourage the use of pkg-config on windows even though most windows-only developers are currently completely unaware of how useful pkg-config can be. [Bill said] So, I had this discussion on the kde list. pkg-config is great if it is installed on the machine you are using. However, since it is not a default install on anything other than linux machines, you really don't want to depend on it. [answering Bill] I think you missed my point (which may be my fault). Many Linux libraries export the information you need to compile and link against those libraries using pkg-config. So if your software depends on those libraries (which is the case for a number of different PLplot components), you _must_ use pkg-config to build against those external libraries. Fortunately, pkg-config is easy to install for any platform, and that small extra dependency is negligible compared to all the many other library dependencies PLplot has which require pkg-config to make their compile/link information accessible. When pkg-config is not available for a platform, the PLplot build system obviously give a big warning about the components that will be missing from the PLplot build. So those PLplot users who refuse to install pkg-config must take the consequences (an extremely basic PLplot with few bells and whistles). My impression is Mac OS X users heed the warning while windows users don't worry about it because they are generally reluctant (I guess because of DLL hell) to use any external library, much less pkg-config to find out how to compile and link against such an external library. However, we do have at least one windows developer who is keen enough on the PLplot bells and whistles to install the required libraries and pkg-config, and he reports (on a MinGW platform) there are no issues with those bells and whistles. Thus, we may already have some ordinary PLplot users on the windows platforms using those bells and whistles as well. [Eric said]Actually, I would go further and argue that pkg-config is fundamentally flawed. It totally breaks with respect to cross-compiling. As you may be aware pkg-config compile/link information for a given library for any particular platform/version is stored in a tiny ascii *.pc file. I have no practical experience with cross-compiling so your negative comment about pkg-config in this regard might be correct, but I am not convinced by your bare assertion. The reason I think this way is the *.pc files are normally stored with each library for each different platform. Thus, it should be straightforward to access the *.pc files associated with each alternate platform library you are linking against to get the correct compile and link flags for that library/platform combination. [Eric said]It doesn't work that well either when you have multiple versions of of a library installed either, either because you are testing different compiled variations or perhaps legacy versions. On the contrary, I know that multiple library versions for the same platform are easily handled by pkg-config since each library version has a corresponding pkg-config *.pc file which you can easily access by playing with the PKG_CONFIG_PATH environment variable. I change that environment variable often to access experimental versions of libraries that PLplot depends upon with no issues at all for our CMake-based build system (since FindPkgConfig.cmake runs pkg-config at CMake time, and that executable honors PKG_CONFIG_PATH). 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] Mostly O.T. Need advice on Mac OS X compatibility version for libraries
On 2008-04-02 20:08-0700 E. Wing wrote:
This seems familiar. I remember a long discussion on this somewhere.
It must have been offlist. I forgot the outcome. Were we going to
introduce a different versioning variable separate from SOVERSION?
You may be referring to VERSION. To give a specific example, we use
set(csirocsa_SOVERSION 0)
set(csirocsa_VERSION ${csirocsa_SOVERSION}.0.1)
and
SET_TARGET_PROPERTIES(csirocsa PROPERTIES SOVERSION ${csirocsa_SOVERSION}
VERSION ${csirocsa_VERSION}) for one of our libraries which our core library
depends upon.
So we set the major portion of the VERSION triplet be consistent with
SOVERSION. That works fine on Linux, but
I am not really sure whether it is SOVERSION or VERSION (or
both) that affects the resulting compatibility version on Mac OS X.
Can somebody at least comment on the relationship between VERSION and/or
SOVERSION from CMake and the resulting compatibility version on Mac OS X? Of
course, if that person has more to say about why the major portion of that
compatibility version should not be zero on that platform, that would be
great as well.
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] FOSDEM Talk on CMake is available
On 2008-04-03 21:06+0200 Alexander Neundorf wrote: If you run pkg-config of the build host it will find the pkg-config files of the libs for the build host. For the record, you have complete control of what set of *.pc files the build-host pkg-config executable finds using the PKG_CONFIG_PATH environment variable. 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] Mostly O.T. Need advice on Mac OS X co mpatibility version for libraries
On 2008-04-03 21:11+0200 Alexander Neundorf wrote: Here's a feature request for the versioning stuff on OSX: http://public.kitware.com/Bug/view.php?id=4383 Hi Alex: Thanks very much for that important reference on this issue. The rest of my comments are directed to Brad who has made a considerable number of notes at the above URL. I encourage you to push ahead with an implementation of your ideas so that 2.6.0 will have a good cross-platform library versioning scheme. (To get around the problem for 2.4.8, it appears both PLplot and libLASi are going to have to use a Mac-only workaround which I would prefer to avoid by moving to 2.6.0 if it has a good cross-platform library versioning scheme.) Currently, it appears you are considering the idea of adopting the libtool cross-platform library versioning scheme. I like that idea since a very large fraction of CMake users who are concerned with library versioning (i.e., the Unix users) are familiar with what libtools does in this regard. The rules are carefully laid out (from the perspective of those putting together a build system for their package) at http://www.gnu.org/software/libtool/manual.html#Updating-version-info. Those rules don't seem natural from a pure Linux perspective (I think this is the basis of Alex's objection), but I believe you when you say nothing simpler could handle the full cross-platform case. In any case, it is easy enough to follow those rules. I did that for years when PLplot and some of my other projects were configured and built with autotools and wouldn't mind going back to using those same rules for 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 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] FOSDEM Talk on CMake is available
On 2008-04-03 23:13+0200 Alexander Neundorf wrote: On Thursday 03 April 2008, you wrote: On 2008-04-03 21:06+0200 Alexander Neundorf wrote: If you run pkg-config of the build host it will find the pkg-config files of the libs for the build host. For the record, you have complete control of what set of *.pc files the build-host pkg-config executable finds using the PKG_CONFIG_PATH environment variable. So when running pkg-config for the target I should set the env. variable before that to /home/alex/target/usr/lib/pkgconfig/ ? Yes. Will it then skip /usr/lib/pkgconfig/ ? No. However, I notice another environment variable documented in the pkg-config man page called PKG_CONFIG_LIBDIR which "Replaces the default pkg-config search directory." I haven't tried that (since for my needs I want pkg-config to fall back to /usr/lib/pkgconfig/ if it cannot find what it needs in PKG_CONFIG_PATH), but it sounds like PKG_CONFIG_LIBDIR (or that variable in combination with PKG_CONFIG_PATH) might give you the absolutely clean result that you want. 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] FindBoost.cmake updated on the bugtracker
On 2008-04-12 10:07+0200 Andreas Pakulat wrote: My experience with MinGW so far is that its simply not ready yet for projects such as boost or KDE, they still need some time. Thats why I won't do work on getting KDevelop4 working on MinGW - at least not without someone paying for it. That's fine, but then somebody else with access to windows should volunteer to do that testing since MinGW is an extremely important platform. I don't have access to windows myself, but I have been fascinated over the years at just how popular MinGW has been at SourceForge. Usually, that software is in the top 25 projects there (rated in terms of an activity index made up of a number of factors including downloads). For example, from http://sourceforge.net/project/stats/detail.php?group_id=2435&ugn=mingw&type=prdownload&mode=12months&year=2008&package_id=0 they have from 300 to 600 thousand (!) downloads per month over the last year. Finally, from our PLplot experience, MinGW (fortunately we do have a couple of developers with access to that platform) works fine if you make some special adjustments for its needs. So Andreas's above statement probably needs to be reversed, i.e., boost and KDE need some time/effort to work on MinGW. Such effort should be worth it since there is obviously _a lot_ of interest in the MinGW platform that would be a shame to ignore for any project. My $0.02. 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] FindBoost.cmake updated on the bugtracker
On 2008-04-13 11:04+0200 Andreas Pakulat wrote: [...]I'll be the first one to try out MinGW which comes with gcc 4.x [...] The MinGW team officially releases their packages at SourceForge. From http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=241304 there is a gcc 4.3.0 release with big warnings in the associated release notes about its alpha quality. However, there are some "technology preview" MinGW gcc-4.2.1 packages available at the same site which from the release notes appears to be much more mature than 4.3.0 but less mature than MinGW gcc-3.4.5. Anyhow, if anyone wants to experiment further with MinGW builds of software that absolutely requires gcc 4.x, then probably the official gcc 4.2.1 MinGW release is the one to try at this time. As far as I know, PLplot windows developers have not tried this version yet, but I assume it is on their agenda. 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] CMake 2.6.0 RC 8 ready for testing
On 2008-04-10 14:39-0400 Bill Hoffman wrote: I am happy to announce that CMake 2.6.0 RC8 is ready for testing. Works for me on my Debian testing platform (g++ (GCC) 4.2.3 (Debian 4.2.3-2)) My tests consisted of a bootstrap, build, and install of cmake starting from cmake-2.6.0-RC-8.tar.gz, and a PLplot build and ctest with that cmake version (2.6-patch 0 RC-8). 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
[CMake] FindX11.cmake needs some work for 2.6.0
On some platforms, X11_LIBRARIES derived by FindX11.cmake is going to be a
mixture of full pathnames for libraries and a series of -l flags which is
not a recommended form for CMake 2.6.x. To see this, look at the
FindX11.cmake logic for CMake-2.6.0-RC-8.
The preliminary version of X11_LIBRARIES is fullpath only since that is
derived using FIND_LIBRARY, but then more libraries are added to this list
as follows:
SET(X11_LIBRARIES ${X11_X_PRE_LIBS} ${X11_LIBRARIES} ${X11_X_EXTRA_LIBS})
X11_X_PRE_LIBS is also fullpath since it is the result of FIND_LIBRARY, but
X11_X_EXTRA_LIBS (empty on my Debian testing system) potentially has lots of
-l flags such as -lnsl_s -linet -ldnet, etc. if you follow the
X11_X_EXTRA_LIBS logic in FindX11.cmake.
Could somebody please change FindX11.cmake so that X11_X_EXTRA_LIBS is
always determined with FIND_LIBRARY? This would make it and X11_LIBRARIES
consistently fullpath on all platforms.
I think these -l forms of libraries just slipped through as some ancient
(autoconf?) boilerplate for X11_X_EXTRA_LIBS that has propagated to all
FindX11.cmake versions in contradiction to the recommendation that libraries
are supposed to be in fullpath form for 2.6.x.
Furthermore, making X11_LIBRARIES fullpath would benefit the PLplot build
(and presumably other builds as well). When first setting up the CMake-based
build system for PLplot, I either copied from our previous autotools-based
build system or I may have noticed the potential for -l flags in
X11_LIBRARIES. But in any case, I prepended X11_LIBRARIES with
"-L${X11_LIBRARY_DIR}" so that our users could have a non-standard install
location for X (especially important for this era of frantic X development
activity where some X testers may have multiple versions of X installed on
their platform). However, this -L flag leads to CMP0003 warnings for the
2.6.0 release candidate since fullpath libraries are preferred for 2.6.x.
(Also, X11_LIBRARY_DIR is an undocumented variable for FindX11.cmake which
I would prefer not to depend upon in the long term.)
Of course, there are workaround for CMP0003 warnings, but the clean solution
would be if a CMake developer would simply change FindX11.cmake in cmake cvs
and also for 2.6.0 so that X11_X_EXTRA_LIBS and therefore X11_LIBRARIES are
always consistently fullpath. That would allow me to stop prepending
"-L${X11_LIBRARY_DIR}" to X11_LIBRARIES which would eliminate the CMP0003
warnings without compromising the need of some who require a non-standard
install location for X.
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] FindX11.cmake needs some work for 2.6.0
On 2008-04-14 21:55-0400 Bill Hoffman wrote:
Alan W. Irwin wrote:
On some platforms, X11_LIBRARIES derived by FindX11.cmake is going to be a
mixture of full pathnames for libraries and a series of -l flags which is
not a recommended form for CMake 2.6.x. To see this, look at the
FindX11.cmake logic for CMake-2.6.0-RC-8.
OK, -l flags are fine with cmake 2.6.x, let me say that again, -l is OK with
2.6. It MAY cause a link error. If you set CMP0003 to NEW, it you can find
out. If CMP0003 is set to NEW and you stuff links, that is not a hack, that
is the right way to do it.
X11_LIBRARIES is used for a variety of linking tasks for PLplot (some for
PLplot libraries, some for PLplot device driver plugins) with more being
added from time to time (such as our cairo device driver that was added a
year ago). Also, the current problem is a corner case that doesn't even
occur on our most tested platform (Linux) since X11_X_EXTRA_LIBS is empty
there. Thus, "MAY cause a link error" produces enough current platform
uncertainty and future overall uncertainty that I prefer to avoid -l flags
if at all possible in X11_LIBRARIES.
You should never use -L directly (in TARGET_LINK_LIBRARIES) .
link_directories should be used.
Our use case is we have a large number of libraries and plugins, but only
four of those (IIRC) use X11_LIBRARIES. I prefer to use -L directly in
TARGET_LINK_LIBRARIES rather than use the LINK_DIRECTORIES alternative since
the latter would would add an unnecessary (and possibly inefficient)
directory search for the link steps for most of our libraries/plugins. Of
course, this entire issue is moot if -l flags never appear in X11_LIBRARIES
for any platform because then I could drop the -L flag altogether.
warnings without compromising the need of some who require a non-standard
install location for X.
I guess I would suggest that you should experiment with a new version of
FindX11 in plplot. If you find it works well, we can look at it for
inclusion in 2.6.1.
I have too much on my plate, and I also don't know enough about X on the
various Unix platforms to really do a good job here. For example, I suspect
all the X11_X_EXTRA_LIBS (the source of the -l trouble) is simply copied
from some ancient autotools script and may not be relevant any more, but I
don't know for sure. On Linux X11_X_EXTRA_LIBS is empty. Does anybody know
if it is still actually useful for any X? If it is no longer relevant then
you could guarantee fullpath for X11_LIBRARIES by replacing
SET(X11_LIBRARIES ${X11_X_PRE_LIBS} ${X11_LIBRARIES} ${X11_X_EXTRA_LIBS})
by
SET(X11_LIBRARIES ${X11_X_PRE_LIBS} ${X11_LIBRARIES})
In the long run full paths would be a good idea for
FindX11, but not a requirement right now.
Fair enough. However, if there is a simple fix that some X cross-platform
expert could recommend (such as eliminating X11_X_EXTRA_LIBS from the
X11_LIBRARIES definition as above), then the long run might be short indeed.
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] FindX11.cmake needs some work for 2.6.0
On 2008-04-14 15:56-0700 Alan W. Irwin wrote:
Furthermore, making X11_LIBRARIES fullpath would benefit the PLplot build
(and presumably other builds as well). When first setting up the CMake-based
build system for PLplot, I either copied from our previous autotools-based
build system or I may have noticed the potential for -l flags in
X11_LIBRARIES. But in any case, I prepended X11_LIBRARIES with
"-L${X11_LIBRARY_DIR}" so that our users could have a non-standard install
location for X (especially important for this era of frantic X development
activity where some X testers may have multiple versions of X installed on
their platform). However, this -L flag leads to CMP0003 warnings for the
2.6.0 release candidate since fullpath libraries are preferred for 2.6.x.
(Also, X11_LIBRARY_DIR is an undocumented variable for FindX11.cmake which
I would prefer not to depend upon in the long term.)
It turns out the X11_X_EXTRA_LIBS component of X11_LIBRARIES (the component
that potentially produces -l flags in FindX11.cmake) is determined by
multiple invocations of CHECK_LIBRARY_EXISTS with the third argument
(location) an empty string. Thus, X11_X_EXTRA_LIBS -l flags only correspond
to default system locations. This means the "-L${X11_LIBRARY_DIR}" flag is
completely unneeded for PLplot so I will remove it.
It would be trivial to transform the -l flags in X11_X_EXTRA_LIBS to
fullpath names with the appropriate FIND_LIBRARY calls since only the system
default location needs to be searched. However, now there is no motivation
for this change since the above "-L${X11_LIBRARY_DIR}" (or apparently any
other use of the internal X11_LIBRARY_DIR variable determined by
FindX11.cmake) is not needed.
Thus, it appears the present FindX11.cmake in 2.6.0-RC-8 is fine. My
apologies for taking so long to arrive at this conclusion.
Alan
The only remaining issue is replacing the -l flags in X11_X_EXTRA_LIBS with
full path names (which Bill has agreed is a worthwhile long-term
goal.
Furthermore, it also
should make it extremely easy to modify FindX11.cmake to replace the -l flags
with fullpath name libraries which Bill has agreed is a worthwhile long-term
goal.
Of course, there are workaround for CMP0003 warnings, but the clean solution
would be if a CMake developer would simply change FindX11.cmake in cmake cvs
and also for 2.6.0 so that X11_X_EXTRA_LIBS and therefore X11_LIBRARIES are
always consistently fullpath. That would allow me to stop prepending
"-L${X11_LIBRARY_DIR}" to X11_LIBRARIES which would eliminate the CMP0003
warnings without compromising the need of some who require a non-standard
install location for X.
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
__
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
[CMake] Some minor issues for 2.6.0-RC-8
On my Debian testing system, here are the results of wx-config --libs
-pthread -lwx_gtk2u_xrc-2.6 -lwx_gtk2u_qa-2.6 -lwx_gtk2u_html-2.6
-lwx_gtk2u_adv-2.6 -lwx_gtk2u_core-2.6 -lwx_baseu_xml-2.6 -lwx_baseu_net-2.6
-lwx_baseu-2.6
Consistent with this result, FindwxWidgets.cmake yields
wxWidgets_LIBRARIES =
-pthread;;;-lwx_gtk2u_xrc-2.6;-lwx_gtk2u_qa-2.6;-lwx_gtk2u_html-2.6;-lwx_gtk2u_adv-2.6;-lwx_gtk2u_core-2.6;-lwx_baseu_xml-2.6;-lwx_baseu_net-2.6;-lwx_baseu-2.6
I process that result with a macro to convert those -l flags to full pathname
form (which I prefer since it makes it trivial to use non-standard install
locations):
wxwidgets_LINK_FLAGS =
-pthread;/usr/lib/libwx_gtk2u_xrc-2.6.so;/usr/lib/libwx_gtk2u_qa-2.6.so;/usr/lib/libwx_gtk2u_html-2.6.so;/usr/lib/libwx_gtk2u_adv-2.6.so;/usr/lib/libwx_gtk2u_core-2.6.so;/usr/lib/libwx_baseu_xml-2.6.so;/usr/lib/libwx_baseu_net-2.6.so;/usr/lib/libwx_baseu-2.6.so
Ultimately I use the logic
target_link_libraries(
plplotwxwidgets${LIB_TAG}
plplotcxx${LIB_TAG}
${wxwidgets_LINK_FLAGS}
)
which gives the following CMake warning:
This warning appears
because target "plplotwxwidgetsd" links to some libraries for which the
linker must search:
-pthread
and other libraries with known full path:
/home/software/plplot_cvs/HEAD/build_dir/bindings/c++/libplplotcxxd.so.9.3.0
/home/software/plplot_cvs/HEAD/build_dir/src/libplplotd.so.9.5.0
/home/software/plplot_cvs/HEAD/build_dir/lib/csa/libcsirocsa.so.0.0.1
/home/software/plplot_cvs/HEAD/build_dir/lib/nn/libcsironn.so.0.0.1
CMake is adding directories in the second list to the linker search path in
case they are needed to find libraries from the first list (for backwards
compatibility with CMake 2.4).
To anticipate Bill's immediate question why I don't set policy CMP0003 to
NEW to avoid this warning message (and also not have the added directories
for the linker search path), I plan to set policy CMP0003 to NEW eventually,
but I am trying to use these warnings to find where I need to transform -l
flags to full pathname form, and the problem is if I don't get rid of the
above warning, then no others are triggered. (I just discovered that this
morning when I got rid of the -L warning for the X libraries only to have
this new completely independent warning show up.)
For now, I plan to work around that issue by artificially filtering out the
linker option -pthread and continuing with cmake runs to find any remaining
"-l" options, and eventually I will set CMP0003 to NEW so I will not see any
of these warnings.
But the above results show there are three minor issues with RC8 that I
summarize here:
(1) In FindwxWidgets.cmake, wxWidgets_LIBRARIES is documented as
"Path to the wxWidgets libraries". From the above result (before my macro
transformed it) this documentation should be changed to something like
"List of linker options to use when linking to the wxWidgets libraries".
(2) In CMP0003 OLD mode, the -pthread linker option triggers the warning.
That is obviously incorrect, and only a list of actual libraries (specified
only by -l options?) should trigger the warning.
(3) There is a "sequential" problem with these warnings so only the first
one encountered is mentioned. Please go back to the old (CVS) method where
(IIRC) a complete list of CMP0003 warnings was generated. It's a completely
self-explanatory warning message so users should not complain if they
encounter more than one of these messages.
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
[CMake] LIST bugs for cmake version 2.6-patch 0 RC-8
The LIST command has issues when dealing with a list with some empty elements.
To see this try the following CMakeLists.txt
set(list_example "1;;;2;3;4")
message("list_example = ${list_example}")
list(APPEND list_example "5")
message("list_example = ${list_example}")
list(LENGTH list_example list_example_length)
message("list_example_length = ${list_example_length}")
list(GET list_example 1 list_example1)
message("list_example1 = ${list_example1}")
list(REMOVE_AT list_example 5)
message("list_example = ${list_example}")
The result is
list_example = 1;;;2;3;4
list_example = 1;;;2;3;4;5
list_example_length = 5
list_example1 = 2
CMake Error at CMakeLists.txt:5 (list):
list index: 5 out of range (-5, 4)
So APPEND is fine, but LENGTH, GET, and REMOVE_AT work as if the two empty
components of the list are not there.
VARIANT 1.
If I replace the last two lines by
list(REMOVE_AT list_example 1)
message("list_example = ${list_example}")
the result is
list_example = 1;;;2;3;4
list_example = 1;;;2;3;4;5
list_example_length = 5
list_example1 = 2
list_example = 1;3;4;5
VARIANT 2.
If I replace the last two lines by
list(REMOVE_ITEM list_example "1")
message("list_example = ${list_example}")
the result is
list_example = 1;;;2;3;4
list_example = 1;;;2;3;4;5
list_example_length = 5
list_example1 = 2
list_example = 2;3;4;5
VARIANT 3.
If I replace the last two lines by
list(REMOVE_ITEM list_example "")
message("list_example = ${list_example}")
the result is
list_example = 1;;;2;3;4
list_example = 1;;;2;3;4;5
list_example_length = 5
list_example1 = 2
list_example = 1;2;3;4;5
VARIANT 4.
If I replace the last two lines by
list(SORT list_example 1)
message("list_example = ${list_example}")
the result is
list_example = 1;;;2;3;4
list_example = 1;;;2;3;4;5
list_example_length = 5
list_example1 = 2
list_example = 1;2;3;4;5
VARIANT 5.
If I replace the last two lines by
list(REVERSE list_example 1)
message("list_example = ${list_example}")
the result is
list_example = 1;;;2;3;4
list_example = 1;;;2;3;4;5
list_example_length = 5
list_example1 = 2
list_example = 5;4;3;2;1
VARIANT 6.
If I replace the last two lines by
list(FIND list_example "1" one_index)
message("list_example = ${list_example}")
message("one_index = ${one_index}")
the result is
list_example = 1;;;2;3;4
list_example = 1;;;2;3;4;5
list_example_length = 5
list_example1 = 2
list_example = 1;;;2;3;4;5
one_index = 0
VARIANT 7.
If I replace the last two lines by
list(FIND list_example "" null_index)
message("list_example = ${list_example}")
message("null_index = ${null_index}")
the result is
list_example = 1;;;2;3;4
list_example = 1;;;2;3;4;5
list_example_length = 5
list_example1 = 2
list_example = 1;;;2;3;4;5
null_index = -1
VARIANT 8.
If I replace the last two lines by
list(INSERT list_example 4 6 7)
message("list_example = ${list_example}")
the result is
list_example = 1;;;2;3;4
list_example = 1;;;2;3;4;5
list_example_length = 5
list_example1 = 2
list_example = 1;2;3;4;6;7;5
All the above results for LENGTH, GET, REMOVE_AT, REMOVE_ITEM, SORT,
REVERSE, and INSERT are consistent with the mental model that no indices are
assigned to empty elements of a CMake list, and the result has the empty
elements dropped (which by accident gives the correct result for REMOVE_ITEM
when an empty element is dropped). However, from the above results APPEND
keeps those empty elements in the result, as does FIND, (but FIND cannot
find those empty elements).
I am not aware of any other language that ignores empty elements or drops
them from the results for certain operations so I believe the above results
are symptoms of a language bug that needs to be addressed. I don't know
CMake well enough to give you a patch, but I assume it is a fairly trivial
fix.
I also have a wishlist bug to report which I hope gets addressed at the same
time as the more serious bug above.
VARIANT 9.
If I replace the last two lines by
list(INSERT list_example 5 6 7)
message("list_example = ${list_example}")
the result is
list_example = 1;;;2;3;4
list_example = 1;;;2;3;4;5
list_example_length = 5
list_example1 = 2
CMake Error at CMakeLists.txt:21 (list):
list index: 5 out of range (-5, 4)
If you insert just after the end of the list, it should work just like an
append instead of giving you an index error as above.
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
Re: [CMake] Some minor issues for 2.6.0-RC-8
On 2008-04-18 10:35-0400 Bill Hoffman wrote: Alan W. Irwin wrote: (2) In CMP0003 OLD mode, the -pthread linker option triggers the warning. That is obviously incorrect, and only a list of actual libraries (specified only by -l options?) should trigger the warning. I will look at the -pthread case, since it can not depend on a -L. Thanks. However, I assume -pthread is just one example of many compiler/linker options that have nothing to do with library location so I suggest it might be easier to use a whitelist approach (-l, etc. accepted) rather than a blacklist (-pthread, etc. rejected) approach. (3) There is a "sequential" problem with these warnings so only the first one encountered is mentioned. Please go back to the old (CVS) method where (IIRC) a complete list of CMP0003 warnings was generated. It's a completely self-explanatory warning message so users should not complain if they encounter more than one of these messages. It was too verbose, a project like paraview produced hundreds of warnings, and in 99% of the cases, making CMP0003 to NEW is the fix that needs to be done. The volume of output was confusing. And still the message is confusing to people. I sympathize with your concern over verbose warnings. However, if you stick with mentioning just the first instance, then the conscientious package developer sets CMP0003 to NEW after realizing it shouldn't make any difference for that instance, then gets killed for the unmentioned hundredth instance making debugging of the resulting linking problem confusing. One idea would be to reduce the warning message to its essence for each instance. Just give what library/executable is affected, and what linking options are causing the warning. Then at the end (assuming there is one or more CMP0003 warnings) you give the boilerplate about the options for dealing with the issues given by each instance. This rearrangement should save you at least a factor of two in the volume of the CMP0003 warnings since you are not repeating the boilerplate about what to do for the issue for each instance. You could also have an option for shortening the instance warning down to something like the current first line: CMP0003 warning at bindings/wxwidgets/CMakeLists.txt:49 (add_library): This short form (with full boilerplate explanation at the end) would save another factor of 15 or so for a total saving of a factor of 30. You could even make this short form the default. I would be happy so long as there is a verbose warning form option available that gives me the linking option details about each instance warning so I can properly evaluate the affect for each different instance of adopting NEW policy for CMP0003. Bill, I know at this stage you are probably sorry you had any CMP0003 warnings at all, but I want to thank you for making this effort since the information in these warning messages is quite helpful. 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] LIST bugs for cmake version 2.6-patch 0 RC-8
Here is an improved CMakeLists.txt file which shows all the issues
simultaneously without having to re-edit the file.
*
set(list_example "1;;;2;3;4")
message("input list_example = ${list_example}")
list(APPEND list_example "5")
message("appended list_example = ${list_example}")
message("")
list(LENGTH list_example list_example_length)
message("list_example_length = ${list_example_length}")
message("")
list(GET list_example 1 list_example1)
message("element 1 from list_example = ${list_example1}")
message("")
list(GET list_example 5 list_example5)
message("element 5 from list_example = ${list_example5}")
message("")
set(list_example "1;;;2;3;4;5")
message("input list_example = ${list_example}")
list(SORT list_example)
message("sorted list_example = ${list_example}")
message("")
set(list_example "1;;;2;3;4;5")
message("input list_example = ${list_example}")
list(REVERSE list_example)
message("reversed list_example = ${list_example}")
message("")
set(list_example "1;;;2;3;4;5")
message("input list_example = ${list_example}")
list(FIND list_example "1" one_index)
message("list_example after find = ${list_example}")
message("one_index = ${one_index}")
message("")
set(list_example "1;;;2;3;4;5")
message("input list_example = ${list_example}")
list(FIND list_example "" null_index)
message("list_example after find = ${list_example}")
message("null_index = ${null_index}")
message("")
set(list_example "1;;;2;3;4;5")
message("input list_example = ${list_example}")
list(REMOVE_ITEM list_example "1")
message("remove 1 list_example = ${list_example}")
message("")
set(list_example "1;;;2;3;4;5")
message("input list_example = ${list_example}")
list(REMOVE_ITEM list_example "")
message("remove empty list_example = ${list_example}")
message("")
set(list_example "1;;;2;3;4;5")
message("input list_example = ${list_example}")
list(INSERT list_example 4 6 7)
message("insert 4 6 7 list_example = ${list_example}")
message("")
set(list_example "1;;;2;3;4;5")
message("input list_example = ${list_example}")
list(INSERT list_example 5 6 7)
message("insert 5 6 7 list_example = ${list_example}")
message("")
*
And here are the results for 2.6.
*
input list_example = 1;;;2;3;4
appended list_example = 1;;;2;3;4;5
list_example_length = 5
element 1 from list_example = 2
CMake Error at CMakeLists.txt:15 (list):
list index: 5 out of range (-5, 4)
element 5 from list_example =
input list_example = 1;;;2;3;4;5
sorted list_example = 1;2;3;4;5
input list_example = 1;;;2;3;4;5
reversed list_example = 5;4;3;2;1
input list_example = 1;;;2;3;4;5
list_example after find = 1;;;2;3;4;5
one_index = 0
input list_example = 1;;;2;3;4;5
list_example after find = 1;;;2;3;4;5
null_index = -1
input list_example = 1;;;2;3;4;5
remove 1 list_example = 2;3;4;5
input list_example = 1;;;2;3;4;5
remove empty list_example = 1;2;3;4;5
input list_example = 1;;;2;3;4;5
insert 4 6 7 list_example = 1;2;3;4;6;7;5
input list_example = 1;;;2;3;4;5
CMake Error at CMakeLists.txt:65 (list):
list index: 5 out of range (-5, 4)
insert 5 6 7 list_example = 1;;;2;3;4;5
On 2008-04-18 12:07-0400 Bill Hoffman wrote:
Is this something new to 2.6, or is it the same as 2.4?
I have been concentrating fairly exclusively on issues I have been noticing
during my 2.6 tests, but in response to your question I ran the above
CMakeLists.txt for 2.4.8, and it turns out 2.4.8 has the same LIST issues.
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] CMake 2.4 (8) & WxWidgets + RichText Pt 2
To see what is going on, check the FindwxWidgets.cmake file. For example, on my Debian testing system with CMake 2.4.8, that file is located at /usr/share/cmake-2.4/Modules/FindwxWidgets.cmake. There is a list of components in that file such as base core adv, etc., but no richtext. So I suggest for cmake-2.4.8 you simply work around the problem for now by editing that file to add the components you need. You could also try cmake 2.6.0 (currently RC8). I notice for that FindwxWidgets.cmake, the components approach is quite different so richtext may just work. 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] LIST bugs for cmake version 2.6-patch 0 RC-8
On 2008-04-18 15:14-0400 Bill Hoffman wrote: Alan W. Irwin wrote: Is this something new to 2.6, or is it the same as 2.4? I have been concentrating fairly exclusively on issues I have been noticing during my 2.6 tests, but in response to your question I ran the above CMakeLists.txt for 2.4.8, and it turns out 2.4.8 has the same LIST issues. OK, so it is not a regression... Can you please create a bug entry for this. Thanks. Done, see http://public.kitware.com/Bug/view.php?id=6852. 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] cmake and distutils
On 2008-04-22 20:06+0200 Christophe Alexandre wrote: Hi all, I'm working on a C++ project exporting its API with in Python. Is there an "easy..." way to compile and generate the Python Modules with cmake. I find the the distutils and cmake hard to use together : not the same build management, the installation process,... Wouldn't it be better to compile the Python Modules only with cmake ? If anyone has some experience on the subject, I'll be happy to hear from it. PLplot historically has chosen to use autotools and now cmake to build our swig-generated (and also one hand-crafted instance) of python bindings to our C library. The method works well. Although we don't use distutils for the actual build, it is quite useful for finding out things about the python environment that we need to know for the build. To see the full example, look at cmake/modules/python.cmake (which finds out everything we need to know about python) and bindings/python/CMakeList.txt (for the module build and install), and examples/python/CMakeList.txt (for examples that use the built python interface to PLplot) in http://plplot.svn.sourceforge.net/viewvc/plplot/trunk/ 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] Differentiate between Linux and FreeBSD
On 2008-04-22 21:48-0400 Amitha Perera wrote:
Horacio Sanson wrote:
The problem is that in linux I have to add the sctp library (i.e.
-lsctp) if not compilation fails and in FreeBSD adding that library
would cause the compiler to complain.
if there is a better way to do this I am eager to learn it.
Not necessarily "better", but if sctp exists on Linux, but not on FreeBSD (or
more generally, if sctp should be linked against whenever it is found), an
option is
find_library( SCTP_LIBRARY sctp )
target_link_libraries( your_exec ${SCTP_LIBRARY} )
Good idea, but I believe you would also need the following modification to
the above logic
find_library( SCTP_LIBRARY sctp )
if(SCTP_LIBRARY)
target_link_libraries( your_exec ${SCTP_LIBRARY} )
endif(SCTP_LIBRARY)
The reason for the extra logic is that if libsctp is not found then
SCTP_LIBRARY with be set to "SCTP_LIBRARY-NOTFOUND" which would screw up
"target_link_libraries" without the "if" protection.
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] Some minor issues for 2.6.0-RC-8
On 2008-04-23 09:28-0400 Miguel A. Figueroa-Villanueva wrote: Actually, the Module should be fixed instead to do the documented thing. Like pkg-config, the wx-config output should be properly post-processed. HS I guess there are always some unhappy customers ;) Actually, I guess this is the right thing to do... However, I think that the redundancy should be exploited. That is, I'm willing to use the FindPkgConfig macros/functions to post-process (even gather) the wx-config output. However, I'll need some time before I can implement/test all this. Also, what does the pkg-config module do with the options: -framework, -isysroot, -arch, etc. I have confirmed there is an undocumented (at least for Debian testing) pkg-config flag called --libs-only-other which delivers all non-L and non-l flags linker flags. This corresponds to what is delivered by _LDFLAGS_OTHER by FindPkgConfig.cmake. On the other hand, the man page for wx-config states --libs Output link flags required for a wxWidgets application. which is equivalent to the pkg-config --libs option, but unlike pkg-config there doesn't appear to be any other linker flag options for wx-config. However, I suggest you use the appropriate CMake logic to transform the contents of what is delivered by --libs into the equivalent of the results returned by FindPkgConfig.cmake such as # wxWidgets_LIBRARIES ... only the libraries (w/o the '-l') # wxWidgets_LIBRARY_DIRS ... the paths of the libraries (w/o the '-L') # wxWidgets_LDFLAGS... all required linker flags # wxWidgets_LDFLAGS_OTHER ... all other linker flags What is the correct thing to do with these parameters in CMake? I would need to check this too, I suppose. Users would be advised to use the LINK_FLAGS and/or LINK_FLAGS_ property set by SET_TARGET_PROPERTIES to pass the separated out (by e.g., wxWidgets_LDFLAGS_OTHER) -framework, -isysroot, -arch, -pthread options to the linker. 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] cmake and distutils
On 2008-04-23 10:38+0200 Christophe Alexandre wrote: Ok for the Module part, but what about the compilation CFLAGS and link flags used by distutils ? Must I copy them in my CMakeList.txt ? I don't understand your question since I am inexperienced with using distutils to build. To answer your question you should check what is done with the complete working example I gave you. 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] Some minor issues for 2.6.0-RC-8
On 2008-04-24 15:45+0200 Hendrik Sattler wrote: Zitat von "Alan W. Irwin" <[EMAIL PROTECTED]>: which is equivalent to the pkg-config --libs option, but unlike pkg-config there doesn't appear to be any other linker flag options for wx-config. However, I suggest you use the appropriate CMake logic to transform the contents of what is delivered by --libs into the equivalent of the results returned by FindPkgConfig.cmake such as # wxWidgets_LIBRARIES ... only the libraries (w/o the '-l') # wxWidgets_LIBRARY_DIRS ... the paths of the libraries (w/o the '-L') The dirs provided with -L are only needed when using find_library() to put libraries with full path into wxWidgets_LIBRARIES. After that, it should not be needed anymore. # wxWidgets_LDFLAGS... all required linker flags # wxWidgets_LDFLAGS_OTHER ... all other linker flags What is the correct thing to do with these parameters in CMake? I would need to check this too, I suppose. Users would be advised to use the LINK_FLAGS and/or LINK_FLAGS_ property set by SET_TARGET_PROPERTIES to pass the separated out (by e.g., wxWidgets_LDFLAGS_OTHER) -framework, -isysroot, -arch, -pthread options to the linker. So such a module only needs to return: xxx_LIBRARIES_<> with full-path libraries and (optional) support for (general|debug|optimized), xxx_INCLUDE_DIRS for position of header files, xxx_COMPILE_FLAGS_<> and xxx_LINK_FLAGS_<> (with support for <> being at least RELEASE and DEBUG). Problem may be that the last two are highly compiler-specific :-( Anything less than that is incomplete, IMHO. Hendrik: since I commented as well (based on my user experience with FindPkgConfig.cmake), I was asked to make a feature request for FindwxWidgets.cmake. However, I don't have that much user experience with FindPkgConfig.cmake or wx-config so will you please make the feature request instead? 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
[CMake] What is the best autotools ==> CMake conversion script?
I have an opportunity to help convert a rather large software project from autotools to CMake, but I don't have much time/motivation to do all the routine conversions from autotools syntax to CMake syntax so I am hoping there is a script out there that will do most of that work. I did use such a script from the KDE project years ago for the PLplot conversion, but it was fairly immature at that time. Thus, I hope it has been improved or there is something better now. 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] CMAKE_MODULE_PATH on windows.
On 2008-05-05 15:36-0700 Phil Pellouchoud wrote: I cannot get this to work. No matter how I set it, it never seems to be able to use it. PROJECT(x) SET(CMAKE_MODULE_PATH path) INCLUDE ( test.cmake ) ^ You are using the "file" signature for INCLUDE here which ignores CMAKE_MODULE_PATH. Use the module form, instead, e.g., INCLUDE(test) which according to the documentation... "If a module is specified instead of a file, the file with name .cmake is searched in the CMAKE_MODULE_PATH." i.e., it will look for path/test.cmake If that doesn't work, please let us know the exact "path" you have specified. I think for INCLUDE it must be in internal CMake form (i.e., in Unix form), but I am not sure since I only have Unix experience with 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 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] compiling a python module
On 2008-05-05 23:46+0100 Jonathan Riddell wrote: Is there a way to compile a library without adding the "lib" prefix as TARGET_LINK_LIBRARIES() does? This is needed for a C python module. Yes. (Actually, it is ADD_LIBRARY that creates the target and the default "lib" name of that target.) To override the default use set_target_properties( PROPERTIES PREFIX "") From the CMake documentation "Properties that affect the name of a target's output file are as follows. The PREFIX and SUFFIX properties override the default target name prefix (such as "lib") and suffix (such as ".so"). 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] CMake 2.6.0 available for download
On 2008-05-06 16:14-0400 Bill Hoffman wrote: On behalf of myself, Ken, Brad, Dave, Alex and the rest of the CMake team, we are pleased to announce that CMake 2.6.0 is available for download at: http://www.cmake.org/HTML/Download.html My tests on the Debian testing platform show no problems so far. The bootstrap build, ctest, and install of http://www.cmake.org/files/v2.6/cmake-2.6.0.tar.gz works fine. So does the build, install, ctest, and install-tree test of PLplot with CMake 2.6.0. Thanks, guys, for all your hard work! 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] How to read content of a registry entry on WIN32?
On 2008-05-07 15:37+0200 Eric Noulard wrote: I want to use the content of a regsitry entry HKEY_LOCAL_MACHINE\SOFTWARE\GnuWin32/InstallPath in order to use it in a FIND_PROGRAM , PATHS argument? find_program(LEX_PROGRAM NAMES flex lex PATHS "[HKEY_LOCAL_MACHINE\\SOFTWARE\\GnuWin32\\InstallPath]/bin" NO_DEFAULT_PATH DOC "A lex-compatible lexer generator") but this does not work? How can I do that? There are a lot of examples of using HKEY_LOCAL_MACHINE in the CMake modules. From studying those (without any knowledge of the windows registry) I cannot see what is wrong with the above, but maybe you will have better luck spotting the problem given all the (presumably) working examples. 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] LIST bugs for cmake version 2.6-patch 0 RC-8
On 2008-04-19 11:46-0700 Alan W. Irwin wrote:
On 2008-04-18 15:14-0400 Bill Hoffman wrote:
OK, so it is not a regression... Can you please create a bug entry for
this. Thanks.
Done, see http://public.kitware.com/Bug/view.php?id=6852.
This bug had been closed, but the fix is not quite complete yet. For CMake
2.6.0 my test script (with
cmake_minimum_required(VERSION 2.6)
prepended) gives good results for all results except the SORT one.
Here is a short test script to show the issue.
cmake_minimum_required(VERSION 2.6)
set(list_example "1;;;2;3;4;5")
message("input list_example = ${list_example}")
list(SORT list_example)
message("sorted list_example = ${list_example}")
The result is
input list_example = 1;;;2;3;4;5
sorted list_example = 1;2;3;4;5
Obviously, the empty elements should show up in the sorted list but they
don't.
Bill, should I enter this as a new bug, reopen the old bug, or is the fix
so trivial I don't need to do either?
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] LIST bugs for cmake version 2.6-patch 0 RC-8
On 2008-05-07 09:12-0700 Alan W. Irwin wrote:
On 2008-04-19 11:46-0700 Alan W. Irwin wrote:
On 2008-04-18 15:14-0400 Bill Hoffman wrote:
OK, so it is not a regression... Can you please create a bug entry for
this. Thanks.
Done, see http://public.kitware.com/Bug/view.php?id=6852.
This bug had been closed, but the fix is not quite complete yet. For CMake
2.6.0 my test script (with
cmake_minimum_required(VERSION 2.6)
prepended) gives good results for all results except the SORT one.
Here is a short test script to show the issue.
cmake_minimum_required(VERSION 2.6)
set(list_example "1;;;2;3;4;5")
message("input list_example = ${list_example}")
list(SORT list_example)
message("sorted list_example = ${list_example}")
The result is
input list_example = 1;;;2;3;4;5
sorted list_example = 1;2;3;4;5
Obviously, the empty elements should show up in the sorted list but they
don't.
Bill, should I enter this as a new bug, reopen the old bug, or is the fix
so trivial I don't need to do either?
I found another instance where empty elements don't work properly.
Here is a simple test script illustrating the problem:
cmake_minimum_required(VERSION 2.6)
set(list_example "1;;;2;3;4;5")
message("input list_example = ${list_example}")
message("individual elements are listed as follows:")
foreach(element ${list_example})
message("${element}")
endforeach(element list_example)
The result is
input list_example = 1;;;2;3;4;5
individual elements are listed as follows:
1
2
3
4
5
Clearly, the empty elements are (incorrectly) being skipped in the foreach
loop.
Bill, separate bug report, reopen old one, or trivial fix?
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] LIST bugs for cmake version 2.6-patch 0 RC-8
On 2008-05-07 14:45-0400 Bill Hoffman wrote:
We actually talked about this when I created policy CMP0007. Brad had this
to say:
The foreach command does see empty items:
foreach(x "" "" a "" b)
will give x each value including the empty string.
However,
set(ITEMS "" "" a "" b)
foreach(x ${ITEMS})
will skip empty ones. Variable expansion without quotes has *always*
removed empty items. It occurs before the foreach command even sees
them and is consistent across all commands. We should not change this.
I don't agree. For consistency sake with the new CMP0007 policy I think you
should expand out the empty elements in LIST variables so the two foreach
commands above give consistent results. The current inconsistent results
between explicit lists (as in the first foreach command above) as opposed to
an expanded LIST variable which contains the same empty and non-empty
elements (as in the second foreach above) are just confusing. So I hope you
reconsider this decision.
The difference is that the list command deals with lists by their
variable name, not in expanded form. The way to deal with this in
foreach is to create a new "list" mode that takes a list by name. So,
something like
foreach(x IN ITEMS)
will iterate over the entries of the list contained in the variable
ITEMS, including empty ones. This does not require a policy. It just
means people cannot iterate through argument lists whose first entry is
"IN" (already the case for "RANGE").
The case for this variation on the foreach signature is compelling if you
do not expand LIST variables consistently with the equivalent explicit lists.
However, I hope you do expand LIST variables consistently making this
signature unnecessary.
BTW, I have fixed the list(SORT to handle empty correctly.
Thanks!
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] LIST bugs for cmake version 2.6-patch 0 RC-8
On 2008-05-07 17:03-0400 Brad King wrote:
The policy is about the LIST command and how it deals with lists whose
*names* are given and not the *values*. This is the FOREACH command
which currently always deals with values. A fundmental rule in CMake
syntax is that the argument
${MYVAR}
expands lists and removes empty elements in all contexts
I agree there is a broader issue here than just the LIST command or just the
FOREACH command. However, let's talk about that broader issue, i.e., the
issue concerning how LIST variables are expanded in all contexts where
normally an ordinary explicit list of values is required as arguments. Is
there any practical justification for removing empty elements from a LIST
variable expansion inconsistently with how an ordinary explicit list with
empty values is treated?
I used your FOREACH example in my post, but it is really this expansion
inconsistency in all contexts which bothers me. Your answer so far is
essentially "we have always done it that way". Perhaps there are excellent
practical reasons for that language quirk that are obvious to you, but I
cannot think of what those might be at the moment so I would appreciate
your help in identifying those practical reasons.
If it turns out there are actually no practical reasons justifying this
current language inconsistency, then I suggest this consistency issue should
be dealt with to help evolve the CMake language into something that is less
confusing. Of course, at the same time the corresponding backwards
compatibility issue should be dealt with using the POLICY mechanism
(presumably with a new independent policy number rather than CMP0007).
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
