Hi,
On Wed, 13 Sept 2023 at 07:35, Maxim Uvarov maxim.uvarov@linaro.org wrote:
On Wed, 13 Sept 2023 at 19:14, Tom Rini trini@konsulko.com wrote:
On Wed, Sep 13, 2023 at 11:06:13AM +0100, Peter Robinson wrote:
Then if for development you need to pull he history of lwip, you can do it with: git pull -s subtree lwip master --allow-unrelated-histories (but I think nobody will need this.)
New update of the lwip net/lwip/lwip-external dir will be done with: git pull -s subtree lwip master --allow-unrelated-histories --squash Squash commit also has to be git format-patch friendly.
If you are ok with that proposal I will send v9 with the first patch created with steps above.
We've gone through this before. The whole purpose of this is not having to maintain patches. Simon, instead of "I had problems in the past", can you elaborate a bit more?
Tom said he is fine with subtrees instead of submodules and I know for a fact EDK2 doesn't have too many issues with submodules. Their documentation is pretty clear on building and requires
git clone https://github.com/tianocore/edk2.git cd edk2 git submodule update --init
Perhaps the situation has improved since you had issues?
Nope.
While I don't really care how you solve this technically, I'd *strongly* be interested for U-Boot to use *unmodified* lwIP sources where an explicit reference to an lwIP commit is used. I'd rather integrate bugfixes for U-Boot into lwIP than having the sources drift apart.
Strongly agree here, we want to use upstream and all the combined development and reviews etc rather than forking off and ending up with yet another slightly different IP stack. The whole advantage of adopting LWIP is the advantage of combined security, features and bugs from a wide range of projects :-)
Yes, this is what I want as well, and why I'm perhaps more agreeable with the approaches where it's a lot harder for us to start forking things unintentionally. I gather submodule rather than subtree would be better for that case?
-- Tom
Yes, submodule will be a much better solution for us. And I also don't think that today there are any issues with submodules. It works well of OE, RPM and DEB builds, distributions should not have problems with it.
My particular experience is with coreboot. Some problems I have:
1. Updating the modules doesn't work and I need to reset, try the --init thing, fetch things manually, etc. etc. 2. In ChromiumOS coreboot we can't use submodules internally since each package has its own build script. E.g. we need to build coreboot separately from its blobs, fsp, external libraries, etc. At least there we can do this, but if U-Boot adopts a submodule for a core feature, this is going to create no end of problems. 3. It makes it impossible to patch lwip for any fix we need for a release 4. We still have to 'fast forward' to a new commit every now and then, which really is no easier than doing a merge commit for the changes since the last sync, is it?
Really, we need a maintainer for the lwip piece, if we are to adopt it. Using submodules is not a substitute for that.
Regards, Simon