Re: [PATCH] build: Install pkg-config file for intl

[Bruno Haible]

Hello Eli,

Thanks for your mail. It's a pleasure to read, because it has many
interesting viewpoints and thoughts.

> This is your personal discussion page, which carefully disclaims that it
> does not speak for the GNU project.

Yes, I do not speak for the GNU project. But in discussions inside the
GNU project, I sometimes have opinions about what would be good or bad for
GNU.

> libtool files are indeed bad, end of story, we all agree. Excellent.

I didn't say that. But libtool .la files were meant to solve merely two
problems (dependencies between static libraries, and dependencies between
shared libraries on some operating systems), and they fall short of solving
the other problems. So, we don't need to discuss them further here.

> foo-config scripts are indeed bad due to the lack of standardization. I
> disagree that they are bad due to inability to select 32-bit vs. 64-bit.
> Historically, one simply invoked foo-config-32 or foo-config-64. And
> autotools-based build systems can override this by specifying
> $FOO_CONFIG as the path to whichever config script is desired. It's not
> elegant, but it does work.

foo-config-32 or foo-config-64 resurfaces the complexity to the user who
wants to build a package. Whereas "solving" a problem, IMHO, means to
deal with the complexity in such a way that it is contained in the
transparent box.

> In fact, there's nothing *stopping* people from naming them
> $target-foo-config, and checking for them with AC_CHECK_TARGET_TOOL,
> except... standardization, or the abject lack thereof.
> 
> But if people all agreed to name the scripts that way, it would
> definitely work, wouldn't it?

Most of the problems of pkg-config would also persist if the general
approach would be a standardized approach (C).

> A bigger issue IMO is for portability it needs to work on any OS. POSIX
> shell scripts don't work on Windows without a lot of fuss -- this means
> Windows users can't do a good job of finding software utilizing config
> scripts, so they probably end up using Windows-specific software, maybe
> even proprietary, as a dependency.

The "shell scripts don't work on Windows" is IMO solved by Cygwin. Many
developers on Windows have installed Cygwin and thus have — after setting
PATH appropriately — the ability to run shell scripts.

Regarding build systems for packages: Before Cygwin it was customary to
have two flavours of each script, one in sh syntax and one in .bat or .cmd
syntax. Assuming Cygwin nowadays, it simplifies maintenance to have the
script only in sh syntax. This is also the route that the GNU Build System
has taken: Autoconf-generated configure scripts can be run on Cygwin,
with CC set to some particular wrapper script (see gettext/INSTALL.windows
for details).

> pkg-config has some fake problems listed, such as the inability to find
> custom .pc files when obviously you very much can -- just like you need
> to set $PATH in order to find executables in the user home, so too you
> need to set $PKG_CONFIG_PATH.

This problem is not fake. It steals actual time and produces actual
frustration to people who want to build a package that relies on a
pkg-config, with the usual pkg.m4.

> It also talks about rpath issues, but I don't think this argument makes
> sense either. Several build systems actually *do* automatically set up
> rpath based on the locations of shared libraries used in the build, and
> they don't care if rpath is in the pkg-config file.

This is interesting, as it could help me solve at least this part of the
issue. Can you please give me pointers to these "several build systems"?
Thanks!

> The larger issue is
> that you want rpath for non-default ld.so paths, but not for the default
> system ones -- but that's a bug in ld.so, as it doesn't have a
> machine-readable way to determine it.

Yes, the problem is that it's not documented which library locations
don't need -rpath. (/usr/lib ? /usr/lib64 ? /usr/lib/amd64 ? /usr/local/lib ?)

But if the answer was merely retrievable by asking the system configuration
(ld.so with some option, or such), it would become impossible for one user
on system XYZ to give their binaries to another user on another machine also
running system XYZ. For this to work, the set of library locations would
have to be documented and fixed forever, for each particular system type.

> Then you also mention some so-called flaw of pkg-config, that it depends
> on pkg.m4, even though it doesn't. This is not even a pkg-config issue,
> it's an autotools issue, and build systems other than autotools have
> pkg-config support built in, so it always works.

You are right that my viewpoint is biased: I care most about the packages
that use the GNU Build System. Probably the solution to some of the
problems — from my point of view — is to write a better pkg.m4, similar
to what you say the other build systems do.

> Use of different compilers is an interesting issue to bring up. This
> mostly works, because the type of flags that typically appear in
> pkg-config files are in the portable set. As for -pthread, well, it
> would be neat if there was a pkg-config file describing how to depend on
> threads.pc, which contained a gcc implementation adding `Libs: -pthread`
> and an xlc implementation in its own directory (added in tandem with the
> compiler) specifying something else.

You can write such a threads.pc by yourself, if you ignore old platforms.
It depends on the OS and compiler:
  - ELF platforms: LDFLAGS += -lpthread
  - AIX, FreeBSD: CFLAGS += -D_THREAD_SAFE
  - Solaris: CFLAGS += -D_REENTRANT
Additionally, on AIX, it's best to pass '-qthreaded -qtls' already as part
of $CC and $CXX.

> Cross compilation, of course, works perfectly well. Especially if you
> use pkgconf instead of pkg-config, and can use
> https://man.voidlinux.org/pkgconf-personality.5

This is interesting! Is this file format going to be supported also by the
original pkg-config?

> Despite this, your gripe is that:
> 
> 
> > Some people think that a per-target target-pkg-config script is the
> > solution. But this "solution" works only for cross-compilation
> > targets defined by the distro, not for cross-compilers that users
> > have built themselves (by building binutils and gcc with special
> > configure options).
> 
> 
> Of course, if one is building binutils and gcc with special configure
> options, they can create their own per-target target-pkg-config script
> at the same time they configure GCC and binutils themselves. Why is this
> not a solution?

You can call it a solution, yes :-) But it's extra work, most people who
work with cross-compilers haven't invested. Perhaps because they didn't
know they would need it? Perhaps because it's not easy (requires hacking
the pkg-config sources)? Perhaps because there's no tutorial?

> Disregard everything above, and instead ask a much simpler question.
> After all the effort you have gone to in describing why you don't think
> pkg-config is fantastically wonderful...
> 
> ... what better option are you proposing?

I'm mostly worried about the integration in the GNU Build System, and
for non-root users to be able to build packages with as little hassle
as possible.

It looks like an improved pkg.m4 will be able to solve some of these
problems. Thank you for the reference to pkgconf-personality; if
the improved pkg.m4 parses that file, it would improve the usability
also in the cross-compilation case.

> ... removes libre capabilities from the user.
> 
> Can you please explain this gravely serious accusation? In what way does
> adding a pkg-config file to the gettext project cause gettext to become
> proprietary software, or otherwise software that maliciously restricts
> what users are permitted to do with their previously Free/Libre and Open
> Source operating systems?
> 
> Does it violate the four essential freedoms?
> Does it track your location?
> Does it send non-free javascript to the .pc interpreter to be executed?
> Does it do treacherous computing? Digital Restrictions Management?
> 
> Please clarify why you think pkg-config files are an enemy of the Free
> Software movement.

The .pc files invite people to use the current pkg.m4 (rather than the
gettext.m4 from the GNU gettext package).

While gettext.m4 makes it easy to use to use a libintl that was installed
by the user with e.g. --prefix=$HOME/installed-gettext, pkg.m4 makes it
hard and frustrating. The net effect is that users struggle with that,
and after two or three failures abandon and say "oh well, let me just use
what my distro vendor provided".

Whereas the idea of Free Software is not only that it *technically possible*
to modify the source code and build and use that modified source code, but
also that, as a user, you are *invited* to do so.

Bruno