On 25 February 2022 at 18:39, Tom Lee wrote:
| So the tiledb upstream sources include *pre-generated *capnproto sources
| that were generated using 0.8.0. The *update-serialization* target will
Indeed! I forgot about that. TileDB has a habit of (strongly) enforcing
third-party dependencies, that conflicts somewhat with Debian best practices
but is driven from cross-platform cross-OS multilanguage uses. Hard to fully
change.
| regenerate those sources for us using whatever version of capnproto is
| installed but that target doesn't run by default. So here I'm making
| *update-serialization* a dependency of tiledb_shared and tiledb_static to
| ensure it runs.
Very clever idea. I like it.
| It could also be achieved by modifying debian/rules to invoke the
| *update-serialization
| *target before running the main build if you'd prefer that, I was just
| trying to come up with something that upstream might be interested in to
| make future upgrades more straightforward for us.
The serialization format is quite important for TileDB as it governs the
interchange one _can_ do from our (Open Source, MIT licensed) TileDB library
and apps to the (not Open Source) TileDB Cloud service. That is conceivably a
key a feature for TileDB ("the company") though of course not a strict
functional requirement for the open source package. I also think CapnProto
might be reliably forward-compatible so I am interested in testing this with
0.9.1. Whether or not I get my colleagues to take such a patch "in the short
to medium term".
| Why a second variable TILEDB_UPDATE_SERIALIZATION? To cover the 'yes well
| > it
| > is 0.8.0 but you will live' case from allowing 0.9.1 in the new interval
| > spec
| > '++set(TILEDB_CAPNPROTO_VERSION 0.8.0...0.9.1)' ?
| >
|
| Again, by default *update-serialization *won't run so this option forces it
| to run by adding it as a dependency of tiledb_shared/tiledb_static.
Yup.
| Now, back to the patch: if it's not clear, the patch I sent you is
| something to be applied to the whole source repo, not something added to
| the quilt series. It's a patch that includes a patch, if you like. :)
| Should apply cleanly against 2.6.2-2 with *patch -p1
| <tiledb-capnproto-0.9.1.patch*:
It's entirely possibly I failed there.
Which is why I urged you to consider working in git. While we all grew up
with diff and patch and emailing stuff around (hey, the kernel effectively
still does, as does our BTS) I do have a preference for git pull/merge
requests. Can we try this here?
| tom@debian-bullseye-arm64:~/src/tiledb-2.6.2$ patch -p1
| <../tiledb-capnproto-0.9.1.patch
| patching file debian/control
| patching file debian/patches/capnp-0.9.1
| patching file debian/patches/series
| patching file debian/rules
| tom@debian-bullseye-arm64:~/src/tiledb-2.6.2$
Maybe I had a thinko and after running the above (as always with added
--dry-run and --verbose) I wasn't thinking all that clearly _and just copied
the whole outer patch including all patches to the debian/patches/ dir_.
I then "gave up" and patches by hand. That is what blew the build.
| Anyway, you don't have to use that if it's not working for you but the key
| changes were:
|
| 1. Add *capnproto (>= 0.8.0) *to the Build-Depends in debian/control
Yep
| 2. Set TILEDB_CAPNPROTO_VERSION to 0.8.0...0.9.1 (either directly in the
| configure step or via the cmake foo in my patch)
Yep
| 3. Invoke the *update-serialization* cmake target before building shared
| libraries (either right before the build step or via the cmake foo in my
| patch)
Yep
| You can skip the TILEDB_UPDATE_SERIALIZATION stuff if it's getting in the
| way.
Let me stash / save debian/changelog etc and try again in a bit.
Best, Dirk
--
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
