dialog: add libdialog subport to install library and headers

[adam@…]

dialog is missing C headers. My debian system shows these get installed

/usr/include/dialog.h
/usr/include/dlg_colors.h
/usr/include/dlg_config.h
/usr/include/dlg_keys.h

[ryandesign (Ryan Carsten Schmidt)]

Wouldn't installing the headers only be useful if we also installed the dialog library, which we also don't do? The makefile says "most users do not want/need the library" which is why it doesn't install these things unless they're explicitly asked for, and we don't explicitly ask for them. Are you saying you do want/need the library (and headers)?

[adam@…]

I was unaware the author insisted against installing the library version. I originally developed Perl bindings on Debian where the header and a static library are ​installed. If it's not too much trouble, I would like the library (shared object) and headers installed so I can work on the Perl bindings.

[ryandesign (Ryan Carsten Schmidt)]

Adding a libdialog subport would probably be the best solution. I'll see what I can do. I got it building the static library already, but of course we'd rather have a dynamic library...

[ryandesign (Ryan Carsten Schmidt)]

The makefile isn't set up to do dynamic libraries so I'll leave that for another day. We'll make do with a static library for now.

Here's a patch to add a libdialog subport which installs the libdialog library, library manpage, and headers. It also adds "installs_libs no" to the main port, and changes the main port's description, and adds a description for the subport. These descriptions could still be changed further, but at minimum I thought it was important that they differ from one another, and that it be clear to the user what the difference is between dialog and libdialog.

The patch doesn't result in as efficient ports as might be possible with a bit more tweaking. Both dialog and libdialog will end up building both the dialog program and the libdialog library. They just differ in which parts they end up installing. This is wasteful of build time. But it doesn't take that long to build (only a minute on my 4-year-old Mac, with the universal variant). And if the user is on a system for which we have a buildbot (currently OS X 10.6 x86_64), then there is no overhead, since they'll be downloading a pre-built binary. So I think the patch is ok to commit as is and not spend further time and effort dissecting and patching the makefile.

[ryandesign (Ryan Carsten Schmidt)]

proposed patch

[jyrkiwahlstedt]

done in r91348