[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug-libunistring] [bug #53717] Workflows that rely on pkgconfig are unh
[bug-libunistring] [bug #53717] Workflows that rely on pkgconfig are unhappy with libunistring's lack of .pc file
Sun, 22 Apr 2018 13:36:21 -0400 (EDT)
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0
Update of bug #53717 (project libunistring):
Category: Build => Interface
Status: None => Need Info
Assigned to: None => haible
Follow-up Comment #1:
> the world no longer revolves around autoconf
Indeed, when I do a trends.google.com comparison between autoconf, cmake,
scons, gradle, pkgconfig,
I can see the following trends:
- Gradle has "taken off" in 2013.
- CMake has "taken off" in 2006 and seen increasing use since 2016.
- Interest in autoconf has strongly declined.
- Interest in SCons was as its maximum in 2006 and has since declined, like
- Interest in pkg-config has dropped as well.
Then, what we need is good support for locating libunistring in CMake.
But CMake has built-in support for finding libraries. See
pkg-config has known severe problems:
1) It makes it hard to use libraries built by a developer with a custom
--prefix. (Need to set and customize PKG_CONFIG_PATH. Lack of support for
-Wl,-rpath option of the compiler.)
2) It does not work when the compiler that uses the library is different from
the compiler that built the library, e.g. on Solaris.
In summary, use of pkg-config takes away freedoms from the developer.
Therefore, I'm looking for a solution that involves CMake but does not involve
If you try to search for an installed libunistring using the CMake command
'find_library', what does the CMake script look like, and what issues do you
Reply to this item at:
Message sent via/by Savannah