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-----