geodynamics
cmake make unity groups.
Since one of my pull requests (#3725) had a problem with the unity build together with the world builder, I though I would explorer the unity groups. They require the latest cmake (3.18.1), but now that I got it working on my laptop (let's see what the tester thinks of it) I think it might be worth it since this should be a lot more stable.
Anyway, the cmake code is probably not pretty yet, but that can wait until the morning :)
I think this is the wrong approach (even though @gassmoeller suggesting looking into UNITY_GROUP):
- This requires 3.18 making it a lot less useful.
- If you use UNITY_GROUP, you get all files in a group in a single unity file, which is wrong unless you want to reimplement something like the batch size.
- Automating the grouping is complicated and or error-prone. Doing the grouping manually is not an alternative as it requires updating things in the CMakeLists file.
Let's compile the WB in a separate shared libary.
I agree this is currently not the approach we should take. I suggested unity build groups, because I was under the impression we can have one group per directory (one for each of our plugin systems, one for Simulator, one for Worldbuilder, etc.), but if we have to assign individual files that is not feasible to maintain.
Couldn't you recurse through source/, find all directories, and for each directory find all .cc files that you then assign to a group with the same name as the directory? FILE(GLOB_RECURSE LIST_DIRECTORIES true ...) should give you a list of everything including directories, and then IF (IS_DIRECTORY ...) tells you whether it is a directory.
Couldn't you recurse through
source/, find all directories, and for each directory find all.ccfiles that you then assign to a group with the same name as the directory?FILE(GLOB_RECURSE LIST_DIRECTORIES true ...)should give you a list of everything including directories, and thenIF (IS_DIRECTORY ...)tells you whether it is a directory.
I agree with @tjhei and @gassmoeller that this might not be the right approach, but at least it was worth it looking into. I also agree that (separately from this pull request) the world builder should become a shared library (although that wont make it compile with unity for now).
@bangerth What you suggest might solve the problem of the subdirs, and I will try later today to see if that works. I do see value in grouping files more logically together, even if the world builder is a shared library.
In short, if there is no way to make it really clean, then I agree that this is not the right approach. If @bangerth does work, it would require an test with cmake 3.18, but my guess is that we can easily add another github tester for that.
I also agree that (separately from this pull request) the world builder should become a shared library (although that wont make it compile with unity for now).
Worldbuilder should be a separate library and you can turn on unity build for that as well. With that change, the problems we have will be gone. Therefore, I don't see a reason to invest a lot of effort into something manually (like @bangerth or @MFraters ) suggest.
it would require an test with cmake 3.18, but my guess is that we can easily add another github tester for that.
I don't like the idea of additional build and test complexity.
I agree with @tjhei, having the world build as a shared library brings us many other advantages as well, so any energy we spend on another solution will only distract us from that.
In #5163 it looks like unity groups are not as good as the current approach. We can always revisit the topic in the future if necessary. Closing this PR for now.