The work to transition to cmake has stalled somewhat. I've tried to use it a few times but keep running into issues that make it unusable for me. Not having make check is a big one, but I think the hackery required to get that going points to the underlying problem(s). I seems like the main problem is that automake puts all build targets in src/ and cmake spreads them all over build/*. This makes that you can't just add ./ to anything that would normally be in your path (or, PATH=.:$PATH, and then run, say, ../qa/workunits/cephtool/test.sh). There's a bunch of kludges in vstart.sh to make it work that I think mostly point to this issue (and the .libs things). Is there simply an option we can give cmake to make it put built binaries directly in build/? Stepping back a bit, it seems like the goals should be 1. Be able to completely replace autotools. I don't fancy maintaining both in parallel. 2. Be able to run vstart etc from the build dir. 3. Be able to run ./ceph[-anything] from the build dir, or put the build dir in the path. (I suppose we could rely in a make install step, but that seems like more hassle... hopefully it's not neceesary?) 4. make check has to work 5. Use make-dist.sh to generate a release tarball (not make dist) 6. gitbuilders use make-dist.sh and cmake to build packages 7. release process uses make-dist.sh and cmake to build a relelase I'm probably missing something? Should we set a target of doing the 10.0.2 or .3 with cmake? sage -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html