[SERVER-12898] SConscript for enterprise modules requires SCons version 2.1.0 or greater. Created: 25/Feb/14  Updated: 07/Apr/15  Resolved: 06/Apr/15

Status: Closed
Project: Core Server
Component/s: Build
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Shaun Verch Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Participants:

 Description   

This causes the configure step to fail:

scons: Configure: Checking for C++ header file net-snmp/net-snmp-config.h...
.scons/Linux/nohost/sconf_temp/conftest_21.cpp <-
  |
  |#include "net-snmp/net-snmp-config.h"
  |
  |
g++ -o .scons/Linux/nohost/sconf_temp/conftest_21.o -c -Wnon-virtual-dtor -Woverloaded-virtual -fPIC -fno-strict-aliasing -ggdb -pthread -Wall -Wsign-compare -Wno-unknown-pragmas -Winvalid-pch -Werror -pipe -O3 -Wno-unused-function -Wno-deprecated-declarations -fno-builtin-memcmp -DBOOST_ALL_NO_LIB -D_SCONS -DMONGO_EXPOSE_MACROS -DSUPPORT_UTF8 -DMONGO_OPTIMIZED_BUILD -D_FILE_OFFSET_BITS=64 -DMONGO_SSL -DMONGO_HAVE___THREAD -DMONGO_HAVE_HEADER_UNISTD_H -DMONGO_HAVE_EXECINFO_BACKTRACE "-D{'MONGO_ENTERPRISE_VERSION': 1}" -Ibuild/linux2/cpppath__usr_include_/ssl/third_party/snappy -Ibuild/linux2/cpppath__usr_include_/ssl/third_party/libstemmer_c/include -Ibuild/linux2/cpppath__usr_include_/ssl/third_party/s2 -Ibuild/linux2/cpppath__usr_include_/ssl/third_party/boost -Ibuild/linux2/cpppath__usr_include_/ssl/third_party/pcre-8.30 -Ibuild/linux2/cpppath__usr_include_/ssl -Ibuild/linux2/cpppath__usr_include_/ssl/mongo -I/usr/include .scons/Linux/nohost/sconf_temp/conftest_21.cpp
<command-line>: error: macro names must be identifiers
scons: Configure: no

The problem is at this line: https://github.com/10gen/mongo-enterprise-modules/blob/master/build.py#L6

It should be changed to:

env.Append(CPPDEFINES=[(MONGO_ENTERPRISE_VERSION, 1)]



 Comments   
Comment by Jonathan Reams [ 06/Apr/15 ]

We already bumped the minimum SCons version to 2.3.0 in SERVER-16255.

Comment by Andy Schwerin [ 27/Feb/14 ]

In the 2.7 timeframe, we should bump the minimum supported SCons version, at least for the enterprise builders.

Comment by Shaun Verch [ 27/Feb/14 ]

Confirmed that it works with a recent version of scons.

$ uname -a
Linux client 2.6.32-358.el6.x86_64 #1 SMP Fri Feb 22 00:31:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
$ lsb_release -a
LSB Version:	:base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
Distributor ID:	CentOS
Description:	CentOS release 6.4 (Final)
Release:	6.4
Codename:	Final

Comment by Andy Schwerin [ 26/Feb/14 ]

Try with a newer SCons version. An easy way is to clone https://github.com/andy10gen/scons-multi.git, and run the scons script in the root of that repository. It defaults to 2.3.0, but you can override it by setting the SCONS_VERSION environment variable. I think this is the result of a SCons bug, in which case we could just bump the minimum supported SCons version for the enterprise build. What do uname -a and lsb_release -a return?

Comment by Shaun Verch [ 26/Feb/14 ]

schwerin, I'm not sure, but here's the version information from the machine that had this issue:

$ python --version
Python 2.6.6
$ scons --version
SCons by Steven Knight et al.:
	script: v2.0.1.r5134, 2010/08/16 23:02:40, by bdeegan on cooldog
	engine: v2.0.1.r5134, 2010/08/16 23:02:40, by bdeegan on cooldog
Copyright (c) 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010 The SCons Foundation

Comment by Andy Schwerin [ 26/Feb/14 ]

sverch, is this due to the python version, the SCons version, or something else?

Generated at Thu Feb 08 03:29:58 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.