NishanthMenon changed the topic of #openocd to: this is the place to discuss all things OpenOCD | Logs: https://libera.irclog.whitequark.org/openocd/
tlwoerner has quit [Quit: Leaving]
tlwoerner has joined #openocd
zear has quit [Server closed connection]
zear has joined #openocd
polprog has quit [Server closed connection]
polprog has joined #openocd
Guest8044 has quit [Server closed connection]
Guest8044 has joined #openocd
Hawk777 has joined #openocd
drath42 has quit [Server closed connection]
drath42 has joined #openocd
key2 has quit [Server closed connection]
key2 has joined #openocd
nerozero has joined #openocd
Hawk777 has quit [Quit: Leaving.]
gpol has quit [Remote host closed the connection]
gpol has joined #openocd
dnm has quit [Server closed connection]
dnm has joined #openocd
nathanhi has quit [Server closed connection]
nathanhi has joined #openocd
jn_ is now known as jn
sevan has joined #openocd
stefanct has quit [Server closed connection]
stefanct has joined #openocd
<borneoa___> PaulFertser: hi, would you please have a look at 8380 and also 8382? Deprecating jimtcl as submodule is not possible with current Jenkins setup. It's not urgent, but should be properly addressed
<PaulFertser> borneoa___: sure, we talked briefly with zapb_ about it, I think he wanted to think about the way forward.
<PaulFertser> borneoa___: do we need compatibility with code that still has it as submodule or can we just make a switch at one point?
<borneoa___> PaulFertser: once a distro will take OpenOCD v0.13.0, it will also take jimtcl as package (or will still build with submodules?). But in the meantime I would keep the option of submodules, and eventually drop them with 0.14.0.
<borneoa___> PaulFertser: but if this gets overly complicated, then let's switch immediately
<PaulFertser> borneoa___: ok, will keep that in mind.
<zapb_> borneoa___, PaulFertser I would suggest to mark it as deprecated in 0.13 and drop in 0.14 as libjaylink
<zapb_> The same should be done with git2cl IMO
<zapb_> (not sure why we need a copy of the Git log :D)
<PaulFertser> :) agreed
<zapb_> PaulFertser, I've tested the Patches with jimtcl built as shared library with the 0.82 tag
<zapb_> So the first steop whould be to install jimtcl from Git on the Jenkins server
<borneoa___> PaulFertser: I think we need jimtcl installed in Jenkins as first step to build there correctly. I don't think we should test the build with either submodules and package, no need to increase the build coverage and the build time
<borneoa___> PaulFertser: which debian is used in Jenkins? (you already wrote here few days ago). Maybe just install the default jimtcl package, not the latest version
<zapb_> borneoa___, there is not package unfortunately
<zapb_> That's why I built it from Git
<zapb_> s/not/no
<zapb_> borneoa___, +1 for not testing the submodule anymore
<borneoa___> zapb_: PaulFertser wrote debian 11, which has jimtcl 0.79
<borneoa___> zapb_: that's accordingly to repology.org ...
<zapb_> borneoa___, yes, but IIRC they do not ship a shared library
<zapb_> Let me check again what the problem was....
<borneoa___> zapb_: it's in package libjim-dev
<zapb_> borneoa___, is 0.79 sufficient?
<borneoa___> zapb_: I have tried to keep the backward compatibility for devs that want to use the jimtcl package of their distro. 0.78 is broken, but >=0.79 should be ok. Check my comment in your 8383
<borneoa___> zapb_: then, I think we can move to support only a more recent jimtcl once v0.13.0 is out
<zapb_> borneoa___, ah, I think the problem was that they do not ship a pkg-config file
<borneoa___> zapb_: I just noticed it too. It's not in the debian package... Shit
<zapb_> But this is probably a bug because it is generated in 0.79 (Git)
zjason` is now known as zjason
<borneoa___> The file jimtcl.pc.in was added in 0.78. it's the package manager of the distro that failed to add it
<borneoa___> Also arch Linux on AUR does not provide support for pkg-config for jimtcl
<borneoa___> zapb_: I think we need to change the check and skip pkg-config. Instead, we should look for jim.h installed in the system
<borneoa___> zapb_: I mean, installed in the default system folders
<zapb_> borneoa___, don't you think they will add/fix it once they notice?
<zapb_> I mean it's definitively a bug, there is no reason to not ship it
<borneoa___> zapb_: AC_CHECK_HEADERS and in case the header is missing, look for pkg-config
<zapb_> borneoa___, thanks, will test it
<borneoa___> I'm not sure it is a bug. I see few other libraries that do not have pkg-config files in my arch linux
<borneoa___> Both jim.h and libjim.so are installed in the default folders, so compiler, linker and loader are able to find them without pkg-config.
<borneoa___> zapb_: maybe better running the opposite; first check if pkg-config knows jimtcl and use it's output; in case of failure test jim.h at default; then configure error.
nerozero has quit [Ping timeout: 246 seconds]
bryanb has quit [Server closed connection]
bryanb has joined #openocd
xantoz has quit [Server closed connection]
xantoz has joined #openocd
cyrozap has quit [Server closed connection]
cyrozap has joined #openocd
sevan has quit [Changing host]
sevan has joined #openocd
<zapb_> borneoa___, yep, I had the same idea, run pkg-config first, if jimtcl is not found raise a warning (?) and check for jim.h, if not found error
<zapb_> borneoa___, why would one **not** ship pkg-config files that are part of a library?
gruetzkopf has quit [Server closed connection]
gruetzkopf has joined #openocd