Unroll some unity files in the nounity build

[mellery451]

This PR makes the nounity (classic) build behave slightly more correctly by unrolling a few more unity sources. I expect the nounity builds to fail on this branch without the changes in #2368, so this change should only be merged along with or after PR2368 (which is already passed and low risk).

[ripplelabs-jenkins]

Jenkins Build Summary

Built from this commit

Built at 20180221 - 09:28:33

Test Results

Build Type	Result	Status
clang.debug.unity	1001 cases, 0 failed, t: 394s	PASS ✅
coverage	1001 cases, 0 failed, t: 631s	PASS ✅
clang.debug.nounity	999 cases, 0 failed, t: 303s	PASS ✅
gcc.debug.unity	1001 cases, 0 failed, t: 442s	PASS ✅
gcc.debug.nounity	999 cases, 0 failed, t: 322s	PASS ✅
clang.release.unity	1000 cases, 0 failed, t: 481s	PASS ✅
gcc.release.unity	1000 cases, 0 failed, t: 519s	PASS ✅

[scottschurr]

Changes look good to me. Everything builds well for me on mac OS. I'll give a thumbs up after the debug nounity failures on Jenkins are figured out. That's interesting because debug.nounity worked just fine for me on mac OS -- both cmake and scons.

You also did us the favor of identifying a bit of dead code. If you'd like to remove that dead code in this pull request you can cherry-pick this commit: scottschurr@f22f907

And, just for a thought for future work, we could consider replacing uses of getComputerName() with asio::host_name(). But that would be a different pull request.

[scottschurr]

Okay, now I see why the debug.nounity builds failed. This pull request is not (yet) sitting atop #2368. Once those includes are in place this commit will build just fine on Jenkins.

Thanks for making this change. 👍.

[mellery451]

@scottschurr -- yep, in this case, I wanted to see the failure (to make sure I captured the original deficiency). Now that we have, I can either cherry pick or just wait and rebase. Thanks for your change...I'll grab that shortly.

[miguelportilla]

I am seeing linker errors with nounity on VS2017. This occurs using the VS integrated cmake and the cmake generated VS solution. The unity builds compile fine.

error LNK2001: unresolved external symbol "public: void __cdecl SpookyHash::Init(unsigned __int64,unsigned __int64)" (?Init@SpookyHash@@QEAAX_K0@Z)

[mellery451]

@miguelportilla the nounity builds are expected to fail in some way because we are missing some key includes. I'm surprised it's a linker error instead of compile error, but chalk that up to VC. If you cherry-pick the changes in #2368, I would expect nounity to work.

[miguelportilla]

@mellery451 Cherry-picking #2368 did not help. Spookyhash is used in the beast hash implementation so I suspect one of the CMakeList.txt changes dealing with beast hash may have something to do with it. Reverting the CMakeList.txt changes (back to 0.90.0-rc1) allows the non unity build to link.

[miguelportilla]

@mellery451 Last commit fixes the issue. The non-unity build is successfully linking. 👍

[mellery451]

rebased. this builds properly with the @MarkusTeufelberger #include fixes, so marking as passed.

[MarkusTeufelberger]

Also check out #2399 :-)

[MarkusTeufelberger]

Should also fix #2159 by the way.

[mellery451]

Merged in 605ace7