[Mesa-dev] Moving amdgpu/addrlib into a git submodule

Erik Faye-Lund kusmabite at gmail.com
Tue Aug 9 16:22:15 UTC 2016


On Tue, Aug 9, 2016 at 4:59 PM, Nicolai Hähnle <nhaehnle at gmail.com> wrote:
> On 09.08.2016 15:58, Rob Clark wrote:
>>
>> tbh, git submodules are more annoying than they need to be, and I'm
>> not really terribly excited to use that for something that is a build
>> dependency.  Maybe just move it into libdrm instead?
>
>
> I know. That's what I would have proposed if the addrlib interface were
> stable. Unfortunately it isn't, and realistically speaking, that's not going
> to change.
>
> So shared linking is right out.
>
> Static linking or just including source files from a separate repository
> could be considered, but then what's the process for ensuring you have the
> right version?
>
> The nice aspect of submodules is that every commit of the Mesa repository
> "knows" what the corresponding right version of addrlib is, and so git can
> update the submodule to the correct version for you automatically.

I'm not a huge fan of submodules either. They just don't deal with
distributed development properly, which should be a non-starter for
OSS IMO. You either set the submodule to point to an absolute URL, in
which case it's awkward to work with if you need to change the code,
or you use a relative URL, which forces everyone who has a fork to
fork the submodule also. Yuck. As a formerly active Git developer, my
impression is that nobody of the core-git developers really loved the
idea of git-submodule, it was mostly introduced into Git to help KDE
transition their gigantic SVN-external based source tree to Git.

IMO, a much better alternative would be to have addrlib live in its
own repository, and periodically do a git subtree-merge into mesa and
other dependent system. That means that nobody really needs to deal
with the fact that the upstream is in a different repo, except when
submitting patches for upstream. This is what git.git itself does for
some of its subsystems.


More information about the mesa-dev mailing list