lto stuff remains for now
since native builds work
(cherry picked from commit 37814472af5e7c35d514bae16d19b08050765d52)
i'm not porting the UNIX-tier cppfs thing
(cherry picked from commit d6edbd789534d4fd0bce6c8c2418347cd80bebdb)
none of this had to be specified directly ffs
(cherry picked from commit 5dbefa7131a6fe0b2006c90ecdba7e466fdd1ecc)
stop breaking shit reee
(cherry picked from commit 14be89902ccc75a7fc21863593da393ca976d0d4)
* 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
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."
enable lokinet shared library on win32
TODO: define an API to expose from this library
currently, it resorts to exporting *everything*
including system implementation details that otherwise
should remain hidden out of sight
(i.e. the winsock2 load stubs for new socket API, or entire libstdc++ classes!)