| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prior to this point, a dynamic build might have resulted in some runtime
libraries being statically linked into shared objects and executables in
cases where "shared" runtime libraries were actually linker scripts that
linked static versions. This was the case with the MongoDB toolchain and
some distro toolchains, including those installed as updated compiler
versions in RHEL.
The effect of having runtime libraries statically linked was that
symbols from those libraries would end up scattered over the compiled
objects, increasing object sizes and slowing down server startup. Now,
whenever a dynamic build is selected, the user can choose whether to
create "shim" runtime libraries that wrap the static ones.
The default behavior remains as it was before, and dynamic runtime must
be enabled in order to use it.
|
| |
|
|
| |
This reverts commit 2a0e76082be0f2aca82830bcaf91f6d737b842ac.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prior to this point, a dynamic build might have resulted in some runtime
libraries being statically linked into shared objects and executables in
cases where "shared" runtime libraries were actually linker scripts that
linked static versions. This was the case with the MongoDB toolchain and
some distro toolchains, including those installed as updated compiler
versions in RHEL.
The effect of having runtime libraries statically linked was that
symbols from those libraries would end up scattered over the compiled
objects, increasing object sizes and slowing down server startup. Now,
whenever a dynamic build is selected, the user can choose whether to
create "shim" runtime libraries that wrap the static ones.
The default behavior on Linux is that dynamic builds will detect whether
runtime libraries are linker scripts and create shim libraries if any are
found. On Windows, the default is to always use a dynamic runtime library
with dynamic builds. For other platforms, the prior behavior remains
unchanged.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We sometimes have situations where a dependency applies at a large
scope, such as in the case of tcmalloc, which can apply everywhere. What
we have done previously is to hack these dependencies into the LIBDEPS
environment variable by adding a builder to all nodes that can produce a
compiler result. This is, as stated previously, hackish and hard to
control, and it results in adding a Public dependency to all those
nodes.
What we now do instead is to define LIBDEPS_GLOBAL on the *build
environment* (not the Builder node) listing the targets we would like to
push down to all other nodes below that point. This has the effect of
adding those targets as Private dependencies on all Builder nodes from
that point downward, which means some common Public dependencies can be
converted to a Private dependency that is stated only once.
|
| |
|
|
|
|
| |
We use a third-party implementation of std::variant on platforms that do
not include it. This change simply upgrades the third-party source to
the most recent release and then fixes the way we actually depend on it.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Add an option to scons: --use-system-fmt
import.sh: use the upstream libfmt github repo.
StringData fmt interop
noexcept for to_string_view(StringData) hook
noexcept for StringData's rawData() and size()
add fmt to THIRD-PARTY-NOTICES + markdown tweaks
import the fmt LICENSE.rst
update fmt lib revision
|
| |
|
|
| |
standard conformant.
|
| |
|
|
| |
Just compiling in the hash tables for now.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Also allows you to have modules in mongos and the shell, as well as mongod.
Requires changes to the modules, to have SConscript files, and define libraries.
Allows modules to have unit tests, interesting linking rules, dependencies into
mongo, etc.
Still may need to do some work on includes. The mongo-enterprise module has very
simple include requirements, today.
|
|
|
This patch is a reorganization of our build files, which brings them slightly
closer in line with standard SCons organization.
In particular, the SConstruct file sets up the various "build environment"
objects, by examining the local system and command line parameters. Then, it
delegates to some SConscript files, which describe build rules, like how to
compile "mongod" from source.
Typically, you would create several SConscript files for a project this large,
after breaking the project into logical sub projects, such as "platform
abstraction", "data manager", "query optimizer", etc. That will be future work.
For now, we only separate out the special rules for executing smoke tests into
SConscript.smoke. Pretty much all other build rules are in src/mongo/SConscript.
"tools" are placed in site_scons/site_tools.
This patch also includes better support for building and tracking dependencies
among static libraries ("libdeps" and "MergeLibrary"), and some incumbent, minor
restructuring.
This patch introduces a "warning" message from SCons about framework.o having
two rules that generate it. It is harmless, for now, and will be removed in
future work.
Future work also includes eliminating use of the SCons "Glob" utility, and
restructuring the source code into sensible components.
|
