emileclarkb/hammer
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
hammer/tools/windows/clvars.bat

60 lines
2.1 KiB
Batchfile
Raw Normal View History

windows build: Add build scripts + appveyor.yml In order to guarantee that Hammer can build on Windows, an appveyor.yml and associated build scripts will build hammer and its examples. The idea is that as soon as the appveyor.yml exists in the repository, pull requests that would impede Windows portability would be immediately detected. The scripts expect CL.EXE to be in the path, and will produce their results in build/ The highest level of warning is enabled on CL.EXE, minus warnings that bring CL.EXE to a level that ressembles C99. The only notable warning that was disabled is the one that tells you about implicit truncating conversions. Hammer's source code has quite a few implicit conversions say from a 64bit unsigned integer to a integer of a lesser size (signed or otherwise)
2015-08-09 15:20:43 +02:00
REM Don't call me directly
REM Exports CLFLAGS
REM Start with the most strict warning level
set WARNINGS=-W4 -Wall -WX
Deactivate compiler warnings from CL.EXE that fire in hammer Some of them are completely spurious however some (marked FIXME(windows)) may benefit from being looked at.
2015-08-09 18:40:04 +02:00
REM c4457 (declaration shadowing function parameter)
REM FIXME(windows) TODO(uucidl): remove occurence of c4457 and reactivate
REM FIXME(windows) TODO(uucidl): remove occurence of c4456 and reactivate
REM see -Wshadow
set WARNINGS=%WARNINGS% -wd4457 -wd4456
REM c4701 (potentially unitialized local variable)
REM FIXME(windows) TODO(uucidl): remove occurence of c4701 if possible
set WARNINGS=%WARNINGS% -wd4701
windows build: Add build scripts + appveyor.yml In order to guarantee that Hammer can build on Windows, an appveyor.yml and associated build scripts will build hammer and its examples. The idea is that as soon as the appveyor.yml exists in the repository, pull requests that would impede Windows portability would be immediately detected. The scripts expect CL.EXE to be in the path, and will produce their results in build/ The highest level of warning is enabled on CL.EXE, minus warnings that bring CL.EXE to a level that ressembles C99. The only notable warning that was disabled is the one that tells you about implicit truncating conversions. Hammer's source code has quite a few implicit conversions say from a 64bit unsigned integer to a integer of a lesser size (signed or otherwise)
2015-08-09 15:20:43 +02:00
REM We disable implicit casting warnings (c4244), as they occur too often here.
REM Its gcc/clang counterpart is Wconversion which does not seem to
REM be enabled by default.
REM See: [[https://gcc.gnu.org/wiki/NewWconversion#Frequently_Asked_Questions]]
Deactivate compiler warnings from CL.EXE that fire in hammer Some of them are completely spurious however some (marked FIXME(windows)) may benefit from being looked at.
2015-08-09 18:40:04 +02:00
REM
REM Likewise for c4242 (conversion with potential loss of data) and c4267
REM (conversion away from size_t to a smaller type) and c4245 (conversion
REM from int to size_t signed/unsigned mismatch)
set WARNINGS=%WARNINGS% -wd4242 -wd4244 -wd4245 -wd4267
windows build: Add build scripts + appveyor.yml In order to guarantee that Hammer can build on Windows, an appveyor.yml and associated build scripts will build hammer and its examples. The idea is that as soon as the appveyor.yml exists in the repository, pull requests that would impede Windows portability would be immediately detected. The scripts expect CL.EXE to be in the path, and will produce their results in build/ The highest level of warning is enabled on CL.EXE, minus warnings that bring CL.EXE to a level that ressembles C99. The only notable warning that was disabled is the one that tells you about implicit truncating conversions. Hammer's source code has quite a few implicit conversions say from a 64bit unsigned integer to a integer of a lesser size (signed or otherwise)
2015-08-09 15:20:43 +02:00
REM c4100 (unreferenced formal parameter) is equivalent to -Wno-unused-parameter
set WARNINGS=%WARNINGS% -wd4100
REM c4200 (zero-sized array) is a C idiom supported by C99
set WARNINGS=%WARNINGS% -wd4200
REM c4204 (non-constant aggregate initializers) ressembles C99 support
set WARNINGS=%WARNINGS% -wd4204
Deactivate compiler warnings from CL.EXE that fire in hammer Some of them are completely spurious however some (marked FIXME(windows)) may benefit from being looked at.
2015-08-09 18:40:04 +02:00
REM c4201 (anonymous unions) ressembles C11 support.
REM see -std=gnu99 vs -std=c99
Allow windows users to include hammer.h We substitute H_GCC_ATTRIBUTE to any occurence of __attribute__ and disable its function with non gcc, non clang compilers. We use a H_ macro so as to not pollute users' namespaces. On windows build without c4201 so as to allow anonymous struct. This shows hammer is not C99 compliant but rather C11.
2015-08-09 17:44:47 +02:00
set WARNINGS=%WARNINGS% -wd4201
Deactivate compiler warnings from CL.EXE that fire in hammer Some of them are completely spurious however some (marked FIXME(windows)) may benefit from being looked at.
2015-08-09 18:40:04 +02:00
REM c4820 (warnings about padding) and c4324 (intentional padding) are
REM not useful
set WARNINGS=%WARNINGS% -wd4820 -wd4324
windows build: Add build scripts + appveyor.yml In order to guarantee that Hammer can build on Windows, an appveyor.yml and associated build scripts will build hammer and its examples. The idea is that as soon as the appveyor.yml exists in the repository, pull requests that would impede Windows portability would be immediately detected. The scripts expect CL.EXE to be in the path, and will produce their results in build/ The highest level of warning is enabled on CL.EXE, minus warnings that bring CL.EXE to a level that ressembles C99. The only notable warning that was disabled is the one that tells you about implicit truncating conversions. Hammer's source code has quite a few implicit conversions say from a 64bit unsigned integer to a integer of a lesser size (signed or otherwise)
2015-08-09 15:20:43 +02:00
REM c4710 (inlining could not be performed) is not useful
set WARNINGS=%WARNINGS% -wd4710
REM c4255 ( () vs (void) ambiguity) is not useful
set WARNINGS=%WARNINGS% -wd4255
Deactivate compiler warnings from CL.EXE that fire in hammer Some of them are completely spurious however some (marked FIXME(windows)) may benefit from being looked at.
2015-08-09 18:40:04 +02:00
REM c4127 (conditional expression is constant) is not useful
set WARNINGS=%WARNINGS% -wd4127
REM c4668 (an undefined symbol in a preprocessor directive) is not useful
set WARNINGS=%WARNINGS% -wd4668
windows build: Add build scripts + appveyor.yml In order to guarantee that Hammer can build on Windows, an appveyor.yml and associated build scripts will build hammer and its examples. The idea is that as soon as the appveyor.yml exists in the repository, pull requests that would impede Windows portability would be immediately detected. The scripts expect CL.EXE to be in the path, and will produce their results in build/ The highest level of warning is enabled on CL.EXE, minus warnings that bring CL.EXE to a level that ressembles C99. The only notable warning that was disabled is the one that tells you about implicit truncating conversions. Hammer's source code has quite a few implicit conversions say from a 64bit unsigned integer to a integer of a lesser size (signed or otherwise)
2015-08-09 15:20:43 +02:00
Deactivate compiler warnings from CL.EXE that fire in hammer Some of them are completely spurious however some (marked FIXME(windows)) may benefit from being looked at.
2015-08-09 18:40:04 +02:00
REM we use sprintf so this should be enabled
windows build: Add build scripts + appveyor.yml In order to guarantee that Hammer can build on Windows, an appveyor.yml and associated build scripts will build hammer and its examples. The idea is that as soon as the appveyor.yml exists in the repository, pull requests that would impede Windows portability would be immediately detected. The scripts expect CL.EXE to be in the path, and will produce their results in build/ The highest level of warning is enabled on CL.EXE, minus warnings that bring CL.EXE to a level that ressembles C99. The only notable warning that was disabled is the one that tells you about implicit truncating conversions. Hammer's source code has quite a few implicit conversions say from a 64bit unsigned integer to a integer of a lesser size (signed or otherwise)
2015-08-09 15:20:43 +02:00
set DEFINES=-D_CRT_SECURE_NO_WARNINGS
windows build: Build with debug symbols
2015-08-09 17:02:49 +02:00
set CLFLAGS=-Od -Z7 %DEFINES% %WARNINGS% -Debug
Reference in a new issue Copy permalink