Bug 14180 – dlang.org: make apidocs-release requires user to hamstring own machine

Also see discussion at https://github.com/D-Programming-Language/dlang.org/pull/758. In brief: "make apidocs-release" does not work unless the user hamstrings their own machine that might have a working dmd installation on it. On my machine, if I run it I get: ====================================== From https://github.com/D-Programming-Language/dmd * branch HEAD -> FETCH_HEAD Current release: 2.066.1 ../dub-0.9.22/bin/dub build --root=dpl-docs --compiler=/tmp/.stable_dmd-2.066.1/dmd2/osx/bin/dmd Error executing command build: Failed to invoke the compiler /tmp/.stable_dmd-2.066.1/dmd2/osx/bin/dmd to determine the build platform: /Users/aalexandre/code/d/druntime/import/core/bitop.d(376): Error: found 'pure' when expecting '{' /Users/aalexandre/code/d/druntime/import/core/bitop.d(376): Error: mismatched number of curly brackets /Users/aalexandre/code/d/druntime/import/core/bitop.d(381): Error: mismatched number of curly brackets /Users/aalexandre/code/d/druntime/import/core/bitop.d(383): Error: mismatched number of curly brackets /Users/aalexandre/code/d/druntime/import/core/bitop.d(389): Error: mismatched number of curly brackets /Users/aalexandre/code/d/druntime/import/core/bitop.d(390): Error: mismatched number of curly brackets /Users/aalexandre/code/d/druntime/import/core/bitop.d(391): Error: mismatched number of curly brackets /Users/aalexandre/code/d/druntime/import/core/bitop.d(392): Error: mismatched number of curly brackets /Users/aalexandre/code/d/druntime/import/core/bitop.d(393): Error: mismatched number of curly brackets /Users/aalexandre/code/d/druntime/import/core/bitop.d(394): Error: mismatched number of curly brackets /Users/aalexandre/code/d/druntime/import/core/bitop.d(395): Error: mismatched number of curly brackets /Users/aalexandre/code/d/druntime/import/core/bitop.d(396): Error: mismatched number of curly brackets /Users/aalexandre/code/d/druntime/import/core/bitop.d(397): Error: mismatched number of curly brackets /Users/aalexandre/code/d/druntime/import/core/bitop.d(398): Error: mismatched number of curly brackets /Users/aalexandre/code/d/druntime/import/core/bitop.d(399): Error: mismatched number of curly brackets /Users/aalexandre/code/d/druntime/import/core/bitop.d(400): Error: mismatched number of curly brackets /Users/aalexandre/code/d/druntime/import/core/bitop.d(401): Error: mismatched number of curly brackets /Users/aalexandre/code/d/druntime/import/core/bitop.d(402): Error: mismatched number of curly brackets /Users/aalexandre/code/d/druntime/import/core/bitop.d(403): Error: mismatched number of curly brackets /Users/aalexandre/code/d/druntime/import/core/bitop.d(404): Error: mismatched number of curly brackets /Users/aalexandre/code/d/druntime/import/core/bitop.d(405): Error: mismatched number of curly brackets make: *** [dpl-docs] Error 2 ====================================== I should note that my ~/dmd.conf makes for a perfectly valid dmd platform.

The easiest solution would be to drop the --compiler=... switch. I think I just chose to use the locally built compiler to enable compilation on a system that doesn't yet have a compiler at all, but it might instead also just have been because the command for generating the JSON documentation already used it. So should I just drop the --compiler switch and assume that a working DMD is found in PATH?

