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 
- 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 
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 
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 
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 
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 
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 
from source, because they'd be able to continue to use the current version 
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.


macports-dev mailing list

Reply via email to