Re: .gitlink for Summer of Code
- From
Daniel Barkalow <barkalow@iabervon.org>
- Date
- Mar 27, 2007, 20:02 UTC
- Message-ID
- <Pine.LNX.4.64.0703271547040.6485@iabervon.org>
- In-Reply-To
- <4609643C.9050803@midwinter.com>
On Tue, 27 Mar 2007, Steven Grimm wrote:
Show 6 quoted lines
> The obvious use case for "I want the superproject and just one submodule" is > when the superproject has build tools, header files, or other pieces of data > that are shared by some/all of the submodules. Maybe not the case in BSD per > se, but having a top-level file full of settings, paths to tools, etc. that > gets included by the individual Makefiles in subdirectories isn't all that > uncommon in complex multi-part projects.
This is actually the case I'm personally interested in. But in that case, you want to reverse the superproject/subproject organization, because that way each project part can use the desired version of the common stuff, and people can modify the common stuff without then testing the whole universe.
I.e., at some point, you'll want to change the behavior of the build system in such a way that all of the per-part configuration information sets needs to be updated to work with it. If the build system is in the superproject, you need to do everything at once. If the build system is in a subsubproject, you can make the change without affecting anything, and, as subprojects pull the build system change, they update the subsubproject entry and the configuration files as a single subproject commit. For sanity, you want to reach the point where all of the projects are using the same subsubproject version, but that doesn't have to happen overnight, and you don't have a single commit which touches every subproject.
-Daniel *This .sig left intentionally blank*