On 2007-11-06 07:50-0600 Geoffrey Furnish wrote: > Alan W. Irwin writes: > > > [...]BTW, when I gnerated the above cmake configuraiton diff, it didn't > > > take effect when I merely removed the cache and reran cmake. I had to > > > run cmake fresh in an empty build dir, to get the .../relink.txt file to > > > be regenerated. Is there a way to get cmake to actually regenerate all > > > it's stuff in your current working dir, or do other developers normally > > > have to start a new build dir from scratch to test changes to the cmake > > > configuration files? > > > > My advice is to always run cmake in an empty build tree. But that is > > not an onerous constraint since the only time you should want to re-run > > it is if you are changing options, and if you are changing options you > > will probably want to use a different build tree in any case. > > Hmm. Well, the situation I was facing, was a build that died part way > through, and I was mucking with the cmake config stuff, and wanted to proceed > from where I was. But, thankfully, plplot builds fast enough that the > start-over mantra is only a minor annoyance.
I covered that scenario in the next paragraph that you didn't quote, but also I wasn't particularly clear. I should have said above never run cmake _directly_ in anything but an empty build tree. After that initial configuration stage, from then on you just run make (which will run cmake indirectly as appropriate) whenever you change either cmake configuration files or source. Most times, the "just continue with make" scenario works fine, but when it obviously doesn't or you cannot figure out what is wrong, then you should start over with an empty build tree as a last resort. It's analogous to the old autotools game of figuring out whether you could continue with make (which would run various autotools as appropriate) or whether you had to completely start over in an empty build tree (or clean source tree). Starting over was always a last resort, but it was essential to use that last resort if you were having trouble you couldn't figure out (i.e., you were preparing a bug report). It's exactly the same for cmake. BTW, I hammer away at the "starting over" scenario quite a bit on list in answer to bug reports, but bug reports are one thing, and normal development is another. For the latter, there is normally no need to start over until you are truly stuck. > Question about the install process: Do I correctly understand that most of > the build process proceeds by constructing Makefiles in each directory, and > recursively invoking them, so that the actual build is just running make, > *but* the install targets actually run cmake on xyz.cmake files? So that the > install itself is not actually a make-controlled process (other than just > kicking off the cmake job)? cmake is mostly just used for the configuration stage. However, cmake also has a command option "-E" which allows you to do simple tasks like copying files in an absolutely cross-platform way. So you will see "cmake -E" commands a fair amount during both the build process (controlled by "make" on Unix platforms, see below) and install process (controlled by "make install" on Unix platforms). But "cmake -E" is a very different beast than invoking the full power of cmake without the -E option. I hasten to add this is where the analogy with autotools breaks down. For autotools, you were on your own for cross-platform correctness with the simple things like copying a file, making a symlink, etc. CMake has all that simple/useful cross-platform stuff (including windows!) covered with "cmake -E" which is great. OTOH, the actual build steps with autotools were done with a massive shell script called libtool acting as a uniform cross-platform front-end to the compiler, linker, etc. Since libtool was run every time you compiled a programme it added substantial overhead to the build. In contrast, cmake sets up static back-end (e.g., make, see below) rules to build and install during the configuration stage. Those rules are platform and back-end dependent, but figured out _once_ (as in how do I compile an executable on this platform) during the configuration stage and not at build time. This substantially reduces the build overhead. For example, on Linux you are just using the native make, gcc, etc., for the build with the appropriate gcc options that are figured out once at the configuration stage rather than figured out dynamically again and again with the libtool shell script. > > If so, is this because the build can't rely on having a working "make" > program on all platforms? So like even the part that runs via make on Unix, > it would actually not use make, but rather VC++ workspaces (or whatever > they're called) on MS platforms? Is that why the install rules appear to not > be expressed as normal make actions on Unix? cmake has various backends. One of the most important is the make-based back end that is default on all Unix systems. (I am pretty sure, but not positive that it always uses the make native to the Unix platform.) There are other backends than the Unix make-based one. For example, I think there is a backend on windows systems that uses something called nmake, but there are windows-only GUI's as well. On the cmake list there has been some discussion recently about developing a cross-platform GUI for cmake based on libqt, and that cross-platform GUI prospect excites a lot of users. I presume it would boil down to make on Unix platforms and nmake on windows platforms, but I am not sure. > > Or is my confusion deeper than I realize? > Nah. You are obviously in the middle of discovering the world of cmake, and that's great, but it does mean you need help from time to time with the overview which is (see above) sometimes similar to autotools and sometimes quite different. I also recommend you look at the cmake tutorial which we reference on the wiki. It's dated, but there is a lot of help there you can get with the overview of how things work. Finally, of course, to follow up on the overview, I suggest you run cmake --help-full |less to get all the gory details. 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 __________________________ ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
