Iain Buclaw ibuclaw at
Wed Sep 16 21:05:27 UTC 2020

On Wednesday, 16 September 2020 at 12:50:57 UTC, wjoe wrote:
> On Wednesday, 16 September 2020 at 10:42:27 UTC, Iain Buclaw 
> wrote:
>> On Wednesday, 16 September 2020 at 09:55:22 UTC, wjoe wrote:
>>> The way it's being done right now is that 'make install' 
>>> installs to the /usr prefix. After that a tarball of this 
>>> prefix is created (via tar cJf gdc-triplet.txz /usr). I'm not 
>>> sure if that's suitable as a release as is because tar omits 
>>> the root / so the result will be extracted as usr/
>>> There isn't a lot of time budget left in that task but it 
>>> should be possible to run some more scripts.
>>> If the time limit won't suffice it should be possible to 
>>> cache /usr and move the tar ball script into a new task.
>> If it follows the convention of the existing packages, it 
>> should be fine.  e.g: tar extracts gdc into 
>> 'x86_64-unknown-linux-gnu/bin/gdc'
> The tar ball is 443MiB. That's because it includes half the 
> docker container :)

You should be able to get yourself down to about ~30MB. ;-)

I'll see if there's any miscellaneous tweaks you can do, but the 
most obvious one is `strip --strip-debug`.

> The buildci script [1] uses hard coded --prefix=/usr and 
> lib-dirs=/usr/lib.
> Is there a particular reason for that ?
> Or, rather, could I just change it or introduce a variable 
> prefix in order to be able to use an isolated directory ?
> [1] 

IIRC, that top line just matches Debian/Ubuntu built gcc (in the 
hope that no weirdness would happen when running testsuite).

Seems reasonable to break it out into a variable that can be 
overridden by the CI.

Just looking at an old binary, the builder used 
`--prefix=/home/build/share/cache/install/x86_64-unknown-linux-gnu`.  Not saying that you should do the same, but the last part being the target triplet is the key.


It may only be a marginal gain, but I find that 
--disable-libstdcxx-pch helps with speeding up incremental builds 
(a long time is spent compiling headers in libstdc++).

More information about the D.gnu mailing list