Compilation failure, cnkalman can't generate it's header files
PureTryOut opened this issue · 15 comments
Can't generate /home/bart/Documents/Git/alpine/aports/community/libsurvive/src/libsurvive-1.0/src/./generated/common_math.gen.h -- /home/bart/Documents/Git/alpine/aports/community/libsurvive/src/libsurvive-1.0/libs/cnkalman
Can't generate /home/bart/Documents/Git/alpine/aports/community/libsurvive/src/libsurvive-1.0/src/./generated/kalman_kinematics.gen.h -- /home/bart/Documents/Git/alpine/aports/community/libsurvive/src/libsurvive-1.0/libs/cnkalman
Can't generate /home/bart/Documents/Git/alpine/aports/community/libsurvive/src/libsurvive-1.0/src/./generated/lighthouse_model.gen.h -- /home/bart/Documents/Git/alpine/aports/community/libsurvive/src/libsurvive-1.0/libs/cnkalman
Can't generate /home/bart/Documents/Git/alpine/aports/community/libsurvive/src/libsurvive-1.0/src/./generated/imu_model.gen.h -- /home/bart/Documents/Git/alpine/aports/community/libsurvive/src/libsurvive-1.0/libs/cnkalman
fatal: not a git repository (or any parent up to mount point /home/bart/Documents/Git/alpine/aports/community/libsurvive)
Note that this is while building an Alpine Linux package. The lib is pulled in as a tarball directly from GitHub and is thus indeed not a Git repository. I'm not sure why it should be anyway.
Also please vendor the used cnkalman and cnmatrix used by the 1.0 release of libsurvive.
I'll fix the output; the generate warnings are fine -- those files are checked in so not everyone needs to be set up for it.
The error is caused by script that tries to embed the GIT describe in the build. I'll fix that; but what is the easiest way to pass in the version slug from your end? This shows up in the log / --help / etc.
Also please vendor the used cnkalman and cnmatrix used by the 1.0 release of libsurvive.
Not sure what you mean by this?
Is the version not set in a file somewhere? Like CMakeLists.txt normally holds the version number of a project. Otherwise I suppose some CMake variable I can set will do.
Not sure what you mean by this?
To get the source of libsurvive I now download the automatically generated tarball from GitHub, https://github.com/cntools/libsurvive/archive/refs/tags/v1.0.tar.gz. That however only includes the libsurvive source, not any of the submodules. So right now I'm also downloading cnkalman and cnmatrix manually and then moving them into the right place.
With "vendoring" I mean upload a tarball to the git tag/release that includes cnkalman and cnmatrix in the right places already. Just a "big" tarball with everything it needs to compile, except system dependencies.
CMake does usually but its also useful to have the exact commit id to know exactly which version you are looking at so I just piped in git describe. Not saying thats ideal; but the big win there is knowing from a log someone sends which version they are running.
https://github.com/cntools/libsurvive/actions/runs/1803406249 <--- does that not do what you want?
I pushed an alternative way to grab version -- VERSION file -- and manually went and downloaded, extracted and built it. Should be functional but I also tried to see what was breaking it originally and it showed that 'fatal' message but completed the build so if something hard errored in cmake it still might be broken.
Feel free to append / modify that VERSION file with alpine specific packaging details if appropriate. That file gets read in at time of build to do the version stamp.
https://github.com/cntools/libsurvive/actions/runs/1803406249 <--- does that not do what you want?
It does but I expected that artifact to be uploaded to the GitHub release/tag, it's the usual way to find such things. Also I rather have the commit hash out of the artifact name so url's are more predictable.
For example in our build script we set pkgver=1.0 and then use source="https://github.com/cntools/libsurvive/archive/$pkgver.tar.gz as the source url to download the tarball from. That url will have to be changed to the artifact but since we use version 1.0, we don't know what commit that is in packaging. I can add it but it would be more manual work while updating and ultimately unnecessary as with "1.0" you already know which commit you're running: the one pointing to the 1.0 release.
That VERSION file should just be in the root of the repository? I can put 1.0 there of course but like I said, no commit hash.
It does but I expected that artifact to be uploaded to the GitHub release/tag, it's the usual way to find such things. Also I rather have the commit hash out of the artifact name so url's are more predictable.
This was the intention but the action was missing a step, so it failed on the release rev
That VERSION file should just be in the root of the repository? I can put 1.0 there of course but like I said, no commit hash.
It is generated and added to the source bundle. I added a bundle to the v1.0 page that should mimic what it'll do in future revs. Its slightly off since its v1.0.4 on the v1.0.0 release page but it should be enough to see if this is more in line with what you were expecting.
Thanks! the -4 in the name but actual release being 1.0 is a bit weird but I can live with that, this does the job!
I'll ignore the error I mentioned in the OP then, now I just need cntools/cnkalman#2 merged/included before I can finish the package upgrade.
Can you check https://github.com/cntools/libsurvive/actions/runs/1816862794 and see if that all works for you? If it does I'll make another release to rekick everything.
In theory the commit id should not be part of the name if it's the exact commit of the tag so I think your script will work for it
I'm closing this since the initial bug is fixed but feel free to keep working the build process here. Once you confirm that that zip file works well for you I'll rev the release
That seems to work 👍 Still a bit strange that it's 1.0-6 vs 1.0.6 but it's doable 😉
Also our build system prints out >>> ERROR: libsurvive*: driver_vive.so: path not found.
The resulting library seems to work though, not sure.
I'm not sure what would cause that issue. Are you sure it's loading the vive driver in the package after that? The library will run if the vive driver isn't there but won't be useful to many people
It's been a while since I've ran libsurvive but 1.01 behaves no differently than 0.4 did for me.
That is: not usable but seemingly no path issues either.
$ survive-cli
Info: Adding tracked object KN0 from HTC
Info: Adding tracked object T20 from HTC
Info: Adding tracked object KN1 from HTC
Info: All enumerated devices attached.
Warning: Could not claim interface 0 of Knuckles: -6 LIBUSB_ERROR_BUSY
Info: Error: cannot open device "Knuckles" with vid/pid 28de:2102 error -6 (LIBUSB_ERROR_BUSY)
Warning: Could not claim interface 0 of Tracker (2018): -6 LIBUSB_ERROR_BUSY
Info: Error: cannot open device "Tracker (2018)" with vid/pid 28de:2300 error -6 (LIBUSB_ERROR_BUSY)
Warning: Could not claim interface 0 of Knuckles: -6 LIBUSB_ERROR_BUSY
Info: Error: cannot open device "Knuckles" with vid/pid 28de:2102 error -6 (LIBUSB_ERROR_BUSY)
Info: Powered unit on.
Info: Cleaning up interface on 3 IMU/Lightcap/Buttons
Info: Cleaning up interface on 7 IMU
Info: Cleaning up interface on 11 Lightcap
Info: Cleaning up interface on 15 Buttons
Info: Cleaning up interface on 3 IMU/Lightcap/Buttons
This is with a Valve Index with the standard Knuckles controllers.
https://github.com/cntools/libsurvive#getting-started
that should fix udev. You can also run as root to test. But either way, this means driver_vive is there so I think its good
That isn't the problem, I have been shipping those udev files from the start 😉 And I did already try with root, made no difference.
The error doesn't suggest it's a permission issue either
Note: I occasionally get the LIBUSB_ERROR_BUSY. I can get it in the cli (as root) consistently. Then I can close the web view, and run the cli and it avoids the issue. Similarly, running survive-cli first, then the web view causes the web view to get the LIBUSB_ERROR_BUSY.
So I think it has something to do with the logic after connect/disconnect