Hi,
Time for one of my wild ideas :)
As some of you know, I've been working to make port:VLC independent of
port:ffmpeg so that the latter can be updated to a version that VLC will not
support for a while.
I went for an approach where port:VLC has an ffmpeg-VLC subport that builds and
installs a minimal ffmpeg 2.8.6 set, and installs it in a directory already
used by VLC for its plugins.
This works but currently requires a hack because I found no way to force the
linker to get the ffmpeg library from that dedicated location instead of from
the global ${prefix}/lib when both locations are added to the linker's search
path via -L options.
This got me thinking about more elegant ways to avoid the issue, in particular
Debian/Ubuntu's approach of distinguishing "user" packages and "developer"
packages. The former contain everything required to use the package, other than
for development. For ffmpeg this would mean, for instance, the ffmpeg c.s.
executables, and the runtime shared libraries (libavFoo.x.y.z.dylib and
libavFoo.x.dylib). Headerfiles and the linker library (libavFoo.dylib) are
provided by the corresponding -dev package.
Going this far would probably be unnecessary and quite cumbersome given the way
MacPorts packages ports, but it seems possible to relegate the linker libraries
to a dedicated -dev port, probably even with a set of procedures that automate
a good part of the process. In the post-destroot :
- find all libfoo.dylib (= the ones with version) that are symlinks and that
are in a common location where the linker could pick them up
- move those libraries to a designated location containing the port name and
the relative path (under ${prefix}) where the originals came from
- create a libfoo-dev subport which installs symlinks in the original directory
(say ${prefix}/lib) to the items in the designated directory.
- Ports depending on port:libfoo can now depends_build-append port:libfoo-dev
For now this is just an idea. It seems useful, I am not very convinced yet that
it's a feature that's going to prove to be useful in practice.
R.
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
