compiler.{white,black}list usage, especially in cxx11-1.1 PG context

[Mihai Moldovan]

The cxx11 1.1 PG currently sets compiler.whitelist to some value (either
mp-gcc-6.0/7.0 or mp-clang-5.0) and follows up with a bit of blacklisting if the
stdlib is libc++ and otherwise just blacklists.

That's hardly the proper way to do compiler selection.


compiler.whitelist sadly is a *huge* misnomer and tricks people into believing
that the listed compilers will be used if they are already available/installed.
It does not mean that. compiler.whitelist should really have been called
compiler.force, because that what it does.


Currently, base fetches the compiler in this way:
  - set search list to compiler.whitelist if it's set, otherwise to
    compiler.fallback (which is managed by base accordingly to the OS version)
  - for each entry in the search list:
    - check if it blacklisted; if true, continue with the next
    - check if it's either executable or a port; if true use it.


Note how base never checks if a port is installed. It won't take "the first
available compiler", but the first one that is not blacklisted and for which
either a port or a binary exists .


One consequence of this is that coupling compiler.whitelist with
compiler.blacklist is just a complicated way of NOT including the blacklisted
values in compiler.whitelist - totally redundant. If you don't want to include
something in compiler.whitelist, just don't do it.

The other consequence is that, currently, every port that uses the cxx11-1.1 PG
will use a specific compiler for builds. That might be good if we want
reproducible builds, but it also means that users will have to install (and in
the worst case, build from source) huge clang or gcc packages even if their
system compiler would easily be able to cope with C++11 support. Worse, on newer
systems we're now installing and using an older compiler than what the system
ships, which sounds wrong to me.

Something like

compiler.whitelist clang macports-clang-5.0
compiler.blacklist {clang < 500}

might be a way to prefer recent-enough system compilers (needing
compiler.blacklist for the compiler_blacklist_versions-1.0 magic), while forcing
a fallback of macports-clang-5.0. If that is what we WANT, anyway.

In the ppc case, we can just continue to force macports-gcc-6.0
macports-gcc-7.0, although the 7.0 part is currently redundant because we do
have a mp-gcc-6.0 port and it would only kick in if there wasn't.

The convoluted compiler.blacklist line could just be deleted.


So much for the cxx11-1.1 PG rant, but it's not just cxx11-1.1 that gets this
stuff wrong. Is there really no way we can make sure that developers don't run
into this trap any longer? The current behavior is unintuitive and requires base
code knowledge to (mostly) get what one is looking for. Even with that knowledge
there is currently no way to prefer *installed* compilers.



Mihai

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20190416/da707fb6/attachment-0001.sig>