[pacman-dev] [PATCH] Add implicit fall through warning

2019-02-11 Thread Allan McRae
Requires modification to our comment about fall through to match compilers
expectations.  Works for GCC and Clang.

Signed-off-by: Allan McRae 
---
 configure.ac| 1 +
 meson.build | 1 +
 src/pacman/pacman.c | 2 +-
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 415ed3cb..2f345b5d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -462,6 +462,7 @@ if test "x$warningflags" = "xyes" ; then
CFLAGS_ADD([-Wformat-nonliteral], [WARNING_CFLAGS])
CFLAGS_ADD([-Wformat-security], [WARNING_CFLAGS])
CFLAGS_ADD([-Wignored-qualifiers], [WARNING_CFLAGS])
+   CFLAGS_ADD([-Wimplicit-fallthrough], [WARNING_CFLAGS])
CFLAGS_ADD([-Winit-self], [WARNING_CFLAGS])
CFLAGS_ADD([-Wlogical-op], [WARNING_CFLAGS])
CFLAGS_ADD([-Wmissing-declarations], [WARNING_CFLAGS])
diff --git a/meson.build b/meson.build
index 0a710653..02a3a3d3 100644
--- a/meson.build
+++ b/meson.build
@@ -220,6 +220,7 @@ if get_option('buildtype').startswith('debug')
 '-Wformat-nonliteral',
 '-Wformat-security',
 '-Wignored-qualifiers',
+'-Wimplicit-fallthrough',
 '-Winit-self',
 '-Wlogical-op',
 '-Wmissing-declarations',
diff --git a/src/pacman/pacman.c b/src/pacman/pacman.c
index a2a420b6..3bb622e6 100644
--- a/src/pacman/pacman.c
+++ b/src/pacman/pacman.c
@@ -196,7 +196,7 @@ static void usage(int op, const char * const myname)
addlist(_("  --ignoreignore a 
package upgrade (can be used more than once)\n"));
addlist(_("  --ignoregroup \n"
  "   ignore a 
group upgrade (can be used more than once)\n"));
-   /* pass through */
+   /* fall through */
case PM_OP_REMOVE:
addlist(_("  -d, --nodeps skip 
dependency version checks (-dd to skip all checks)\n"));
addlist(_("  --assume-installed 
\n"
-- 
2.20.1


Re: [pacman-dev] [PATCH] build: link vercmp staticly with libalpm

2019-02-11 Thread Eli Schwartz
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



signature.asc
Description: OpenPGP digital signature


[pacman-dev] [PATCH] build: link vercmp with a static copy of libalpm

2019-02-11 Thread Eli Schwartz
This has historically been the case in autotools since we want vercmp to
not break mid-transaction in an install script.

For convenience, we create libalpm.a and use this to optionally generate
libalpm.so (when not configured with -Dbuildstatic=true) as well as to
link any binary which explicitly wishes to be built statically "with
libalpm", but does not care where a function is defined. meson then
treats this correctly: it builds the object file only once for both
libraries, and the compiler strips out unused functionality from the
final static binary.

Currently the only binary which requires this is vercmp.

Fixes FS#61719

Signed-off-by: Eli Schwartz 
---

This is based on my initial suggestion via IRC for how to solve the
vercmp build issue using two libalpm libraries.

The important distinction is that in order to not be an error when
buildstatic is used, we cannot try to create multiple rules that
generate libalpm.a -- and also we don't want to install
/usr/lib/libalpm_a.a

 meson.build | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/meson.build b/meson.build
index 0a710653..4a74786b 100644
--- a/meson.build
+++ b/meson.build
@@ -354,15 +354,24 @@ libcommon = static_library(
   include_directories : includes,
   install : false)

-libalpm = library(
+libalpm_a = static_library(
   'alpm',
   libalpm_sources,
-  version : libalpm_version,
   include_directories : includes,
   dependencies : [crypto_provider, libarchive, libcurl] + gpgme_libs,
   link_with : [libcommon],
   install : true)

+if not get_option('buildstatic')
+  libalpm = shared_library(
+'alpm',
+version : libalpm_version,
+link_whole: [libalpm_a],
+install : true)
+else
+  libalpm = libalpm_a
+endif
+
 install_headers(
   'lib/libalpm/alpm.h',
   'lib/libalpm/alpm_list.h')
@@ -413,7 +422,7 @@ executable(
   'vercmp',
   vercmp_sources,
   include_directories : includes,
-  link_with : [libalpm],
+  link_with : [libalpm_a],
   install : true,
 )

--
2.20.1


Re: [pacman-dev] [PATCH] build: link vercmp staticly with libalpm

2019-02-11 Thread Dave Reisner
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


[pacman-dev] [PATCH] build: link vercmp staticly with libalpm

2019-02-11 Thread Dave Reisner
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