Iain Buclaw ibuclaw at
Sat Sep 12 20:56:08 UTC 2020

On Friday, 11 September 2020 at 12:33:02 UTC, wjoe wrote:
> On Wednesday, 9 September 2020 at 23:13:38 UTC, Iain Buclaw 
> wrote:
>> On Wednesday, 9 September 2020 at 18:32:07 UTC, wjoe wrote:
>>> On Wednesday, 9 September 2020 at 12:37:37 UTC, wjoe wrote:
>>>> On Wednesday, 9 September 2020 at 12:13:32 UTC, kinke wrote:
>>>>> On Wednesday, 9 September 2020 at 11:33:22 UTC, wjoe wrote:
>>>>>> I suspect that maybe the compiler wasn't properly 
>>>>>> installed in the container ?
>>>>> Maybe just a typo in your Dockerfile? You're installing 
>>>>> `g++9`, but the package name is `g++-9`.
>>>> Ahh good catch! It works now! Thanks :)
>>> The build as well as the unittests finished successfully.
>>> The entire run took close to 70  minutes. This was a linux 
>>> container with 4 CPUs and 10G RAM.
>> Sounds about right.  There are a couple heavy modules that 
>> instantiate tens of thousands of functions when building 
>> phobos unittests.
>>> Which files should be kept once the task completed and what 
>>> should happen with them ?
>>> On success I could add a package task.
>> There's 'make install'.  I probably wouldn't prune anything 
>> copied during that recipe, as you'll lose integration with C, 
>> C++ and LTO compilers if any of those components are missing.
> I would create a prefix for make install, install to that 
> location, tar that folder and keep the tarball.

Yes, that works, IIRC the same was done for the historical binary 

> Also, on failure it would probably be a good idea to preserve 
> the logs ?

If stdout/stderr is accessible after build, then the relevant 
logs can just be cat'd.  For the testsuite, these be 
./gcc/testsuite/gdc/gdc.log and 
(substitute the target where necessary).

> The docs mention that it's possible to define GitHub actions, 
> e.g. to email stuff. Would that be useful ?

In the event of failed builds, or builds where the success/fail 
status changed, perhaps.  Having emails for every build would 
just be noise.

More information about the D.gnu mailing list