This is to give us a way to let which boost to use toggleable in the
source code as BOOSTDIR_BASENAME, and let build enviornments configure
where to find appropriately named boost folders via BOOSTDIR_BASEDIR.
This isn't pretty, and CMake's FindBoost is a far better way to do this,
but it'll work for now.
This fixes a long standing weird issue of doing non-docker builds of FDB
can hit problems of $CC not being defined in link-wrapper.sh. It turns
out that this is because the official docker image defines CC in the
environment, and no one else does that.
Instead, we can just force Make to propagate its setting of CC into the
environment, thus requiring no extra configuration to be able to do a
build.
I'm really not proud of how I did this though.
It must be run from the same environment as one's editor (ie. not in the
docker image) so that the paths are correct.
This includes...
* A minimal vcxproj file to list all the source files required for the build.
Some future Visual Studio user can come along and replace it with a real
actual vcxproj file with all the other metadata that I didn't bother to copy.
* A local.mk file to specify all the custom flags and libraries we need for
the build/link of the TLS plugin.
* Including the project in the list of all FDB sub-projects
* Fixes `make clean` to wipe all of lib/, including libFDBLibTLS.so
And offers a target of `bin/FDBLibTLS.so` that can be built, and I have
verified that it works with simulation.
Note that this requires a build image that contains the previous Dockerfile changes.
This appears to have caused performance regressions, which will need to be investigated.
This reverts commit 0b0284ba21989a0b8377f0a4d1057e3e7cd5fae1.
This reverts commit 4bde728b0eb8d277c8f59bfaf24869da67c68c47.
...via moving it all to linux-only. Clang is picky about flags, and the osx
linker doesn't accept -z flags. Technically, this will likely break
clang-on-linux, but that's not a config that we run and I'll probably end up
fixing it later.
This makes us fully position independant and have a noexec stack. There's a
small chance that the former part of that can interfere with
gdb/corefiles/stackdumps, but we'll handle that if it becomes a problem.
Andrew Noyes