Re: [bug-libunistring] pkg-config

2018-02-22 Thread Daiki Ueno 
Nikos Mavrogiannopoulos  writes:

> I think it is reasonable to expect that pkg-config will not cover
> every use case possible, however it has its benefits on very common
> uses. The advantages that I see in libraries that use pkg-config:
>  1. The installed library can be determined by users on cmd in a cross
> platform way (i.e., using rpm in fedora/centos and dpkg in
> debian/ubuntu), as pkg-config --modver gnutls.
>  2. It makes it very easy to introduce conditional to version
> dependencies on configure scripts. If for example my code only works
> with cmocka 1.0.1 or later, I use:
>  PKG_CHECK_MODULES(CMOCKA, [cmocka >= 1.0.1], [with_cmocka=yes],
> [with_cmocka=no])
> The alternative, is writing programs in configure to check for
> specific functionality introduced in that version, or check for the
> absence of bugs, version numbers in headers, etc., depending on the
> library.
>  3. It provides a consistent method to override the system library.
> E.g, on the example with cmocka above, as user I can run
> 'CMOCKA_LIBS="-L/usr/local/lib -lcmocka2" ./configure' to override the
> default library shipped in the system.
>
> Overall, it may be a matter of taste. No-one is forced to use
> pkg-config, if they see no benefit. It would be great to have it for
> ones who see benefit in it, if it is not a big maintenance burden.

Thank you for the clarification.  As far as I can see, the only argument
against adding it is that we should not encourage our users to switch
over to the inferior method for linking with the library.

On the other hand, the recommended way mentioned in the manual is not
handier than pkg-config:
https://www.gnu.org/software/libunistring/manual/html_node/Autoconf-macro.html#Autoconf-macro

Perhaps, if we could improve this situation, e.g., by shipping the
autoconf macro in the distribution or by providing a traditional
*-config script that prints the precise linker configuration, it
wouldn't be a problem to add a pkg-config file as an alternative choice?

>> Thanks, your patch highlights two more reasons why pkg-config is broken:
>>
>>   3) When a user uses --prefix to install a library, the user who uses
>>  the library needs -Wl,-rpath,${LIBDIR} when linking - otherwise
>>  executables don't run.
>>  You perfectly highlighted this by omitting such an option from the
>>  'Libs' line.
>
> I do not see as an issue in pkg-config as the same result happens if
> not use. The 'rpath' in my opinion is something optional, and should
> not be forced upon by software (I may for example compile to run in a
> chroot environment, container etc.).

I agree.

>>   4) It cannot distinguish whether libtool is used to perform the linking
>>  or not. With libtool, one needs -R ${LIBDIR}. Without libtool,
>>  one needs -Wl,-rpath,${LIBDIR}.
>>  You perfectly highlighted this by choosing one of @LIBICONV@
>>  @LTLIBICONV@ in Libs.private. (The other choice would have been
>>  equally wrong.)
>
> My understanding is that, pkg-config is not supposed to contain
> libtool specific flags. It is expected to be used by any project
> whether compiled by libtool or not.

Indeed, I actually took it from libidn2.pc, which has:

  Libs.private: @LTLIBICONV@ @LTLIBUNISTRING@

However, this would also be simplified with:

  Requires.private: libunistring

if we could assume libunistring.pc installed on the system.

>> For completeness: Earlier, there was also a problem between pkg-config and
>> cross-compilation. I don't know whether this problem still exists.
>
> I'm relying on it for cross compilation on windows, and I'm not aware
> of any issues.

Me neither.

Regards,
-- 
Daiki Ueno

Re: [bug-libunistring] pkg-config

2018-02-13 Thread Nikos Mavrogiannopoulos 
On Mon, Feb 12, 2018 at 4:59 PM, Bruno Haible  wrote:
> Hi Daiki,
>
>> I remember there was a discussion about pkg-config support a few years
>> ago.  At that time I opposed to do that, because a similar library
>> detection mechanism is also provided by libunistring.m4.
>>
>> However, given the wider adoption of this library (even in non-autotools
>> projects), I reconsider adding it.
>>
>> What do people think?
>
> I still consider it an extremely bad idea. EACH time I had to deal with
> packages that require pkg-config in the past year, it reinforced my
> conviction how broken it is.
>
> The points that pkg-config gets wrong are:
>   1) It cannot support multiple compilers (e.g. building a library with
>  GCC and using it with SunPRO C on Solaris).
>   2) Users who install packages with --prefix need to manually set up
>  PKG_CONFIG_PATH environment variable (additionally to PATH and
>  --prefix).
>
>> The change itself would be trivial as attached.

