Jan Stary wrote:
> Would you please give an example of such software
> that needs to be made into a separate -dev port?
Sorry, I missed your messages.
The -dev port of a library (port:libfoo) would contain
- header files
- pkgconfig and/or cmake modules needed for dependent software to detect the
library
- the libfoo.dylib symlink used by the link editor - if the library provides
versioned files (libfoo.x.dylib, libfoo.x.y.dylib).
The presence of any of those 3 types of files can lead the build system of a
dependent software package to detect the library (in /opt/local) and use it. If
none of them are present, the build system ought to fail detecting the library,
and from the build's point of view it should be as if the library port isn't
installed at all. However, already built and installed dependents will continue
to have access to libfoo.x.dylib which evidently isn't the case if you
uninstall
or deactivate port:libfoo.
I don't have a ready and "urgent" example of a port that would really need this
kind of treatment in MacPorts, which is why I'm not pushing this very hard and
also can make do with a "userland" implementation in a PortGroup.
There's FFmpeg though. Not so very long ago there were several dependents that
were stuck on FFmpeg 2. The FFmpeg2 and FFmpeg3 runtime libraries can co-exist,
but not the headerfiles and other development files. With a set of
port:ffmpeg2{,-
dev} and port:ffmpeg{,-dev} ports the main FFmpeg port could have been updated
more easily and sooner without breaking any dependents.
The SDL and SDL2 ports could benefit from split -dev ports too, probably
(though
in that case one can also patch any dependent that doesn't provide an option to
chose SDL over SDL2).
There's another class of software that would benefit greatly from such a
feature:
software that cannot be built correctly when an earlier version is already
installed. I don't know of any current examples but have already run into this
kind of problem building Qt and have learned that not all developers consider
it
a bug. With Qt the problems have always resolved themselves, fortunately.
But this issue should be avoidable with -dev ports: an affected port:foo can
simply declare a build conflict on its own port:foo-dev , and if implemented in
base the `port upgrade` command could ask permission from the user to auto-
deactivate that foo-dev port (and upgrade it subsequently).
This would be a huge advantage for big ports (like Qt) and users who build
those
from source, because they'd be able to continue to use the current version
while
the new version builds.
The situation is different in my personal MacPorts "transplant" on Linux: there
port:gettext often causes issues that I haven't yet been able to understand
beyond the fact that the system has a conflicting implementation which cannot
always be ignored. The issues can be prevented by deactivating port:gettext-dev
as described above.
R.
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
