On Wednesday, 16 September 2020 at 21:05:27 UTC, Iain Buclaw wrote:
> 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] https://github.com/W-joe/gcc/blob/master-ci/buildci.sh#L274-L280
>
> 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++).

Installation and creation of the tar ball now works as expected.

It contains a folder named after the build_target triplet and includes the libstdcxx, libphobos headers/sources as well as the static/shared libs, the binaries and man pages.
It took 1:54 to build and weighs 316MB but it isn't stripped yet.
Still waiting on the results of make install-strip and with pre-compiled headers disabled.

Once those are done I'll setup a github action to upload the tar ball to the repository releases.

Maybe it would be a good idea to tag the directory name with a version ID or to make a version directory there and install into that ?

On Thursday, 17 September 2020 at 14:15:34 UTC, wjoe wrote:
> On Wednesday, 16 September 2020 at 21:05:27 UTC, Iain Buclaw
>> [...]
>
> Installation and creation of the tar ball now works as expected.
>
> It contains a folder named after the build_target triplet and includes the libstdcxx, libphobos headers/sources as well as the static/shared libs, the binaries and man pages.
> It took 1:54 to build and weighs 316MB but it isn't stripped yet.
> Still waiting on the results of make install-strip and with pre-compiled headers disabled.
>
> Once those are done I'll setup a github action to upload the tar ball to the repository releases.
>
> Maybe it would be a good idea to tag the directory name with a version ID or to make a version directory there and install into that ?

make install-strip cuts the time for the Package task by 20 minutes (~4 minutes, down from ~24).
The tar ball now weighs 54MiB but it's still not anywhere close to 30.

On Thursday, 17 September 2020 at 14:15:34 UTC, wjoe wrote:
> On Wednesday, 16 September 2020 at 21:05:27 UTC, Iain Buclaw wrote:
>> On Wednesday, 16 September 2020 at 12:50:57 UTC, wjoe wrote:
>>>[...]
>>
>> 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`.
>>
>>> [...]
>>
>> 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++).
>
> Installation and creation of the tar ball now works as expected.
>
> It contains a folder named after the build_target triplet and includes the libstdcxx, libphobos headers/sources as well as the static/shared libs, the binaries and man pages.
> It took 1:54 to build and weighs 316MB but it isn't stripped yet.
> Still waiting on the results of make install-strip and with pre-compiled headers disabled.
>
> Once those are done I'll setup a github action to upload the tar ball to the repository releases.
>
> Maybe it would be a good idea to tag the directory name with a version ID or to make a version directory there and install into that ?

I can provide a server for you to upload to.  Git tags for versioning might be interesting for uploads, but they're not going to be binaries that will stay around for too long.

This is a bastardized version of the git gcc-descr alias.

git describe --all --abbrev=40 --match 'basepoints/gcc-[0-9]*' origin/master | sed -n 's,^\(tags/\)\?basepoints/gcc-,r,p'

That should get you a tag like r11-3179-g5de41c886207a3a0ff1f44ce0a5a644e9d9a17f8

On Saturday, 19 September 2020 at 00:29:37 UTC, Iain Buclaw wrote:
> [...]
>
> I can provide a server for you to upload to.  Git tags for

Great.

> versioning might be interesting for uploads, but they're not going to be binaries that will stay around for too long.
>
> This is a bastardized version of the git gcc-descr alias.
>
> git describe --all --abbrev=40 --match 'basepoints/gcc-[0-9]*' origin/master | sed -n 's,^\(tags/\)\?basepoints/gcc-,r,p'
>
> That should get you a tag like r11-3179-g5de41c886207a3a0ff1f44ce0a5a644e9d9a17f8

Thanks.

On Saturday, 19 September 2020 at 09:53:29 UTC, wjoe wrote:
>>
>> This is a bastardized version of the git gcc-descr alias.
>>
>> git describe --all --abbrev=40 --match 'basepoints/gcc-[0-9]*' origin/master | sed -n 's,^\(tags/\)\?basepoints/gcc-,r,p'
>>
>> That should get you a tag like r11-3179-g5de41c886207a3a0ff1f44ce0a5a644e9d9a17f8
>
> Thanks.

This fails with:
> fatal: No names found, cannot describe anything.

This is probably because of a shallow clone and maybe also because there aren't any tags.
Would this tag be 'basepoints/gcc-10' ?