On Wed, Aug 14, 2024 at 01:50:24PM +0200, Helmut Grohne wrote:
> How about separating the availability of libarchive from the interest in
> supporting libarchive? Since it is runtime-loaded using dlopen,
> e2fsprogs already carries the prototypes for most libarchive functions
> and doesn't actually need to #include them. What it does not yet do is
> carry forward declarations "struct archive;" and "struct
> archive_entry;". Adding these would likely allow building e2fsprogs with
> libarchive support, but without using libarchive-dev at build time. Of
> course #including it is a good idea to locate problems, so in the common
> case, we'd want to actually use it. What I am effectively proposing here
> is adding another --with-libarchive value that should produce the same
> binary result as --with-libarchive=yes (dlopen), but work without any
> access to libarchive headers. Then, libarchive-dev could be annotated
> <!nocheck> and all regular builds would remain unchanged.
This only passes the "it builds, ship it!" test, but it appears that
it might be enough to replace
#include <archiveh.h>
#include <archive_entry.h>
with something like this:
#ifdef HAVE_ARCHIVE_H
#include <archiveh.h>
#include <archive_entry.h>
#else
struct archive;
struct archive_entry;
#define ARCHIVE_EOF 1 /* Found end of archive. */
#define ARCHIVE_OK 0 /* Operation was successful. */
#include <unistd.h> /* ssize_t */
typedef ssize_t la_ssize_t;
#endif
so it's a bit more than definig the blind structures archive and
archive_entry. We'd also have to define ARCHIVE_EOF, ARCHIVE_OK, and
la_ssize_t. (The hack above will only work on Unix/Linux systems but
it would break on Windows.)
So yeah, I think your suggestion should be tractable. I'd prefer that
the debian/control file requires libarchive-dev be used to build if at
all possible, but I don't think we do something like this "Recommends:
libarchive". :-(
- Ted