I think it is reasonable to expect that pkg-config will not cover
every use case possible, however it has its benefits on very common
uses. The advantages that I see in libraries that use pkg-config:
 1. The installed library can be determined by users on cmd in a cross
platform way (i.e., using rpm in fedora/centos and dpkg in
debian/ubuntu), as pkg-config --modver gnutls.
 2. It makes it very easy to introduce conditional to version
dependencies on configure scripts. If for example my code only works
with cmocka 1.0.1 or later, I use:
 PKG_CHECK_MODULES(CMOCKA, [cmocka >= 1.0.1], [with_cmocka=yes],
[with_cmocka=no])
The alternative, is writing programs in configure to check for
specific functionality introduced in that version, or check for the
absence of bugs, version numbers in headers, etc., depending on the
library.
 3. It provides a consistent method to override the system library.
E.g, on the example with cmocka above, as user I can run
'CMOCKA_LIBS="-L/usr/local/lib -lcmocka2" ./configure' to override the
default library shipped in the system.

Overall, it may be a matter of taste. No-one is forced to use
pkg-config, if they see no benefit. It would be great to have it for
ones who see benefit in it, if it is not a big maintenance burden.

> Thanks, your patch highlights two more reasons why pkg-config is broken:
>
>   3) When a user uses --prefix to install a library, the user who uses
>  the library needs -Wl,-rpath,${LIBDIR} when linking - otherwise
>  executables don't run.
>  You perfectly highlighted this by omitting such an option from the
>  'Libs' line.

I do not see as an issue in pkg-config as the same result happens if
not use. The 'rpath' in my opinion is something optional, and should
not be forced upon by software (I may for example compile to run in a
chroot environment, container etc.).

>   4) It cannot distinguish whether libtool is used to perform the linking
>  or not. With libtool, one needs -R ${LIBDIR}. Without libtool,
>  one needs -Wl,-rpath,${LIBDIR}.
>  You perfectly highlighted this by choosing one of @LIBICONV@
>  @LTLIBICONV@ in Libs.private. (The other choice would have been
>  equally wrong.)

My understanding is that, pkg-config is not supposed to contain
libtool specific flags. It is expected to be used by any project
whether compiled by libtool or not.

> For completeness: Earlier, there was also a problem between pkg-config and
> cross-compilation. I don't know whether this problem still exists.

I'm relying on it for cross compilation on windows, and I'm not aware
of any issues.

regards,
Nikos

[bug-libunistring] pkg-config

2018-02-12 Thread Daiki Ueno 
Hello,

I remember there was a discussion about pkg-config support a few years
ago.  At that time I opposed to do that, because a similar library
detection mechanism is also provided by libunistring.m4.

However, given the wider adoption of this library (even in non-autotools
projects), I reconsider adding it.

What do people think?  The change itself would be trivial as attached.

Regards,
-- 
Daiki Ueno
>From e854631d5914680988c7a42a0c6a921d285b4072 Mon Sep 17 00:00:00 2001
From: Daiki Ueno 
Date: Mon, 12 Feb 2018 13:21:31 +0100
Subject: [PATCH] build: Add libunistring.pc

---
 ChangeLog  |  8 
 Makefile.am|  4 
 configure.ac   |  1 +
 libunistring.pc.in | 11 +++
 4 files changed, 24 insertions(+)
 create mode 100644 libunistring.pc.in

diff --git a/ChangeLog b/ChangeLog
index 563c6e6..87b0a4d 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2018-02-12  Daiki Ueno  
+
+	build: Add libunistring.pc
+	* libunistring.pc.in: New file.
+	* configure.ac: Generate libunistring.pc.
+	* Makefile.am (pkgconfigdir): New.
+	(pkgconfig_DATA): Install libunistring.pc.
+
 2018-02-02  Bruno Haible  
 
 	Update after gnulib changed.
diff --git a/Makefile.am b/Makefile.am
index fd39e47..3269f44 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -39,3 +39,7 @@ EXTRA_DIST += woe32dll/export.h
 # Windows support.
 
 EXTRA_DIST += INSTALL.windows build-aux/windres-options
+
+
+pkgconfigdir = $(libdir)/pkgconfig
+pkgconfig_DATA = libunistring.pc
diff --git a/configure.ac b/configure.ac
index 38fe5dd..9ccafd6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -156,4 +156,5 @@ AC_CONFIG_FILES([lib/exported.sh])
 AC_CONFIG_FILES([lib/unistring/version.h:lib/unistring/version.in.h])
 AC_CONFIG_FILES([lib/unistring/woe32dll.h:lib/unistring/woe32dll.in.h])
 AC_CONFIG_FILES([tests/Makefile])
