Changing default cxx_stdlib to libc++

[Ryan Schmidt]

On Mar 12, 2018, at 13:56, db wrote:
> On 11 Mar 2018, at 15:47, Ken Cunningham wrote:
>>> On Mar 11, 2018, at 06:06, db wrote:
>>> On 11 Mar 2018, at 02:47, Kenneth F. Cunningham wrote:
>>>>> On 2018-03-10, at 12:23 PM, db wrote:
>>>>> Except for building from source for minor versions and revbumps, especially large binaries, and for ports that have open defects. Oh well…
>>>> Well, everything for 10.6.8 users on MacPorts is about to get supremely better. Hard to be too upset about that!
>>> I don't doubt that! What I don't understand is, why would port be allowed to build a port from source on a certain system that already failed on the buildbot, and what's worse, be left with a port in a non-working state, while downloading binaries would work, because it couldn't donwload something that's failed to build.
>> You can sent your buildfromsource value to "never" I believe .... would that do what you're asking?
> 
> No. Recently, someone posted about a port dependent on qscintilla-qt4 left in a non-working state because this dependency fails to build. Why is a current version of software made available in a port definition whereby it cannot be built by the buildbot yet in the first place?

Maybe because it worked for the developer on their system before they committed it, and they were not aware that it would fail in other situations. Maybe the problem only affected one subport, or one variant, or one version of macOS, and the developer did not test that specifically beforehand. Who knows. Why does any software have bugs? What we can do is try to fix the bugs when we become aware of them, as Michael did to fix this issue yesterday.


> I noticed that qscintilla-qt4 is not distributed at http://distfiles.macports.org/, although the license should allow it, I guess.

Yes it is: https://distfiles.macports.org/qscintilla/

As far as we know, we are allowed to distribute the distfiles of all but three of our ports.

Distributing binary archives is much more likely to be affected by license restrictions, as it is for qscintilla-qt4, for example:

"qscintilla-qt4" is not distributable because its license "gpl" conflicts with license "OpenSSL" of dependency "openssl"


> But even if it weren't, does the buildbot build software that's not distributable just for the sake of testing?

Of course it does. You're welcome to observe what the buildbot does: https://build.macports.org/waterfall


> If not, shouldn't it, prior to accepting an updated port definition?

The buildbot is only engaged after a commit is in the repository master branch.

We have a separate system, using Travis CI, for doing test builds of updates that have been submitted as pull requests but have not yet been merged into the repository master branch. But most maintainers that are committers don't submit pull requests for their own software, they just commit directly to master, so their changes would not go through Travis.