Conversation
|
I have broken down the big branching function by moving some of the commandline options to the modules they belong to. Hopefully the parts are OK. |
|
Somehow I completely missed this! I'll have to check this in a few hours... |
85d1d21 to
8c1aca3
Compare
|
Update: MSVC seems to be able to compile hyper.cpp without hitting that internal limit, which is cool. But now MSVC's linker is unhappy for a different reason. I'll look into this. In the meantime, I think it would be safe to cherry-pick efc9e81 if you wanted. |
|
Confirmed — |
|
MSYS2/MinGW-W64 is confirmed to work with the new Makefile.simple |
d400c73 to
60bca9b
Compare
60bca9b to
bb94b2b
Compare
|
Rebased. |
bb94b2b to
4aae7f3
Compare
Lambdas to be stored in `function<void()>` should not return `bool`. Two uses of `std::function` could be just `function`, like everywhere else in the codebase.
…e time.
Before:
time c++ -O2 -DMAC -I/usr/local/include -std=c++11 -march=native
-W -Wall -Wextra -Werror -pedantic -Wno-format-pedantic
-Wno-missing-field-initializers -Wno-unused-parameter
-DCAP_GLEW=0 -DCAP_PNG=0 -c hyper.cpp -o hyper.o
real 2m22.508s
user 2m20.625s
sys 0m1.648s
After:
time c++ -O2 -DMAC -I/usr/local/include -std=c++11 -march=native
-W -Wall -Wextra -Werror -pedantic -Wno-format-pedantic
-Wno-missing-field-initializers -Wno-unused-parameter
-DCAP_GLEW=0 -DCAP_PNG=0 -c hyper.cpp -o hyper.o
real 1m30.515s
user 1m29.793s
sys 0m0.689s
Comparing object file size:
-rw-r--r-- 1 ajo staff 8215036 Jan 5 20:46 old-hyper.o
-rw-r--r-- 1 ajo staff 7538072 Jan 5 20:47 new-hyper.o
Comparing number of symbols:
nm old-hyper.o | wc -l => 12590
nm new-hyper.o | wc -l => 9742
No appreciable difference in link time; the linker takes less than
half a second in either case.
Suppress some spammy warnings on MSVC.
/wd4068 "unknown pragma"
/wd4244 "possible loss of data"
The `setlocal` at the top of appveyor.bat is the appropriate fix for
"Input line too long", according to
https://stackoverflow.com/a/19929778/1424877
https://stackoverflow.com/questions/16821784/input-line-is-too-long-error-in-bat-file#comment63959177_19929778
It keeps the global PATH from getting longer every time appveyor.yml
reinvokes appveyor.bat. Besides, having appveyor.bat change the global PATH
is almost certainly a terrible idea!
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.15.26726\include\utility(241):
warning C4267: 'initializing': conversion from 'size_t' to '_Ty1', possible loss of data
with [_Ty1=int]
MSVC cannot handle `extern` declarations inside a member function, when that member function is itself inside a namespace: it "forgets" the namespace part when generating the symbol, which leads in this case to an "unresolved symbol" error at link time. Reduced example: https://godbolt.org/z/YSQ--9
4aae7f3 to
d79d261
Compare
MSVC requires `-D_USE_MATH_DEFINES=1` in order to be standards-conforming. https://stackoverflow.com/questions/6563810/m-pi-works-with-math-h-but-not-with-cmath-in-visual-studio util.cpp(197): error C2065: 'M_PI': undeclared identifier MSVC warns on implicit double-to-float conversions: screenshot.cpp(825): warning C4305: 'argument': truncation from 'double' to 'float' screenshot.cpp(827): warning C4305: 'argument': truncation from 'double' to 'float' screenshot.cpp(829): warning C4305: 'argument': truncation from 'double' to 'float'
25e6cc8 to
a05eff5
Compare
|
TravisCI supports Windows now! But I haven't figured out how to build HyperRogue on it yet. |
I'm not sure of the cost/benefit here, but there's no harm in posting a pull request. :)
Benefit: Appveyor will test the MinGW and MSVC builds!
Cost: 120 lines of Appveyor-specific .yml and .bat files. Also, you'll have to give GitHub permissions to Appveyor — and it asks for more permissions than Travis, in suspiciously broken English. 😕
I'd also want to hear from @Danfun64 that I'm not messing up his MinGW build with this change to Makefile.simple.
-DMSVC_COMPILER_LIMITSis only because MSVC is stupid (and non-conforming). I haven't thought of a better easy way to fix that fatal error. I think better but complicated ways would be to rewrite that function as some kind of lookup into a big table of function pointers (expressed as lambdas), or break it down into subfunctions at the points currently indicated by comments (// cheats,// mode changes:,// informational:, etc).