On 1/7/2019 7:33 PM, Manu via Digitalmars-d wrote:
> I can't move forward with my extern(C++) work until we do something
> about the build issues.
> 
> I'm waiting/blocked on these patches:
> https://github.com/dlang/druntime/pull/2442
> https://github.com/dlang/druntime/pull/2446
> https://github.com/dlang/druntime/pull/2444
> 
> There appears to be one OSX build machine that fails due to an old
> build environment (as I'm told).
> Who are the people that have access to these machines?

There are no build hosts in the auto-tester fleet that are running unsupported platforms.  If any of them are "too old" then we need to formally deprecate one or more platforms.

> std::array, and std::string_view can't be tested because the C++
> toolchains are too old (don't all support C++11/14/17).

Same issue, we support a wide variety of build platforms so the tests need to be conditional on what toolchains exist on the various platforms.

> The toolchains are all out of date, and it's throwing up issues
> constantly. How do we resolve this?

By intelligently testing based on what is supported on those platforms or deprecating them.  The issues aren't the build fleet, it's trying to support newer stuff on older platforms where the support just isn't there.

For what it's worth, the dmd build log for each build has an info block at the beginning with details of the os and tool versions in use.

On Mon, Jan 7, 2019 at 10:09 PM Brad Roberts via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On 1/7/2019 7:33 PM, Manu via Digitalmars-d wrote:
> > I can't move forward with my extern(C++) work until we do something
> > about the build issues.
> >
> > I'm waiting/blocked on these patches: https://github.com/dlang/druntime/pull/2442 https://github.com/dlang/druntime/pull/2446 https://github.com/dlang/druntime/pull/2444
> >
> > There appears to be one OSX build machine that fails due to an old
> > build environment (as I'm told).
> > Who are the people that have access to these machines?
>
> There are no build hosts in the auto-tester fleet that are running unsupported platforms.  If any of them are "too old" then we need to formally deprecate one or more platforms.

The platforms aren't too old, the compilers they run are.
All platforms are and will remain supported... I'm sure we can run the
code, we just can't *build* it.

> > std::array, and std::string_view can't be tested because the C++ toolchains are too old (don't all support C++11/14/17).
>
> Same issue, we support a wide variety of build platforms so the tests need to be conditional on what toolchains exist on the various platforms.

As far as I can tell, there's no machines at all in the fleet with
C++14 or C++17 era compilers.
How do you selectively deploy tests to specific build machines?

I'm not sure what you're suggesting, I need to run the tests on every
build platform we have in the list, but we also need a recent
toolchain on every platform to perform the builds.
The build tools and the targat platforms are separate entities. I want
to test on all platforms, but we need to build with more modern tools.

> > The toolchains are all out of date, and it's throwing up issues constantly. How do we resolve this?
>
> By intelligently testing based on what is supported on those platforms
> or deprecating them.  The issues aren't the build fleet, it's trying to
> support newer stuff on older platforms where the support just isn't there.

There's no plan or intent to deprecate test platforms.
I intend to test on all of them... but how do I *build* the tests?

On 2019-01-08 07:09, Brad Roberts wrote:

> There are no build hosts in the auto-tester fleet that are running unsupported platforms.  If any of them are "too old" then we need to formally deprecate one or more platforms.

This is one of the tests that failed [1]. That info block says it's running "Darwin Kernel Version 13.4.0". According this [2], that's OS X Mavericks. According this [3], support for Mavericks was dropped in 2016. That's two years ago.

> For what it's worth, the dmd build log for each build has an info block at the beginning with details of the os and tool versions in use.

[1] https://auto-tester.puremagic.com/show-run.ghtml?projectid=1&runid=3473553&dataid=24663324&isPull=true

[2] https://en.wikipedia.org/wiki/Darwin_(operating_system)#Release_history

[3] https://en.wikipedia.org/wiki/OS_X_Mavericks

-- 
/Jacob Carlborg

On 1/8/19 6:33 AM, Jacob Carlborg wrote:
> On 2019-01-08 07:09, Brad Roberts wrote:
> 
>> There are no build hosts in the auto-tester fleet that are running unsupported platforms.  If any of them are "too old" then we need to formally deprecate one or more platforms.
> 
> This is one of the tests that failed [1]. That info block says it's running "Darwin Kernel Version 13.4.0". According this [2], that's OS X Mavericks. According this [3], support for Mavericks was dropped in 2016. That's two years ago.
> 
>> For what it's worth, the dmd build log for each build has an info block at the beginning with details of the os and tool versions in use.
> 
> [1] https://auto-tester.puremagic.com/show-run.ghtml?projectid=1&runid=3473553&dataid=24663324&isPull=true 
> 
> 
> [2] https://en.wikipedia.org/wiki/Darwin_(operating_system)#Release_history
> 
> [3] https://en.wikipedia.org/wiki/OS_X_Mavericks
> 

That's my vm, and I'm happy to update if Brad agrees. There is some value in having older systems for the language to be able to build/use for support. I would tend to say for macos, however, that the likelihood of someone running mavericks is pretty low. Any computer that runs Mavericks will go up to El Capitan, and the upgrades are free. It makes sense to deprecate support for Mavericks, and possibly even Yosemite. El capitan should still be supported for older hardware, and some people may be stuck on it due to GC-using apps that they depend on (I know my wife uses an older version of quickbooks that requires GC, and won't run on sierra).

What I CAN do, also, is make a backup of that VM, upgrade it to el capitan, and keep it around in case anyone complains that they have issues.

-Steve

On Tue, Jan 8, 2019 at 6:15 AM Steven Schveighoffer via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On 1/8/19 6:33 AM, Jacob Carlborg wrote:
> > On 2019-01-08 07:09, Brad Roberts wrote:
> >
> >> There are no build hosts in the auto-tester fleet that are running unsupported platforms.  If any of them are "too old" then we need to formally deprecate one or more platforms.
> >
> > This is one of the tests that failed [1]. That info block says it's running "Darwin Kernel Version 13.4.0". According this [2], that's OS X Mavericks. According this [3], support for Mavericks was dropped in 2016. That's two years ago.
> >
> >> For what it's worth, the dmd build log for each build has an info block at the beginning with details of the os and tool versions in use.
> >
> > [1] https://auto-tester.puremagic.com/show-run.ghtml?projectid=1&runid=3473553&dataid=24663324&isPull=true
> >
> >
> > [2] https://en.wikipedia.org/wiki/Darwin_(operating_system)#Release_history
> >
> > [3] https://en.wikipedia.org/wiki/OS_X_Mavericks
> >
>
> That's my vm, and I'm happy to update if Brad agrees. There is some value in having older systems for the language to be able to build/use for support. I would tend to say for macos, however, that the likelihood of someone running mavericks is pretty low. Any computer that runs Mavericks will go up to El Capitan, and the upgrades are free. It makes sense to deprecate support for Mavericks, and possibly even Yosemite. El capitan should still be supported for older hardware, and some people may be stuck on it due to GC-using apps that they depend on (I know my wife uses an older version of quickbooks that requires GC, and won't run on sierra).
>
> What I CAN do, also, is make a backup of that VM, upgrade it to el capitan, and keep it around in case anyone complains that they have issues.

This sounds like a good plan. I'd appreciate!

On 1/8/2019 1:24 PM, Manu via Digitalmars-d wrote:
> On Tue, Jan 8, 2019 at 6:15 AM Steven Schveighoffer via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>>
>> On 1/8/19 6:33 AM, Jacob Carlborg wrote:
>>> On 2019-01-08 07:09, Brad Roberts wrote:
>>>
>>>> There are no build hosts in the auto-tester fleet that are running
>>>> unsupported platforms.  If any of them are "too old" then we need to
>>>> formally deprecate one or more platforms.
>>>
>>> This is one of the tests that failed [1]. That info block says it's
>>> running "Darwin Kernel Version 13.4.0". According this [2], that's OS X
>>> Mavericks. According this [3], support for Mavericks was dropped in
>>> 2016. That's two years ago.
>>>
>>>> For what it's worth, the dmd build log for each build has an info
>>>> block at the beginning with details of the os and tool versions in use.
>>>
>>> [1]
>>> https://auto-tester.puremagic.com/show-run.ghtml?projectid=1&runid=3473553&dataid=24663324&isPull=true
>>>
>>>
>>> [2] https://en.wikipedia.org/wiki/Darwin_(operating_system)#Release_history
>>>
>>> [3] https://en.wikipedia.org/wiki/OS_X_Mavericks
>>>
>>
>> That's my vm, and I'm happy to update if Brad agrees. There is some
>> value in having older systems for the language to be able to build/use
>> for support. I would tend to say for macos, however, that the likelihood
>> of someone running mavericks is pretty low. Any computer that runs
>> Mavericks will go up to El Capitan, and the upgrades are free. It makes
>> sense to deprecate support for Mavericks, and possibly even Yosemite. El
>> capitan should still be supported for older hardware, and some people
>> may be stuck on it due to GC-using apps that they depend on (I know my
>> wife uses an older version of quickbooks that requires GC, and won't run
>> on sierra).
>>
>> What I CAN do, also, is make a backup of that VM, upgrade it to el
>> capitan, and keep it around in case anyone complains that they have issues.
> 
> This sounds like a good plan. I'd appreciate!
> 

The deprecation of the platform by the provider does not dictate the deprecation of it by the D community (by way of any of the various compilers).  It does, however, inform it.  The noted supported minimum version is still Mavericks based on:  https://dlang.org/dmd-osx.html

Did the D release management team also declare it deprecated?  I might well have missed that.  If so, I apologize for being out of sync.

If it should be updated, the set of upgrade options for that tester are:
  Yosemite    (14.5)
  High Sierra (17.7)
  Mojave      (18.2)

Yosemite is probably the right choice since that would be the next version in the list, unless it too is being deprecated.  The lowest supported version needs to be in the fleet otherwise it's de-facto deprecated.  There is already an El Capitan (15.6) host in the fleet, so that's a bad choice for your vm.

So, this falls back to the leadership/release team to clarify what the minimum supported version of osx is.  I don't make that call, as I've said more than a couple times.

As to the other question regarding the compiler used on the various versions, we use the default compiler provided.  That's the one that the vast majority of developers using those platforms are going to have in use so that's what we cater to.

Much like for the os, it's not reasonable to expect the minimum supported c++ compiler to be a c++17.  It _might_ be reasonable to expect c++11/14, but someone would have to survey what's actually there to be sure.  Regardless, conditionalizing the support is a more usable longer term solution.  Exactly how to do that within the existing test suites, I can't answer that since I haven't touched it in a few years and really don't know the state of the art for them.

On 1/9/2019 12:45 AM, Brad Roberts wrote:
> Much like for the os, it's not reasonable to expect the minimum supported c++ compiler to be a c++17.  It _might_ be reasonable to expect c++11/14, but someone would have to survey what's actually there to be sure.  Regardless, conditionalizing the support is a more usable longer term solution.  Exactly how to do that within the existing test suites, I can't answer that since I haven't touched it in a few years and really don't know the state of the art for them.

If the c++17 compiler has switches that revert it to older behaviors, that might be reasonable.

On 2019-01-09 09:45, Brad Roberts wrote:

> If it should be updated, the set of upgrade options for that tester are:
>    Yosemite    (14.5)
>    High Sierra (17.7)
>    Mojave      (18.2)
> 
> Yosemite is probably the right choice since that would be the next version in the list, unless it too is being deprecated. 

It is deprecated too, as well as El Capitan. For El Capitan it ended August 2018. iTunes support ends this year.

-- 
/Jacob Carlborg

On 2019-01-09 11:01, Walter Bright wrote:

> If the c++17 compiler has switches that revert it to older behaviors, that might be reasonable.

They do. The latest compiler for macOS still defaults to C++ 98. But it's possible compile C++ 2x.

-- 
/Jacob Carlborg

On Wednesday, 9 January 2019 at 10:01:20 UTC, Walter Bright wrote:
> On 1/9/2019 12:45 AM, Brad Roberts wrote:
>> Much like for the os, it's not reasonable to expect the minimum supported c++ compiler to be a c++17.  It _might_ be reasonable to expect c++11/14, but someone would have to survey what's actually there to be sure.  Regardless, conditionalizing the support is a more usable longer term solution.  Exactly how to do that within the existing test suites, I can't answer that since I haven't touched it in a few years and really don't know the state of the art for them.
>
> If the c++17 compiler has switches that revert it to older behaviors, that might be reasonable.

It might be a good choice for D to support such things.