On Thursday 10 March 2011 01:57:37 Walter Bright wrote: > On 3/9/2011 7:08 PM, Jonathan M Davis wrote: > > Truth be told, I would have thought that it would be a given that there > > would be a 64-bit version of dmd when going to support 64-bit > > compilation and was quite surprised when that was not your intention. > > Adding another set of binaries doubles the testing time and download times > for users.
The testing time, I understand. The download times seems pretty inconsequential to me and not a big deal at all (and as Gour points out, you could have separate zip files for separate architectures). However, it's a given that people are going to want a full 64-bit binary and to some extent will expect it. It's not at all normal to produce 64-bit binaries from a 32-bit compiler. Obviously such cross-compiling _can_ be done and sometimes is, but it's not at all the norm, and the more naive folks probably don't even think that you can do that, so having a 32-bit binary produce 64-bit code will confuse the less experienced. Linux distros _definitely_ prefer to have native binaries, and those that try and be 64-bit pure _can't_ use 32-bit binaries unless those binaries are completely statically linked - though multilib is still the most common scenario for 64-bit versions of most Linux distros. Still, they lean heavily towards 64-bit and generally try to use absolutely as little 32-bit as possible. So, having a 32-bit binary produce 64-bit binaries works, and it's better than having no 64-bit support, but in the long run, it really is preferable to have a 64-bit binary for dmd. I understand if that's not exactly a high priority at the moment (and I agree that there are more important issues), but I would still expect that we'd get a 64-bit dmd binary eventually. - Jonathan M Davis