mlt upgrade

[RJVB (René Bertin)]

This updates port:mlt to 0.9.8 (required for kdenlive 5.12.0 for which I'm preparing a port)

[RJVB (René Bertin)]

I should have waited with posting this update until after I had gotten kdenlive5 to build :)

I have yet to compare with mlt 0.9.6, but the 0.9.8 code uses __DARWIN__ in numerous places to check if running under OS X. That's fine for the mlt build itself (its configure script defines the token), but not for use in the headers. Given the number of files and the kind of patch involved I've resolved this with a composite reinplace expression that replaces __DARWIN__ with __APPLE__ in the source code (I suggest leaving the -D__DARWIN__ defines in the 2 configure scripts).

[ddennedy (Dan Dennedy)]

I will try to replace __DARWIN__ with __APPLE__ upstream and test that it passes our build services for the next release. Otherwise, this looks good to me (maintainer).

[RJVB (René Bertin)]

Using __APPLE__ works for me and allows kdenlive5 to build

Just one more thing which I missed somehow: I'll need to introduce a subport for the Qt5 version. I guess I thought mlt provided only the melt executable...

[RJVB (René Bertin)]

Here's a version that introduces a qt5-mlt subport. Was really simple to implement by including the proper PortGroup, on the condition that -qt-includedir is set to ${qt_includes_dir}, i.e. without the /Qt subdir. That one isn't even necessary for Qt4 detection.

Is there demand for making mlt and qt5-mlt co-installable? That would require moving them into individual sub-prefices, or modification of the build system so that lib/mlt/libmltqt.dylib becomes libmltqt4 or libmltqt5 . That'd be up to upstreams to decide (Dan?)

[ddennedy (Dan Dennedy)]

There is no demand for them to be co-installable. In fact, if both libmltqt4 and libmltqt5 are in the same folder from which MLT is loading plugins, then it is going to fail because Qt does not allow mixing libraries from different major versions in the same process. Due to how MLT loads and registers plugins, merely the existence of both will cause them both to be loaded at startup; it is not on-demand by the application or composition.

[RJVB (René Bertin)]

Impossibility by design doesn't mean there's no demand ;)

[ddennedy (Dan Dennedy)]

Well, then, whoever is demanding it can just fuck off as far as I'm concerned.

[RJVB (René Bertin)]

Very subtle.

MacPorts provides everything that's required to make this possible (via parallel prefices in ${prefix}/libexec), including a port select mechanism that allows users to determine which version should be the default.

[mkae (Marko Käning)]

René, if you can come up with a Portfile which will put mlt's files for both Qt versions into their specific locations - just like it was done for qt[45] - that would be awesome!

Coinstallability is what we'll need for quite some time to come, I am afraid.

If you manage to allow for both versions (kdenlive and kdenlive5) to coexist in one MacPorts installation that would be ideal!!!

[RJVB (René Bertin)]

At this point I'm not sure if kdenlive can be made to co-install without side-effects or sacrifices to one or both of the applications. There's a lot of overlap in installed files.

mlt is a different matter. Is it a dependency for other ports or only for kdenlive?

[ddennedy (Dan Dennedy)]

I believe we can close this. MLT was upgraded to v6.0.0 (new versioning scheme) including its port, and it includes the changes from the patch attached here.

[dbevans (David B. Evans)]

Updated in r145945.

[RJVB (René Bertin)]

New versioning scheme so probably an ABI break? :-/

[ddennedy (Dan Dennedy)]

Replying to rjvbertin@…:

New versioning scheme so probably an ABI break? :-/

No, see ​http://mltframework.blogspot.com/2016/02/version-600-released.html

edit:

it includes the changes from the patch attached here.

Uhm, no. The qt5 subport went MIA.

True, but this is a multi-part ticket where the first part is upgrade, second part is change OS defines, and third part is qt5 subport. The first two are addressed. Make a new ticket for the subport. Do not continue adding more parts to a single ticket.