[bug#60013] [PATCH 1/3] gnu: Add libmodule

[Florian <florhizome@posteo.net>]

Hi all,
thanks for your comments. 
A revamped patch-set should be on the way soon, depending mostly on
your's truly input on how to go on with the tests, but see below :)

T B-R: That's how it was! Although these days my mails were as fast as a
couple hours to appear on the mailing list, who could complain ;)

unmatched-paren: I checked the projects for configure flags before I
sent them. Unfortunately I am pretty sure, the remaining patches are not
avoidable, since the variables are set by cmakes pkg-config
queries, but correct me if wrong! I am no expert in any build system,
but these things are often detectable I think :). (btw if there was an effort to write a blog post to document
problems for nix/guix packaging, the use of pkg-config queries those should be explicitly
mentioned, it's a pest!).

About tests:
I also can't find any tests in clight and clightd's repos. At least for
libmodule I found how to build and enable tests
https://github.com/FedeDP/libmodule/tree/16435d57b7600610313dc21301f3b5717480a3a8/tests
So by setting this flag and packing valgrind and cmocka into
'native-inputs', two tests will be built and run. The one using valgrind
will fail though:

starting phase `check'
Running tests...
/gnu/store/j65q3aw414010gdfvmsynwpzfb2jyyd3-cmake-minimal-3.21.4/bin/ctest --force-new-ctest-process 
Test project /tmp/guix-build-libmodule-5.0.1.drv-0/build
    Start 1: ModuleTest
1/2 Test #1: ModuleTest .......................   Passed    1.21 sec
    Start 2: ModuleTest_valgrind
2/2 Test #2: ModuleTest_valgrind ..............***Failed    0.02 sec
==258== Memcheck, a memory error detector
==258== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==258== Using Valgrind-3.17.0 and LibVEX; rerun with -h for copyright info
==258== Command: ./ModuleTest
==258== 

valgrind:  Fatal error at startup: a function redirection
valgrind:  which is mandatory for this platform-tool combination
valgrind:  cannot be set up.  Details of the redirection are:
valgrind:  
valgrind:  A must-be-redirected function
valgrind:  whose name matches the pattern:      strlen
valgrind:  in an object with soname matching:   ld-linux-x86-64.so.2
valgrind:  was not found whilst processing
valgrind:  symbols from the object with soname: ld-linux-x86-64.so.2
valgrind:  
valgrind:  Possible fixes: (1, short term): install glibc's debuginfo
valgrind:  package on this machine.  (2, longer term): ask the packagers
valgrind:  for your Linux distribution to please in future ship a non-
valgrind:  stripped ld.so (or whatever the dynamic linker .so is called)
valgrind:  that exports the above-named function using the standard
valgrind:  calling conventions for this platform.  The package you need
valgrind:  to install for fix (1) is called
valgrind:  
valgrind:    On Debian, Ubuntu:                 libc6-dbg
valgrind:    On SuSE, openSuSE, Fedora, RHEL:   glibc-debuginfo
valgrind:  
valgrind:  Note that if you are debugging a 32 bit process on a
valgrind:  64 bit system, you will need a corresponding 32 bit debuginfo
valgrind:  package (e.g. libc6-dbg:i386).
valgrind:  
valgrind:  Cannot continue -- exiting now.  Sorry.



50% tests passed, 1 tests failed out of 2

Total Test time (real) =   1.23 sec

And I'm not sure how to help with that. including (list glibc "debug")
didn't do it. Do we need really need this test?
The next question is then if the tests that are automatically run are
those mentioned in the README on the projects wiki (see url
above). Chime-in!

zimoun: I think I have been leaving that indentation after (description
in everything I contributed so far. I seriously hope I don't need to rework all of
those just for that. But for the future, I know now ;)
These also would be those "prerequisite-patch-ids" hanging around, that
are generated by the --base=auto flag I use with git send-email like a
good manual follower. I don't want to operate on multiple guix repos or branches, I find
the workflow to keep one updated time-consuming enough so far... So I
guess, to be frank, what can I actually do about that?

Side Note: Of course this list would become smaller the more previous patches are
actually merged *cough cough* most of whom are simple, one-hunk patches
that should require the least amount of time :)