Ticket #381 (closed enhancement: fixed)

Opened 6 years ago

Last modified 6 years ago

Change order of build system's jack detection

Reported by: lilrc Assigned to: jwoithe
Priority: major Milestone:
Component: generic Version: FFADO SVN (trunk)
Keywords: build system, patch Cc:
The device the bug applies to:


Greetings developers!

The build system currently checks the jack version by first trying to execute jackd and then, if jackd does not work, trying to find pkg-config files. To make ffado build properly in Gentoo the check using jackd must be avoided, since calling jackd from the build system causes the build to fail with a so called sandbox error (jackd tries to write outside the build directory). To avoid calling jackd a patch has been used. The problem is that whenever the source code of that part of the build system changes this patch have to be re-written.

Thus, I have written a patch that simply swaps the two checks, so that the pkg-config files are checked before jackd is called. This preserves the intent to not force users to have jack pkg-config files just to build ffado as well as it removes the need for additional downstream patching. Since the patch does not remove any functionality I believe it is alright to apply here (upstream).

Here is the patch:

Index: SConstruct
--- SConstruct	(revision 2574)
+++ SConstruct	(working copy)
@@ -250,21 +250,22 @@
     # Provide a way for users to compile newer libffado which will work 
     # against older jack installations which will not accept the new API
     # version reported at runtime.
-    jackd_ver = CheckJackdVer()
-    if (jackd_ver != -1):
-        # If jackd is available, use the version number reported by it.  This
-        # means users don't have to have jack development files present on
-        # their system for this to work.
-        have_jack = (jackd_ver >= VersionInt('0.0.0'))
-        good_jack1 = (jackd_ver < VersionInt('1.9.0')) and (jackd_ver >= VersionInt('0.121.4'))
-        good_jack2 = (jackd_ver >= VersionInt('1.9.9'))
-    else:
-        # Jackd is not runnable.  Attempt to identify a version from
-        # pkgconfig on the off-chance jack details are available from there.
-        print "Will retry jack detection using pkg-config"
-        have_jack = conf.CheckPKG('jack >= 0.0.0')
+    # The following code tries to determine the jack version using the
+    # pkg-config files. If these are not found it tries to determine the
+    # version using the jackd binary. The order of these checks is
+    # relevant since checking pkg-config files before calling jackd
+    # reduces the work for gentoo maintainers.
+    have_jack = conf.CheckPKG('jack')
+    if have_jack:
         good_jack1 = conf.CheckPKG('jack < 1.9.0') and conf.CheckPKG('jack >= 0.122.0')
         good_jack2 = conf.CheckPKG('jack >= 1.9.9')
+    else:
+        jackd_ver = CheckJackdVer()
+        if (jackd_ver != -1):
+            have_jack = (jackd_ver >= VersionInt('0.0.0'))
+            good_jack1 = (jackd_ver < VersionInt('1.9.0')) and (jackd_ver >= VersionInt('0.121.4'))
+            good_jack2 = (jackd_ver >= VersionInt('1.9.9'))
     if env['ENABLE_SETBUFFERSIZE_API_VER'] == 'auto':
         if not(have_jack):
             print """

Thanks in advance,

Change History

12/01/14 13:54:15 changed by lilrc

  • type changed from bug to enhancement.

12/01/14 14:53:51 changed by jwoithe

  • owner set to jwoithe.

Thank you for your feedback regarding the compilation of ffado in gentoo.

I must say I am surprised that jackd attempts to write anything when the "--version" flag is given. I would have thought that it would simply write the version number to stdout and exit without doing anything else. If it does anything else it probably constitutes a bug in jackd. Do you have any idea what jackd is trying to write in this situation? That said, there does seem to be a need to address this in existing jackd versions since they will persist for quite some time.

I don't see an immediate problem with the idea of switching the check order but I would like others to cast their eye over this idea in case there's a specific reason behind us checking the version returned by jackd before trying pkg-config. Perhaps it was just an attempt to avoid problems with broken jackd installations. For other devs, can anyone see a problem with relying on pkg-config in preference to "jackd --version"?

12/01/14 22:10:16 changed by adi

While "jackd1 --version" doesn't write anything, jackd2 does:

open("/dev/shm/pulse-shm-1869646667", O_RDWR|O_CREAT|O_EXCL|O_NOFOLLOW|O_CLOEXEC, 0700) = 6 open("/dev/snd/controlC0", O_RDWR|O_CLOEXEC) = 4

I guess that's what the reporter was referring to.

I'm OK with reversing the order, as I too cannot think of any immediate problem.

12/01/14 22:25:54 changed by jwoithe

  • status changed from new to assigned.

Thanks for the feedback Adrian. I'll cue this change up (with slightly revised comments and consistent jackd version checks).

In any case, I think someone should probably point the open() call(s) out to the jackd2 developers. I cannot see any reason why "--version" should need to do anything other than print the version number and exit (as jackd1 evidently does).

12/01/14 22:45:15 changed by adi

JFTR: open() calls reported to jackd2 in https://github.com/jackaudio/jack2/issues/81

12/06/14 04:37:26 changed by jwoithe

  • status changed from assigned to closed.
  • resolution set to fixed.

The reordering of the tests as requested has been committed in r2575. This revision also makes the test for jackd1 versions consistent (previously the "jackd --version" was tested against 0.121.4 while the pkg-config version required 0.122.0).

12/15/14 05:15:53 changed by lilrc

Many thanks!