[aur-general] TU application: Daurnimator

Tue Dec 11 22:44:01 UTC 2018

On 12/11/18 4:21 PM, Daurnimator wrote:
> On Tue, 11 Dec 2018 at 13:18, Eli Schwartz via aur-general
> <aur-general at archlinux.org> wrote:
>> Lua *does* provide a "make pc" target.
> 
> Only lua 5.1 does, it was removed in the lua 5.2 release. Due to
> disagreements between debian and fedora lua package maintainers about
> what it should contain.

I found it by downloading https://www.lua.org/ftp/lua-5.3.5.tar.gz and
looking at the Makefile. Pretty sure this is not lua5.1, could be wrong
though.

Do you mean they removed a pc rather than an echo target?

..

It seems bizarre that Debian and Fedora would disagree about what
pkg-config should contain. There's an official spec about what it should
contain. :)

Maybe link both the Debian and Fedora maintainers to the pc(5) manpage?
They seem to have badly pendanticized themselves into irrelevance, which
I guess is sad for the lua community. None of the mentioned debian
concerns, at least, are remotely relevant to lua.

Once again, Debian is why we cannot have nice things I guess.

On 12/11/18 4:43 PM, Daurnimator wrote:
>   - http://lua-users.org/lists/lua-l/2008-09/msg00186.html

Ouch. It's a job for downstream packagers to provide the .pc in much the
same way it's a job for downstream packagers to provide the Makefile.

>   - http://lua-users.org/lists/lua-l/2010-03/msg00718.html
>   - http://lua-users.org/lists/lua-l/2010-05/msg00616.html

The FHS specifies,

/usr/share : Architecture-independent data

It is thus only technically correct that it be stored in /usr/lib, and
if they get this nigglingly insignificant detail wrong, then Debian,
which does make use of multiarch packages, will be happy to perform a
trivial downstream integration patch and likely also inform the lua
developers of their typo.

>   - http://lua-users.org/lists/lua-l/2011-12/msg00731.html

If lua does not officially compile a C++ version, it is the job of
Debian to both provide their own pkg-config files, and modify lua to
build using C++.

If lua only provides a static library named liblua.a, then this will
conflict with any other version of lua, and thus, so will the pkg-config
file. Distributions which work around this using `mv` and `ln` on the
library can also `mv` and `ln` the pkg-config file.

tl;dr why is it the job of lua to provide pkg-config files for libraries
that they don't provide?

More on static linking and pkg-config files below.

>   - http://lua-users.org/lists/lua-l/2012-02/msg00814.html

Huh? http://lua-users.org/lists/lua-l/2012-02/msg00748.html

If downstream lua applications wish to support versioned lua shared
libraries, I would recommend using something like

LDLIBS += $(shell pkg-config --libs lua$(LUAVER))

and telling distros to compile with make LUAVER=5.2 to match their own
distro versioning, if they don't want to use the one, official,
canonical lua.pc that doesn't support dynamic linking at all.

If LUAVER is not defined, then no loss! It does as intended and compiles
for the default version of lua, right?

>   - http://lua-users.org/lists/lua-l/2015-03/msg00334.html

That person is just deliberately trolling. :(

>> Admittedly, this target is
>> missing the Libs: keyword so that users can actually use the invocation
>> `pkg-config --libs lua` to find out the right flags for linking lua.
>> This would be helpful both to users wishing to statically link, and
>> those wishing to dynlink. Admittedly also, this pc target echoes to
>> stdout instead of like creating the actual file.
>>
>> Note: the Arch, Debian, and Fedora maintainers have *all* fixed the pc
>> file to provide proper Libs:, and while I wouldn't generally recommend
>> relying on downstream pkg-config files, the official sources do quite
>> plainly allow you to use in your Makefile:
>>
>> CFLAGS += $(shell pkg-config --variable includedir lua)
>>
>> since it is assumed lua distributors will run make pc > lua.pc and
>> install this file themselves.
> 
> They do not.

Then why do they have the target? For that matter, reading your links it
appears that the lua developers are quite insistent that distributions
*should* provide these pc files even if they write them themselves.

I'd guess the assumption by lua devs is therefore that "yes, they will
either use: make pc > lua.pc, or they will write their own from scratch,
either way assume it exists". Maybe they should document this on their
installation guidelines to make it official.

> The upstream lua makefile does not even support creating shared
> libraries; that is patched in (differently!) by each distro.

This is such a huge misunderstanding of what pkg-config is, and it's
something I have zero opinion on. For the purposes of this discussion I
don't care if lua uses shared libraries either officially or
unofficially, and it has no bearing on anything I say.

pkg-config is not about shared libraries. pkg-config does not care about
whether you use shared libraries. pkg-config is about telling you which
compiler flags to use, and compiler flags don't care whether you use
shared or static.

There are primarily four types of flags pkg-config provides:

Name:
Version:
Cflags:
Libs:

1) is documented to contain a name useful for naming the thing

2) is documented to contain a version that can be used for checking to
see if your system claims to support a given version of the named thing.

3) and 4) are documented to contain symbolic flags that are required by
an application that expects to consume  the project provided by the
pkg-config file. It does not specify whether this project has any such
flags, but if it does have such flags, they need to be here. The flags
that the project needs are philosophically derived from whatever the
project that provides the pkg-config file believes is right and just
that should be used, and wish to unconditionally message to the entire
world that they should use.

3) should contain any -I/usr/include/ path to the location of the
headers, and any other compiler CFLAGS of note

4) should contain the -lfoo name of any compiler LDLIBS of note, paying
heed to the fact that statically linked applications use -lfoo to link
to libfoo.a just as surely as shared applications use -lfoo to link to
libfoo.so, and your compiler will in fact always check for both.

In fact, GNU ld documents -lfoo as searching for libfoo.a, and adds as
an afternote that "on systems which support shared libraries, ld may
also search for files other than libnamespec.a" (and on ELF systems, it
will first search for *.so)

You may also specify compiler LDLIBS like:

Libs: -l:libfoo.a

which is a pkg-config metadata specifier signaling a GNU ld flag that
looks for the exact filename "libfoo.a" and thus does not give the
option of auto-detecting shared libraries.

...

Finally, pkg-config explicitly supports static linking via

Libs.private:
Cflags.private:

(The latter is ignored by freedesktop pkg-config, but used by pkgconf.)

The .private variant means, this is the additional flags you use when
explicitly using `pkg-config --static --libs foo` to request the flags
that are fine-tuned to building your application with a static version
of the pkg-config symbolic system provider for "foo".

The pkg-config specification authors would like the lua developers --
and you -- to know that they are warmly welcoming to the needs of people
who provide static libraries.

-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20181211/96d5ddfb/attachment.asc>