Guile-Fluidsynth - make distcheck fails, any hint?

David Pirotte <[email protected]> Wed, 27 May 2026 21:01:05 -0300
Newsgroups gmane.lisp.guile.user
Message-ID <20260527210105.43385d0d@tintin>
--Sig_/_xcbPtge6xw_2NKiQxoHNr5
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Hi guilers,

For some reason I can't explain, make distcheck does not execute the
exact same steps as a 'normal' make in the repo ... which I described
an asked for help in ##workingset (libera.chat), but didn't get any
answer.

Here is what I described and asked in ##workingset (note that the
double ## isn't a typo, this is the 'real channel name) [1]:

I am  wonering if anyone here, autotool chain 'guru' that is, could
help?

Thanks,
David

[1]=09

<daviid> hello - working on my guile fluidsynth bindings -
         https://cgit.git.savannah.nongnu.org/cgit/guile-fluidsynth.git/tre=
e/
         - I am facing the problem that everything is fine, except make
         distcheck, which fails because, unlike I was expecting, it does not
         execute the exact same steps in the exact same order as make in the
         repo, let me explain better, see if someone here can help me fix t=
he
         issue [20:11]
<daviid> guile-fluisynth depens on nyacc (a package that automatically
         provides scheme loww level bindings to C libraries), and so one of
         the first step is to generate the low level scheme binding files,
         from the *.ffi "source files", here is a paste of calling make (af=
ter
         ./autogen.sh;./configure) in the repo -
         https://paste.centos.org/view/ce2739fb - as you can see, after
         running make in the doc subdir, it 1st processes to the ffi -> scm=
=20
                                                                        [20=
:22]
<daviid> files generation, and calls the guile scheme compiler on those (see
         lines 7 to 46
<daviid> then it proceeds compiling the scheme modules in the support subdi=
r,
         and finally compiles the higher level scheme files in the f-synth
         source dir [20:23]
<daviid> in that orer, everything is fine, as the scheme files in the f-syn=
th
         in the source dir depends on the scheme (generate/compiled) modules
         in the f-synth/ffi subdir [20:24]
<daviid> now, running make distcheck, after making and unpacking the tarball
         in the build dirextory, it 1st tries to compile the scheme files in
         the f-synth in the source dir and ofc this fails, as they depend on
         the f-synth/ffi modules, which for sone reason I fail to unertstan=
d,
         were not generated/compiled, as in the 'normal' make steps. here is
         the error, fwiw -  [20:29]
<daviid> https://paste.centos.org/view/3ff3fe21 - you can see, starting lin=
es
         156 in the paste, that after make in the doc subdir, it tries to
         compile the f-synth/*.scm modules, and that can not work, it has to
         1st, as in the 'normal' make in a repo, produce the ffi -> scm fil=
es
         ... [20:32]
<daviid> the top level Makefile.am imports am/guile/mk -
         https://cgit.git.savannah.nongnu.org/cgit/guile-fluidsynth.git/tre=
e/am/guile.mk
         - which afaict, line 45, asks that the $(FFI_GOBJECTS) be produced
         first (?) - I actually had this line as nobase_go_DATA =3D $(GOBJE=
CTS)
         $(FFI_GOBJECTS) when working on this, and that failed as well in a
         'normal' make ... [20:35]
<daviid> does anyone here has an idea on why make distcheck does not _exact=
ly_
         runs the exact same steps as make (after making and unpacking the
         tarball I mean) ? Thanks [20:36]
<daviid> just to complete, the error is on line 200 - no code for module
         (f-synth ffi types) - as make distcheck, for some reason I do not
         understand, unlike 'normal' make, does not first produce an compile
         the required f-synth/ffi/*.scm modules [20:49]
ERC>=20

--Sig_/_xcbPtge6xw_2NKiQxoHNr5
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEhCJlRZtBM3furJHe83T9k6MFetcFAmoXhcEACgkQ83T9k6MF
eteMwwf9GDZp4J6pWD6eQpOOY6wgqNiY3uE+AZA971XpqMfhP1TB1LXg6S8G2Wsy
ijjZEM1D0vVsYKCnJF59/W7dZEhYYrQ6eB5gQ0xgfTKR6hGEp5IlvtY3tKeCDf2k
eXvLBQLTigEQw+ucOPPJ7dg4vn4YxjWmSR21LIw+WcP+3sTTbYr3krUxCKv8QpnF
g7O89ZTFTyquS90gqm8ymzWZkw6CiAhqmZwRi5JT6a8PVvRchRWsiEs+7oxQdNKm
5vbCQTgcYbubOyv2MNOFyyQs7XiRVVOAJkia9h9UoCNsYIW/zvVU4we4g64l+c7Q
HkLj6bmsmcdjOEdgUvoPSCuIm+gsKg==
=qFcf
-----END PGP SIGNATURE-----

--Sig_/_xcbPtge6xw_2NKiQxoHNr5--