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

[Felix Natter]

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]
>> +PKG_CHECK_MODULES([NCURSESW], [ncursesw])
>
> 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.

Why not try PKG_CHECK_MODULES, and use AC_CHECK_LIB/AC_CHECK_HEADER as a
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
(http://stackoverflow.com/questions/10220946/pkg-check-modules-considered-harmful):

"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
PKG_CHECK_MODULES."

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