From: Andrea Claudi <aclaudi@redhat.com>
To: Phil Sutter <phil@nwl.cc>,
netdev@vger.kernel.org, stephen@networkplumber.org,
dsahern@gmail.com, bluca@debian.org, haliu@redhat.com
Subject: Re: [PATCH iproute2 v4 0/5] configure: add support for libdir and prefix option
Date: Fri, 8 Oct 2021 18:19:44 +0200 [thread overview]
Message-ID: <YWBvoFW1RDQDYAGx@renaissance-vector> (raw)
In-Reply-To: <20211008135025.GM32194@orbyte.nwl.cc>
On Fri, Oct 08, 2021 at 03:50:25PM +0200, Phil Sutter wrote:
[...]
> > This avoid the endless loop and allows configure to terminate correctly,
> > but results in an error anyway:
> >
> > $ ./configure --include_dir
> > ./configure: line 544: shift: shift count out of range
>
> Ah, I didn't see it with bash. I don't think it's a problem though:
> Input is invalid, the loop is avoided and (depending on your patches)
> there will be another error message complaining about invalid $INCLUDE
> value.
>
Yes, this error can be disregarded. Still I would try to avoid a
meaningless error message, if possible.
[...]
>
> Which sounds like you'll start accepting things like
>
> | ./configure --include_dir foo bar
>
We already accept things like this in the current configure, and I would
try to not modify current behaviour as much as possible.
[...]
> > > Can't you just:
> > >
> > > | [ -n "$PREFIX" ] && echo "PREFIX=\"$PREFIX\"" >>config.mk
> > > | [ -n "$LIBDIR" ] && echo "LIBDIR=\"$LIBDIR\"" >>config.mk
> > >
> > > and leave the default ("?=") cases in Makefile in place?
> > >
> > > Either way, calling 'eval' seems needless. I would avoid it at all
> > > costs, "eval is evil". ;)
> >
> > Unfortunately this is needed because some packaging systems uses
> > ${prefix} as an argument to --libdir, expecting this to be replaced with
> > the value of --prefix. See Luca's review to v1 for an example [1].
> >
> > I can always avoid the eval trying to parse "${prefix}" and replacing it
> > with the PREFIX value, but in this case "eval" seems a bit more
> > practical to me... WDYT?
>
> Do autotools support that? If not, I wouldn't bother.
I don't know about autotools, but Debian packaging system makes use of
this, and we cannot break their workflow.
Regards,
Andrea
next prev parent reply other threads:[~2021-10-08 16:19 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-07 13:40 [PATCH iproute2 v4 0/5] configure: add support for libdir and prefix option Andrea Claudi
2021-10-07 13:40 ` [PATCH iproute2 v4 1/5] configure: fix parsing issue on include_dir option Andrea Claudi
2021-10-07 13:40 ` [PATCH iproute2 v4 2/5] configure: fix parsing issue on libbpf_dir option Andrea Claudi
2021-10-07 13:40 ` [PATCH iproute2 v4 3/5] configure: support --param=value style Andrea Claudi
2021-10-07 13:40 ` [PATCH iproute2 v4 4/5] configure: add the --prefix option Andrea Claudi
2021-10-07 13:40 ` [PATCH iproute2 v4 5/5] configure: add the --libdir option Andrea Claudi
2021-10-07 16:02 ` [PATCH iproute2 v4 0/5] configure: add support for libdir and prefix option Phil Sutter
2021-10-08 13:08 ` Andrea Claudi
2021-10-08 13:50 ` Phil Sutter
2021-10-08 16:19 ` Andrea Claudi [this message]
2021-10-09 23:45 ` David Ahern
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YWBvoFW1RDQDYAGx@renaissance-vector \
--to=aclaudi@redhat.com \
--cc=bluca@debian.org \
--cc=dsahern@gmail.com \
--cc=haliu@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=phil@nwl.cc \
--cc=stephen@networkplumber.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.