+AC_CONFIG_FILES([libunistring.pc])
 AC_OUTPUT
diff --git a/libunistring.pc.in b/libunistring.pc.in
new file mode 100644
index 000..e06402d
--- /dev/null
+++ b/libunistring.pc.in
@@ -0,0 +1,11 @@
+prefix=@prefix@
+exec_prefix=@exec_prefix@
+includedir=@includedir@
+libdir=@libdir@
+
+Name: libunistring
+Description: Library to manipulate Unicode strings
+Version: @PACKAGE_VERSION@
+Cflags: -I${includedir}
+Libs: -L${libdir} -lunistring
+Libs.private: @LTLIBICONV@
-- 
2.13.6

Re: [bug-libunistring] pkg-config support, please

2015-01-23 Thread Paolo Bonzini 


On 22/01/2015 15:52, Daiki Ueno wrote:
 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

It's actually really good at cross compiling.

You just have to treat it like the compiler or a binutil.  For example
Fedora provides /usr/bin/x86_64-w64-mingw32-pkg-config.

In fact, cross-compilation is the main advantage of pkg-config over
scripts such as xml2-config also mentioned in libxml.m4.  With
pkg-config, only one macro (PKG_PROG_PKG_CONFIG) has to get things
right, and it does:

if test x$ac_cv_env_PKG_CONFIG_set != xset; then
AC_PATH_TOOL([PKG_CONFIG], [pkg-config])
fi

(see AC_PATH_TOOL instead of AC_PATH_PROG).

 and it still seems to be the case.  One would need to maintain a
 separate pkg-config database per target platform.

What's wrong with that?  It's pretty obvious that the dependencies of a
library are different for each platform, or that the include paths could
be different.  The former only matters for static linking, but include
paths matter even if you're linking dynamically.

It's okay not to provide pkg-config if you're willing to provide an
official macro to find libunistring.  But stating that pkg-config does
not support cross-compilation is just FUD.

A mildly valid complaint is that pkg-config is less friendly towards
compiling in the home directory.  Even that however is just a matter of
setting PKG_CONFIG_PATH to $HOME/lib/pkgconfig, and my .bash_profile
already has to set PATH, MANPATH, INFOPATH, CLASSPATH, COMPILER_PATH,
LIBRARY_PATH, LD_LIBRARY_PATH and PERL5LIB to support compilation in the
home directory.

Paolo

Re: [bug-libunistring] pkg-config support, please

2015-01-22 Thread Tim Ruehsen 
On Thursday 22 January 2015 12:10:39 Daiki Ueno wrote:
 Tim Ruehsen tim.rueh...@gmx.de writes:
  there has been a request (incl. patch) in May 06, 2014 from Chris
  Morrison.
  
  What about it ? Is there something missing ?
  
  I would really like to see pkg-config support for libunistring (as project
  author and maintainer). And it is so easy to add :-)
 
 I'm aware of it (and not opposed to it), but there are also criticisms
 on pkg-config, for example:
 http://lists.gnupg.org/pipermail/gnupg-devel/2014-May/028473.html
 I'm not sure if there was any consensus about it.

Hi Daiki,

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 read the above conversation. Werner Koch's arguments against pkg-config 
sound more like a dictate to project maintainers. The direction of his 
arguments are simply false. He should not dictate other people what they 
should like and what not. It better to offer choices and let people decide 
what's good for them on their own (except they ask for advice).

We introduced pkg-config to Wget a while ago because distribution maintainers 
asked for it. They said, it would make their life much easier.

Yesterday I had a (private) conversation with Dagobert Michelsen, who is 
strongly involved in building packages for Solaris (https://www.opencsw.org).
He had problems with configuring different versions of libicu to link with a 
library project of mine (libpsl). I offered him to add pkg-config support into 
configure.ac. He said That would immediately solve my problem. So I did - 
and his problem was solved.

 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) ?
I already heard voice saying it doesn't provide *pc files ? Arg, isn't there 
an alternative ?. And that drops into my mind from time to time as well.

Please give libunistring users the *choice* and don't choose for them by not 
supporting pkg-config.

Regards, Tim


signature.asc
Description: This is a digitally signed message part.

Re: [bug-libunistring] pkg-config support, please

2015-01-22 Thread Tim Ruehsen 
On Thursday 22 January 2015 23:52:14 Daiki Ueno wrote:
 Tim Ruehsen tim.rueh...@gmx.de 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, b.)

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