Change location of the dmd binary (druntime) #1
Conversation
Uses a wildcard instead of the OS name under the assumption that there's only OS directory per OS
andralex
changed the title
|
Are all branches that the auto-tester builds ready to cut over together? I'm guessing not and that there needs to be a fall back while the changes make their way through the various releases. (ditto for the other pull) |
Please see the discussion at dlang/dmd#6489 |
|
Unless I'm missing something, backwards compatibility is easy here. Check new location for binary. If it exists, use that. If it doesn't, look in the old location. |
|
@braddr this may be possible but testing the respective PR has a fixed cost for me, i.e. I'd need to install the unittester, learn its workings etc. Could you please take this over? Let me know, thanks! |
|
Looks like stable has picked up the changes since this was filed, so backwards compatibility isn't as important as it was. The DMD Yebblies will fail if not synced before it's built next, but that's almost certainly going to be the case anyway. I'll merge and get the changes deployed to a couple redundant hosts (ie, can be pulled from the fleet if it's breaking the builds) to make sure they're working correctly. If they're ok, then I'll update the rest of the fleet in a couple days. |
|
For what it's worth, I'd be happy to drop the command line setting of the DMD variable in the auto-tester, but the win32.mak and win64.mak files in both druntime and phobos would need to be updated to default to the same path structure as posix.mak uses. Currently they both default to using the shell's path to find a dmd to use, which is really not advisable in a controlled reproducible continuous testing environment. |
|
@braddr following up. Is there any lingering issue we need to look at? |
|
Yes, the windows layout is different than the posix layout. See also pull #3 |
Uses a wildcard instead of the OS name under the assumption that there's only OS directory per OS