From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 01274C10F14 for ; Wed, 17 Apr 2019 02:53:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C19162075B for ; Wed, 17 Apr 2019 02:53:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728960AbfDQCxh (ORCPT ); Tue, 16 Apr 2019 22:53:37 -0400 Received: from vulcan.kevinlocke.name ([107.191.43.88]:51782 "EHLO vulcan.kevinlocke.name" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727063AbfDQCxh (ORCPT ); Tue, 16 Apr 2019 22:53:37 -0400 Received: from kevinolos (unknown [71.15.201.20]) (Authenticated sender: kevin@kevinlocke.name) by vulcan.kevinlocke.name (Postfix) with ESMTPSA id EB0FFE9FA36; Wed, 17 Apr 2019 02:53:35 +0000 (UTC) Received: by kevinolos (Postfix, from userid 1000) id BE2E113003AD; Tue, 16 Apr 2019 20:53:33 -0600 (MDT) Date: Tue, 16 Apr 2019 20:53:33 -0600 From: Kevin Locke To: "John W. Linville" Cc: netdev@vger.kernel.org, Jesse Brandeburg Subject: Re: [PATCH v2] ethtool: Add bash-completion script Message-ID: <20190417025333.GA28674@kevinolos> Mail-Followup-To: Kevin Locke , "John W. Linville" , netdev@vger.kernel.org, Jesse Brandeburg References: <4dedb8b19e812805abdd4ffbdfddac5df755b8a5.1555004349.git.kevin@kevinlocke.name> <20190416183714.GA14097@tuxdriver.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190416183714.GA14097@tuxdriver.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Tue, 2019-04-16 at 14:37 -0400, John W. Linville wrote: > Overall, it looks good to me. But when I build with "make distcheck", > I get this output: > > [...] > > It looks like somewhere you are using "$(bashcompletiondir)" instead of > "$(DESTDIR)$(bashcompletiondir)", but I can't seem to find it. Perhaps > you can find the change required to avoid this build error? Thanks for taking a look at it! Good catch. DESTDIR would have been my guess as well. Interestingly, the issue is that make distcheck expects `./configure --prefix=foo && make install` to only install files below foo, which fails because --with-bash-completion-dir defaults to `pkg-config --variable=completionsdir bash-completion` (usually /usr/share/bash-completion/completions). I can think of a few different ways to fix this: 1. Add =--without-bash-completion-dir or --with-bashcompletiondir=$something to DISTCHECK_CONFIGURE_FLAGS in Makefile.am to avoid installing the script during distcheck. 2. Replace the prefix for bash-completion (using `pkg-config --variable=prefix bash-completion`) in $bashcompletiondir with --prefix passed to configure. 3. Stop using pkg-config and install to $datadir/bash-completion/completions by default. Option 1 has the disadvantage that users may not expect files to be installed outside of --prefix, that the script does not install to /usr/local (with everything else) by default, and that --with-bash-completion-dir= must be passed for non-root installs. kmod passes --with-bashcompletiondir=$$dc_install_base/$(bashcompletiondir) to DISTCHECK_CONFIGURE_FLAGS, which has the additional disadvantage of using the undocumented (AFAICT) Automake $$dc_install_base variable. Options 2 and 3 have the disadvantage that passing --prefix= which is not the prefix of $XDG_DATA_HOME or $XDG_DATA_DIRS will install the script to a directory that bash-completion doesn't use. Option 3 has the additional disadvantage of ignoring the upstream recommendations, which could install the script to a directory not used by bash-completion for customized or future versions. It has the advantage of being extremely simple and understandable. My personal preference is #2, but I would defer to your judgement. Let me know which you would prefer and I'll update the patch. Best, Kevin P.S. I noticed that the PKG_CHECK_MODULES macro does unnecessary work handling BASH_COMPLETION_CFLAGS and BASH_COMPLETION_LIBS and adds them to the configure --help text, so I will remove it in favor of calling $PKG_CONFIG directly, unless you object.