[PATCHv9 01/15] submodule: add lwIP as git submodule

[Alper Nebi Yasak]

On 2023-09-21 18:39 +03:00, Tom Rini wrote:
> On Wed, Sep 20, 2023 at 07:03:07PM -0600, Simon Glass wrote:
>> Hi Maxim,
>>
>> On Thu, 14 Sept 2023 at 10:20, Maxim Uvarov <maxim.uvarov at linaro.org> wrote:
>>>
>>> add external lwIP library as a git submodule.

If we add submodules, they should point to mirrors on source.denx.de, in
case upstream repositories vanish.

>>
>> Oh dear...what is the motivation for using a submodule?
> 
> That we don't have a better alternative.  Using "git subtree" has it's
> own problems and won't make things overall better.

I need to raise a technical concern here, buildman uses "git worktree"
to save disk space (provides git functionality in .bm-work source copies
without copying .git into N such dirs), and there's this warning in the
git-worktree(1) manual page:

 Multiple checkout in general is still experimental, and the support for
 submodules is incomplete. It is NOT recommended to make multiple
 checkouts of a superproject.

It's been there for a while, and I don't know what the current status
is. But if we decide to add submodules we'll most likely need to rework
some stuff in buildman to support that.

Besides that, I've been running into git submodule problems in other
projects and don't like it at all. It doesn't seem to play nice with
even fundamental git features/commands like git pull and git checkout.

>> Our current stack is nicely integrated into U-Boot. This would make
>> moving between development branches much more painful.
> 
> It really shouldn't matter in that case.  Unless you're trying out a new
> lwip upstream commit, nothing changes in there.  It _may_ mean that if
> we want to update lwip it's not something that can be staged first in
> the -next branch but instead something to pull in just after release,
> but I'd need to see how smart or not git is today about things like
> that.
> 
>> I would much prefer that we bring in the necessary code, and that you
>> send a patch every 3 months or so to deal with updates, making sure
>> there are no code-size regressions.
> 
> And I much prefer something that will make sure that we don't start
> making changes in upstream code and diverging.  I don't think there's a
> mechanic short of submodule that will do that for us.

Coreboot clones some payload repositories in Makefiles (although they
use submodules a lot as well). Another alternative is having buildman
manage external sources like how binman can download sources and build
the tools it needs. Or maybe just assume the source already exists at
../lwip/ or $LWIP_SOURCE and raise an error if we can't find it there.

I admit these might sound worse than git submodules, but at least any
problems with them will be our fault and would be solvable in U-Boot
instead of requiring a trip to upstream git.