[pacman-dev] [PATCH] build: link vercmp staticly with libalpm
This makes the meson-built vercmp equivalent to the autotools build. Employ an intermediate archive of libalpm which our generic library rule can slurp in. Other alpm-only binaries (specifically we care about vercmp) can then link this in for alpm functionality without caring exactly where the function is defined. meson passes the right flags to ensure that unused data is stripped out of the executable. ref: FS#61719 --- meson.build | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/meson.build b/meson.build index 0a710653..5c1efd73 100644 --- a/meson.build +++ b/meson.build @@ -354,12 +354,21 @@ libcommon = static_library( include_directories : includes, install : false) +libalpm_a = static_library( + 'alpm_a', + libalpm_sources, + version : libalpm_version, + include_directories : includes, + dependencies : [crypto_provider, libarchive, libcurl] + gpgme_libs, + link_with : [libcommon], + install : true) + libalpm = library( 'alpm', - libalpm_sources, version : libalpm_version, include_directories : includes, dependencies : [crypto_provider, libarchive, libcurl] + gpgme_libs, + link_whole : [libalpm_a], link_with : [libcommon], install : true) @@ -413,7 +422,7 @@ executable( 'vercmp', vercmp_sources, include_directories : includes, - link_with : [libalpm], + link_with : [libalpm_a], install : true, ) -- 2.20.1
On Mon, Feb 11, 2019 at 08:12:51AM -0500, Dave Reisner wrote:
This makes the meson-built vercmp equivalent to the autotools build.
Employ an intermediate archive of libalpm which our generic library rule can slurp in. Other alpm-only binaries (specifically we care about vercmp) can then link this in for alpm functionality without caring exactly where the function is defined. meson passes the right flags to ensure that unused data is stripped out of the executable.
ref: FS#61719 ---
Sorry, this patch is a bit hasty, but I'm still curious if anyone has any objections to the approach.
meson.build | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/meson.build b/meson.build index 0a710653..5c1efd73 100644 --- a/meson.build +++ b/meson.build @@ -354,12 +354,21 @@ libcommon = static_library( include_directories : includes, install : false)
+libalpm_a = static_library( + 'alpm_a', + libalpm_sources, + version : libalpm_version, + include_directories : includes, + dependencies : [crypto_provider, libarchive, libcurl] + gpgme_libs, + link_with : [libcommon], + install : true) + libalpm = library( 'alpm', - libalpm_sources, version : libalpm_version, include_directories : includes, dependencies : [crypto_provider, libarchive, libcurl] + gpgme_libs, + link_whole : [libalpm_a], link_with : [libcommon], install : true)
@@ -413,7 +422,7 @@ executable( 'vercmp', vercmp_sources, include_directories : includes, - link_with : [libalpm], + link_with : [libalpm_a], install : true, )
-- 2.20.1
On 2/11/19 9:45 AM, Dave Reisner wrote:
On Mon, Feb 11, 2019 at 08:12:51AM -0500, Dave Reisner wrote:
This makes the meson-built vercmp equivalent to the autotools build.
Employ an intermediate archive of libalpm which our generic library rule can slurp in. Other alpm-only binaries (specifically we care about vercmp) can then link this in for alpm functionality without caring exactly where the function is defined. meson passes the right flags to ensure that unused data is stripped out of the executable.
ref: FS#61719 ---
Sorry, this patch is a bit hasty, but I'm still curious if anyone has any objections to the approach.
I (obviously) like the approach, but when I originally suggested it I had a slightly different take on how to implement it.
meson.build | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/meson.build b/meson.build index 0a710653..5c1efd73 100644 --- a/meson.build +++ b/meson.build @@ -354,12 +354,21 @@ libcommon = static_library( include_directories : includes, install : false)
+libalpm_a = static_library( + 'alpm_a',
We're installing a file called "/usr/lib/libalpm_a.a" now?
+ libalpm_sources, + version : libalpm_version,
Generates a meson warning that static_library -> version will eventually become a fatal error.
+ include_directories : includes, + dependencies : [crypto_provider, libarchive, libcurl] + gpgme_libs, + link_with : [libcommon], + install : true) + libalpm = library( 'alpm', - libalpm_sources, version : libalpm_version, include_directories : includes, dependencies : [crypto_provider, libarchive, libcurl] + gpgme_libs, + link_whole : [libalpm_a], link_with : [libcommon], install : true)
Building a maybe-shared, maybe-static library causes pacman-static to be unhappy. I may end up with libalpm_a.a and libalpm.a installed, or if I try to rename the first target, I end up with the same build rule defined twice and meson throws an error. It should be guarded with an if not get_option(...) which I've done in an alternative patch. ... also there's no need to define libcommon or the assorted dependencies and headers when all we're doing is linking a static library into a shared one. The buildtarget already remembers its own dependencies.
@@ -413,7 +422,7 @@ executable( 'vercmp', vercmp_sources, include_directories : includes, - link_with : [libalpm], + link_with : [libalpm_a], install : true, )
-- 2.20.1
-- Eli Schwartz Bug Wrangler and Trusted User
participants (3)
-
Dave Reisner
-
Dave Reisner
-
Eli Schwartz