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

[Eli Schwartz]

On 10/12/22 11:22 AM, Bruno Haible wrote:
> As long as pkg-config is designed to make things more efficient for 
> the distro builder while at the same time removing freedoms from the 
> end user [1], we should not add more pkg-config files in GNU, IMHO.
> 
> Bruno
> 
> [1]
> https://gitlab.com/ghwiki/gnow-how/-/wikis/Discussion-about-pkg-config


This is your personal discussion page, which carefully disclaims that it
does not speak for the GNU project. Other GNU projects seem to be
reasonably happy to add pkg-config files for the purpose of usefully
helping the software ecosystem. I suspect that that means "GNU" at large
will continue to add pkg-config files.

Of course, that does mean this discussion page is canonical for projects
which you maintain. So, let's discuss that.


According to this discussion page of yours, there are a number of
approaches to discoverability of software, none of which are "good" in
your opinion. But, I'm not convinced by your logic in several areas here.

...

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

...

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.

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?

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.

You cannot get around this in a shell script. I guess you could tell
Windows users they should go eat paste.

...

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.

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

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. But also, pkg.m4 is
included in dist tarballs anyway. So I don't understand the problem.

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.

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

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?

Obviously, it is more work. But you are not claiming it's more work,
you're claiming it is not a valid solution under any circumstances.

...

...

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?

Seems to me based on your description page that *everything* has
objectionable points to you. But pkg-config has fewer of them.

So, the solution here is pretty simple. Add pkg-config, because it's the
best option available. Consider using something else, if something
better eventually comes along.


I'll end off with one last question. You state about pkg-config, "while
at the same time removing freedoms from the end user", but neither your
email, nor your reference link describes any suggestion, hint, or
rationale for how pkg-config goes beyond "not useful for such and such
case", and actively...

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


-- 
Eli Schwartz