Packaging preference for websocketpp

[Jeff Mitchell]

Hi guys,

For 0.8 we'll have a new dependency -- websocketpp.

Right now websocketpp is in thirdparty/ in one of our plugins (not in the main repo) -- but that plugin will be moving to the main repo before 0.8. There are a few issues with keeping websocketpp in thirdparty/:

* We, and you, dislike having copies of libraries in our tree

* The next release of websocketpp, which we are moving to, is a complete rewrite and is not friendly to building in-tree

* Modifying it to build in-tree requires changes that probably would not get accepted upstream as it's not a supported configuration to begin with

The 0.3 release (which is not out, and is likely to be renamed 1.0) is coming at some point, but it's unclear when. Also, upstream uses SCons; there is a CMake system in a different branch, but that branch lags behind a bit.

So we have a few options, and I'd like to know what your preferences are:

1) I modify the source to build in-tree (not the best use of my time, since it will have to get packaged anyways upon official release)

2) You guys package snapshots of the upstream git repository of the revisions I tell you guys (wouldn't be often, only when there are major updates or necessary bug fixes).

3) I fork the repo and issue my own releases, which you package; when the official 0.3(/1.0) comes out, you switch to packaging that source instead.

My relatively strong preference would be #3. It seems the cleanest thing to do, as you'll have tarballs you can point to, I can ensure that the CMake branch (I'm making an assumption that you'd prefer CMake over SCons, but you may have no preference there) keeps merged, and so on; and it'll make it very easy to switch over to official tarballs when they come out.

Feedback appreciated!

Thanks,

Jeff

[Johannes Huber]

Hi Jeff,

i vote for option 2) git snapshot, this is in my opinion the cleanest solution, because of

a) no need to fork (and have additional workload)

b) rely on the upstream

Greetings