"dev" ports (=/= "devel" ports!)

[Jan Stary]

On Apr 23 15:54:07, rjvbertin at gmail.com wrote:
> I'd like to draw some attention to a prototype implementation of a PortGroup I wrote for creating "dev" ports, akin to Debian/Ubuntu's "-dev" packages:
> https://trac.macports.org/ticket/52713

> I've been using this for a while now and find it particularly useful for avoiding build conflicts. That kind of conflict usually arises when the presence of certain files from a port A interferes with building port B. Most often that concerns headerfiles but "linker interface" libraries can also be at cause, or even pkgconfig/cmake files.

Can you please describe the motivating situation in detail,
i.e. what header files were conflicting with what?

Also, I am not entirely clear on what you mean by
"link libraries" (as opposed to "libraries").

I remember from my Debian days (long ago) how strange this felt.
I have installed, say, libpng. So there is /usr/local/libpng.so
and the programs that need png run hapilly. But I cannot write
any program that uses the library, because? There is no png.h;
I need to install a separate libpng-dev for that.

Please don't. Or at least only in very specific cases that need it.
Even if one library's header file(s) conflict with other library's
header file (example?), the solution is imho not to not install the
header files.

Have one port, say 'png', that installs the library, the headers,
and the manpages. Please don't go the Debian way where a modest
workstation needs to have hundreds of packages installed.

> Those are all files that are only required when using port "A"
> as a dependency for *building* other software but not as a dependency
> for running that dependent software.

The keyword here is "only". It is not unusual to install a library
(and its header files, and its pkgconfig files, and its documentation)
because you want to develop software using that library.
Please don't make it needlessly complicated by requiring
more than one port to be installed.

I admit there are packeges where a separate -doc might be in order
(as a subport? or a variant? is there an agreement?) if the documentation
is considerably bigger than the library itself, or is just a copy
of a set of html pages to be found on the upstream's homepage.

> I think that it should even be possible to use this kind of approach for ports that cannot be built when an older version is already installed; such ports could probably declare a build conflict with their own -dev port (possibly even deactivate it in an appropriate stage).

That's the kind of mess I'm talking about.
"Declare a build conflict with you own -dev port."
Please don't.

	Jan