On Sun, 2024-06-23 at 10:27 +0200, Antonio Borneo wrote: > > On Sat, Jun 22, 2024 at 9:20 AM Marc Schink <d...@zapb.de> wrote: > > A more general question: what is the reason for integrating jimtcl > > as a > > submodule in the first place? According to repology it seems to be > > widespread. We deprecated the libjaylink submodule, what is the > > reason > > to keep jimtcl? > > I'm not aware of the reason for this; I was not contributing to > OpenOCD at that time. > I can imagine it was 'comfortable' to build OpenOCD without relying > on installed dependencies. > Git log show that: > - 2009-10-28 added tools/git2cl > - 2010-10-29 added jimtcl > - 2015-11-26 added src/jtag/drivers/libjaylink (your commit dated > 2014-10-20) > > Personally, I use a lot 'git worktree', which unfortunately is not > well integrated with 'git submodule'. > Each worktree has to keep an independent out-of-sync clone of each > submodule, which is completely crap! (it's also a waste of disk > space). > > I'm aware of few ACI that don't use OpenOCD submodules in order to > prevent the build server from accessing the network. >
Yes, I had to deploy OpenOCD in an environment without internet access recently. Git submodules are not helpful here too ;D > Then: > - libjaylink is already present as an independent package in several > Linux distributions. I have no concern about keeping it as an > external dependency. > > - jimtcl package instead is not so popular. In Arch Linux it is in > AUR only. But this would change if we force it as an external > dependency. > > - git2cl is only used for OpenOCD releases. We could keep it as a > submodule and change the default of bootstrap to no-submodule. > git2cl is apparently not maintained anymore, so it could even be > copied in our code, but since it's GPL2.0-only I prefer keeping it > outside! Where do we actually use git2cl? The ChangeLog file (also in releases) is "empty" and we have a seperate (manually generated) NEWS file anyway. > I would suggest to progressively drop the submodules to see what the > feedback is. > - libjaylink submodule would be deprecated in v0.13.0. Would it be > dropped in v0.14.0? > - jimtcl submodule could be deprecated in v0.14.0 and dropped later > on. > - git2cl submodule could remain, but with bootstrap defaulting to no- > submodule already in v0.14.0. > Or, we could be more aggressive by also deprecating jimtcl submodule > in v0.13.0! Yes, I would prefer to deprecate jimtcl already in 0.13.0 if no one comes up with a good reason why we should wait for the next release. I will prepare some commits. Best regards, Marc
