Arch Linux User Repository

It's not namcap that shows it, but makepkg. So, its kind of hard to catch. For me, at least, I consider namcap to be the definitive package checking tool.

==> Tidying install...
  -> Removing libtool files...
  -> Removing static library files...
  -> Purging unwanted files...
  -> Stripping unneeded symbols from binaries and libraries...
  -> Compressing man and info pages...
==> Checking for packaging issues...
==> WARNING: Package contains reference to $srcdir
usr/lib/libavm.so.1.0.0
usr/bin/avmdec
usr/bin/avmenc

@HurricanePootis namcap is not showing any references to $srcdir for me. Anyway, this package is benefited by adding the 'NDEBUG' macro, as the upstream source code references it. Implemented. I wrote the initial version of the CMake Package Guidelines in the ArchWiki, but sometimes I really forgot to test for the necessity of adding 'NDEBUG'. Thanks for suggesting it.

Hey, I noticed that there are some references to the $srcdir whenever compiling avm. These can be removed by add -DNDEBUG to the CFLAGS and CXXFLAGS, as stated in the CMake Packaging Guidelines.

Here's a diff file:

diff --git a/PKGBUILD b/PKGBUILD
index 05023ad..449fc1d 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -28,6 +28,8 @@ build() {
         -G 'Unix Makefiles' \
         -DCMAKE_BUILD_TYPE:STRING='None' \
         -DCMAKE_INSTALL_PREFIX:PATH='/usr' \
+        -DCMAKE_C_FLAGS:STRING="${CFLAGS} -DNDEBUG" \
+        -DCMAKE_CXX_FLAGS:STRING="${CXXFLAGS} -DNDEBUG" \
         -DCONFIG_DIP_EXT_PRUNING:STRING='0' \
         -DCONFIG_ML_PART_SPLIT:STRING='0' \
         -DCONFIG_TENSORFLOW_LITE:STRING='0' \

@HurricanePootis This was to comply with the default Arch Linux target CPU (plain generic x86_64), which supports only MMX, SSE and SSE2 instruction sets. At the time of the package creation four years ago, I was not sure how upstream deals with the instruction set levels at run time (if it strictly followed the build time selection or if it dynamically detects if the running CPU supports the available instructions compiled). Now, by revisiting the subject, it looks like it goes for the second option, by detecting if the executing CPU supports the compiled instruction sets. I've pushed an update to allow the maximum supported instruction set level.

@dbermond What's your logic behind disabling SSE3-SSE4_2, AVX, & AVX2?