On 5/19/16 2:39 PM, Jeff Trull wrote:
One more vote for "allow CMakeLists.txt in the places we allow Jamfiles". Let the bigger questions be addressed separately.
If anyone's interested, There are currently three libraries with CMake files in them: compute, hana, and serialization and test compute and hana have a CMakeLists.txt file in the library root as well as other CMakeLists.txt files in subdirectories. test is a compiled library that has CMakeLists.txt files in it's build and test subdirectories serialization is a compiled library that has one CMakelists.txt file in a subdirectory named CMake There's quite a bit of variety among all these implementations. Looking at them, it would be alot of work to reconcile them. Given my esperience with CMake scripting this is not a surprise. I found in my case that it required lots and lots of trial and error and I never felt I really had it "right". I just stopped when it created my XCode project. No one's ever complained about it, so I'm really doubtful that anyone has ever tried aside from my self. My Xcode project builds and tests about 1000 tests - it takes a while to start up since it seems that XCode likes to pre-compile everything it can in order to make intellisense work. Building is pretty fast and text execution is very fast. I've been using it for about two (or three?) years without much problem (once it gets setup !!!) so that speaks well for it. From my perspective, the main attraction is that it sets up my XCode project correctly - for 1000 tests this is a big deal. With my old msvc setup setting up such a project by hand was an ongoing pain. When I want to run my "official" boost tests I use boost build with all the compilers I have on this machine in debug/release static/shared 32/64. This takes a while. Then I check in the changes and watch fail on environments I don't have. I don't really have a point there, just a little factual experience to keep things in perspective.