From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16718 invoked by alias); 12 Nov 2019 21:59:28 -0000 Mailing-List: contact elfutils-devel-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: elfutils-devel-owner@sourceware.org Received: (qmail 16672 invoked by uid 89); 12 Nov 2019 21:59:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.3 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=partners X-Spam-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on sourceware.org X-Spam-Level: X-HELO: gnu.wildebeest.org Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (212.238.236.112) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 12 Nov 2019 21:59:26 +0000 Received: from tarox.wildebeest.org (tarox.wildebeest.org [172.31.17.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id AE10B3001768; Tue, 12 Nov 2019 22:59:24 +0100 (CET) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 6D0F04970340; Tue, 12 Nov 2019 22:59:24 +0100 (CET) Message-ID: Subject: Re: patch 1/2 debuginfod client From: Mark Wielaard To: "Frank Ch. Eigler" Cc: elfutils-devel@sourceware.org, amerey@redhat.com Date: Tue, 12 Nov 2019 21:59:00 -0000 In-Reply-To: <20191112151443.GA12710@redhat.com> References: <20191028190438.GC14349@redhat.com> <20191028190602.GD14349@redhat.com> <0bdee1935e9cce5e7ae6804d6d6335cf8ab97b7b.camel@klomp.org> <20191112151443.GA12710@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-5.el7) Mime-Version: 1.0 X-Spam-Flag: NO X-IsSubscribed: yes X-SW-Source: 2019-q4/txt/msg00125.txt.bz2 Hi Frank, On Tue, 2019-11-12 at 10:14 -0500, Frank Ch. Eigler wrote: > > My only concern is that these might slow down configure when > > debuginfod > > isn't enabled? Can/Should they be moved later after the enable > > test? >=20 > It'd be fractions of a second per configure run ... worth worrying > about? Probably not, but if it is easy to hide after the check, why not do it? Don't if it requires nasty trickery though. > > > +PKG_PROG_PKG_CONFIG > > > +AC_ARG_ENABLE([debuginfod], AC_HELP_STRING([--enable-debuginfod], [B= uild debuginfo server and client solib])) > > > +AS_IF([test "x$enable_debuginfod" =3D "xyes"], [ > > > + AC_DEFINE([ENABLE_DEBUGINFOD],[1],[Build debuginfo-server]) > > > + PKG_CHECK_MODULES([libmicrohttpd],[libmicrohttpd >=3D 0.9.33]) > > > + PKG_CHECK_MODULES([libcurl],[libcurl >=3D 7.29.0]) > > > + PKG_CHECK_MODULES([sqlite3],[sqlite3 >=3D 3.7.17]) > > > + PKG_CHECK_MODULES([libarchive],[libarchive >=3D 3.1.2]) > > > +], [enable_debuginfod=3D"no"]) > > > +AM_CONDITIONAL([DEBUGINFOD],[test "x$enable_debuginfod" =3D "xyes"]) > >=20 > > Would it be better to enable by default with an error to disable if any > > dependencies (and CXX compiler?) aren't found? >=20 > That's up to you as a policy question. We could keep it this way > (manually opt in) for this release to minimize build complications for > our non-rpm/intimate distro partners and then switch to opt-out the > later. I think it is better to enable it by default and error out when the dependencies aren't found. Just add an explicit notice that people can disable it when they don't want it. AC_MSG_NOTICE([checking debuginfod dependencies, disable to skip]) or something like that.=20 Thanks, Mark