#50294 closed update (fixed)
mlt upgrade
Reported by: | RJVB (René Bertin) | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.3.4 |
Keywords: | haspatch | Cc: | ddennedy (Dan Dennedy), mkae (Marko Käning) |
Port: | mlt |
Description
This updates port:mlt to 0.9.8 (required for kdenlive 5.12.0 for which I'm preparing a port)
Attachments (1)
Change History (15)
comment:1 Changed 9 years ago by RJVB (René Bertin)
comment:2 Changed 9 years ago by 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).
comment:3 Changed 9 years ago by 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...
Changed 9 years ago by RJVB (René Bertin)
comment:4 Changed 9 years ago by 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?)
comment:5 Changed 9 years ago by 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.
comment:6 Changed 9 years ago by RJVB (René Bertin)
Impossibility by design doesn't mean there's no demand ;)
comment:7 Changed 9 years ago by ddennedy (Dan Dennedy)
Well, then, whoever is demanding it can just fuck off as far as I'm concerned.
comment:8 Changed 9 years ago by 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.
comment:9 Changed 9 years ago by 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!!!
comment:10 Changed 9 years ago by 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?
comment:11 Changed 9 years ago by 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.
comment:12 Changed 9 years ago by dbevans (David B. Evans)
Resolution: | → fixed |
---|---|
Status: | new → closed |
Updated in r145945.
comment:13 follow-up: 14 Changed 9 years ago by RJVB (René Bertin)
New versioning scheme so probably an ABI break? :-/
edit:
it includes the changes from the patch attached here.
Uhm, no. The qt5 subport went MIA.
comment:14 Changed 9 years ago by 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.
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).