On Monday, November 25, 2013 08:43:37 Iain Buclaw wrote: > On Sunday, 24 November 2013 at 22:38:15 UTC, Jonathan M Davis > > wrote: > > But it is true that a large portion of our platform-specific > > problems stem from > > types that vary in size. > > Size *and* format. ie: big/little endian, 80/96/128bit reals, > etc... > > My biggest problem with stuff like this (see link in original > post) is that after so much combined effort getting things > working across multiple architectures - just take a look at any > pull for version MIPS, PPC, PPC64, SPARC, ARM, etc... or my pull > for implementing std.math for almost all (double-double reals the > main one missing), IEEE real types - someone goes ahead and > breaks support for all these targets and no one thinks or lifts > an eyebrow over it. > > Library maintainers need to stop writing code with the assumption > that their code is only going to be used with dmd and x86, and > they should have stopped doing it 6 months ago.
In a lot of cases, I expect that folks just forget. In others, they don't realize that what they're doing won't work on other targets. I'm aware of some of the issues involved with all of that, but I fully expect that I'm not aware of them all, and I expect that it's the same with many of the other developers. And since the autotester only targets dmd and x86(_64), non- x86(_64) breakage isn't caught when it occurs - though it's my understanding at this point, that the integration between gdc or ldc and the front-end is not smooth enough to be able to simply rebuild them when the front-end gets updated, which would likely be required to integrate them into the autotester. I don't know how to solve the main issue other than educating people better. Personally, I don't get involved with druntime pulls all that often, because I often don't feel qualified to do so (and I should get involved with Phobos pulls more than I do, but I'm busy enough these days that that's hard - though hopefully that will be improving relatively soon). I expect that there's enough work to get there that it'll be a while before we do, but if we could reach the point where gdc and ldc could be built as part of the autotester (especially if that can be done with multiple architectures), that would go a long way towards fixing the breakage problems. - Jonathan M Davis