https://docs.mongodb.org/manual/release-notes/3.2/
Created attachment 419348 [details] mongodb-3.2.0.ebuild
Created attachment 419350 [details, diff] mongodb-3.2.0-fix-scons.patch
Created attachment 419352 [details] mongodb-3.2-test-build.log.bz2
Mongo tools ebuild from 3.0.7 works ok Changes in the ebuild: - adding specific version deps as taken from src/third_party in mongodb - valgrind is used in some sources, maybe instead of dep we can remove those includes? - we only run the js integration tests as it tests the binary with real data Thoughts?
I skimmed the build log and I wonder how long the entire emerge process took to build the binaries and do the tests?
Speaking as a user, when I emerge'd mongodb-3.0.7, and installed it as a new deployment for me, it looks like that defaulted to the mmapv1 storage engine. In mongodb-3.2.0, the default storage engine is WiredTiger, however when the database starts up it will automatically detect whether mmapv1 is in use and switch to mmapv1. I don't have mission critical databases installed yet, so I can follow the mongodb manual for changing the storage engine in 3.0.7 from mmapv1 to WiredTiger. That is, I mongodump all my data, change the dbpath to a new one, create that dbpath with user 'mongodb' as the owner, change the /etc/mongodb.conf file to specify the WiredTiger engine (and of course the new dbpath), start a mongod instance up, then use mongorestore to restore all my databases. Supposing I do all the above, and then emerge this ebuild so I can upgrade to 3.2.0. Will the WiredTiger storage engine choice and the new dbpath still be honored when the upgrade is done? Or will I need to edit an updated /etc/mongodb.conf to specify these?
I successfully converted my mongodb 3.0.7 deployment to use the WiredTiger storage engine. In addition to the new dbpath I opted to change the logfile name to /var/log/mongodb/mongtodbwt.log as well. WiredTiger appears to have started up nicely. All databases are restored and I have access to the test documents. I will wait a little for any comments here and then try Tomas' ebuild on my system. Tomas, I apologize for not getting the accented characters to show up correctly on your first name. I'm not sure how to make them render as I type.
Should pkg_setup() in the ebuild test whether the mongod server is running and if it is, warn the user to shut down the server and then stop the ebuild? The pkg_postinst() probably needs to be made more specific now for this version. You can't directly upgrade a mongod 2.x deployment to 3.2.0. Instead 2.x must first be upgraded to 3.0.x and from there one can upgrade 3.0.x to 3.2.0. I will try to develop a patch to help with this. I'm very new and inexperienced with ebuilds so feel free to correct any attachments I post.
Created attachment 419418 [details, diff] Patch #1 for pkg_setup() This checks whether mongodb-3.2.0.ebuild is replacing an installed mongodb version in the 2.0 series. If so, it issues a warning message and the ebuild terminates without installing. One cannot directly upgrade from mongodb 2.x to mongodb 3.2.
Created attachment 419422 [details, diff] Patch #2 for pkg_setup() Patch #2 for pkg_setup() should be applied right after patch #1 for pkg_setup(). It tests whether the mongod server is running. If so, it prints a warning to the screen and terminates the ebuild. The user needs to shut down the mongod server prior to upgrading.
Created attachment 419424 [details, diff] Patch #3 for pkg_setup() Patch #3 for pkg_setup() should be applied after patch #2 for pkg_setup(). This patch tests whether the group 'mongodb' already exists on the running system. If it does not exist, the new group is created. Then it tests whether the user 'mongodb' exists on the system. If it does not exist, it creates the user.
I have not yet tested any of the patches 1, 2, or 3 that I submitted yet, in an actual ebuild. I want to create one more patch for pkg_postinst() then I will test the patches.
Created attachment 419430 [details, diff] Patch #4 for pkg_postinst() This patch changes the pkg_postinst() message. Updated URL links are added and the subject focus is on the 3.2 version of mongodb.
Created attachment 419432 [details, diff] Combined patches to mongodb-3.2.0.ebuild This shows all the patches I've submitted, patch 1 through 4, to the mongodb-3.2.0.ebuild file. I am still learning how to create patches, so please excuse my errors. I will test the new ebuild file soon and report back with my results.
Created attachment 419458 [details] mongodb-3.2.0.ebuild Adding test deps and remove system tcmalloc.
(In reply to Bob Cochran from comment #5) > I skimmed the build log and I wonder how long the entire emerge process took > to build the binaries and do the tests? Without tests: real 4m36.313s user 53m33.516s sys 9m2.839s With tests: real 21m48.043s user 62m1.638s sys 11m41.623s Tested on a 20 core 3.1GHz server ;)
Thanks for your work guys ! @Tomas, does your ebuild include Bob's remarks / patches ? @Lujeni, will you plz try this out and report ?
I have an *.ebuild file which contains all of Tomas' changes plus my own patches, which I will post here later this evening (I'm on Eastern Standard Time, being on the east coast of the USA.) I'm embarassed to say that I don't know how to test my own ebuild file. I started out thinking I should use an "overlay", and I recently installed layman on my system after working on my patches for this version bump, but it seems I have more learning to do before I can get an overlay environment properly set up and a way to test a 3.2.0 ebuild file. I will check the Gentoo user forums to see if I can learn more. I get the impression that first I have to declare an overlay directory to layman, and then that directory has to be initialized in a particular way, and it is the initialization that I am failing to do. Later this evening -- I will post my own updated mongodb-3.2.0.ebuild file for consideration and testing.
Created attachment 420140 [details] incorporates Tomas' changes and Bob's patches This ebuild should include all of Tomas' changes plus Bob Cochran's patches. I have not tested it yet, but will try to learn how to do so effectively and report my results.
(In reply to Bob Cochran from comment #9) > Created attachment 419418 [details, diff] [details, diff] > Patch #1 for pkg_setup() > > This checks whether mongodb-3.2.0.ebuild is replacing an installed mongodb > version in the 2.0 series. If so, it issues a warning message and the ebuild > terminates without installing. One cannot directly upgrade from mongodb 2.x > to mongodb 3.2. I wouldn't die after checking this, because what if you have a system with 2.4 and want to clean the data and start with 3.2? I would suggest just printing a note.
(In reply to Bob Cochran from comment #10) > Created attachment 419422 [details, diff] [details, diff] > Patch #2 for pkg_setup() > > Patch #2 for pkg_setup() should be applied right after patch #1 for > pkg_setup(). It tests whether the mongod server is running. If so, it prints > a warning to the screen and terminates the ebuild. The user needs to shut > down the mongod server prior to upgrading. Why you think so? I always update while the server is running for minimal downtime. The binaries will have the deps loaded in memory and the binary will not get rewritten until you restart the server.
(In reply to Bob Cochran from comment #11) > Created attachment 419424 [details, diff] [details, diff] > Patch #3 for pkg_setup() > > Patch #3 for pkg_setup() should be applied after patch #2 for pkg_setup(). > This patch tests whether the group 'mongodb' already exists on the running > system. If it does not exist, the new group is created. Then it tests > whether the user 'mongodb' exists on the system. If it does not exist, it > creates the user. I don't understand why. For this we have the enewuser/enewgroup functions, they will add the user/group if they don't exist and do nothing otherwise, why doing the checking here? Did you have any problems with this?
(In reply to Bob Cochran from comment #13) > Created attachment 419430 [details, diff] [details, diff] > Patch #4 for pkg_postinst() > > This patch changes the pkg_postinst() message. Updated URL links are added > and the subject focus is on the 3.2 version of mongodb. I agree we can add some information regarding WireTiger being default in vesion 3.2. By the way, the link in the patch: https://docs.mongodb.org/release-notes/3.0-upgrade/#change-storage-engine-to-wiredtiger is a 404.
Created attachment 420218 [details] mongodb-3.2.0.ebuild Adding info regarding upgrading < 3.0 and about WiredTiger being default.
(In reply to Tomáš Mózes from comment #20) > (In reply to Bob Cochran from comment #9) > > Created attachment 419418 [details, diff] [details, diff] [details, diff] > > Patch #1 for pkg_setup() > > > > This checks whether mongodb-3.2.0.ebuild is replacing an installed mongodb > > version in the 2.0 series. If so, it issues a warning message and the ebuild > > terminates without installing. One cannot directly upgrade from mongodb 2.x > > to mongodb 3.2. > > I wouldn't die after checking this, because what if you have a system with > 2.4 and want to clean the data and start with 3.2? I would suggest just > printing a note. You want to kill the entire ebuild / upgrade process if an installation has a version of MongoDB prior to 3.0. You cannot upgrade directly from 2.4 to 3.2. Please read the documentation provided by the company MongoDB -- the upstream vendor. https://docs.mongodb.org/manual/release-notes/3.2-upgrade/ If you are at version 2.4 then you cannot upgrade directly to 3.0. First you must upgrade 2.4 to 2.6 and only then can you upgrade 2.6 to 3.0. They define an upgrade process. https://docs.mongodb.org/manual/release-notes/3.0-upgrade/#change-storage-engine-to-wiredtiger When I wrote my matches I spent quite a lot of time checking the mongodb.org website for upgrade instructions. The patches I suggest follow those instructions. I think that in addition, the user should get a direct warning to dump his or her databases using mongodump before this ebuild proceeds. A reminder to do a backup with mongodump never hurts the user and could save the person from a disaster.
(In reply to Tomáš Mózes from comment #22) > (In reply to Bob Cochran from comment #11) > > Created attachment 419424 [details, diff] [details, diff] [details, diff] > > Patch #3 for pkg_setup() > > > > Patch #3 for pkg_setup() should be applied after patch #2 for pkg_setup(). > > This patch tests whether the group 'mongodb' already exists on the running > > system. If it does not exist, the new group is created. Then it tests > > whether the user 'mongodb' exists on the system. If it does not exist, it > > creates the user. > > I don't understand why. For this we have the enewuser/enewgroup functions, > they will add the user/group if they don't exist and do nothing otherwise, > why doing the checking here? Did you have any problems with this? I don't know if 'enewuser' and/or 'enewgroup' will raise an error if the user and group already exist. If an error is raised, that could affect later processing in some way. The cleanest way around it is to simply check if the user and group exists and do not attempt to add either user or group if they do. This is conservative code. It doesn't hurt anything by checking and could save a problem later on. You don't want to attempt an action on a system's users and groups if you do not need to in the first place.
(In reply to Tomáš Mózes from comment #21) > (In reply to Bob Cochran from comment #10) > > Created attachment 419422 [details, diff] [details, diff] [details, diff] > > Patch #2 for pkg_setup() > > > > Patch #2 for pkg_setup() should be applied right after patch #1 for > > pkg_setup(). It tests whether the mongod server is running. If so, it prints > > a warning to the screen and terminates the ebuild. The user needs to shut > > down the mongod server prior to upgrading. > > Why you think so? I always update while the server is running for minimal > downtime. The binaries will have the deps loaded in memory and the binary > will not get rewritten until you restart the server. You need to read the MongoDb upgrade documentation. https://docs.mongodb.org/manual/release-notes/3.2-upgrade/ The upstream vendor always recommends shutting down a running instance of MongoDb.
(In reply to Bob Cochran from comment #25) > (In reply to Tomáš Mózes from comment #20) > > (In reply to Bob Cochran from comment #9) > > > Created attachment 419418 [details, diff] [details, diff] [details, diff] [details, diff] > > > Patch #1 for pkg_setup() > > > > > > This checks whether mongodb-3.2.0.ebuild is replacing an installed mongodb > > > version in the 2.0 series. If so, it issues a warning message and the ebuild > > > terminates without installing. One cannot directly upgrade from mongodb 2.x > > > to mongodb 3.2. > > > > I wouldn't die after checking this, because what if you have a system with > > 2.4 and want to clean the data and start with 3.2? I would suggest just > > printing a note. > > You want to kill the entire ebuild / upgrade process if an installation has > a version of MongoDB prior to 3.0. > > You cannot upgrade directly from 2.4 to 3.2. Please read the documentation > provided by the company MongoDB -- the upstream vendor. > > https://docs.mongodb.org/manual/release-notes/3.2-upgrade/ > > If you are at version 2.4 then you cannot upgrade directly to 3.0. First you > must upgrade 2.4 to 2.6 and only then can you upgrade 2.6 to 3.0. They > define an upgrade process. > > https://docs.mongodb.org/manual/release-notes/3.0-upgrade/#change-storage- > engine-to-wiredtiger > > When I wrote my matches I spent quite a lot of time checking the mongodb.org > website for upgrade instructions. The patches I suggest follow those > instructions. > > I think that in addition, the user should get a direct warning to dump his > or her databases using mongodump before this ebuild proceeds. A reminder to > do a backup with mongodump never hurts the user and could save the person > from a disaster. Hello, I was referring to systems where you can delete your data. For example in testing or for logging purposes, you can simply update the binary from 2.4 directly to 3.2, purge the data and start the new binaries. Why would I go from 2.4 -> 2.6 -> 3.0 -> 3.2 if I'm about to delete the data as only new ones are interesting? I wouldn't force anybody to do so.
(In reply to Bob Cochran from comment #26) > (In reply to Tomáš Mózes from comment #22) > > (In reply to Bob Cochran from comment #11) > > > Created attachment 419424 [details, diff] [details, diff] [details, diff] [details, diff] > > > Patch #3 for pkg_setup() > > > > > > Patch #3 for pkg_setup() should be applied after patch #2 for pkg_setup(). > > > This patch tests whether the group 'mongodb' already exists on the running > > > system. If it does not exist, the new group is created. Then it tests > > > whether the user 'mongodb' exists on the system. If it does not exist, it > > > creates the user. > > > > I don't understand why. For this we have the enewuser/enewgroup functions, > > they will add the user/group if they don't exist and do nothing otherwise, > > why doing the checking here? Did you have any problems with this? > > I don't know if 'enewuser' and/or 'enewgroup' will raise an error if the > user and group already exist. If an error is raised, that could affect later > processing in some way. The cleanest way around it is to simply check if the > user and group exists and do not attempt to add either user or group if they > do. This is conservative code. It doesn't hurt anything by checking and > could save a problem later on. You don't want to attempt an action on a > system's users and groups if you do not need to in the first place. As I said before, those functions take care of that. Adding those checks just duplicates code. Test yourself by running emerge mongodb twice, do you get any errors or you just think you may get an error? From https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/user.eclass: enewuser() { # get the username local euser=$1; shift if [[ -z ${euser} ]] ; then eerror "No username specified !" die "Cannot call enewuser without a username" fi # lets see if the username already exists if [[ -n $(egetent passwd "${euser}") ]] ; then return 0 fi einfo "Adding user '${euser}' to your system ..."
(In reply to Bob Cochran from comment #27) > (In reply to Tomáš Mózes from comment #21) > > (In reply to Bob Cochran from comment #10) > > > Created attachment 419422 [details, diff] [details, diff] [details, diff] [details, diff] > > > Patch #2 for pkg_setup() > > > > > > Patch #2 for pkg_setup() should be applied right after patch #1 for > > > pkg_setup(). It tests whether the mongod server is running. If so, it prints > > > a warning to the screen and terminates the ebuild. The user needs to shut > > > down the mongod server prior to upgrading. > > > > Why you think so? I always update while the server is running for minimal > > downtime. The binaries will have the deps loaded in memory and the binary > > will not get rewritten until you restart the server. > > You need to read the MongoDb upgrade documentation. > > https://docs.mongodb.org/manual/release-notes/3.2-upgrade/ > > The upstream vendor always recommends shutting down a running instance of > MongoDb. You start your MongoDB 3.0 instance on your dataset, it will load the libraries and start working on the data. Later when you start upgrading your MongoDB instance, the running instance is not affected in any way. The new binary and libraries are loaded just when you restart your MongoDB instance. I've never had problems with this during the years, not with MySQL, MariaDB, MongoDB, PostgreSQL. Did you?
(In reply to Tomáš Mózes from comment #30) > (In reply to Bob Cochran from comment #27) > > (In reply to Tomáš Mózes from comment #21) > > > (In reply to Bob Cochran from comment #10) > > > > Created attachment 419422 [details, diff] [details, diff] [details, diff] [details, diff] [details, diff] > > > > Patch #2 for pkg_setup() > > > > > > > > Patch #2 for pkg_setup() should be applied right after patch #1 for > > > > pkg_setup(). It tests whether the mongod server is running. If so, it prints > > > > a warning to the screen and terminates the ebuild. The user needs to shut > > > > down the mongod server prior to upgrading. > > > > > > Why you think so? I always update while the server is running for minimal > > > downtime. The binaries will have the deps loaded in memory and the binary > > > will not get rewritten until you restart the server. > > > > You need to read the MongoDb upgrade documentation. > > > > https://docs.mongodb.org/manual/release-notes/3.2-upgrade/ > > > > The upstream vendor always recommends shutting down a running instance of > > MongoDb. > > You start your MongoDB 3.0 instance on your dataset, it will load the > libraries and start working on the data. Later when you start upgrading your > MongoDB instance, the running instance is not affected in any way. The new > binary and libraries are loaded just when you restart your MongoDB instance. > I've never had problems with this during the years, not with MySQL, MariaDB, > MongoDB, PostgreSQL. Did you? MongoDB, MariaDB, Oracle all recommend shutting down their servers before doing any upgrade. An example of a non-MongoDB upgrade recommendation from the actual vendor is MariaDB 10 to 10.1. The process they describe includes a shutdown of the server for an upgrade. The upstream vendor's recommendations should be followed in any upgrade process. That is the safest approach.
(In reply to Tomáš Mózes from comment #29) > (In reply to Bob Cochran from comment #26) > > (In reply to Tomáš Mózes from comment #22) > > > (In reply to Bob Cochran from comment #11) > > > > Created attachment 419424 [details, diff] [details, diff] [details, diff] [details, diff] [details, diff] > > > > Patch #3 for pkg_setup() > > > > > > > > Patch #3 for pkg_setup() should be applied after patch #2 for pkg_setup(). > > > > This patch tests whether the group 'mongodb' already exists on the running > > > > system. If it does not exist, the new group is created. Then it tests > > > > whether the user 'mongodb' exists on the system. If it does not exist, it > > > > creates the user. > > > > > > I don't understand why. For this we have the enewuser/enewgroup functions, > > > they will add the user/group if they don't exist and do nothing otherwise, > > > why doing the checking here? Did you have any problems with this? > > > > I don't know if 'enewuser' and/or 'enewgroup' will raise an error if the > > user and group already exist. If an error is raised, that could affect later > > processing in some way. The cleanest way around it is to simply check if the > > user and group exists and do not attempt to add either user or group if they > > do. This is conservative code. It doesn't hurt anything by checking and > > could save a problem later on. You don't want to attempt an action on a > > system's users and groups if you do not need to in the first place. > > As I said before, those functions take care of that. Adding those checks > just duplicates code. Test yourself by running emerge mongodb twice, do you > get any errors or you just think you may get an error? > > From https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/user.eclass: > > enewuser() { > # get the username > local euser=$1; shift > if [[ -z ${euser} ]] ; then > eerror "No username specified !" > die "Cannot call enewuser without a username" > fi > > # lets see if the username already exists > if [[ -n $(egetent passwd "${euser}") ]] ; then > return 0 > fi > einfo "Adding user '${euser}' to your system ..." After seeing the actual code for `enewuser', that looks okay. I'm not sure about function enewgroup.
(In reply to Tomáš Mózes from comment #28) > (In reply to Bob Cochran from comment #25) > > (In reply to Tomáš Mózes from comment #20) > > > (In reply to Bob Cochran from comment #9) > > > > Created attachment 419418 [details, diff] [details, diff] [details, diff] [details, diff] [details, diff] > > > > Patch #1 for pkg_setup() > > > > > > > > This checks whether mongodb-3.2.0.ebuild is replacing an installed mongodb > > > > version in the 2.0 series. If so, it issues a warning message and the ebuild > > > > terminates without installing. One cannot directly upgrade from mongodb 2.x > > > > to mongodb 3.2. > > > > > > I wouldn't die after checking this, because what if you have a system with > > > 2.4 and want to clean the data and start with 3.2? I would suggest just > > > printing a note. > > > > You want to kill the entire ebuild / upgrade process if an installation has > > a version of MongoDB prior to 3.0. > > > > You cannot upgrade directly from 2.4 to 3.2. Please read the documentation > > provided by the company MongoDB -- the upstream vendor. > > > > https://docs.mongodb.org/manual/release-notes/3.2-upgrade/ > > > > If you are at version 2.4 then you cannot upgrade directly to 3.0. First you > > must upgrade 2.4 to 2.6 and only then can you upgrade 2.6 to 3.0. They > > define an upgrade process. > > > > https://docs.mongodb.org/manual/release-notes/3.0-upgrade/#change-storage- > > engine-to-wiredtiger > > > > When I wrote my matches I spent quite a lot of time checking the mongodb.org > > website for upgrade instructions. The patches I suggest follow those > > instructions. > > > > I think that in addition, the user should get a direct warning to dump his > > or her databases using mongodump before this ebuild proceeds. A reminder to > > do a backup with mongodump never hurts the user and could save the person > > from a disaster. > > > Hello, I was referring to systems where you can delete your data. For > example in testing or for logging purposes, you can simply update the binary > from 2.4 directly to 3.2, purge the data and start the new binaries. Why > would I go from 2.4 -> 2.6 -> 3.0 -> 3.2 if I'm about to delete the data as > only new ones are interesting? I wouldn't force anybody to do so. A gentoo system could be running (for example) MongoDB version 2.4.x. If it is, any upgrade process to 3.2 should stop because the product vendor says you cannot directly upgrade from 2.4 to 3.2, regardless of a specific use case, the state of the data or the end user's actual management of data. MongoDB publishes that recommendation. Any upgrade package should respect the process detailed by the product vendor.
(In reply to Bob Cochran from comment #32) > (In reply to Tomáš Mózes from comment #29) > > (In reply to Bob Cochran from comment #26) > > > (In reply to Tomáš Mózes from comment #22) > > > > (In reply to Bob Cochran from comment #11) > > > > > Created attachment 419424 [details, diff] [details, diff] [details, diff] [details, diff] [details, diff] [details, diff] > > > > > Patch #3 for pkg_setup() > > > > > > > > > > Patch #3 for pkg_setup() should be applied after patch #2 for pkg_setup(). > > > > > This patch tests whether the group 'mongodb' already exists on the running > > > > > system. If it does not exist, the new group is created. Then it tests > > > > > whether the user 'mongodb' exists on the system. If it does not exist, it > > > > > creates the user. > > > > > > > > I don't understand why. For this we have the enewuser/enewgroup functions, > > > > they will add the user/group if they don't exist and do nothing otherwise, > > > > why doing the checking here? Did you have any problems with this? > > > > > > I don't know if 'enewuser' and/or 'enewgroup' will raise an error if the > > > user and group already exist. If an error is raised, that could affect later > > > processing in some way. The cleanest way around it is to simply check if the > > > user and group exists and do not attempt to add either user or group if they > > > do. This is conservative code. It doesn't hurt anything by checking and > > > could save a problem later on. You don't want to attempt an action on a > > > system's users and groups if you do not need to in the first place. > > > > As I said before, those functions take care of that. Adding those checks > > just duplicates code. Test yourself by running emerge mongodb twice, do you > > get any errors or you just think you may get an error? > > > > From https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/user.eclass: > > > > enewuser() { > > # get the username > > local euser=$1; shift > > if [[ -z ${euser} ]] ; then > > eerror "No username specified !" > > die "Cannot call enewuser without a username" > > fi > > > > # lets see if the username already exists > > if [[ -n $(egetent passwd "${euser}") ]] ; then > > return 0 > > fi > > einfo "Adding user '${euser}' to your system ..." > > > After seeing the actual code for `enewuser', that looks okay. I'm not sure > about function enewgroup. You can open that link and see for yourself :)
Thanks a lot for your work guys I left the pretend message from Bob on the ebuild and made a few adjustements. It's in tree now, don't hesitate to report if it works good for you ;) Cheers
Thanks, Julien! I'm starting an online class with MongoDB University in January, which is devoted to development using the Java programming language. After that class finishes in February or March, I may take a class on MongoDB administration too. I can always learn more. Perhaps later in 2016 I will be able to set up multiple servers for MongoDB replication and then practice the upgrading of replication sets. That depends on my ability to purchase additional hardware, of course. Thanks to everyone for giving me a chance to contribute to a "version bump" type of bug. It is a good experience for me and I've learned from it. Happy holidays to all! Cheers!
(In reply to Ultrabug from comment #35) > It's in tree now, don't hesitate to report if it works good for you ;) Thanks Ultrabug for looking into this. Currently this fails with: scons: done reading SConscript files. usage: scons [OPTION] [TARGET] ... SCons Error: no such option: --variant-dir Seems like these options are no longer supported: scons_opts="--variant-dir=build --cc=$(tc-getCC) --cxx=$(tc-getCXX)"
(In reply to Tomáš Mózes from comment #37) > (In reply to Ultrabug from comment #35) > > It's in tree now, don't hesitate to report if it works good for you ;) > > Thanks Ultrabug for looking into this. Currently this fails with: > > scons: done reading SConscript files. > usage: scons [OPTION] [TARGET] ... > SCons Error: no such option: --variant-dir > > Seems like these options are no longer supported: > scons_opts="--variant-dir=build --cc=$(tc-getCC) --cxx=$(tc-getCXX)" I don't have this problem.. what's your scons version ?
Tried scons 2.3.0 and 2.4.1. In Mongo 3.0 I see these in SConstruct: add_option( "variant-dir", "override variant subdirectory", 1, False ) add_option( "cxx", "compiler to use" , 1 , True ) add_option( "cc", "compiler to use for c" , 1 , True ) I failed to find them in 3.2.
(In reply to Tomáš Mózes from comment #39) > Tried scons 2.3.0 and 2.4.1. > > In Mongo 3.0 I see these in SConstruct: > add_option( "variant-dir", "override variant subdirectory", 1, False ) > add_option( "cxx", "compiler to use" , 1 , True ) > add_option( "cc", "compiler to use for c" , 1 , True ) > > I failed to find them in 3.2. The same here with scons-2.4.1 with Python 3.4
must be py3 related, sorry & fixed !
Thanks, works fine. By the way, why do we require boost 1.57?
(In reply to Tomáš Mózes from comment #42) > Thanks, works fine. > > By the way, why do we require boost 1.57? I must say that I don't recall why, but I'm almost sure I had a good reason to :(
In the third_party src directory there is boost 1.56, so that's why I was wondering :)
