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. 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! 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! Regards Antonio
