[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-gtypist] gtypist fails to build with ncurses[tinfo]

From: Felix Natter
Subject: Re: [bug-gtypist] gtypist fails to build with ncurses[tinfo]
Date: Sat, 28 Sep 2013 16:34:55 +0200
User-agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.4 (gnu/linux)

Tim Marston <address@hidden> writes:

> Hi Felix,

hi Tim,

> On Sat, Sep 14, 2013 at 12:54:34PM +0200, Felix Natter wrote:
>> the patch seems to be simple:
>> [snip]
> I don't think that it is going to be this simple, unfortunately.
> I checked with some GNU folks about the policy on using pkg-config and,
> while there is no problem with using pkg-config to *augment* the build
> process, we should make sure that gtypist can build without it.

Ok, makes sense.

> I believe that using PKG_CHECK_MODULES (in the way you are suggesting)
> would make GNU typist's build process dependent on pkg-config.  (There
> is an interesting discussion about it here[1].)  But we should be able
> to make gtypist build without using pkg-config at all...
> I haven't looked in to this properly, so the following ideas might be
> rubbish, but here are a couple of ideas that might work...
>   * It looks like we could add another AC_CHECK_LIB line that looks for
>     the cbreak function (which is in libtinfo, not libncurses, on
>     Gentoo, according to this[2]) and put tinfo as a fifth parameter.
>     This should cause it to look for cbreak in libncurses first, and
>     then libtinfo if it can't find it.  (See autoconf docs[4].)

Good idea, but I think the OP wanted us to specifically use pkg-config,
and I think it's the better solution because it's more general/stable.

>   * We also might be able to use AC_SEARCH_LIBS, as suggested here[3]
>     and in the autoconf docs[4].  Or we could also use AC_LINK_IFELSE
>     for the same purpose.
> I also found a discussion[5] suggesting that you can "invoke
> AC_CHECK_LIBS first, then conditionally invoke PKG_CHECK_MODULES, and
> then invoke AC_CHECK_LIBS again to validate the information found by
> PKG_CHECK_MODULES".  This sounds a lot more complicat       ed and (as far as
> I can see) only gives us the benefit of including pkg-config in the
> build process.  But since that's not really the goal here -- it was
> just a proposed solution -- I suggest we try one of the above first.

fallback? Ok, I realize that this a problem with systems using
pkg-config, but in a broken way (see [5]).

> [1] http://lists.gnu.org/archive/html/autoconf/2009-10/msg00132.html
> [2] https://bugs.gentoo.org/show_bug.cgi?id=483778
> [3] http://lists.gnu.org/archive/html/autoconf/2009-10/msg00149.html
> [4] 
> https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Libraries.html
> [5]
> http://stackoverflow.com/questions/10220946/pkg-check-modules-considered-harmful

Ok, now I see

"In short, to use PKG_CHECK_MODULES correctly, it is necessary to invoke
AC_CHECK_LIBS first, then conditionally invoke PKG_CHECK_MODULES, and
then invoke AC_CHECK_LIBS again to validate the information found by

But we only need to cover gentoo's pkg-config setup...

What do you think, shall I try the above solution (AC_CHECK_LIB(S),
PKG_CHECK_MODULES, AC_CHECK_LIB(S)) can you think of easier solution?

>> - src/Makefile.am contains the following header:
>> ## Process this file with automake to produce Makefile.in
>> #
>> #    NOTE:  this file will probably be changed by gettextize, so don't
>> #    commit changed version into CVS.
>> #
>> => is this still applicable?
> That's a very good question.  I don't know!  :o)  You could try to run
> gettextize and see what happens!

Good idea. I does not touch that file. I will remove that comment in the
next commit.

Best Regards,
Felix Natter

reply via email to

[Prev in Thread] Current Thread [Next in Thread]