cmake

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux