On Wednesday, 4 November 2015 at 09:14:12 UTC, Manu wrote:
> On 4 November 2015 at 18:34, Adrian Matoga via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> On Tuesday, 3 November 2015 at 04:10:57 UTC, Manu wrote:
>>>
>>> On 3 November 2015 at 11:07, mattcoder via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>>>
>>>> On Sunday, 1 November 2015 at 02:36:16 UTC, Manu wrote:
>>>>>
>>>>>
>>>>> ...
>>>>> Does it support Dreamcast? :P
>>>>
>>>>
>>>>
>>>> I don't know if you are being serious here but if yes... what's the catch with Dreamcast? I mean this is a Fan thing or what?
>>>
>>>
>>> I'm just a massive nerd, and the Dreamcast was a great console! :P
>>
>>
>> By the way, since it's called fuji, I assume it runs on Atari. ;)
>
> Hah! That's really pushing the limits!
> I did write some little Atari2600 games once... we even did a 2600
> demo comp once ;)
> Terrible machine!

There's a chance I've seen that demo. what's its title?

I've tried (with success) compiling C for STe with pre-built gcc, I only gave up porting D because I couldn't get my head around these messy patches the Atari gcc port is full of.

Am Wed, 4 Nov 2015 09:37:46 +1000
schrieb Manu via Digitalmars-d <digitalmars-d@puremagic.com>:

> On 3 November 2015 at 17:30, Johannes Pfau via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> > Am Tue, 3 Nov 2015 09:16:47 +1000
> > schrieb Manu via Digitalmars-d <digitalmars-d@puremagic.com>:
> > 
> >> I have a samples directory which it would be theoretically possible to run and see that they don't crash as part of a test run. Also, I'd like to annotate my whole engine quite comprehensively with unittests. It's something that I'm keen to work on, and then it further helps to assure those toolchains remain working.
> >
> > But how exactly would you run these? All CI machines are x86_64. I guess emulators could be a possibility as long as they run headless. We'd need some way to get feedback from the emulator though (test passed/failed). If you're talking about running tests on the x86_64 architecture that should be easy.
> 
> Emulators are the typical approach. Even Android + iOS have emulators
> that can be used for CI.
> Most emulators have such features required to return runtime errors
> back to the host environment for this sort of testing.

OK, that should work. I think the main problem is still the resource
usage when building GCC cross compilers. On Travis-CI we hit the 50
Minute execution limit, on SemaphoreCI we don't have enough temporary
disk space. CircleCI seems to work but I'm not sure if the "build
minutes per month" limit applies to OSS projects.
(Using prebuilt GDC toolchains to do CI for _fuji_ should work fine).


I've added support for devkitPro to our build scripts (I already knew
how to build these compilers so this was easy). We can build devkitARM
(GBA, DS, 3DS, N3DS) and devkitPPC (GC, Wii, WiiU) compilers. devkitPSP
can't be supported as it uses GCC 4.6. The oldest supported GCC version
for GDC  is 4.8.

Here is an build of all these toolchains running on CircleCI:
https://circleci.com/gh/jpf91/GDC/11
In theory this builds ready to use packages and could deploy these to
gdcproject.org as nightly builds.


If you want to build manually, use docker.io:

docker run -v ~/result-dir:/home/build/shared -t jpf91/build-gdc /usr/bin/build-gdc build --toolchain=i686-w64-mingw32/gcc-4.8/devkitPPC --toolchain=i686-w64-mingw32/gcc-4.9/devkitARM


I've also uploaded initial toolchain builds here (untested): ftp://ftp.gdcproject.org/binaries/devkitpro/

I still need to integrate devkitPro builds into the download page, write some documentation and think about a directory layout which isn't confusing when we have multiple devkitpro releases. I'll probably have a look at this next weekend.

On 5 November 2015 at 06:31, Johannes Pfau via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> Am Wed, 4 Nov 2015 09:37:46 +1000
> schrieb Manu via Digitalmars-d <digitalmars-d@puremagic.com>:
>
>> On 3 November 2015 at 17:30, Johannes Pfau via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> > Am Tue, 3 Nov 2015 09:16:47 +1000
>> > schrieb Manu via Digitalmars-d <digitalmars-d@puremagic.com>:
>> >
>> >> I have a samples directory which it would be theoretically possible to run and see that they don't crash as part of a test run. Also, I'd like to annotate my whole engine quite comprehensively with unittests. It's something that I'm keen to work on, and then it further helps to assure those toolchains remain working.
>> >
>> > But how exactly would you run these? All CI machines are x86_64. I guess emulators could be a possibility as long as they run headless. We'd need some way to get feedback from the emulator though (test passed/failed). If you're talking about running tests on the x86_64 architecture that should be easy.
>>
>> Emulators are the typical approach. Even Android + iOS have emulators
>> that can be used for CI.
>> Most emulators have such features required to return runtime errors
>> back to the host environment for this sort of testing.
>
> OK, that should work. I think the main problem is still the resource
> usage when building GCC cross compilers. On Travis-CI we hit the 50
> Minute execution limit, on SemaphoreCI we don't have enough temporary
> disk space. CircleCI seems to work but I'm not sure if the "build
> minutes per month" limit applies to OSS projects.
> (Using prebuilt GDC toolchains to do CI for _fuji_ should work fine).

Travis-CI lets you install things prior to the build, this should work well assuming they cache these sorts of downloads ;)

> devkitPSP can't be supported as it uses GCC 4.6. The oldest supported GCC version for GDC  is 4.8.

Aww! It's one of the platforms I actively support, and works well.
It's also the only MIPS platform, which is a good test bed.
Do you know what's holding it back? Is it possible it may be updated,
or has it just been left to die?

I miss the PS2, but it hasn't been maintained at all :(

> I've also uploaded initial toolchain builds here (untested): ftp://ftp.gdcproject.org/binaries/devkitpro/

Awesome, downloading now...

> I still need to integrate devkitPro builds into the download page, write some documentation and think about a directory layout which isn't confusing when we have multiple devkitpro releases. I'll probably have a look at this next weekend.

This is great! Thanks!
Is there instructions anywhere for attempting to build druntime with
these toolchains so I can have a crack at filling in the gaps there?

On 5 November 2015 at 21:37, Manu <turkeyman@gmail.com> wrote:
> On 5 November 2015 at 06:31, Johannes Pfau via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>
>> I've also uploaded initial toolchain builds here (untested): ftp://ftp.gdcproject.org/binaries/devkitpro/
>
> Awesome, downloading now...

I see these archives are minimal, only the gdc binaries, but there is
also a gcc binary... why is that?
The filesize is very different than the ones bundled in devkitPro; is
it intended that arm-none-eabi-gcc.exe (and friends) overwrite the
ones in the devkitPro distro?

Am Thu, 5 Nov 2015 21:37:50 +1000
schrieb Manu via Digitalmars-d <digitalmars-d@puremagic.com>:

> On 5 November 2015 at 06:31, Johannes Pfau via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> > devkitPSP can't be supported as it uses GCC 4.6. The oldest supported GCC version for GDC  is 4.8.
> 
> Aww! It's one of the platforms I actively support, and works well.
> It's also the only MIPS platform, which is a good test bed.
> Do you know what's holding it back? Is it possible it may be updated,
> or has it just been left to die?

The main problem is that these toolchains use some GCC patches. These need to be ported to newer GCC releases. This is usually the only problem.

I'm not sure if the PSP toolchain is still supported. It seems like the sources weren't modified in the last 4 years. All other PSP buildscripts seem to use the same GCC 4.6 patches, so there's not much we can do.

You could probably ask for some more information in the devkitPro forum.

> I miss the PS2, but it hasn't been maintained at all :(
> 
> > I've also uploaded initial toolchain builds here (untested): ftp://ftp.gdcproject.org/binaries/devkitpro/
> 
> Awesome, downloading now...
> 
> > I still need to integrate devkitPro builds into the download page, write some documentation and think about a directory layout which isn't confusing when we have multiple devkitpro releases. I'll probably have a look at this next weekend.
> 
> This is great! Thanks!
> Is there instructions anywhere for attempting to build druntime with
> these toolchains so I can have a crack at filling in the gaps there?

There's some very basic information here:
http://wiki.dlang.org/GDC/Installation/Generic#Building_only_Druntime.2FPhobos
Only tested on linux though. It should work on windows if you use a
msys2 installation and install the base-devel package.

Note that you need the GCC sources as well (unpatched is OK). These won't be compiled but the druntime Makefile/configure scripts depend on some macros from these sources.

It might be clever to use the same druntime and GCC sources that were used when building these compilers. This means GCC4.8 + gdc-4.8 branch for devkitPPC and GCC4.9 + gdc-4.9 branch for devkitARM.

(I'm not sure if you have to pass some additional devkitPro specifc flags to GCC? If think these could be set using the LDFLAGS/DFLAGS environment variable, but I'm not sure)

Am Thu, 5 Nov 2015 21:59:39 +1000
schrieb Manu via Digitalmars-d <digitalmars-d@puremagic.com>:

> On 5 November 2015 at 21:37, Manu <turkeyman@gmail.com> wrote:
> > On 5 November 2015 at 06:31, Johannes Pfau via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >>
> >> I've also uploaded initial toolchain builds here (untested): ftp://ftp.gdcproject.org/binaries/devkitpro/
> >
> > Awesome, downloading now...
> 
> I see these archives are minimal, only the gdc binaries, but there is
> also a gcc binary... why is that?
> The filesize is very different than the ones bundled in devkitPro; is
> it intended that arm-none-eabi-gcc.exe (and friends) overwrite the
> ones in the devkitPro distro?

That's the reason I still need to write a README ;-)
I'm not sure why the file size could be very different, I'll have a look
at that later.

But yes, the idea is to overwrite the *gcc.exe files. In theory it doesn't really matter, but it's necessary to make the gcc command work with d files (arm-none-eabi-gcc test.d). If you always use arm-none-eabi-gdc you won't need to overwrite the gcc files.


IIRC such a setup (gcc/gdc from different builds, this setup is also used in ArchLinux) can cause problems with LTO. As long as GDC doesn't support LTO this doesn't matter.

We can always start shipping complete GCC toolchains but I'd like to avoid building GDB and all the devkitARM utils (these have some dependencies such as libusb which make building more difficult). So in that case you'd have to overwrite many more files. Maybe I can make full builds work as well, but this will also increase build times a lot.

On 5 November 2015 at 23:42, Johannes Pfau via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> Am Thu, 5 Nov 2015 21:59:39 +1000
> schrieb Manu via Digitalmars-d <digitalmars-d@puremagic.com>:
>
>> On 5 November 2015 at 21:37, Manu <turkeyman@gmail.com> wrote:
>> > On 5 November 2015 at 06:31, Johannes Pfau via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> >>
>> >> I've also uploaded initial toolchain builds here (untested): ftp://ftp.gdcproject.org/binaries/devkitpro/
>> >
>> > Awesome, downloading now...
>>
>> I see these archives are minimal, only the gdc binaries, but there is
>> also a gcc binary... why is that?
>> The filesize is very different than the ones bundled in devkitPro; is
>> it intended that arm-none-eabi-gcc.exe (and friends) overwrite the
>> ones in the devkitPro distro?
>
> That's the reason I still need to write a README ;-)
> I'm not sure why the file size could be very different, I'll have a look
> at that later.
>
> But yes, the idea is to overwrite the *gcc.exe files. In theory it doesn't really matter, but it's necessary to make the gcc command work with d files (arm-none-eabi-gcc test.d). If you always use arm-none-eabi-gdc you won't need to overwrite the gcc files.

Right, this is exactly what I suspected.


> We can always start shipping complete GCC toolchains but I'd like to avoid building GDB and all the devkitARM utils (these have some dependencies such as libusb which make building more difficult). So in that case you'd have to overwrite many more files. Maybe I can make full builds work as well, but this will also increase build times a lot.

Cool, I think this should be fine for now.

On 5 November 2015 at 23:42, Johannes Pfau via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> Am Thu, 5 Nov 2015 21:59:39 +1000
>
> We can always start shipping complete GCC toolchains but I'd like to avoid building GDB and all the devkitARM utils (these have some dependencies such as libusb which make building more difficult). So in that case you'd have to overwrite many more files. Maybe I can make full builds work as well, but this will also increase build times a lot.

Will not building GDB mean that the regular devkitPro GDB has no
knowledge of D symbol demangling?
I thought that support was included in GCC proper some time back?

On Thursday, 5 November 2015 at 11:37:59 UTC, Manu wrote:
> Is there instructions anywhere for attempting to build druntime with
> these toolchains so I can have a crack at filling in the gaps there?

Maybe not what you were asking, but if you want an idea of what needs to be added to druntime when porting to a new OS, take a look at the first 3-4 Android/x86 PRs from a couple years ago:

https://github.com/D-Programming-Language/druntime/pulls?q=is%3Apr+android+is%3Aclosed+sort%3Acreated-asc

Of course, you'll also need to add architecture-specific declarations, you can find those by searching for an existing arch, like "version(ARM)", and modifying the 19 files which refer to it already.

Am Fri, 6 Nov 2015 00:25:00 +1000
schrieb Manu via Digitalmars-d <digitalmars-d@puremagic.com>:

> On 5 November 2015 at 23:42, Johannes Pfau via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> > Am Thu, 5 Nov 2015 21:59:39 +1000
> >
> > We can always start shipping complete GCC toolchains but I'd like to avoid building GDB and all the devkitARM utils (these have some dependencies such as libusb which make building more difficult). So in that case you'd have to overwrite many more files. Maybe I can make full builds work as well, but this will also increase build times a lot.
> 
> Will not building GDB mean that the regular devkitPro GDB has no
> knowledge of D symbol demangling?
> I thought that support was included in GCC proper some time back?

IIRC the D support in GDB is always enabled. So the standard devkitPro builds should work. The GDB version is more interesting. 7.8 was the first version with extended D support and we're now at 7.10. devkitARM uses 7.8, devkitPPC 7.7.

The devkitPro patches for gdb are trivial and only modify the gdb build scripts. It should be easy to port these patches and compile newer gdb versions if necessary.



BTW: If you find some GDB with support for the arm-none-eabi and powerpc-eabi targets these should work as well. The devkitPro GDBs are unmodified standard GDB builds. Other builds might even provide some additional features (python scripting, ...)

I can only highly recommend installing ArchLinux ;-)

Then you can simply use this for devkitARM: https://www.archlinux.org/packages/community/x86_64/arm-none-eabi-gdb/ And building a powerpc-eabi GDB should be simple as well.