Info

This isn't new. Has been this way for quite some time. Steps to reproduce: $ git reset --hard r5.1.0 $ git clean -f -x -d && python buildscripts/scons.py --dbg=off --disable-warnings-as-errors --enable-free-mon=on --enable-http-client=on --opt=on --release --server-js=on --ssl=on --wiredtiger=on --ninja=enabled --use-system-abseil-cpp generate-ninja ... KeyError: 'LIBDEPS_ABSL_CONTAINER_SYSLIBDEP': File "/Users/nwani/repos/mongo/SConstruct", line 5218: env.SConscript( File "/Users/nwani/repos/mongo/src/third_party/scons-3.1.2/scons-local-3.1.2/SCons/Script/SConscript.py", line 597: return _SConscript(self.fs, *files, **subst_kw) File "/Users/nwani/repos/mongo/src/third_party/scons-3.1.2/scons-local-3.1.2/SCons/Script/SConscript.py", line 286: exec(compile(scriptdata, scriptname, 'exec'), call_stack[-1].globals) File "/Users/nwani/repos/mongo/src/SConscript", line 22: env.SConscript('third_party/SConscript', exports=['env']) File "/Users/nwani/repos/mongo/src/third_party/scons-3.1.2/scons-local-3.1.2/SCons/Script/SConscript.py", line 597: return _SConscript(self.fs, *files, **subst_kw) File "/Users/nwani/repos/mongo/src/third_party/scons-3.1.2/scons-local-3.1.2/SCons/Script/SConscript.py", line 286: exec(compile(scriptdata, scriptname, 'exec'), call_stack[-1].globals) File "/Users/nwani/repos/mongo/src/third_party/SConscript", line 373: env['LIBDEPS_ABSL_CONTAINER_SYSLIBDEP'], File "/Users/nwani/repos/mongo/src/third_party/scons-3.1.2/scons-local-3.1.2/SCons/Environment.py", line 405: return self._dict[key]

Top User Comments

JIRAUSER1263196 commented on Tue, 29 Mar 2022 19:34:41 +0000: Thank you for considering it. At the very least, clients do not end up with a CLI option that is not officially supported. IMHO, that is a better state than before. acm commented on Tue, 29 Mar 2022 02:20:26 +0000: Hi nehaljw.kkd1@gmail.com - I don't like to disappoint, but I'm sorry to say that after considerable internal debate, we have decided not only to not fix the support for building with --use-system-abseil-cpp, but to go so far as to remove that flag entirely. The next LTS release of MongoDB, 6.0, will not offer it. We do not believe that the release model for abseil is suitable for presentation as a system package that we can meaningfully consume. I understand that you may disagree with that decision. The change we made is simple enough (it is linked in this ticket) that it should be straightforward for you to fold a revert into the patch you provided earlier, should you decide that you still wish to build against the system abseil. xgen-internal-githook commented on Mon, 28 Mar 2022 22:47:55 +0000: Author: {'name': 'Andrew Morrow', 'email': 'acm@mongodb.com', 'username': 'acmorrow'} Message: SERVER-61305 Disallow --use-system-abseil-cpp Branch: master https://github.com/mongodb/mongo/commit/51918a385ab8b3fc1f922bede326ff84e846a47b acm commented on Tue, 9 Nov 2021 19:25:35 +0000: No blog post, sorry, but I can assure you that we aren't switching build systems anytime soon. It would be an enormous undertaking for us. I do understand the reluctance to use vendored components. We will see if we can do something smarter that would make this work better. There really isn't any reason in principle that we couldn't consult pkg-config ourselves to get the library names, though of course it would require some effort. But even using the pkg-config approach assumes that the package names are stable. Has abseil committed to a stable set of package names? Meanwhile, I do have a few other pieces of information that you may find interesting: The 5.1 release isn't really intended for use outside Atlas. Please see https://www.mongodb.com/blog/post/new-quarterly-releases-starting-with-mongodb-5-0 I had a look at the conda recipe for mongodb, and noticed that it is using the ninja generator. I don't recommend using the ninja generator for packaging. It is primarily intended for incremental developer builds so they can drive more parallelism to a compile cluster like icecream. It doesn't offer many advantages over a plain SCons build in a CI-type environment where you are building anew each time. The SCons build is the canonical way to build a release, and is what we use to build our releases. JIRAUSER1263196 commented on Tue, 9 Nov 2021 19:08:23 +0000: In the conda forge ecosystem, we try very hard to not link dependencies statically, if we can avoid them. Even if upstream drops the support, I might have to patch it anyway. If mongodb uses CMake, then abseil wouldn't have been a problem, since the targets names would come from the respective find module from the 3rd party library itself. Is there a blog post/JIRA which lists the reasons as to why Scons is so critical? acm commented on Tue, 9 Nov 2021 18:06:36 +0000: Hi nehaljw.kkd1@gmail.com - I started looking into this. The instability of the abseil target names probably renders this impossible to achieve in a good way, unfortunately. Without being able to know the names of the system abseil libraries that support the features we need, we simply can't declare that we depend on them in a meaningful way. As you note, you constantly need to update your patch as the abseil project iterate the names. We may need to go the other way, and just drop support for --use-system-abseil entirely. It probably isn't a good idea anyway, since as far as I know the abseil folks aren't offering any sort of ABI stability assurances, and I don't think most distributions package it. Most projects that use it seem to vendor it. How severe a limitation would it be if conda needed to stop using the flag? Meanwhile, regarding build systems: I know a bit about bazel from prior experience with it in a slightly different context, and I know CMake reasonably well from writing the build system for libmongocxx. However, we currently have no plans to move away from SCons to either of those or to anything else. We are heavily invested in SCons and it affords us a level of flexibility that is hard to achieve with others. JIRAUSER1263196 commented on Sun, 7 Nov 2021 13:53:04 +0000: Although it is not ideal, I've been patching my way around this for quite some time now. https://github.com/conda-forge/mongodb-feedstock/blob/master/recipe/patches/0005-Fix-flags-for-un-vendoring-abseil-cpp.patch . First, it looks ugly, second, I've to update it whenever absl changes target names, which adds to the ugliness. Are there any plans to move to a different build system? I heard somewhere that bazel was a possibility. Please don't!  Try CMake instead?

Steps to Reproduce