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