On Sun, May 25, 2014 at 11:42:49AM +0200 I heard the voice of Rhialto, and lo! it spake thus: > > I haven't found out how to get cmake to print out the command that > is actually executed,
make VERBOSE=1 > It seems like removing the quotes when setting YFLAGS in > CMakeLists.txt is the way (one way of?) fixing it. The same thing > should probably be done 2 lines lower too. Strange. I DID test it, I swear. Must have tweaked something afterward that hit the yacc case, since it does the same for me now. Without the parens, it ends up making YFLAGS a list rather than a string. I guess as a string, the add_custom_command() for yacc escapes it away to make it a single arg, which obviously Ain't Right(tm). Changed it to a list (and the DO_DEBUGPARSER case to a list append to match) and pushed as r344. > Another idea: add a variable for the name of the build directory and > a mkdir command for it. That way you can easily blow away the entire > build and start over. And by setting the variable on the command > line, have separate build dirs at the same time if you want. As far as blowing away, I have the 'allclean' target in the base Makefile for that. That mostly only seems needed normally to blow away cmake's cache of params etc. Changing what you -D on the cmake command line sometimes doesn't override what's already cached by rules that I don't really understand, so it's easier to just *boom* it. But the plain (cmake-provided) 'clean' target should clean up all the ctwm-build-related stuff just fine. CMake doesn't care what the build dir is called; build just seems a common convention in the cmake world, so I went with it. But you can pile on a bunch easy, just by making them and running cmake in them with different args. The one run via the base Makefile is mostly a convenience for simple cases; there's nothing in it except a thunk thruogh to cmake. In more intricate cases you'd be changing the cmake invocation in various ways anyway (e.g., 'cmake -DCMAKE_BUILD_TYPE=Debug ..' to do debug builds, which adds -g to the compiler invocations). Heck, you could even "mkdir /tmp/ctwmbuild ; cd /tmp/ctwmbuild ; cmake ~/work/ctwm/foo ; make" if you wanted. So I decided not to attempt covering more than the trivial case in the Makefile. Though I guess it's easy enough to add a little more; added a CMAKE_EXTRAS var so you can set extra -D's and such on the command line for cmake via the base Makefile. e.g.: % make CMAKE_EXTRAS="-DUSE_IMCONV=ON" allclean cmake rm -rf build/* ( cd build && cmake -DCMAKE_C_FLAGS:STRING="-O2 -pipe -march=amdfam10 " -DUSE_IMCONV=ON .. ) -- The C compiler identification is Clang 3.4.0 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works [....] -- Enabling GNOME1 support. CMake Error at CMakeLists.txt:163 (message): Can't find libim for imconv -- Configuring incomplete, errors occurred! See also "/home/fullermd/work/ctwm/bzr/cmake/build/CMakeFiles/CMakeOutput.log". *** Error code 1 Stop. I have this sneaking feeling we should probably just retire imconv support too; 's hard to believe anybody's using it, and it takes an extreme effort even to _find_ the code, which was last released in 1995. For anybody not willing to spend a while digging and guessing, <ftp://ftp.sdsc.edu/pub/sdsc/graphics/imtools/>. Heck, they even provide binaries for the Cray C-90 and Sun-4 (I presume the pre-UltraSPARC 32 bit)! -- Matthew Fuller (MF4839) | [email protected] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
