[dbrobins]

As part of work to build a test harness for scrapers, and perhaps other test harnesses, unit tests, utilities, etc., I have broken out XBMC into a main binary, containing the main function (xbmc.bin as now) and a call to a shared initialization function, and a shared library (libxbmc.so).

See pull request at 214 (PR).

A simple console app that links to the new library and runs a scraper (requires -std=c++0x and libxbmc.so from the patch of course):

Code:

#include <cstdio>
#include "xbmc.h"
#include "addons/Addon.h"
#include "addons/Scraper.h"
#include "addons/AddonManager.h"
#include "filesystem/FileCurl.h"
#include "video/VideoInfoTag.h"

using namespace std;
using namespace ADDON;

int main()
{
  XBMC_Init(grfxaNil, "test");

  AddonPtr pao;
  if (!CAddonMgr::Get().GetDefault(ADDON_SCRAPER_MOVIES, pao))
  {
    fprintf(stderr, "Failed to get default movie scraper.\n");
    return 1;
  }
  ScraperPtr psc = boost::dynamic_pointer_cast<CScraper>(pao);

  XFILE::CFileCurl fcurl;
  vector<CScraperUrl> vcscurl = psc->FindMovie(fcurl, "Ben-Hur", true/*fFirst*/);
  printf("Results (%d):\n", (int)vcscurl.size());
  for (auto i = vcscurl.begin(); i != vcscurl.end(); ++i)
  {
    printf("\tTitle: %s (id: %s)\n", i->strTitle.c_str(), i->strId.c_str());
    if (i->m_url.size() != 1)
      printf("\t(%d items)\n", (int)i->m_url.size());
    else
      printf("\t%s\n", i->m_url[0].m_url.c_str());
  }

  // details for the first...
  CVideoInfoTag vidtag;
  if (vcscurl.empty() || !psc->GetVideoDetails(fcurl, vcscurl[0], true/*fMovie*/, vidtag))
    printf("GetVideoDetails failed or no matches\n");
  else
  {
    printf("Got details: title %s, genre %s; plot:\n%s\n",
      vidtag.m_strTitle.c_str(), vidtag.m_strGenre.c_str(), vidtag.m_strPlot.c_str());
  }
}

I am looking for feedback for this design, as well as direction/testing on making this work for other platforms (it may work on OSX as-is, since Xcode is supposed to support -shared; I'm not sure what tool Windows uses; if Cygwin it may work there too).

[davilla]

xcode ignores -shared, you have two choices, -bundle or -dynamiclib.

-dynamiclib build a traditional darwin dylib. On pre osx 10.6, dylibs cannot be unloaded. We build xbmc for mac against 10.4sdk for other reasons.

-bundle builds a shared lib closer to the linux .so and that's how we name them, using a .so extension instead of the .bundle that is traditionally used.

both contain internal paths that are used at link and runtime dyload to find and load any dependent libs. -install_name sets that path at link. -install_name_tool can be used to change it. When we package, we scan xbmc.bin and all dyloaded .so's we build for dependent libs and scan those too for depends. Then everything is packaged into the app's framework. internal paths are changed to reflect the new location using a relative path.

You also have to watch usage of equivalent of whole-archive (all_load) as no-whole-archive does not exist on darwin. Not sure about as-needed/no-as-needed.

[dbrobins]

xcode ignores -shared, you have two choices, -bundle or -dynamiclib.

-dynamiclib build a traditional darwin dylib. On pre osx 10.6, dylibs cannot be unloaded. We build xbmc for mac against 10.4sdk for other reasons.

-bundle builds a shared lib closer to the linux .so and that's how we name them, using a .so extension instead of the .bundle that is traditionally used.

both contain internal paths that are used at link and runtime dyload to find and load any dependent libs. -install_name sets that path at link. -install_name_tool can be used to change it. When we package, we scan xbmc.bin and all dyloaded .so's we build for dependent libs and scan those too for depends. Then everything is packaged into the app's framework. internal paths are changed to reflect the new location using a relative path.

You also have to watch usage of equivalent of whole-archive (all_load) as no-whole-archive does not exist on darwin. Not sure about as-needed/no-as-needed.

Thanks. It looks like -bundle is what I want, then. If the library is in the same dir as the executable, do I need an -install_name /path/to/lib (which I suppose is like -rpath), or will it check the current directory?

My libxbmc.so build line for OSX is now:

Code:

$(CXX) $(LDFLAGS) -bundle -o $@ -Wl,-all_load,-ObjC $(DYNOBJSXBMC) $(OBJSXBMC) $(LIBS) -rdynamic

and the xbmc.bin build line is:

Code:

$(CXX) $(LDFLAGS) -o xbmc.bin -Wl,-all_load,-ObjC libxbmc.so $(MAIN) -rdynamic -install_name $(DESTDIR)$(libdir)/xbmc

(install_name used to be -Wl,-rpath, with no space).

Is that right or do I need other changes?

[davilla]

see lib/libsquish/Makefile, it uses -install_name to set the internal lib name to it's current location so TexturePacker can use it.

It's a dynamiclib so that TexturePacker can link to it. You cannot link to bundles.

Be aware that xbmc for mac actually can run two ways under development. 1) use /Users/Shared/xbmc-depends/osx-10.4_i386 as the depends location and <trunk>... is the location for xbmc bits (like system) or packaged into XBMC.app.

iOS is similar to OSX but atv2 is different as it's a plugin under frontrow and so xbmc itself is actually a bundle

[dbrobins]

see lib/libsquish/Makefile, it uses -install_name to set the internal lib name to it's current location so TexturePacker can use it.

It's a dynamiclib so that TexturePacker can link to it. You cannot link to bundles.

Be aware that xbmc for mac actually can run two ways under development. 1) use /Users/Shared/xbmc-depends/osx-10.4_i386 as the depends location and <trunk>... is the location for xbmc bits (like system) or packaged into XBMC.app.

iOS is similar to OSX but atv2 is different as it's a plugin under frontrow and so xbmc itself is actually a bundle

Since I don't know OSX and have no way to test, it would probably be better to limit the shared lib to non-OSX until an OSX dev wants to port things over properly, rather than kluging around hoping to get it right with no way to verify. (Any chance you want to be that dev, or know someone interested? The non-OSX shared lib patch could go in first with no time dependency for the OSX version.)

[dbrobins]

Updated pull-request by removing the shared library in the OSX build.