(In reply to Sönke Ludwig from comment #1) > The easiest solution would be to drop the --compiler=... switch. I think I > just chose to use the locally built compiler to enable compilation on a > system that doesn't yet have a compiler at all, but it might instead also > just have been because the command for generating the JSON documentation > already used it. > > So should I just drop the --compiler switch and assume that a working DMD is > found in PATH? That was the situation before, and there was code that didn't compile depending on what D version was installed on the client machine. FWIW if you remove --compiler, I'll have errors on my machine because my default compiler is HEAD and for some reason can't compile that.

(In reply to Andrei Alexandrescu from comment #2) > (In reply to Sönke Ludwig from comment #1) > > So should I just drop the --compiler switch and assume that a working DMD is > > found in PATH? > > That was the situation before, and there was code that didn't compile > depending on what D version was installed on the client machine. FWIW if you > remove --compiler, I'll have errors on my machine because my default > compiler is HEAD and for some reason can't compile that. Hmm, so is there a way to use the one at /tmp/.stable_dmd-2.066.1/dmd2/osx/bin/dmd without it reading /etc/dmd.conf? Or would the one at $(DMD_DIR)-${LATEST}/src/dmd be a better choice? The relevant code in posix.mak doesn't look familiar to me, so I'm a little unsure what the intention has been to do it exactly like it is now.

(In reply to Sönke Ludwig from comment #3) > (In reply to Andrei Alexandrescu from comment #2) > > (In reply to Sönke Ludwig from comment #1) > > > So should I just drop the --compiler switch and assume that a working DMD is > > > found in PATH? > > > > That was the situation before, and there was code that didn't compile > > depending on what D version was installed on the client machine. FWIW if you > > remove --compiler, I'll have errors on my machine because my default > > compiler is HEAD and for some reason can't compile that. > > Hmm, so is there a way to use the one at > /tmp/.stable_dmd-2.066.1/dmd2/osx/bin/dmd without it reading /etc/dmd.conf? One option is to use the -conf= flag for dmd that Martin added recently. Of course that's not available with 2.066 :o). Another possibility is to plant a dmd.conf file in the working directory. Martin disagreed with that. I happen to think that's a good solution (in fact a great solution considering right now things are just broken) but I defer to him because he's the release czar. > Or would the one at $(DMD_DIR)-${LATEST}/src/dmd be a better choice? The > relevant code in posix.mak doesn't look familiar to me, so I'm a little > unsure what the intention has been to do it exactly like it is now. I, too, think that's better but again I got vetoed by Martin because "it's just one more short download". Martin - guess you need to fix this :o).

(In reply to Andrei Alexandrescu from comment #4) > Another possibility is to plant a dmd.conf file in the working directory. > Martin disagreed with that. I happen to think that's a good solution (in > fact a great solution considering right now things are just broken) but I > defer to him because he's the release czar. FWIW, this is what we do for LDC (when building druntime/Phobos), and it works quite nicely so far. Our build process is quite different, though.

(In reply to Andrei Alexandrescu from comment #4) > Another possibility is to plant a dmd.conf file in the working directory. > Martin disagreed with that. I happen to think that's a good solution (in > fact a great solution considering right now things are just broken) but I > defer to him because he's the release czar. But you'd need one for each different OS. You could probably cd into the STABLE_DMD dir, then you have a working dmd.conf in your working dir. Quite a hack IMO, and depends on dub not changing the working dir. Or you copy the dmd.conf from the STABLE_DMD into dlang.org before building. But seriously this discussion just shows that we should change the dmd.conf search order. When did you ever have such trouble with your gcc specs? https://github.com/D-Programming-Language/dmd/pull/4256#issuecomment-68931542 > > Or would the one at $(DMD_DIR)-${LATEST}/src/dmd be a better choice? The > > relevant code in posix.mak doesn't look familiar to me, so I'm a little > > unsure what the intention has been to do it exactly like it is now. > > I, too, think that's better but again I got vetoed by Martin because "it's > just one more short download". > > Martin - guess you need to fix this :o). Trouble with LATEST is that LATEST changes the moment we tag a new version, which means we need to fix any dmd version dependent issues/deprecations in dpl-docs and it's dependencies before tagging a new dmd version. This still causes a lot of trouble and makes it unnecessarily harder to build a release, because nobody tests these targets with a recent dmd. It will hopefully improve when all dependencies and dmd releases become even more stable and when we autotest dlang.org.

(In reply to Martin Nowak from comment #6) > (In reply to Andrei Alexandrescu from comment #4) > > Another possibility is to plant a dmd.conf file in the working directory. > > Martin disagreed with that. I happen to think that's a good solution (in > > fact a great solution considering right now things are just broken) but I > > defer to him because he's the release czar. > > But you'd need one for each different OS. Nonono, I'm thinking empty dmd.conf and pass everything needed in the command line. > You could probably cd into the STABLE_DMD dir, then you have a working > dmd.conf in your working dir. Quite a hack IMO, and depends on dub not > changing the working dir. Yah, agreed. > Or you copy the dmd.conf from the STABLE_DMD into dlang.org before building. I say again: dmd.conf is a distraction. Plant an empty one to end all lookup and pass everything needed in the command line. > But seriously this discussion just shows that we should change the dmd.conf > search order. When did you ever have such trouble with your gcc specs? > https://github.com/D-Programming-Language/dmd/pull/4256#issuecomment-68931542 That's a total red herring. > > > Or would the one at $(DMD_DIR)-${LATEST}/src/dmd be a better choice? The > > > relevant code in posix.mak doesn't look familiar to me, so I'm a little > > > unsure what the intention has been to do it exactly like it is now. > > > > I, too, think that's better but again I got vetoed by Martin because "it's > > just one more short download". > > > > Martin - guess you need to fix this :o). > > Trouble with LATEST is that LATEST changes the moment we tag a new version, > which means we need to fix any dmd version dependent issues/deprecations in > dpl-docs and it's dependencies before tagging a new dmd version. > This still causes a lot of trouble and makes it unnecessarily harder to > build a release, because nobody tests these targets with a recent dmd. > It will hopefully improve when all dependencies and dmd releases become even > more stable and when we autotest dlang.org. I'm thinking generalizing LATEST into fetching any specific release we need, dmd and druntime and phobos. All code is there, it needs only minor adjustments. Replace LATEST with SPECIFIC_VERSION or something then you should be able to say make SPECIFIC_VERSION=2.066.1 dpl-docs to fetch all needed.

Should be solved by using a stable compiler.