Change OSX32 dmd build to create a 64-bit dmd binary

[yebblies]

I think this is all that's needed. #33

[braddr]

That would certainly do it, but if it's not a build configuration we intend to support, then the posix.mak file inside the dmd repo needs to be altered to either explicitly block it, or implicitly convert a MODEL=32 request to a MODEL=64 build. I'm actually leaning towards the latter. Consider a build process that does an export MODEL=32 before running make in each of the three project directories.

Also, a thought that needs to be followed up on. Doesn't dmd default to building output that matches the way dmd itself was built? ie, a 32 bit dmd produces 32 bit object files, and similar for 64 bit? Doesn't this have implications to a change of default behavior on osx/32? I'm not opposed to it, but it needs to be verified and properly considered if so.

Additionally, there are additional ripple effects that extend beyond the tester into the other build tools. This should not be done quietly.

[yebblies]

This is exactly why I'd prefer to start by making the change in the autotester only. Then if there is anyone out there still using OSX32 (which seems fairly unlikely) their configurations won't break unnecessarily.

Put another way, I don't want to break OSX32, I just want to remove it from the list of tested dmd models.

If there are users out there building their own OSX32 dmd binaries, it will most likely continue to work right up until we switch the compiler to D, at which point a makefile error would be appropriate. I don't like implicitly changing 32 -> 64 because as you said it will change the default to -m64.

[braddr]

Except that changing the auto tester is effectively changing the supported configurations without actually making it official. If it's not being tested, it's broken... I strongly disagree with a behind the scenes not-publicly discussed change like this. If the other tools aren't changed, we risk only finding out during the final steps of building a release. That's a horrible point to discover problems. And it opens the rest of the cans of worms you say you're trying to avoid, but aren't avoidable like that.

[braddr]

@WalterBright and @andralex, you two ought to weigh in on this.

[yebblies]

We don't really support it anyway - an OSX32 dmd binary is not part of the release and has not been for a long time.

I agree that dropping it from the autotester is equivalent to dropping support, but we already lost all of our users when we stopped shipping it in releases. We might as well have dropped it from the autotester then.

If the other tools aren't changed, we risk only finding out during the final steps of building a release. That's a horrible point to discover problems.

I don't see how that's possible, since it's not part of the release.

[WalterBright]

I don't see the point of this PR. What does it cost us to support building a 32 bit dmd? At the minimum, it'll ensure continued portability of the source code.

[yebblies]

I don't see the point of this PR. What does it cost us to support building a 32 bit dmd? At the minimum, it'll ensure continued portability of the source code.

OSX32 dmd won't link with ddmd, and it's time to get the autotesters building ddmd. Switching OSX32 to cross-compiling is the first step. DDMD, DDMD, DDMD.

I'm hoping it's a matter of days until the autotester is building ddmd, and that will need to include the OSX32 target.

[yebblies]

Ping on this. To reiterate, I want to move 32-bit osx dmd binary support into the same category as 64-bit windows dmd binary - that is, not tested but we will accept patches and not intentionally break the build.

@WalterBright I asked you about this at dconf and you agreed it would be acceptable. The alternative would be replacing all uses of size_t in the frontend's interface or changing the calling convention to extern(C) to avoid the mangling mismatch. It's possible but it doesn't seem worthwhile.

@braddr Again, I don't want to break OSX32 or silently change the build. I just want to stop supporting it with the autotester. The breakage will happen later with the switch to D and I see no reason to do it sooner.

[yebblies]

@braddr @WalterBright Can I get a green light on this? All of the other platforms are now green or need cross-compiler-related work.

[WalterBright]

Why does building 32 bit binaries work with Linux DDMD and not OSX?

[yebblies]

Because linux32 mangles size_t as unsigned int in both D and C++, while osx32 mangles it as unsigned long for some stupid reason. D does not have a second 32-bit unsigned integral type to match unsigned long, so we would have to remove all use of size_t from the frontend/glue api. This doesn't seem worth it for what is practically a dead platform.

[WalterBright]

Ok, I understand the problem. So why not leave 32 bit support in for CDMD, and drop it for DDMD? Why does CDMD need to drop it, too?

[yebblies]

Ok, I understand the problem. So why not leave 32 bit support in for CDMD, and drop it for DDMD? Why does CDMD need to drop it, too?

It doesn't, I want to leave it intact. I just want to stop auto-testing it because that configuration is not compatible with DDMD. I do not think it is a good idea to have one configuration not testing DDMD.

This might mean that we don't catch bugs/incompatibilities that only affect osx32, much like the current situation for a msvc-built dmd. I do not think this will be a significant problem becase: 1) Almost nobody is building their own osx32 dmd 2) We are testing linux32 and osx64, so osx32-only incompatibilities are unlikely (most msvc problems are build-system related) 3) Anybody using osx32 must be building it themselves and are therefore not tied to our release cycle, so any reported problems can be easily and quickly resolved.

[braddr]

I just switched the three osx auto testers to only build Darwin_64_64 and Darwin_64_32, dropping Darwin_32. I believe this achieves the desired goal, right?

[yebblies]

Yes! Thankyou Brad!