This is not a search and replace of __MING32__ with _WIN32.
There are places where __MINGW32__ is still used and all changes are
tested with MSVC 2019 compiler. Although, this commit alone will not work
on MSVC because there are plenty of other things to be done which are
seperated into multiple PR. PR OSGeo#289 is the one that "works" on MSVC and
unix as well. But that contains too many changes which shouldn't in a single
PR. Even though this PR alone won't compile GRASS GIS on MSVC, it sure will
not break existing compilers which I think is very important.

Complete support for MSVC will be ready after 2/3 PRs

OSGeo#289

This is not a search and replace of __MING32__ with _WIN32.
There are places where __MINGW32__ is still used and all changes are
tested with MSVC 2019 compiler. Although, this commit alone will not work
on MSVC because there are plenty of other things to be done which are
seperated into multiple PR. PR OSGeo#289 is the one that "works" on MSVC and
unix as well. But that contains too many changes which shouldn't in a single
PR. Even though this PR alone won't compile GRASS GIS on MSVC, it sure will
not break existing compilers which I think is very important.

Complete support for MSVC will be ready after 2/3 PRs

OSGeo#289

This is not a search and replace of __MING32__ with _WIN32.
There are places where __MINGW32__ is still used and all changes are
tested with MSVC 2019 compiler. Although, this commit alone will not work
on MSVC because there are plenty of other things to be done which are
seperated into multiple PR. PR OSGeo#289 is the one that "works" on MSVC and
unix as well. But that contains too many changes which shouldn't in a single
PR. Even though this PR alone won't compile GRASS GIS on MSVC, it sure will
not break existing compilers which I think is very important.

Complete support for MSVC will be ready after 2/3 PRs

OSGeo#289

* cmake support preparation: use of INFINITY and NAN

- use of `INFINITY` rather than only division by zero (this is supported by gcc and other compilers but not on Windows)
- use of `NAN` rather than only division by zero

Extracted from WIP PR #289

Further changes on top:

- fix indentation
- revert void* arithmetic change
- remove superfluous comments
- use 0 (zero) to init integers
- 0/0 = NAN, 1/0 = INFINITY
- Include math.h for Windows
- Use c++ include
- r.series: add INFINITY
- apply clang-format to match reformatting in `main` by using `for i in $(gh pr view 2681 --json files --jq '.files.[].path') ; do clang-format -i $i ; done`

Co-authored-by: @rkanavath
Co-authored-by: @nilason

* cmake support preparation: use of INFINITY and NAN

- use of `INFINITY` rather than only division by zero (this is supported by gcc and other compilers but not on Windows)
- use of `NAN` rather than only division by zero

Extracted from WIP PR OSGeo#289

Further changes on top:

- fix indentation
- revert void* arithmetic change
- remove superfluous comments
- use 0 (zero) to init integers
- 0/0 = NAN, 1/0 = INFINITY
- Include math.h for Windows
- Use c++ include
- r.series: add INFINITY
- apply clang-format to match reformatting in `main` by using `for i in $(gh pr view 2681 --json files --jq '.files.[].path') ; do clang-format -i $i ; done`

Co-authored-by: @rkanavath
Co-authored-by: @nilason

* cmake support preparation: use of INFINITY and NAN

- use of `INFINITY` rather than only division by zero (this is supported by gcc and other compilers but not on Windows)
- use of `NAN` rather than only division by zero

Extracted from WIP PR OSGeo#289

Further changes on top:

- fix indentation
- revert void* arithmetic change
- remove superfluous comments
- use 0 (zero) to init integers
- 0/0 = NAN, 1/0 = INFINITY
- Include math.h for Windows
- Use c++ include
- r.series: add INFINITY
- apply clang-format to match reformatting in `main` by using `for i in $(gh pr view 2681 --json files --jq '.files.[].path') ; do clang-format -i $i ; done`

Co-authored-by: @rkanavath
Co-authored-by: @nilason

Based on original work by Rashad Kanavath in 2020 with pull request:
#289

This update introduces preliminary support for building and installing
GRASS GIS using CMake across multiple platforms, including Windows with
MSVS, Linux, and macOS. The installation can be performed using either
the traditional GRASS file structure or a structure that complies with
the Filesystem Hierarchy Standard (FHS).

Co-authored-by: Rashad Kanavath <[email protected]>
Co-authored-by: Markus Neteler <[email protected]>
Co-authored-by: Loïc Bartoletti <[email protected]>
Co-authored-by: Aaron Saw <[email protected]>
Co-authored-by: Nicklas Larsson <[email protected]>
Co-authored-by: Huidae Cho <[email protected]>
Co-authored-by: Mahesh Maddineni <[email protected]>
Co-authored-by: Kandel Nelson <[email protected]>
Co-authored-by: Edouard Choinière <[email protected]>

This is not a search and replace of __MING32__ with _WIN32.
There are places where __MINGW32__ is still used and all changes are
tested with MSVC 2019 compiler. Although, this commit alone will not work
on MSVC because there are plenty of other things to be done which are
seperated into multiple PR. PR #289 is the one that "works" on MSVC and
unix as well. But that contains too many changes which shouldn't in a single
PR. Even though this PR alone won't compile GRASS GIS on MSVC, it sure will
not break existing compilers which I think is very important.

Complete support for MSVC will be ready after 2/3 PRs

OSGeo#289

This is not a search and replace of __MING32__ with _WIN32.
There are places where __MINGW32__ is still used and all changes are
tested with MSVC 2019 compiler. Although, this commit alone will not work
on MSVC because there are plenty of other things to be done which are
seperated into multiple PR. PR #289 is the one that "works" on MSVC and
unix as well. But that contains too many changes which shouldn't in a single
PR. Even though this PR alone won't compile GRASS GIS on MSVC, it sure will
not break existing compilers which I think is very important.

Complete support for MSVC will be ready after 2/3 PRs

OSGeo#289

This is not a search and replace of __MING32__ with _WIN32.
There are places where __MINGW32__ is still used and all changes are
tested with MSVC 2019 compiler. Although, this commit alone will not work
on MSVC because there are plenty of other things to be done which are
seperated into multiple PR. PR #289 is the one that "works" on MSVC and
unix as well. But that contains too many changes which shouldn't in a single
PR. Even though this PR alone won't compile GRASS GIS on MSVC, it sure will
not break existing compilers which I think is very important.

Complete support for MSVC will be ready after 2/3 PRs

OSGeo#289

Co-authored-by: Rashad Kanavath <[email protected]>

This is not a search and replace of __MING32__ with _WIN32.
There are places where __MINGW32__ is still used and all changes are
tested with MSVC 2019 compiler. Although, this commit alone will not work
on MSVC because there are plenty of other things to be done which are
seperated into multiple PR. PR #289 is the one that "works" on MSVC and
unix as well. But that contains too many changes which shouldn't in a single
PR. Even though this PR alone won't compile GRASS GIS on MSVC, it sure will
not break existing compilers which I think is very important.

Complete support for MSVC will be ready after 2/3 PRs

OSGeo#289

Co-authored-by: Rashad Kanavath <[email protected]>