It is difficult to maintain one build system, let alone two - especially
if one build system is known to be better maintained and the other build
system continues to be used - with bug and feature requests raised
against it.
The maintainers are aware that there are people using the CMake system,
but believe that the extra maintainability of only having one build
system, combined with the knowledge that the current CI system
demonstrates that all supported architectures are working with the
Makefiles make the use of these Makefiles a more sustainable direction.
* Address shellcheck concerns with n2n_gateway.sh script
* Rename n2n_gateway.sh to live with all the other scripts (and update docs)
* Rename hack_fakeautoconf to make it clearly a shell script
* Address shellcheck concerns with hack_fakeautoconf.sh
* Rename python scripts to match other n2n tools
* Fix windows compile - when streamlining the use of hack_fakeautoconf.sh, I forgot to update all uses of this script
* Add an example cross compile build
* Harmonise the naming to reflect full architecture and if it is a real package or not
* Add some more example cross compile targets
* Only one RPM package is created, so use the singular word
* Dont use build triplet for OS packages, use the OS prefered arch name
* Add some cross compiling documentation to the Building.md
* Provide a minimal reimplementation of our autoconf, to try windows builds
* Try building with windows
* Fix thinko in spelling
* Ensure shell script runs inside a shell
* Add a hack to aid include discovery
* Just keep adding tech debt...
* Assume that we will have slashes in some of the replacement strings and avoid that char with sed
* Restore one slash
* Hack around the tools makefile interdependancy bug
* A correct cflags include hack for each compile dir
* Ensure we link against winsock (note, even though this says 32bit, it should link the 64bit library ... I think)
* Bad link ordering if we dont use LDLIBS
* Remove unused make variable
* Remove makefile duplication using inheritance (this does mean you can no longer cd tools; make, but must do make tools)
* Add missing library for win32
* Show OS variable
* Make hack autoconf more robust for tests on non gitlab runners
* Remove no longer used substitutions from hack autoconf
* Add missing include path to tools under win32
* Build the win32 subdir when the compiler is Msys
* The different subdirs have different dependancies
* Ensure we can find the include files
* Fix library link ordering
* Ensure the tools dir can find the special win32 lib
* Deal with the differing basic type sizes on both linux/64bit and windows/64bit
* Document the steps to mimic the github windows/mingw build locally - to allow for simpler debugging
* Ensure branch name in instructions matches my test branch name
* Clarify the shell needed to build with mingw
* Since the makefile depends on knowing the OS, raise a fatal error if we cannot determine this
* Handling different compile environments is hard.
- Linux: sane and reasonable results for both uname -s (=Linux) and
uname -o (=GNU/Linux)
- Windows/Mingw: insane results for uname -s
(=MSYS_NT-$MAJOR.$MINOR-$BUILDNR) but sane results for uname -o (Msys)
- Macos: sane results for uname -s (=Darwin) but does not support
uname -o at all
* Revamp the way that Mingw is detected
* Avoid attempting to generate gcovr report when running under windows
* Whoops, isolate the right step
* Fix spelling mistake
* win32/Makefile: Remove unused setting and add comment
* ensure that all win32 includes use the same expected path
* Allow simpler cross compilation by letting configure pass the CC and AR environment through
* Avoid multiple '_CRT_SECURE_NO_WARNINGS redefined' warnings
* Convert to a consolidated CONFIG_TARGET variable to select any different compile options
* Use the more generic printf defines to avoid warnings on mingw
* Update mingw build docs
* English better for reader happy make
* Address a number of mingw compiler warnings
* Fix Visual C compile
* Be sure to document some of the hacky nature of the mingw build
