Fix meson dist with relative submodule URLs #8667
Conversation
This function will gain another directory parameter in the following commit, so things would get confusing otherwise.
This replaces the manual scan for path keys with complete parsing of the file as dictionaries. Though overkill at this point, this complete description will be needed to rewrite the file in the following commit. Parsing is now done via 'git config', which isolates meson from the details of the git configuration syntax. So, a side-effect of this commit should be that meson is more resilient to unusual files or future possible changes to the syntax supported by git. The downside is that this is slower (particularly on Windows where launching a process is very slow), but this shouldn't be significant compared to everything else 'meson dist' is doing.
Git supports relative submodule URLs, for example "../mylib.git" to refer to a sibling of the parent project. This allows mirroring of repositories with submodules across several hosts. Configurations like this were broken in 'meson dist', because the submodules would not be cloned correctly. This commit checks if any submodules have relative URLs, and if so, writes a new .gitmodules in the distribution directory which points to the original submodule path. In other words, when making a distribution, submodules are cloned in the same way that the parent project is: from the local git repository.
|
I'm not sure what makes sense with submodules in the grand scheme of things, this just seemed like an outright bug that could be fixed, so I tried to make it work. From a user perspective one thing that still seems odd about this is that, if you have subprojects as submodules, they will be included in the archive unconditionally. One might want to exclude them and rely on wrap files to fetch things for users if they need them, but |
|
Great work! The overall approach seems sane here, and the first two commits especially seem good to have anyway so thank you for factoring out each discrete change into its own commit.
Shower thoughts here (literally, actually) as I don't have much time today: Maybe we could compare each submodule and, if it is in the subprojects directory and has an associated wrap file, ignore it by default, unless This seems like an additional change, above and beyond "fix relative urls", so it's okay to not fix it right now. :D |
Hmm, good idea. Seems like that would cover most of what people might want to do, without really breaking anything or adding new options. I'll have a go. |
|
I completely forgot all about this PR. :D Meanwhile, I ended up taking a completely different approach to completely rewriting the archiving approach of My rewrite uses git archive and assumes you have inited the submodule yourself in the actual project tree, so it doesn't need to rewrite .gitmodules -- it is also marked as fixing #8144 which this PR would have fixed too, I guess. I'm going to close this PR since the thing it is solving is solved a different way, but
This is welcome to receive a new PR. |
|
Heh, no worries, me too (or at least it was on a back burner). Not needing to rewrite .gitmodules is nice. I'll revisit this on the node with my project structure soonish. |
2 participants
See the last commit message for details.