All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Frysinger <vapier@gentoo.org>
To: "Rüdiger Meier" <sweet_f_a@gmx.de>
Cc: Karel Zak <kzak@redhat.com>,
	Carlos Santos <casantos@datacom.ind.br>,
	util-linux@vger.kernel.org
Subject: Re: Problem building util-linux without a separate ncursesw include dir
Date: Sat, 20 Jan 2018 21:49:12 -0500	[thread overview]
Message-ID: <20180121024912.GG15022@vapier> (raw)
In-Reply-To: <8f64924f-f89f-bc10-1be5-c8e64d2cdd12@gmx.de>

[-- Attachment #1: Type: text/plain, Size: 2554 bytes --]

On 20 Jan 2018 20:31, Rüdiger Meier wrote:
> On 01/20/2018 07:14 PM, Mike Frysinger wrote:
> > On 20 Jan 2018 18:50, Rüdiger Meier wrote:
> >> On 01/19/2018 07:21 PM, Mike Frysinger wrote:
> >>> On 19 Jan 2018 10:40, Karel Zak wrote:
> >>>> On Thu, Jan 18, 2018 at 09:47:17PM -0500, Mike Frysinger wrote:
> >>>>> why don't we just support ncurses's pkg-config files as the default ?
> >>>>> $ pkg-config --cflags ncurses
> >>>>> -D_GNU_SOURCE
> >>>>> $ pkg-config --cflags ncursesw
> >>>>> -D_GNU_SOURCE -I/usr/include/ncursesw
> >>>>
> >>>> because pkg-config is not supported by ncurses upstream by default and
> >>>> it's not always the best solution.
> >>>
> >>> you mean upstream's configure script doesn't default it to on.  distros
> >>> can (and many do) simply pass --enable-pc-files to get them.  but i don't
> >>> see how that's relevant to preference when it comes to detection.
> >>>
> >>>> See commit 4c12a334dc4104d16dc06edf51904b08b08fcdfa.
> >>>
> >>> seems like that's trivial to resolve with a compile test rather than
> >>> throwing it all out.  xxx-config scripts provide bad defaults when you
> >>> cross-compile because now the user has to make sure the build's copy
> >>> of ncurses-config don't get used.
> >>>
> >>>> The ncurses detection and variability in distros is horrible. We
> >>>> already tried all possible combinations and always someone complains
> >>>> about the way how we detect ncurses. See mailing list archive for more
> >>>> information.
> >>>
> >>> that's the point of pkg-config.  if someone is having problems because
> >>> they're doing something weird/non-standard, tell them to sort out their
> >>> pkg-config installs.
> >>
> >> non-standard is to have ncurses.pc installed.
> > 
> > that's a silly position to try to take.  you're claiming anything that isn't
> > turned on by default in `./configure` is non-standard ?
> 
> No, as you could have read I'm talking only about --enable-pc-files being non
> standard. Many distros and users are not using it

most distros are enabling it.  Debian & Fedora & openSUSE & Gentoo & ArchLinux
& OpenEmbedded OE and everything based on it are enabling them.  so it's the
common case now, and if that's what it requires for you define something
"standard", then it is standard now.

> and you can't just call them all stupid.

i didn't call anyone stupid.  don't put words in my mouth.

> We have to support this case first.

i didn't say to drop xxx-config usage.  i said it shouldn't come first.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2018-01-21  2:49 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-01  0:12 Problem building util-linux without a separate ncursesw include dir Carlos Santos
2017-08-01  0:46 ` Carlos Santos
2017-08-01  7:20   ` Karel Zak
2017-08-01 12:09     ` Carlos Santos
2017-08-01 12:44       ` Karel Zak
2017-08-01 22:10         ` Carlos Santos
2018-01-19  2:47     ` Mike Frysinger
2018-01-19  9:40       ` Karel Zak
2018-01-19 18:21         ` Mike Frysinger
2018-01-20 17:50           ` Rüdiger Meier
2018-01-20 18:14             ` Mike Frysinger
2018-01-20 19:31               ` Rüdiger Meier
2018-01-21  2:49                 ` Mike Frysinger [this message]
2018-01-20 21:01             ` Bruce Dubbs
2018-01-22  8:50       ` Karel Zak

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=20180121024912.GG15022@vapier \
    --to=vapier@gentoo.org \
    --cc=casantos@datacom.ind.br \
    --cc=kzak@redhat.com \
    --cc=sweet_f_a@gmx.de \
    --cc=util-linux@vger.kernel.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.