link libatomic if we're targeting 486
link libatomic.a if we're targeting windows
idk what the hell MSVC does for -arch:IA32
we already set the c++14 flag early on
strip target selection flags from MSVC builds and clang-cl
c++14 does not propagate to compile tests
This commit refactors functionality from the Router class into separate,
dedicated classes.
There are a few behavior changes that came as a result of discussion on
what the correct behavior should be.
In addition, many things Router was previously doing can now be provided
callback functions to alert the calling point when the asynchronous
action completes, successfully or otherwise.
- Multi-stage docker build (final image only 15MB!)
- Build in release mode
- Fix bug with release mode
- Fix compiler being dumb AF
- Disable FORTIFY for now
- Enable LTO when making a staticly linked release
- Fix some gcc specific warnings
- Refactor cmake stuff into multiple files
* Import cxxopts to replace getopts usage
* Add visual studio build things
* Fixup abseil build parts
* Replace __attribute__((unused)) with ABSL_ATTRIBUTE_UNUSED
* Fixup minor windows build issues
* Replace getopts usage
* Temporarily fixup .rc files
* More minor windows fixes
* Get a working build
* Revert .rc files
* Revert changes to nodedb
select 64-bit target by default (since normal devs REEEEEEEE at the sight of 4 byte ptrs)
pretty much every _other_ linux/unix has a c++17 windows compiler
This reverts commit a844c61049.
moved platform-specifc stuff *to* platform specifc lib
removed -Wno-format on windows and *actually* turn on proper format checking
here using compiler-specifc extension for C99
While the absl:: namespace is aliased to std:: in a
standard win32 build, it also needlessly adds the
library to the build process, only to discard most
of it at link time. This also makes the distinction
between Abseil STL and G++ STL more explicit, to avoid
some forms of confusion.
From the product page:
"...We think not: if you look at the preprocessor conditional
structure in our string_view.h you'll see that we are trying
to identify whether your C++ installation has std::string_view.
If you do, absl::string_view is defined only as an alias to the
standard type. If you don't, you get a C++11/C++14 compatible
implementation of the type. This means you can adopt Abseil,
and for types we are b you can use the type from the absl
namespace. As soon as your project is built with the appropriate
compiler/standard library version, we'll fall away and leave you
with the standard type, albeit spelled funny. Better: as soon as
you know that your project will only build with the appropriate
language version you can run tools that we will provide to change
the places that refer to absl::string_view to spell it std::string_view
-- since those are the same type, this is safe to do, even across
API boundaries.
So, one reason you might want to adopt Abseil: early access to facilities
from upcoming C++ standard library releases, with a clear migration path."