[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-libunistring] pkg-config support, please
From: |
Tim Ruehsen |
Subject: |
Re: [bug-libunistring] pkg-config support, please |
Date: |
Thu, 22 Jan 2015 17:17:05 +0100 |
User-agent: |
KMail/4.14.2 (Linux/3.16.0-4-amd64; KDE/4.14.2; x86_64; ; ) |
On Thursday 22 January 2015 23:52:14 Daiki Ueno wrote:
> Tim Ruehsen <address@hidden> writes:
> > Despite the criticisms, you simply give project maintainers an *option* to
> > use pkg-config. When you add the patch, nothing changes to existing
> > projects. And project maintainers who use libunistring can simply decide
> > if they want to use pkg-config or not.
> > Nothing changes for project libunistring maintainers. See it as an
> > extended
> > service for people who use libunistring.
>
> I know, but it is also a library's choice to encourage a standard way to
> detect the library by NOT supporting other ways.
>
> As a new maintainer recently inherited the project, I'd like to follow
> the existing direction if any (in this case, what Bruno would say).
>
> In other context, he pointed that pkg-config is not very good at
> cross-compiling:
> http://git.savannah.gnu.org/cgit/gettext.git/tree/gnulib-local/m4/libxml.m4#
> n36 and it still seems to be the case. One would need to maintain a
> separate pkg-config database per target platform.
Many projects have template files for different target platforms.
So what is the point ?
If you don't want to have these, just turn pkg-config off for your special
case.
> > We introduced pkg-config to Wget a while ago because distribution
> > maintainers asked for it. They said, it would make their life much
> > easier.
>
> But it could make other developers' life difficult. As Werner says,
> pkg-config is not standardized and it is not available in some cases,
> even though it is de-facto.
Please don't try to tell other people what is good for them and what not.
Werner is absolutely wrong with this point.
(Tomorrow, Werner tries to tell me what I should eat and what not, brrrr.)
If pkg-config is not available, your fallback comes into play (in
configure.ac).
> >> By the way, for your use-case, perhaps libunistring.m4 in Gnulib might
> >> help. It looks self-contained and you could just copy it into the m4
> >> directory and call gl_LIBUNISTRING from configure.ac:
> >> http://git.savannah.gnu.org/cgit/gnulib.git/tree/m4/libunistring.m4
> >
> > Thank you to point this out.
> > Of course I would like to offer a consistent way to change library and
> > include paths for all libraries that my project uses. How can I explain
> > that changing these for libunistring is completely different than for
> > other libraries (that support pkg-config) ?
>
> There are several other libraries which choose that way:
>
> $ grep AM_ /usr/share/aclocal/*.m4 | grep DEFUN
>
> and I think it's sometimes more flexible than pkg-config, like this
> case.
Again, pkg-config is meant as an *option*. Nobody is forced to use it, just
because you provide a *.pc file.
But thank you for thinking about it.
I am out.
Tim
- [bug-libunistring] pkg-config support, please, Tim Ruehsen, 2015/01/21
- Re: [bug-libunistring] pkg-config support, please, Daiki Ueno, 2015/01/21
- Re: [bug-libunistring] pkg-config support, please, Tim Ruehsen, 2015/01/22
- Re: [bug-libunistring] pkg-config support, please, Daiki Ueno, 2015/01/22
- Re: [bug-libunistring] pkg-config support, please,
Tim Ruehsen <=
- Re: [bug-libunistring] pkg-config support, please, Jim Meyering, 2015/01/22
- Re: [bug-libunistring] pkg-config support, please, Simon Josefsson, 2015/01/22
- Re: [bug-libunistring] pkg-config support, please, Paolo Bonzini, 2015/01/23
- Re: [bug-libunistring] pkg-config support, please, Daiki Ueno, 2015/01/23