I maintain a Linux distro of my own design. It has a non-standard structure but is up-to-date with respect to libraries. Nightengale builds successfully if a few minor changes are made. I'm not able to run the resulting program, but I thought I'd offer some related suggestions for developers.
As a side note, I ported Rhythmbox 2.95 to my distro recently. I look forward to completing a Nightengale port and comparing the two programs.
If there's a solution to the XPCOM issue that's discussed below, I'll maintain a Nightengale page at my site (which discusses open-source programs in general). For now, I'll follow this thread and I can also be reached at the site:
http://tools.99k.org/
The upstream remarks below are for Nightengale developers. The downstream remarks are for other developers who'd like to build the program.
1. GStreamer detection.
Upstream: Some distros put libraries in non-standard locations. I'd suggest modifying "build.sh" to make it easier for distro maintainers to override the default-directories list that's used to locate GStreamer.
Downstream: If you have GStreamer in a non-standard location, edit "build.sh". Look for one or more lines that say "/usr/lib". Add an absolute path for the GStreamer "lib" directory on the same line (or lines), before "/usr/lib". Put a space after the path.
2. Prebuilt binaries.
Upstream: The Nightengale dependencies tarball that's downloaded by "build.sh" includes prebuilt binaries (for example, "libsqlite3.a"). Eventually, the binaries should be replaced with sources; distro maintainers may need to do a full build for things to work and this will include the dependencies.
Additionally, if possible, "build.sh" should allow downstream developers to use the system's copies of libraries (such as XULRunner).
Downstream: If you have libraries in non-standard locations, the prebuilt binaries may cause "build" errors. To correct the errors, try adding absolute paths for the "lib" directories associated with Alsa and "libIDL" to the environment variable LD_LIBRARY_PATH. Note that entries in the variable should be separated by colons. If you're using "bash", "export" the variable afterward.
3. "glib2" compatibility patch.
Upstream and downstream: For Nightengale 1.11, "sbGStreamerService.cpp" needs a patch to compile against newer releases of "glib2". The line that includes "glib/gutils.h" should include "glib.h" instead. This change should be backwards-compatible with older versions of "glib2". Note: The change may already have been made in the Nightengale "git" sources.
4. XPCOM issue.
I made the downstream changes mentioned above and Nightengale then built without problems. However, when I tried to run the program, the error message "Couldn't load XPCOM" was printed.
I tried modifying Nightengale to build against my distro's copy of XULRunner instead of the copy provided by the Nightengale dependencies tarball. This seemed like a possible workaround. Note: My copy of XULRunner is release 1.9.2.19; I assume that this release is compatible.
I didn't see a simple way to do this. Ultimately, I deleted the prebuilt XULRunner binaries (to ensure that they weren't used) and worked out some distro-specific changes that allowed "build.sh" to succeed. The resulting executable produced the same error message ("Couldn't load XPCOM"). That's where I stopped.
Note: "build.sh" didn't rebuild a prebuilt executable named "nightengale-bin". However, most of the Nightengale code seems to be in libraries that were rebuilt, so this may not be related to the problem.
As a side note, I ported Rhythmbox 2.95 to my distro recently. I look forward to completing a Nightengale port and comparing the two programs.
If there's a solution to the XPCOM issue that's discussed below, I'll maintain a Nightengale page at my site (which discusses open-source programs in general). For now, I'll follow this thread and I can also be reached at the site:
http://tools.99k.org/
The upstream remarks below are for Nightengale developers. The downstream remarks are for other developers who'd like to build the program.
1. GStreamer detection.
Upstream: Some distros put libraries in non-standard locations. I'd suggest modifying "build.sh" to make it easier for distro maintainers to override the default-directories list that's used to locate GStreamer.
Downstream: If you have GStreamer in a non-standard location, edit "build.sh". Look for one or more lines that say "/usr/lib". Add an absolute path for the GStreamer "lib" directory on the same line (or lines), before "/usr/lib". Put a space after the path.
2. Prebuilt binaries.
Upstream: The Nightengale dependencies tarball that's downloaded by "build.sh" includes prebuilt binaries (for example, "libsqlite3.a"). Eventually, the binaries should be replaced with sources; distro maintainers may need to do a full build for things to work and this will include the dependencies.
Additionally, if possible, "build.sh" should allow downstream developers to use the system's copies of libraries (such as XULRunner).
Downstream: If you have libraries in non-standard locations, the prebuilt binaries may cause "build" errors. To correct the errors, try adding absolute paths for the "lib" directories associated with Alsa and "libIDL" to the environment variable LD_LIBRARY_PATH. Note that entries in the variable should be separated by colons. If you're using "bash", "export" the variable afterward.
3. "glib2" compatibility patch.
Upstream and downstream: For Nightengale 1.11, "sbGStreamerService.cpp" needs a patch to compile against newer releases of "glib2". The line that includes "glib/gutils.h" should include "glib.h" instead. This change should be backwards-compatible with older versions of "glib2". Note: The change may already have been made in the Nightengale "git" sources.
4. XPCOM issue.
I made the downstream changes mentioned above and Nightengale then built without problems. However, when I tried to run the program, the error message "Couldn't load XPCOM" was printed.
I tried modifying Nightengale to build against my distro's copy of XULRunner instead of the copy provided by the Nightengale dependencies tarball. This seemed like a possible workaround. Note: My copy of XULRunner is release 1.9.2.19; I assume that this release is compatible.
I didn't see a simple way to do this. Ultimately, I deleted the prebuilt XULRunner binaries (to ensure that they weren't used) and worked out some distro-specific changes that allowed "build.sh" to succeed. The resulting executable produced the same error message ("Couldn't load XPCOM"). That's where I stopped.
Note: "build.sh" didn't rebuild a prebuilt executable named "nightengale-bin". However, most of the Nightengale code seems to be in libraries that were rebuilt, so this may not be related to the problem.