On Friday, 2 March 2018 at 06:07:25 UTC, Nick Sabalausky
(Abscissa) wrote:
(I'm posting this here instead of D.learn because it isn't
really a "How to do XYZ in D?", but rather to invite discussion
on high-level solutions to a problem.)
Here's a common problem:
1. A project (ex, some library)
On 03/04/2018 03:42 AM, Jacob Carlborg wrote:
Aha, you mean like that. Seems a bit difficult to fix. Perhaps
specifying a range of compiler versions would do?
Yea, there's really no two ways around it: Ultimately, each new compiler
release will need to get added to .travis.yml (or any other
On 03/05/2018 02:42 AM, Nick Sabalausky (Abscissa) wrote:
On 03/04/2018 02:05 AM, Nick Sabalausky (Abscissa) wrote:
On 03/03/2018 10:22 AM, Jacob Carlborg wrote:
You should get an email notification about failed builds [1] [2],
Weird. Never worked for me. Will have to check into that.
Ahh
On 03/04/2018 02:05 AM, Nick Sabalausky (Abscissa) wrote:
On 03/03/2018 10:22 AM, Jacob Carlborg wrote:
You should get an email notification about failed builds [1] [2],
Weird. Never worked for me. Will have to check into that.
Ahh, it looks like travis disregards the github email address
On 2018-03-04 08:05, Nick Sabalausky (Abscissa) wrote:
3. Release of DMD 2.081.0 occurs. "dmd" now points to 2.081.0. Unless
.travis.yml has been manually updated, it still contains:
- dmd # Ie, dmd-2.081.0, now
# WTF?!?! dmd-2.080.0 is no longer being tested
- dmd-2.079.0
On 03/04/2018 02:05 AM, Nick Sabalausky (Abscissa) wrote:
1. Suppose a library supports DMD v2.071.0 and up. Because of this,
.travis.yml includes:
- dmd # Ie, dmd-2.079.0, ATM
- dmd-2.079.0
- dmd-2.078.2
- dmd-2.078.1
- dmd-2.078.0
- dmd-2.077.1
- dmd-2.077.0
Summary:
On 03/04/2018 02:23 AM, Nick Sabalausky (Abscissa) wrote:
Oops, proofread failures. Naturally, I meant this (fixes emphasized):
-
1. Suppose a library supports ***DMD v2.077.0*** and up. Because of
this, .travis.yml includes:
- dmd # Ie, dmd-2.079
On 03/04/2018 02:05 AM, Nick Sabalausky (Abscissa) wrote:
No. That is only sufficient *temporarily*, that is, until the next time
the label "dmd" is updated to another new release once again. At *some*
point, .travis.yml will still need to be manually updated...
Scenario 1-2-3:
1. Suppose a
On 03/03/2018 10:22 AM, Jacob Carlborg wrote:
On 2018-03-03 07:39, Nick Sabalausky (Abscissa) wrote:
- Maybe there's a simple setting I've overlooked, but when a build job
fails on travis, the author does not get proactively notified. The
author only finds out next time they go into travis. (I'
On 2018-03-03 07:39, Nick Sabalausky (Abscissa) wrote:
Certainly a possible approach, but has downsides:
- Maybe there's a simple setting I've overlooked, but when a build job
fails on travis, the author does not get proactively notified. The
author only finds out next time they go into travi
On Saturday, 3 March 2018 at 06:39:42 UTC, Nick Sabalausky
(Abscissa) wrote:
On 03/02/2018 02:24 AM, Jacob Carlborg wrote:
Travis CI allows you to specify a D compiler in the following
ways:
* - the latest version of the specified compiler
* -beta - the latest beta
* -nightly - the nightly
On Fri, 02 Mar 2018 01:07:25 -0500, Nick Sabalausky (Abscissa) wrote:
> Another sample point of discussion: One possible approach is to have a
> bot generate PRs to update project's compiler lists. But that leads to
> other questions: How/when is the bot triggered? On what machine does it
> run? I
On 03/02/2018 02:24 AM, Jacob Carlborg wrote:
Travis CI allows you to specify a D compiler in the following ways:
* - the latest version of the specified compiler
* -beta - the latest beta
* -nightly - the nightly build
* - - a specific version of the compiler
Where is "dmd", "ldc" or "gdc".
On Friday, 2 March 2018 at 06:07:25 UTC, Nick Sabalausky
(Abscissa) wrote:
(I'm posting this here instead of D.learn because it isn't
really a "How to do XYZ in D?", but rather to invite discussion
on high-level solutions to a problem.)
Here's a common problem:
1. A project (ex, some library)
14 matches
Mail list logo
