Re: Problems building Maildrop on a Macintosh

Sam Varshavchik <[email protected]> Sat, 01 Dec 2018 13:30:01 -0500
Newsgroups gmane.mail.maildrop
Message-ID <[email protected]>
Larry Stone writes:

> Not to complain (too much) about free software, with so many packages where  
> “./configure; make; make install” just works, Maildrop was a little but

That might work for simple basic software packages. But the world is more  
complex now than it was twenty years ago. There's internationalization, and  
Unicode. Having each individual bit of software reinventing the same wheel  
is a non-starter. So, a typical software package now will certainly have  
more dependencies than it would've before.
 
> frustrating. For us system admin types (hard-core coding is 25+ years in my  
> past), compiler and linker flags are not obvious (particularly since my hard- 
> core coding was on VMS, not Unix). My experience is most packages do look in  
> /usr/local for dependencies so I was not expecting that maildrop needs to be  
> explicitly told to do so. Considering how many posts in other forums I found  
> about the PCRE not found issue (but without good solutions), it seems to be  
> a common problem - perhaps a hint in INSTALL or in configure about using

You should not have had to do that. If you have a platform, such as a Mac,  
where stuff gets installed in /usr/local it is not unreasonable to expect  
that the system compiler has it in its default search path for header files.  
Every software package should not be responsible for adding an explicit  
compilation flag for that.

But increased inter-package software dependencies is not a new problem. And  
Linux, in general, evolved to address that. Most Linux distributions have  
native package managers that handle these kinds of software dependencies:  
either dnf/yum, or apt. And native Linux packages know what their  
dependencies are. You cannot install libidn-devel on Fedora without  
installing pkg-config. If you try, pkg-config gets automatically downloaded  
and installed too. That should be the case for every Linux distribution.

Furthermore, once installed, you can't remove it; an attempt to do so will  
inform you that you have libidn installed which requires this package.

libidn on Mac isn't packaged correctly. You should not've been able to have  
libidn installed without also having pkg-config. Whatever installation  
procedure on a Mac gets used to install libidn, that should've also pulled  
in pkg-config at the same time; and software packages that use libidn can  
reasonably expect pkg-config to be there. It's part of libidn's public  
documentation, for how to build software that uses libidn.

Increased complexity of free software is why Linux distributions exists.  
Most of them include maildrop, and attempting to install whatever version of  
maildrop the Linux distribution provides, using the distro's package manager  
(dnf/yum/apt), is going to take care of installing whatever else needs to be  
installed. If a distro gets updated to the current version of maildrop where  
libidn is mandatory, sysadmins that try to install the distro's maildrop  
package are going to also have libidn automatically installed for them, as  
part of the deal. No additoinal work is quired. Not much software building  
experience is necessary, there.

Although free software can be installed on Macs, Macs' free software  
ecosystem is really not as advanced as Linux's, and installing free software  
on Macs will always be more work. That's simply the way that it is.

P.S. – at least Mac's gcc is recent enough for C++11 support, which is  
required to build courier-unicode, and by extension, everything that depends  
on it. If Mac's gcc was too old for C++11, that would've been a real pickle.

_______________________________________________
Courier-maildrop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/courier-maildrop
signature.asc (application/pgp-signature, 801 B)
-----BEGIN PGP SIGNATURE-----

iQIcBAABAgAGBQJcAtMpAAoJEGs6Yr4nnb8lZp4P/23hQ50YpiCT1Nyb9ZCcIYp2
eqC7DiWTRoN0PeY4syOcJR8LqPTR/CakAdnggRrwTajfauVtYKbZDcMy0LePYKHo
d5icjIBEmubuSGapH28AERFu4ZP9EAAuzh2TzX0NJ3xlEmemVOf67SnxdeGNN4HC
1vOkqstNmpksQ21rMyUXeCqEC5F+mU6oI3qJ3OhnMQjcwJafL8eXhmdQYfoi+i4Z
QKtXz3cpN19+RGsrgMJHc7FEkdvWF89G+ntUs36PB5dWtgeumVbYDCwvH4qJmG6t
Orntg5kNke5aXErHi8BkQFBSp95gjJm1eK1KbBV9/vswhwb79WVgxbMHL8IVMMuC
yL8O5Qch+QRnwnDArA8Usi3fsyFBcuLbVx37WDeNxo2j+icmaavQc9YdCk/4a74F
vQQo53nxgOFKhO2wJhv/ottJLnKGSDCSrn5GyI6OpocKZcU8f+CXlydhxWsaF4Lh
ZES6fMMHLbnGsXOsSokKSZ1gxHeWklsS0VBCPuxYUkkWZZKtuAHV9ZNAEbWFXsiW
FwM1FLL9Us7j6BnOoe/aoUKQIAKuOi1MF2WTNuggdl/UBd6DZtQv+OeRXYVCWWfo
3wZNEcb5+Bg8bSJB1Ijq84HVLTBuEvHKhkTrh2/yQsHqRx+g2HIppUL1k7ySqa7Q
dYk9WbnNyppsozQs4xGa
=JcSE
-----END PGP SIGNATURE-----