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

[Nicolai Hähnle]

On 11.08.2016 13:12, Enrico Weigelt, metux IT consult wrote:
> On 10.08.2016 15:19, Nicolai Hähnle wrote:
>> It would be nice to have something more concrete to go on, like what are
>> the problems _really_ :)
>
> Actually, I haven't understood who the other users of addrlib actually
> are - is it just AMDs proprietary driver ?

ROCm, i.e. compute, will want to use it at some point.


>> What pain do submodules give you that wouldn't be even _worse_ with a
>> separate script for fetching external sources?
>
> In the end - from dist perspective - it's the same kind of problem:
> you still have to do extra steps to get a full source tree, and you'll
> need to do extra downloads within the build process (unless you mirror/
> merge it into your own repo, to create a full tree for the source
> package) ... in either ways: really ugly.

The "extra steps" are `git clone --recursive` instead of `git clone` and 
`git pull && git submodule update` instead of `git pull`. If you're 
building from source releases, you don't have to change anything at all 
(the idea is to include addrlib in those).


>> Look, there are a bunch of different use cases here. Distro packagers;
>> Mesa contributors and bleeding-edge users; and us (which is slightly
>> separate because we're not _just_ Mesa contributors but have parts of
>> the stack elsewhere, which is why this is coming up in the first place).
>
> ACK.
>
>> Most of the complaints seem to come from distro packaging, though I have
>> yet to understand what the exact problems are.
>
> We need a 100% automatic build process - from the original source.
> And we need an *easy* way to apply/deapply our local patches ontop of
> the source tree - or even better: just have a git repo with just the
> full tree.
>
> If upstream doesn't provide that, all the distros out there have to invent
> their own mechanisms to transform upstream's mess into sth useful - and
> that needs to support easy rebasing.

Rebasing, seriously?

Honestly, when distributions go crazy with local patches, they just tend 
to make everybody's life worse. Suddenly you have users appearing with 
weird bug reports that you do not understand because their distribution 
changed something for whatever reason.

I can understand that a tweak in the build scripts is occasionally 
necessary, but when you start applying your own patches to the _drivers_ 
(which _is_ what you're implying here...), you should re-think your life 
choices.

At the very least, you shouldn't come whining to upstream when you're 
having a hard time doing something stupid.

I'll admit though that the rebasing situation sucks. Given Git's 
underlying data model, there's really no reason why rebase should be any 
harder with submodules than in the alternative world where you keep 
addrlib completely separately, but right now the command-line interface 
is supremely unhelpful for that use case.

Seems like a classic chicken-and-egg situation where submodules have a 
bad reputation because some of the tooling is not up to the usual git 
standard, and then it doesn't get fixed because of that bad reputation. 
Oh well.


>> For us, in addition to avoiding the same hassles there's the question of
>> maintainability, and perhaps (with a huge load of optimism) getting the
>> closed source folks a bit more involved in the fact that there's another
>> world out here as well.
>
> The hassle comes from the fact that source tree's (instead of having
> libraries) directly shared between projects in the first place. So, the
> root is having a bad sw architecture.

I actually disagree about the architecture part. The pro and con 
arguments are fundamentally the same as in the mono-repo vs. multi-repo 
debate. If there were no legal (closed vs. open) and social obstacles, 
I'd say a monorepo is the technically correct solution for this 
particular case -- for basically the same reason(s) that the Linux 
kernel does that, by the way.


> Why can't we just solve the root problem instead of burning our time
> w/ workarounds ?
>
>
> By the way: just had a quick look into addrlib and found several
> defines which aren't used anywhere (in mesa):
>
> https://github.com/metux/mesa/commit/a38def1c9c6ac09c151399ec1f91b92a5fac3eb0
>
> Maybe there's another consumer for that, but then it would be private
> to him and therefore should be defined there.

Yes, there are some other things as well. I'm actually trying to get a 
process worked out here where we're better at that stuff. This thread is 
part of that :-)

Cheers,
Nicolai


>
>
> --mtx
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>