[135847] trunk/dports/science/volk

[Michael Dickens]

Yes; OK; agreed in general.

So, why do we have "configure.cxx_stdlib"? Why not just force users to
use libc++ and never libstdc++? I know this setting -can be- per port,
but for (guessing) 99%+ of all users they just use the default (they
likely do not even know they can change this setting). On 10.8- this
setting defaults to "libstdc++" and thus ports can use clang or GCC for
building (Apple or MacPorts). On 10.9+ this setting defaults to "libc++"
and thus ports must use clang for building (Apple or MacPorts). I don't
see these settings as opposing what you wrote, including that "we should
not allow use of the GCC compilers in the general case". The major issue
happens someone decides to mix and match the stdlib in the same MacPorts
install -- which is never a good idea in general, and should be used
only in very specific instances by knowledgeable and qualified
developers; in this case "you get what you pay for" I think fits the
bill pretty well.

What I'm saying is that when specifying -std=c++11 and using libstdc++,
one -must- use GCC 4.7+ but -cannot- use Clang because of how Clang
finds headers -in this case-. I don't think that these conditions
contradict what you wrote below, nor the general / specific usage cases.
If the user is brave enough to be using libc++ on 10.8-, then compiling
using -std=c++11 will work just fine for my ports because they are
programmed to use Clang as the compiler. If they use libstdc++, then
they are programmed to use GCC 4.7+ as the compiler -- doesn't matter
the OS; what matters is the stdlib setting.

I don't see this as a big deal; maybe I'm just not getting the point
yet? Sorry if I'm being daft! - MLD

On Wed, May 6, 2015, at 03:27 PM, Lawrence Velázquez wrote:
> The MacPorts GCC ports do not use the system's libstdc++ / libsupc++;
> they use the copy from the libgcc{,-devel} ports.
>
> Thus, any C++ ports compiled with our GCC compilers needs to depend on
> libgcc{,-devel} and should not use any of the system's C++ APIs.
>
> And if those ports use any C++ APIs from other ports, those other ports
> need to have been built with our FSF GCC also.
>
> And we currently have no way of accounting for C++ library/runtime during
> dependency resolution, so we should not allow use of the GCC compilers in
> the general case. Ports may be able to safely opt in on a case-by-case
> basis if they do not use any external C++ objects.