joerg-krause writes

The current autotools scripts depends on using the ohbuild.sh where all necessary openhome libraries are installed in a build directory.

Build systems, like Buildroot, prefer to install the dependencies into a sysroot/staging directory and point the sysroot path to the dependent package, e.g. --with-openssl=$SYSROOT/usr.

Applied to the openhome packages, the header files are in $SYSROOT/usr/include, e.g.:

$SYSROOT/usr/include/ohNet/OpenHome/OsWrapper.h
$SYSROOT/usr/include/ohNetmon/OpenHome/NetworkMonitor.h
$SYSROOT/usr/include/ohTopology/OpenHome/Av/CpTopology.h

whereas the libraries are installed in $SYSROOT/usr/lib

$SYSROOT/usr/lib/ohNet/libohNetDevices.a
$SYSROOT/usr/lib/ohNet/libohNetCore.a
$SYSROOT/usr/lib/ohNet/libohNet.so
$SYSROOT/usr/lib/ohNet/libohNetProxies.a
$SYSROOT/usr/lib/ohNetGenerated/libohNetGeneratedDevices.a
$SYSROOT/usr/lib/ohNetGenerated/libohNetGeneratedProxies.a
$SYSROOT/usr/lib/ohTopology/libohTopology.a
$SYSROOT/usr/lib/ohNetmon/libohNetmon.a

Maybe we can add some more config options like, --with-ohnet=, --with-ohnetgenerated=, etc`?

Furthermore, it would be more convenient to not link against object files, but against the libraries.

medoc92 writes

From my experience when I first did this, building openhome is nightmarish, and the OpenHome people don’t really have a concept of release. The Git code is not always correct, or even buildable.

As far as I know, no distribution currently has a packaged openhome ?

So I use semi-arbitrary commits which worked for me, and do what is necessary to get it to build (some patching, etc.), inside the ohbuild.sh script. Things will stay this way for Debian/Fedora etc., as long as no blocking bug is found in the version I use, and until a packaged version exists.

It’s quite probable that I sometimes link against object files because the full lib did not build and I did not bother fixing it.

If buildroot already has a set of released openhome libs, I agree that another approach would be preferable. In this case, yes, we could use configure options to find the libs and includes, and conditional code in Makefile.am to either use the tree built by ohbuild.sh or the system libs, this should not be very complicated.

joerg-krause writes

> From my experience when I first did this, building openhome is nightmarish, and the OpenHome people don't really have a concept of release. The Git code is not always correct, or even buildable.

That’s for sure! It is very difficult to set up a build configuration for all the packages. But, I’ll try.

> As far as I know, no distribution currently has a packaged openhome ?

I did not checked, yet. But I wouldn’t wonder if not.

> So I use semi-arbitrary commits which worked for me, and do what is necessary to get it to build (some patching, etc.), inside the ohbuild.sh script. Things will stay this way for Debian/Fedora etc., as long as no blocking bug is found in the version I use, and until a packaged version exists.
> It's quite probable that I sometimes link against object files because the full lib did not build and I did not bother fixing it.

I understand, and it is a proper approach to have something stable at least.

> If buildroot already has a set of released openhome libs, I agree that another approach would be preferable. In this case, yes, we could use configure options to find the libs and includes, and conditional code in Makefile.am to either use the tree built by ohbuild.sh or the system libs, this should not be very complicated.

Thanks, I am working on this on my [oh](https://github.com/joerg-krause/buildroot/tree/oh) branch. It’s WIP and I’ll do a force commit every now and then.

---

I am struggling about the "Ohm*" header files, like "OhmReceiver.h". Are they songcast library headers, or are they project files for the example implementations like Receiver?

medoc92 writes

I think that they are songcast library headers, referring to the OHM protocol: http://wiki.openhome.org/wiki/Av:Developer:Songcast:Ohm

joerg-krause writes

I’ve prepared a PR: https://github.com/medoc92/sc2mpd/pull/11. I’ve tested building the package with the ohbuild script and with preinstalled openhome libraries.

joerg-krause writes

Many thanks for merging! It works fine for me. I’ve prepared a [private Buildroot branch](https://github.com/joerg-krause/buildroot/tree/oh) which can be used to cross-build sc2mpd for the supported architectures. As there are still some "ugly" things concerning howto build the openhome projects, it may need some time until I will submit the patches upstream.