https://sourceware.org/bugzilla/show_bug.cgi?id=25509
--- Comment #17 from Mark Wielaard <mark at klomp dot org> --- Just to be clear, the current setup is: --enable-debuginfod or --enable-debuginfod=yes: builds all debuginfod server/client artifacts (requires libcurl) --disable-debuginfod or --enable-debuginfod=no: builds none of the debuginfod server/client artifacts. The proposed patch introduces: --enable-libdebuginfod or --enable-libdebuginfod=yes: builds the debuginfod client artifacts --disable-libdebuginfod or --enable-libdebuginfod=no: don't build the debuginfod client artifacts --enable-libdebuginfod=dummy: builds all debuginfod clients artifacts, but the libdebuginfod.so is just a stub (does not depend on libcurl). --enable-debuginfod or --enable-debuginfod=yes: builds all debuginfod server artifacts (requires either --enable-libdebuginfod=yes or --enable-libdebuginfod=dummy and sqlite3, microhttpd, libarchive) --disable-debuginfod or --enable-debuginfod=no: build none of the debuginfod server artifacts. I am hoping that helps both the Suse use case which would like a bootstrap/dummy libdebuginfod.so (--enable-libdebuginfod=dummy --disable-debuginfod) and the Arch use case which is to only have the client library, but not the debuginfod server (--enable-libdebuginfod --disable-debuginfod). I admit that having the combination --enable-libdebuginfod=dummy and --enable-libdebuginfod is somewhat redundant/non-sensical, but it helps with (build time) testing. Other testing matrix would imho be as complicated (you'll get extra install flags or need to setup compile time or runtime environment variables). -- You are receiving this mail because: You are on the CC list for the bug.
