On 12/15/06, Josef Weidendorfer <Josef.Weidendorfer@xxxxxx> wrote:
If you want to track build results for some source,
why would you ever want these builds go out of sync with the source?
I don't, bad wording by me. That was the problem I wanted to address.
Your example has the folling submodule dependence
("X ==> Y" means Y being a submodule of X):
App ==> Lib
^ ^
| |
AppBuild ==> LibBuild
In my example "AppBuild" and "LibBuild" were the same project but this
scenario is relevant as well.
If we force submodules to be subdirectories of supermodules,
Lib needlessly will have to appear two times in a checkout of
AppBuild.
However, there is nothing wrong with it. Yet, you perhaps want
the 2 Lib submodules not to go out of sync. This easily
can be done with symlinking the Lib checkouts. As they are submodules,
everything should work fine.
This is interesting. In my notation:
/path/to/link/name -> <commit>/path/to/subtree
means that there is a link named "name" in the tree object for
"path/to/link". The link points to a "link object" specifying a
subtree or blob of the tree that is pointed to in a submodule commit.
This is not currently implemented but has at least the following
advantages:
1. You can access files in a submodule without fetching the whole
submodule (which may be very large). (App1 is only interested in
lib1.h, the rest is toally irrelevant)
2. Superproject can access referenced (linked) files in it's own
folder-structure without being forced a structure by the subproject.
If you do a symlink instead, doesn't you loose versioning information?
What happens with the symlinks if someone clones the superproject?
Perhaps an option you want to have is to force a checkout
of AppBuild to make these symlinking itself when it detects
identical submodules links.
Hmmm... the only problem with a symlink is that it can go wrong
when moved. Unfortunately, I do not have a good solution for
this. We can not make UNIX symlinks smart in any way.
Hardlinking directories would be a solution, but that is not
possible.
Wouldn't specifying the submodule path in the link object fit in well
here? Then each "link object" can represent a checked out tree from
the subproject in the superproject directory-structure.
Another thing:
With normal "$buildroot != $srcroot" environments, the source
can not be a subdirectory of the build directory.
This is true for symlinks and would also be corrected if we have a
(sparse) submodule checkout there in it's place.
BTW, build project commits probably should not depend on any
history of other build commits.
Why? Can you give an example here.
> Link: /headers/lib1.h -> <lib1-commit3>/src/lib1.h
> Link: /bin/lib1.so -> <build1-commit>/i386/lib1/lib1.so
> Link: /bin/app1 -> <build1-commit>/i386/app1/app1
>
>
> <lib1-commit1>, <lib1-commit2> and <lib1-commit3> should be the same,
> dictated by the app1 project.
I do not see any problem here. Symlinks are stored in the git repository.
As the AppBuild commit depends on App and LibBuild submodule commits, the
symlinks always should be correct.
The main reason for these "links" are for versioning purposes: the
uniqe SHA1 of the "link" representing a tree/blob in a version of the
submodule should be "included" in the supermodules commit. Symlinks
won't give that at all.
> How do the super-projects in this case get access to the blobs pointed
> by the links - transparent or explicit in the build-process?
Submodules should automatically be checked out when checking out the
supermodule. So the blobs should already be there.
Or do I miss something?
Probably not as that was a piece of the puzzle that I was missing.
//Torgil
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html