make test kept building the environment, even after it was built.
Running make --debug=v test first showed that build/CmdLine/bin/$(TARGET)/CmdLine.exe is not found. It is on the file system. build/Tests/bin/$(TARGET)/Tests.dll seems to be found without issue, so the directory shouldn't be an issue. I don't see a case sensitive problem.
I removed CmdLine.exe from the Makefile as a test, and it progressed further. Now there is a weird timestamp issue that is repeating:
Prerequisite `build/CmdLine/bin/Debug/CKAN-GUI.exe' is newer than target `c
kan.exe'.
Prerequisite `build/CmdLine/bin/Debug/CKAN.dll' is newer than target `ckan.
exe'.
Prerequisite `build/CmdLine/bin/Debug/log4net.dll' is newer than target `ck
an.exe'.
Prerequisite `build/CmdLine/bin/Debug/ChinhDo.Transactions.dll' is newer th
an target `ckan.exe'.
Prerequisite `build/CmdLine/bin/Debug/Newtonsoft.Json.dll' is newer than ta
rget `ckan.exe'.
Prerequisite `build/CmdLine/bin/Debug/ICSharpCode.SharpZipLib.dll' is newer
than target `ckan.exe'.
Prerequisite `build/CmdLine/bin/Debug/CommandLine.dll' is newer than target
`ckan.exe'.
Must remake target `ckan.exe'.
ckan.exe is built from those files, yet running bin/build seems to consistently cause the ckan.exe timestamp to be older than its dependencies.
This problem is intermittent.
Luckily it happened long enough for me to capture the above logs. I'm not seeing the it happen right now, though.
I wonder if it might help to break bin/build into components relevant to the build targets instead of doing it in one lump sum?
Asking @politas for some review, I think especially with recent changes to build system this can be closed out as outmoded.
@dbent is the one that understands the cmake build process.
Anyhoo, this is still technically a thing, ./build test will trigger a new build, but this is an intentional design choice. Making the build conditional requires additional logic, additional logic means more potential for bugs, more potential for bugs means more times I or someone else has to investigate. So since a full build is so fast anyway (~10s from start to finish on my machine) it's no big deal to keep things simple and just redo it all the time.
Maybe if the build time started to creep up into the minutes, it might be worth it. Until then if you really, really, really want to not have to rebuild to run tests, you can use the test+only target instead of test, i.e. ./build test+only, the target assumes the build already ran and will break if it didn't. This is what Travis does to shave a bit of time off the 10 different builds it does.
I agree with this design decision. Can we move from xbuild to msbuild to avoid those warnings, though? I do think a ./build release would be nice rather than having to remember ./build --configuration=Release
Can we move from xbuild to msbuild to avoid those warnings, though?
I'll upgrade Cake when I get a chance, pretty sure recent releases use msbuild on Mac/Linux if available.
I do think a
./build releasewould be nice rather than having to remember./build --configuration=Release
Sure.