cmake repo/submodule

Development
1

I'd like to reorganize all the CMake-related scripts of each repository (the cmake/ dirs) into it's own repository and then just have each repo use that as a submodule. The advantage of this is decreasing the burden of maintaining CMake script changes -- there's a lot of shared code between repos that are currently maintained separately. Disadvantages might be:

1) more submodule maintenance. I think we already understand well enough how do this that it's not going to be a problem, and maintaining submodules is much less of a burden than maintaining CMake scripts in each repo

2) initializing/updating at least this cmake module after cloning the parent repo will be required to configure/build it. This is only a problem for people that weren't cloning recursively, but to take care of it I'll just make the ./configure scripts do the cmake/ submodule initialization if it sees nothing's there.

Anyone think of a reason not to go forward with that plan?

(This could wait until release-after-next, but it's been nagging at me lately).

- Jon

2

I'd like to reorganize all the CMake-related scripts of each
repository (the cmake/ dirs) into it's own repository and then just
have each repo use that as a submodule.

That's a very good thought.

1) more submodule maintenance.
2) initializing/updating at least this cmake module after cloning

Both sound fine to me.

(This could wait until release-after-next, but it's been nagging at me lately).

I'd rather do it now than later. How much work do you estimate this
reorg to be?

Robin

3

I'd rather do it now than later. How much work do you estimate this
reorg to be?

Probably just a day or two; mostly shuffling files around and testing that I didn't break anything. I'll start on it this afternoon.

- Jon

4

It's done now in all the masters. A regular `git pull` alone at this point is not going to be enough for anyone to make their local clones work again, make sure to also do `git submodule update --recursive --init`

- Jon