scons .

scons /

scons C:\ D:\

scons src/subdir

cd src/subdir
scons -u .

scons -c .

scons -c build export

scons -j 4

env = Environment()

env = Environment(FOO='foo')
env['FOO'] = 'foo'

# initializes msvc to v14.1
env = Environment(MSVC_VERSION="14.1")
env = Environment()
# msvc tool was initialized to default, does not reinitialize
env['MSVC_VERSION'] = "14.1"
env = Environment(tools=[])
env['MSVC_VERSION'] = "14.1"
# msvc tool initialization was deferred, so will pick up new value
env.Tool('default')

env = Environment(parse_flags='-Iinclude -DEBUG -lm')

env = Environment(platform='cygwin')

def my_platform(env):
    env['VAR'] = 'xyzzy'
env = Environment(platform=my_platform)

env = Environment(tools=['msvc', 'lex'])

تنظیم می‌کند: $AS, $ASCOM, $ASFLAGS, $ASPPCOM, $ASPPFLAGS.

استفاده می‌کند: $CC, $CPPFLAGS, $_CPPDEFFLAGS, $_CPPINCFLAGS.

تنظیم می‌کند: $CXX, $CXXVERSION, $SHCXX, $SHOBJSUFFIX.

تنظیم می‌کند: $CC, $CCVERSION, $SHCC.

تنظیم می‌کند: $F77, $SHF77.

تنظیم می‌کند: $LINKFLAGS, $SHLIBSUFFIX, $SHLINKFLAGS.

تنظیم می‌کند: $APPLELINK_COMPATIBILITY_VERSION, $APPLELINK_CURRENT_VERSION, $APPLELINK_NO_COMPATIBILITY_VERSION, $APPLELINK_NO_CURRENT_VERSION, $FRAMEWORKPATHPREFIX, $LDMODULECOM, $LDMODULEFLAGS, $LDMODULEPREFIX, $LDMODULESUFFIX, $LINKCOM, $SHLINKCOM, $SHLINKFLAGS, $_APPLELINK_COMPATIBILITY_VERSION, $_APPLELINK_CURRENT_VERSION, $_FRAMEWORKPATH, $_FRAMEWORKS.

استفاده می‌کند از: $FRAMEWORKSFLAGS.

تنظیم می‌کند: $AR, $ARCOM, $ARFLAGS, $LIBPREFIX, $LIBSUFFIX, $RANLIB, $RANLIBCOM, $RANLIBFLAGS.

تنظیم می‌کند: $AS, $ASCOM, $ASFLAGS, $ASPPCOM, $ASPPFLAGS.

استفاده می‌کند از: $CC, $CPPFLAGS, $_CPPDEFFLAGS, $_CPPINCFLAGS.

تنظیم می‌کند: $CC, $CCCOM, $CCFLAGS, $CFILESUFFIX, $CFLAGS, $CPPDEFPREFIX, $CPPDEFSUFFIX, $INCPREFIX, $INCSUFFIX, $SHCC, $SHCCCOM, $SHCCFLAGS, $SHCFLAGS, $SHOBJSUFFIX.

استفاده می‌کند از: $_CPPDEFFLAGS, $_CPPINCFLAGS.

تنظیم می‌کند: $CC, $CCCOM, $CCDEPFLAGS, $CCFLAGS, $CFILESUFFIX, $CFLAGS, $CPPDEFPREFIX, $CPPDEFSUFFIX, $FRAMEWORKPATH, $FRAMEWORKS, $INCPREFIX, $INCSUFFIX, $SHCC, $SHCCCOM, $SHCCFLAGS, $SHCFLAGS, $SHOBJSUFFIX.

استفاده می‌کند از: $CCCOMSTR, $PLATFORM, $SHCCCOMSTR.

تنظیم می‌کند: $CC, $CCDEPFLAGS, $CCVERSION, $SHCCFLAGS.

تنظیم می‌کند: $CXX, $CXXVERSION, $SHCXXFLAGS, $SHOBJSUFFIX, $STATIC_AND_SHARED_OBJECTS_ARE_THE_SAME.

تنظیم می‌کند: $COMPILATIONDB_COMSTR, $COMPILATIONDB_PATH_FILTER, $COMPILATIONDB_USE_ABSPATH.

تنظیم می‌کند: $FORTRAN, $FORTRANCOM, $FORTRANMODDIR, $FORTRANMODDIRPREFIX, $FORTRANMODDIRSUFFIX, $FORTRANPPCOM, $OBJSUFFIX, $SHFORTRANCOM, $SHFORTRANPPCOM.

استفاده می‌کند از: $CPPFLAGS, $FORTRANFLAGS, $SHFORTRANFLAGS, $_CPPDEFFLAGS, $_FORTRANINCFLAGS, $_FORTRANMODFLAG.

تنظیم می‌کند: $CPPDEFPREFIX, $CPPDEFSUFFIX, $CXX, $CXXCOM, $CXXFILESUFFIX, $CXXFLAGS, $INCPREFIX, $INCSUFFIX, $OBJSUFFIX, $SHCXX, $SHCXXCOM, $SHCXXFLAGS, $SHOBJSUFFIX.

استفاده می‌کند از: $CXXCOMSTR, $SHCXXCOMSTR.

تنظیم می‌کند: $IMPLIBPREFIX, $IMPLIBSUFFIX, $LDMODULEVERSIONFLAGS, $LINKFLAGS, $RPATHPREFIX, $RPATHSUFFIX, $SHLIBPREFIX, $SHLIBSUFFIX, $SHLIBVERSIONFLAGS, $SHLINKCOM, $SHLINKFLAGS, $_LDMODULEVERSIONFLAGS, $_SHLIBVERSIONFLAGS.

فهرست ابزارهای انتخاب‌شده به صورت پیش‌فرض ایستا نیست، بلکه هم به پلتفرم و هم به نرم‌افزارهای نصب‌شده روی آن پلتفرم وابسته است. برخی از ابزارها در صورتی که دستور زیربنایی مربوطه‌شان یافت نشود مقداردهی اولیه نمی‌شوند، و برخی ابزارها از یک فهرست گزینه‌ها بر مبنای «نخستین موردِ یافت‌شده» انتخاب می‌شوند. فهرست نهایی ابزارها را می‌توان با بررسی متغیر ساخت $TOOLS در محیط ساخت مشاهده کرد.

در تمامی پلتفرم‌ها، ابزارهای فهرست زیر در صورت برآورده شدن شرایط مربوطه‌شان انتخاب می‌شوند: filesystem;, wix, lex, yacc, rpcgen, swig, jar, javac, javah, rmic, dvipdf, dvips, gs, tex, latex, pdflatex, pdftex, tar, zip, textfile.

در سیستم‌های لینوکس، فهرست ابزارهای پیش‌فرض این موارد را (بر اساس نخستین مورد یافت‌شده) انتخاب می‌کند: یک کامپایلر C از میان gcc, intelc, icc, cc; یک کامپایلر C++ از میان g++, intelc, icc, cXX; یک اسمبلر از میان gas, nasm, masm; یک پیونددهنده از میان gnulink, ilink; یک کامپایلر Fortran از میان gfortran, g77, ifort, ifl, f95, f90, f77; و یک آرشیوکننده ایستا ar. همچنین تمام موارد یافت‌شده از فهرست زیر را انتخاب می‌کند: m4 rpm.

در سیستم‌های ویندوز، فهرست ابزارهای پیش‌فرض این موارد را (بر اساس نخستین مورد یافت‌شده) انتخاب می‌کند: یک کامپایلر C از میان msvc, mingw, gcc, intelc, icl, icc, cc, bcc32; یک کامپایلر C++ از میان msvc, intelc, icc, g++, cXX, bcc32; یک اسمبلر از میان masm, nasm, gas, 386asm; یک پیونددهنده از میان mslink, gnulink, ilink, linkloc, ilink32; یک کامپایلر Fortran از میان gfortran, g77, ifl, cvf, f95, f90, fortran; و یک آرشیوکننده ایستا از میان mslib, ar, tlib; همچنین تمام موارد یافت‌شده از فهرست زیر را انتخاب می‌کند: msvs, midl.

در سیستم‌های مک‌او‌اس (MacOS)، فهرست ابزارهای پیش‌فرض این موارد را (بر اساس نخستین مورد یافت‌شده) انتخاب می‌کند: یک کامپایلر C از میان gcc, cc; یک کامپایلر C++ از میان g++, cXX; یک اسمبلر as; یک پیونددهنده از میان applelink, gnulink; یک کامپایلر Fortran از میان gfortran, f95, f90, g77; و یک آرشیوکننده ایستا ar. همچنین تمام موارد یافت‌شده از فهرست زیر را انتخاب می‌کند: m4, rpm.

در سیستم‌های BSD که کامپایلر پایه آن‌ها LLVM/clang است (FreeBSD و OpenBSD)، فهرست ابزارهای پیش‌فرض با لینوکس یکسان است، با این تفاوت که کامپایلر C (بر اساس نخستین مورد یافت‌شده) از میان clang, gcc, intelc, icc, cc و کامپایلر C++ از میان clangxx, g++, intelc, icc, cXX انتخاب می‌شود.

فهرست‌های پیش‌فرض برای سایر پلتفرم‌ها را می‌توان با بررسی کد منبع scons یافت (ببینید: SCons/Tool/__init__.py).

مقادیر زیر را تنظیم می‌کند: $DC, $DCOM, $DDEBUG, $DDEBUGPREFIX, $DDEBUGSUFFIX, $DFILESUFFIX, $DFLAGPREFIX, $DFLAGS, $DFLAGSUFFIX, $DINCPREFIX, $DINCSUFFIX, $DLIB, $DLIBCOM, $DLIBDIRPREFIX, $DLIBDIRSUFFIX, $DLIBFLAGPREFIX, $DLIBFLAGSUFFIX, $DLIBLINKPREFIX, $DLIBLINKSUFFIX, $DLINK, $DLINKCOM, $DLINKFLAGPREFIX, $DLINKFLAGS, $DLINKFLAGSUFFIX, $DPATH, $DRPATHPREFIX, $DRPATHSUFFIX, $DVERPREFIX, $DVERSIONS, $DVERSUFFIX, $SHDC, $SHDCOM, $SHDLIBVERSIONFLAGS, $SHDLINK, $SHDLINKCOM, $SHDLINKFLAGS.

وابستگی‌های ضمنی به تصاویر و XIncludeها در صورت برآورده کردن پیش‌نیازهای HTML به‌طور خودکار شناسایی می‌شوند. بدین منظور از شیوه‌نامهٔ کمکی utils/xmldepend.xsl اثر Paul DuBois استفاده می‌شود.

توجه داشته باشید که هیچ پشتیبانی‌ای برای تفکیک کاتالوگ XML ارائه نمی‌شود! این ابزار پردازنده‌های XSLT و رندرکننده‌های PDF را با شیوه‌نامه‌های مشخص‌شده توسط شما فراخوانی می‌کند، همین و بس. باقی کارها بر عهدهٔ شماست و هنگام تفکیک نام‌ها از طریق یک کاتالوگ، همچنان باید بدانید چه کاری انجام می‌دهید.

برای فعال‌سازی ابزار "docbook"، باید نام آن را به سازندهٔ Environment اضافه کنید، مانند این:

env = Environment(tools=['docbook'])

ابزار docbook هنگام راه‌اندازی، تلاش می‌کند پردازندهٔ مورد نیاز xsltproc و یک رندرکنندهٔ PDF، مانند fop را پیدا کند. بنابراین مطمئن شوید که این موارد به متغیر محیطی PATH سیستم شما اضافه شده‌اند و می‌توان آن‌ها را بدون تعیین مسیر کامل، مستقیماً فراخوانی کرد.

برای پایه‌ای‌ترین پردازش Docbook به HTML، باید این موارد را نصب داشته باشید:

رندر گرفتن به PDF مستلزم نصب یکی از برنامه‌های fop یا xep است.

ایجاد یک سند HTML یا PDF بسیار ساده و سرراست است. عبارت:

env = Environment(tools=['docbook'])
env.DocbookHtml('manual.html', 'manual.xml')
env.DocbookPdf('manual.pdf', 'manual.xml')

را بنویسید تا هر دو خروجی را از منبع XML خود یعنی manual.xml به دست آورید. به عنوان یک میانبر، می‌توانید تنها ریشهٔ نام فایل‌ها را تعیین کنید، مانند این:

env = Environment(tools=['docbook'])
env.DocbookHtml('manual')
env.DocbookPdf('manual')

و همان نتیجه را دریافت کنید. فهرست‌های هدف و منبع نیز پشتیبانی می‌شوند:

env = Environment(tools=['docbook'])
env.DocbookHtml(['manual.html','reference.html'], ['manual.xml','reference.xml'])

یا حتی:

env = Environment(tools=['docbook'])
env.DocbookHtml(['manual','reference'])

سازنده‌های DocbookHtmlChunked، DocbookHtmlhelp و DocbookSlidesHtml خاص هستند، از این جهت که:

در نتیجه، مشخص کردن نام هدف HTML عملاً کاربردی ندارد. بنابراین نحو پایه برای این سازنده‌ها همواره بدین صورت است:

env = Environment(tools=['docbook'])
env.DocbookHtmlhelp('manual')

اگر می‌خواهید از یک فایل XSL خاص استفاده کنید، می‌توانید پارامتر اضافی xsl را در فراخوانی سازندهٔ خود به‌صورت زیر تعیین کنید:

env.DocbookHtml('other.html', 'manual.xml', xsl='html.xsl')

از آنجا که در صورت استفادهٔ مداوم از یک نام‌گذاری محلی یکسان برای فایل‌های XSL سفارشی‌تان، مثلاً html.xsl برای HTML و pdf.xsl برای خروجی PDF، این کار ممکن است خسته‌کننده شود، مجموعه‌ای از متغیرها برای تنظیم نام پیش‌فرض XSL در نظر گرفته شده است. این متغیرها عبارتند از:

DOCBOOK_DEFAULT_XSL_HTML
DOCBOOK_DEFAULT_XSL_HTMLCHUNKED
DOCBOOK_DEFAULT_XSL_HTMLHELP
DOCBOOK_DEFAULT_XSL_PDF
DOCBOOK_DEFAULT_XSL_EPUB
DOCBOOK_DEFAULT_XSL_MAN
DOCBOOK_DEFAULT_XSL_SLIDESPDF
DOCBOOK_DEFAULT_XSL_SLIDESHTML

و می‌توانید هنگام ساخت محیط خود، آن‌ها را تنظیم کنید:

env = Environment(
    tools=['docbook'],
    DOCBOOK_DEFAULT_XSL_HTML='html.xsl',
    DOCBOOK_DEFAULT_XSL_PDF='pdf.xsl',
)
env.DocbookHtml('manual')  # now uses html.xsl

تنظیم می‌کند: $DOCBOOK_DEFAULT_XSL_EPUB، $DOCBOOK_DEFAULT_XSL_HTML، $DOCBOOK_DEFAULT_XSL_HTMLCHUNKED، $DOCBOOK_DEFAULT_XSL_HTMLHELP، $DOCBOOK_DEFAULT_XSL_MAN، $DOCBOOK_DEFAULT_XSL_PDF، $DOCBOOK_DEFAULT_XSL_SLIDESHTML، $DOCBOOK_DEFAULT_XSL_SLIDESPDF، $DOCBOOK_FOP، $DOCBOOK_FOPCOM، $DOCBOOK_FOPFLAGS، $DOCBOOK_XMLLINT، $DOCBOOK_XMLLINTCOM، $DOCBOOK_XMLLINTFLAGS، $DOCBOOK_XSLTPROC، $DOCBOOK_XSLTPROCCOM، $DOCBOOK_XSLTPROCFLAGS، $DOCBOOK_XSLTPROCPARAMS.

استفاده می‌کند: $DOCBOOK_FOPCOMSTR، $DOCBOOK_XMLLINTCOMSTR، $DOCBOOK_XSLTPROCCOMSTR.

تنظیم می‌کند: $DVIPDF، $DVIPDFCOM، $DVIPDFFLAGS.

استفاده می‌کند: $DVIPDFCOMSTR.

تنظیم می‌کند: $DVIPS، $DVIPSFLAGS، $PSCOM، $PSPREFIX، $PSSUFFIX.

استفاده می‌کند: $PSCOMSTR.

تنظیم می‌کند: $F03، $F03COM، $F03FLAGS، $F03PPCOM، $SHF03، $SHF03COM، $SHF03FLAGS، $SHF03PPCOM، $_F03INCFLAGS.

استفاده می‌کند: $F03COMSTR، $F03PPCOMSTR، $FORTRANCOMMONFLAGS، $SHF03COMSTR، $SHF03PPCOMSTR.

تنظیم می‌کند: $F08, $F08COM, $F08FLAGS, $F08PPCOM, $SHF08, $SHF08COM, $SHF08FLAGS, $SHF08PPCOM, $_F08INCFLAGS.

استفاده می‌کند: $F08COMSTR, $F08PPCOMSTR, $FORTRANCOMMONFLAGS, $SHF08COMSTR, $SHF08PPCOMSTR.

تنظیم می‌کند: $F77, $F77COM, $F77FILESUFFIXES, $F77FLAGS, $F77PPCOM, $F77PPFILESUFFIXES, $FORTRAN, $FORTRANCOM, $FORTRANFLAGS, $SHF77, $SHF77COM, $SHF77FLAGS, $SHF77PPCOM, $SHFORTRAN, $SHFORTRANCOM, $SHFORTRANFLAGS, $SHFORTRANPPCOM, $_F77INCFLAGS.

استفاده می‌کند: $F77COMSTR, $F77PPCOMSTR, $FORTRANCOMMONFLAGS, $FORTRANCOMSTR, $FORTRANFLAGS, $FORTRANPPCOMSTR, $SHF77COMSTR, $SHF77PPCOMSTR, $SHFORTRANCOMSTR, $SHFORTRANFLAGS, $SHFORTRANPPCOMSTR.

تنظیم می‌کند: $F90, $F90COM, $F90FLAGS, $F90PPCOM, $SHF90, $SHF90COM, $SHF90FLAGS, $SHF90PPCOM, $_F90INCFLAGS.

استفاده می‌کند: $F90COMSTR, $F90PPCOMSTR, $FORTRANCOMMONFLAGS, $SHF90COMSTR, $SHF90PPCOMSTR.

تنظیم می‌کند: $F95, $F95COM, $F95FLAGS, $F95PPCOM, $SHF95, $SHF95COM, $SHF95FLAGS, $SHF95PPCOM, $_F95INCFLAGS.

استفاده می‌کند: $F95COMSTR, $F95PPCOMSTR, $FORTRANCOMMONFLAGS, $SHF95COMSTR, $SHF95PPCOMSTR.

تنظیم می‌کند: $FORTRAN, $FORTRANCOM, $FORTRANFLAGS, $SHFORTRAN, $SHFORTRANCOM, $SHFORTRANFLAGS, $SHFORTRANPPCOM.

استفاده می‌کند: $CPPFLAGS, $FORTRANCOMSTR, $FORTRANPPCOMSTR, $SHFORTRANCOMSTR, $SHFORTRANPPCOMSTR, $_CPPDEFFLAGS.

تنظیم می‌کند: $CXX, $CXXVERSION, $SHCXXFLAGS, $SHOBJSUFFIX.

تنظیم می‌کند: $F77, $F77COM, $F77FILESUFFIXES, $F77PPCOM, $F77PPFILESUFFIXES, $FORTRAN, $FORTRANCOM, $FORTRANPPCOM, $SHF77, $SHF77COM, $SHF77FLAGS, $SHF77PPCOM, $SHFORTRAN, $SHFORTRANCOM, $SHFORTRANFLAGS, $SHFORTRANPPCOM.

استفاده می‌کند: $F77FLAGS, $FORTRANCOMMONFLAGS, $FORTRANFLAGS.

تنظیم می‌کند: $AS.

تنظیم می‌کند: $CC, $CCDEPFLAGS, $CCVERSION, $SHCCFLAGS.

تنظیم می‌کند: $DC, $DCOM, $DDEBUG, $DDEBUGPREFIX, $DDEBUGSUFFIX, $DFILESUFFIX, $DFLAGPREFIX, $DFLAGS, $DFLAGSUFFIX, $DINCPREFIX, $DINCSUFFIX, $DLIB, $DLIBCOM, $DLIBDIRPREFIX, $DLIBDIRSUFFIX, $DLIBFLAGPREFIX, $DLIBFLAGSUFFIX, $DLIBLINKPREFIX, $DLIBLINKSUFFIX, $DLINK, $DLINKCOM, $DLINKFLAGPREFIX, $DLINKFLAGS, $DLINKFLAGSUFFIX, $DPATH, $DRPATHPREFIX, $DRPATHSUFFIX, $DVERPREFIX, $DVERSIONS, $DVERSUFFIX, $SHDC, $SHDCOM, $SHDLIBVERSIONFLAGS, $SHDLINK, $SHDLINKCOM, $SHDLINKFLAGS.

هنگامی که gettext را فعال می‌کنید، به صورت داخلی تمام ابزارهای یادشده را بارگذاری می‌کند، بنابراین توصیه می‌شود مستندات اختصاصی هر یک را ببینید.

هر یک از ابزارهای فوق سازنده(های) اختصاصی خود را ارائه می‌دهند که می‌توان از آن‌ها برای انجام فعالیت‌های ویژه مربوط به بین‌المللی‌سازی نرم‌افزار استفاده کرد. با این حال ممکن است به سازنده سطح‌بالای Translate علاقه‌مند باشید.

برای استفاده از ابزارهای gettext، ابزار 'gettext' را به محیط ساخت خود اضافه کنید:

env = Environment(tools=['default', 'gettext'])

تنظیم می‌کند: $F77, $F90, $F95, $FORTRAN, $SHF77, $SHF77FLAGS, $SHF90, $SHF90FLAGS, $SHF95, $SHF95FLAGS, $SHFORTRAN, $SHFORTRANFLAGS.

تنظیم می‌کند: $LDMODULEVERSIONFLAGS, $RPATHPREFIX, $RPATHSUFFIX, $SHLIBVERSIONFLAGS, $SHLINKFLAGS, $_LDMODULESONAME, $_SHLIBSONAME.

تنظیم می‌کند: $GS, $GSCOM, $GSFLAGS.

استفاده می‌کند: $GSCOMSTR.

تنظیم می‌کند: $CXX, $CXXVERSION, $SHCXXFLAGS.

تنظیم می‌کند: $LINKFLAGS, $SHLIBSUFFIX, $SHLINKFLAGS.

تنظیم می‌کند: $CC, $CCCOM, $CFILESUFFIX, $CPPDEFPREFIX, $CPPDEFSUFFIX, $CXXCOM, $CXXFILESUFFIX, $INCPREFIX, $INCSUFFIX.

استفاده می‌کند: $CCFLAGS, $CFLAGS, $CPPFLAGS, $_CPPDEFFLAGS, $_CPPINCFLAGS.

تنظیم می‌کند: $FORTRAN, $FORTRANCOM, $FORTRANPPCOM, $SHFORTRANCOM, $SHFORTRANPPCOM.

استفاده می‌کند: $CPPFLAGS, $FORTRANFLAGS, $_CPPDEFFLAGS, $_FORTRANINCFLAGS.

تنظیم می‌کند: $F77, $F90, $F95, $FORTRAN, $SHF77, $SHF77FLAGS, $SHF90, $SHF90FLAGS, $SHF95, $SHF95FLAGS, $SHFORTRAN, $SHFORTRANFLAGS.

تنظیم می‌کند: $LIBDIRPREFIX, $LIBDIRSUFFIX, $LIBLINKPREFIX, $LIBLINKSUFFIX, $LINK, $LINKCOM, $LINKFLAGS.

تنظیم می‌کند: $LIBDIRPREFIX, $LIBDIRSUFFIX, $LIBLINKPREFIX, $LIBLINKSUFFIX, $LINK, $LINKCOM, $LINKFLAGS.

تنظیم می‌کند: $INSTALL, $INSTALLSTR.

تنظیم می‌کند: $AR, $CC, $CXX, $INTEL_C_COMPILER_VERSION, $LINK.

تنظیم می‌کند: $JAR, $JARCOM, $JARFLAGS, $JARSUFFIX.

استفاده می‌کند: $JARCOMSTR.

تنظیم می‌کند: $JAVABOOTCLASSPATH, $JAVAC, $JAVACCOM, $JAVACFLAGS, $JAVACLASSPATH, $JAVACLASSSUFFIX, $JAVAINCLUDES, $JAVASOURCEPATH, $JAVASUFFIX.

استفاده می‌کند: $JAVACCOMSTR.

تنظیم می‌کند: $JAVACLASSSUFFIX, $JAVAH, $JAVAHCOM, $JAVAHFLAGS.

استفاده می‌کند: $JAVACLASSPATH, $JAVAHCOMSTR.

تنظیم می‌کند: $LATEX, $LATEXCOM, $LATEXFLAGS.

استفاده می‌کند: $LATEXCOMSTR.

تنظیم می‌کند: $DC, $DCOM, $DDEBUG, $DDEBUGPREFIX, $DDEBUGSUFFIX, $DFILESUFFIX, $DFLAGPREFIX, $DFLAGS, $DFLAGSUFFIX, $DINCPREFIX, $DINCSUFFIX, $DLIB, $DLIBCOM, $DLIBDIRPREFIX, $DLIBDIRSUFFIX, $DLIBFLAGPREFIX, $DLIBFLAGSUFFIX, $DLIBLINKPREFIX, $DLIBLINKSUFFIX, $DLINK, $DLINKCOM, $DLINKFLAGPREFIX, $DLINKFLAGS, $DLINKFLAGSUFFIX, $DPATH, $DRPATHPREFIX, $DRPATHSUFFIX, $DVERPREFIX, $DVERSIONS, $DVERSUFFIX, $SHDC, $SHDCOM, $SHDLIBVERSIONFLAGS, $SHDLINK, $SHDLINKCOM, $SHDLINKFLAGS.

تنظیم می‌کند: $LEX, $LEXCOM, $LEXFLAGS, $LEXUNISTD.

استفاده می‌کند: $LEXCOMSTR, $LEXFLAGS, $LEX_HEADER_FILE, $LEX_TABLES_FILE.

تنظیم می‌کند: $LDMODULE, $LDMODULECOM, $LDMODULEFLAGS, $LDMODULENOVERSIONSYMLINKS, $LDMODULEPREFIX, $LDMODULESUFFIX, $LDMODULEVERSION, $LDMODULEVERSIONFLAGS, $LIBDIRPREFIX, $LIBDIRSUFFIX, $LIBLINKPREFIX, $LIBLINKSUFFIX, $LINK, $LINKCOM, $LINKFLAGS, $SHLIBSUFFIX, $SHLINK, $SHLINKCOM, $SHLINKFLAGS, $__LDMODULEVERSIONFLAGS, $__SHLIBVERSIONFLAGS.

استفاده می‌کند: $LDMODULECOMSTR, $LINKCOMSTR, $SHLINKCOMSTR.

تنظیم می‌کند: $LIBDIRPREFIX, $LIBDIRSUFFIX, $LIBLINKPREFIX, $LIBLINKSUFFIX, $LINK, $LINKCOM, $LINKFLAGS, $SHLINK, $SHLINKCOM, $SHLINKFLAGS.

استفاده می‌کند: $LINKCOMSTR, $SHLINKCOMSTR.

تنظیم می‌کند: $M4, $M4COM, $M4FLAGS.

استفاده می‌کند: $M4COMSTR.

تنظیم می‌کند: $AS, $ASCOM, $ASFLAGS, $ASPPCOM, $ASPPFLAGS.

استفاده می‌کند: $ASCOMSTR, $ASPPCOMSTR, $CPPFLAGS, $_CPPDEFFLAGS, $_CPPINCFLAGS.

تنظیم می‌کند: $MIDL, $MIDLCOM, $MIDLFLAGS.

استفاده می‌کند: $MIDLCOMSTR.

تنظیم می‌کند: $AS, $CC, $CXX, $LDMODULECOM, $LIBPREFIX, $LIBSUFFIX, $OBJSUFFIX, $RC, $RCCOM, $RCFLAGS, $RCINCFLAGS, $RCINCPREFIX, $RCINCSUFFIX, $SHCCFLAGS, $SHCXXFLAGS, $SHLINKCOM, $SHLINKFLAGS, $SHOBJSUFFIX, $WINDOWSDEFPREFIX, $WINDOWSDEFSUFFIX.

استفاده می‌کند: $RCCOMSTR, $SHLINKCOMSTR.

تنظیم می‌کند: $MOSUFFIX, $MSGFMT, $MSGFMTCOM, $MSGFMTCOMSTR, $MSGFMTFLAGS, $POSUFFIX.

استفاده می‌کند: $LINGUAS_FILE.

تنظیم می‌کند: $MSGINIT, $MSGINITCOM, $MSGINITCOMSTR, $MSGINITFLAGS, $POAUTOINIT, $POCREATE_ALIAS, $POSUFFIX, $POTSUFFIX, $_MSGINITLOCALE.

استفاده می‌کند: $LINGUAS_FILE, $POAUTOINIT, $POTDOMAIN.

تنظیم می‌کند: $MSGMERGE, $MSGMERGECOM, $MSGMERGECOMSTR, $MSGMERGEFLAGS, $POSUFFIX, $POTSUFFIX, $POUPDATE_ALIAS.

استفاده می‌کند: $LINGUAS_FILE, $POAUTOINIT, $POTDOMAIN.

تنظیم می‌کند: $AR, $ARCOM, $ARFLAGS, $LIBPREFIX, $LIBSUFFIX.

استفاده می‌کند: $ARCOMSTR.

تنظیم می‌کند: $LDMODULE, $LDMODULECOM, $LDMODULEFLAGS, $LDMODULEPREFIX, $LDMODULESUFFIX, $LIBDIRPREFIX, $LIBDIRSUFFIX, $LIBLINKPREFIX, $LIBLINKSUFFIX, $LINK, $LINKCOM, $LINKFLAGS, $REGSVR, $REGSVRCOM, $REGSVRFLAGS, $SHLINK, $SHLINKCOM, $SHLINKFLAGS, $WINDOWSDEFPREFIX, $WINDOWSDEFSUFFIX, $WINDOWSEXPPREFIX, $WINDOWSEXPSUFFIX, $WINDOWSPROGMANIFESTPREFIX, $WINDOWSPROGMANIFESTSUFFIX, $WINDOWSSHLIBMANIFESTPREFIX, $WINDOWSSHLIBMANIFESTSUFFIX, $WINDOWS_INSERT_DEF.

استفاده می‌کند: $LDMODULECOMSTR, $LINKCOMSTR, $REGSVRCOMSTR, $SHLINKCOMSTR.

استفاده می‌کند: $MSSDK_DIR, $MSSDK_VERSION, $MSVS_VERSION.

تنظیم می‌کند: $BUILDERS, $CC, $CCCOM, $CCDEPFLAGS, $CCFLAGS, $CCPCHFLAGS, $CCPDBFLAGS, $CFILESUFFIX, $CFLAGS, $CPPDEFPREFIX, $CPPDEFSUFFIX, $CXX, $CXXCOM, $CXXFILESUFFIX, $CXXFLAGS, $INCPREFIX, $INCSUFFIX, $OBJPREFIX, $OBJSUFFIX, $PCHCOM, $PCHPDBFLAGS, $RC, $RCCOM, $RCFLAGS, $SHCC, $SHCCCOM, $SHCCFLAGS, $SHCFLAGS, $SHCXX, $SHCXXCOM, $SHCXXFLAGS, $SHOBJPREFIX, $SHOBJSUFFIX.

استفاده می‌کند از: $CCCOMSTR, $CXXCOMSTR, $MSVC_NOTFOUND_POLICY, $MSVC_SCRIPTERROR_POLICY, $MSVC_SCRIPT_ARGS, $MSVC_SDK_VERSION, $MSVC_SPECTRE_LIBS, $MSVC_TOOLSET_VERSION, $MSVC_USE_SCRIPT, $MSVC_USE_SCRIPT_ARGS, $MSVC_USE_SETTINGS, $MSVC_VERSION, $PCH, $PCHSTOP, $PDB, $SHCCCOMSTR, $SHCXXCOMSTR.

تنظیم می‌کند: $MSVSBUILDCOM, $MSVSCLEANCOM, $MSVSENCODING, $MSVSPROJECTCOM, $MSVSREBUILDCOM, $MSVSSCONS, $MSVSSCONSCOM, $MSVSSCONSCRIPT, $MSVSSCONSFLAGS, $MSVSSOLUTIONCOM.

تنظیم می‌کند: $CC, $CCCOM, $CFILESUFFIX, $CPPDEFPREFIX, $CPPDEFSUFFIX, $CXX, $CXXCOM, $CXXFILESUFFIX, $INCPREFIX, $INCSUFFIX, $MWCW_VERSION, $MWCW_VERSIONS, $SHCC, $SHCCCOM, $SHCCFLAGS, $SHCFLAGS, $SHCXX, $SHCXXCOM, $SHCXXFLAGS.

استفاده می‌کند از: $CCCOMSTR, $CXXCOMSTR, $SHCCCOMSTR, $SHCXXCOMSTR.

تنظیم می‌کند: $AR, $ARCOM, $LIBDIRPREFIX, $LIBDIRSUFFIX, $LIBLINKPREFIX, $LIBLINKSUFFIX, $LINK, $LINKCOM, $SHLINK, $SHLINKCOM, $SHLINKFLAGS.

تنظیم می‌کند: $AS, $ASCOM, $ASFLAGS, $ASPPCOM, $ASPPFLAGS.

استفاده می‌کند از: $ASCOMSTR, $ASPPCOMSTR.

استفاده می‌کند: $AR, $ARCOM, $ARFLAGS, $CC, $CCCOM, $CCDEPFLAGS, $CCFLAGS, $CXX, $CXXCOM, $ESCAPE, $LINK, $LINKCOM, $PLATFORM, $PRINT_CMD_LINE_FUNC, $PROGSUFFIX, $RANLIB, $RANLIBCOM, $SHCCCOM, $SHCXXCOM, $SHLINK, $SHLINKCOM.

تنظیم می‌کند: $PDFPREFIX, $PDFSUFFIX.

تنظیم می‌کند: $LATEXRETRIES, $PDFLATEX, $PDFLATEXCOM, $PDFLATEXFLAGS.

استفاده می‌کند: $PDFLATEXCOMSTR.

تنظیم می‌کند: $LATEXRETRIES, $PDFLATEX, $PDFLATEXCOM, $PDFLATEXFLAGS, $PDFTEX, $PDFTEXCOM, $PDFTEXFLAGS.

استفاده می‌کند: $PDFLATEXCOMSTR, $PDFTEXCOMSTR.

در دسترس از scons 4.0 به بعد..

تنظیم می‌کند: $JAVACLASSSUFFIX, $RMIC, $RMICCOM, $RMICFLAGS.

استفاده می‌کند: $RMICCOMSTR.

تنظیم می‌کند: $RPCGEN, $RPCGENCLIENTFLAGS, $RPCGENFLAGS, $RPCGENHEADERFLAGS, $RPCGENSERVICEFLAGS, $RPCGENXDRFLAGS.

تنظیم می‌کند: $AR, $ARCOMSTR, $ARFLAGS, $LIBPREFIX, $LIBSUFFIX, $SHLINK, $SHLINKFLAGS.

استفاده می‌کند: $ARCOMSTR, $SHLINKCOMSTR.

تنظیم می‌کند: $CXX, $CXXFLAGS, $SHCXX, $SHOBJSUFFIX.

تنظیم می‌کند: $CXX, $SHOBJSUFFIX.

تنظیم می‌کند: $LINK, $RPATHPREFIX, $RPATHSUFFIX, $SHLINKFLAGS.

تنظیم می‌کند: $AR, $ARCOM, $ARFLAGS, $LIBPREFIX, $LIBSUFFIX.

استفاده می‌کند: $ARCOMSTR.

تنظیم می‌کند: $CXX, $CXXVERSION, $SHCXX, $SHCXXFLAGS, $SHOBJPREFIX, $SHOBJSUFFIX.

تنظیم می‌کند: $CXX, $SHCCFLAGS, $SHOBJPREFIX, $SHOBJSUFFIX.

تنظیم می‌کند: $F77, $FORTRAN, $SHF77, $SHF77FLAGS, $SHFORTRAN, $SHFORTRANFLAGS.

تنظیم می‌کند: $F90, $FORTRAN, $SHF90, $SHF90FLAGS, $SHFORTRAN, $SHFORTRANFLAGS.

تنظیم می‌کند: $F95, $FORTRAN, $SHF95, $SHF95FLAGS, $SHFORTRAN, $SHFORTRANFLAGS.

تنظیم می‌کند: $RPATHPREFIX, $RPATHSUFFIX, $SHLINKFLAGS.

تنظیم می‌کند: $SWIG, $SWIGCFILESUFFIX, $SWIGCOM, $SWIGCXXFILESUFFIX, $SWIGDIRECTORSUFFIX, $SWIGFLAGS, $SWIGINCPREFIX, $SWIGINCSUFFIX, $SWIGPATH, $SWIGVERSION, $_SWIGINCFLAGS.

استفاده می‌کند: $SWIGCOMSTR.

تنظیم می‌کند: $TAR, $TARCOM, $TARFLAGS, $TARSUFFIX.

استفاده می‌کند: $TARCOMSTR.

تنظیم می‌کند: $BIBTEX, $BIBTEXCOM, $BIBTEXFLAGS, $LATEX, $LATEXCOM, $LATEXFLAGS, $MAKEINDEX, $MAKEINDEXCOM, $MAKEINDEXFLAGS, $TEX, $TEXCOM, $TEXFLAGS.

استفاده می‌کند: $BIBTEXCOMSTR, $LATEXCOMSTR, $MAKEINDEXCOMSTR, $TEXCOMSTR.

تنظیم می‌کند: $FILE_ENCODING, $LINESEPARATOR, $SUBSTFILEPREFIX, $SUBSTFILESUFFIX, $TEXTFILEPREFIX, $TEXTFILESUFFIX.

استفاده می‌کند: $SUBST_DICT.

تنظیم می‌کند: $AR, $ARCOM, $ARFLAGS, $LIBPREFIX, $LIBSUFFIX.

استفاده می‌کند: $ARCOMSTR.

تنظیم می‌کند: $POTSUFFIX, $POTUPDATE_ALIAS, $XGETTEXTCOM, $XGETTEXTCOMSTR, $XGETTEXTFLAGS, $XGETTEXTFROM, $XGETTEXTFROMPREFIX, $XGETTEXTFROMSUFFIX, $XGETTEXTPATH, $XGETTEXTPATHPREFIX, $XGETTEXTPATHSUFFIX, $_XGETTEXTDOMAIN, $_XGETTEXTFROMFLAGS, $_XGETTEXTPATHFLAGS.

استفاده می‌کند: $POTDOMAIN.

تنظیم می‌کند: $YACC, $YACCCOM, $YACCFLAGS, $YACCHFILESUFFIX, $YACCHXXFILESUFFIX, $YACCVCGFILESUFFIX, $YACC_GRAPH_FILE_SUFFIX.

استفاده می‌کند: $YACCCOMSTR, $YACCFLAGS, $YACC_GRAPH_FILE, $YACC_HEADER_FILE.

تنظیم می‌کند: $ZIP, $ZIPCOM, $ZIPCOMPRESSION, $ZIPFLAGS, $ZIPSUFFIX.

استفاده می‌کند: $ZIPCOMSTR.

Buildername(target, source, [key=val, ...])

در Windows، مسیرهای DOS ممکن است با یک شناسهٔ بخش (volume) یا حرف درایو و به دنبال آن جداکنندهٔ بخش (:) آغاز شوند. ادامهٔ مسیر مطلق یا نسبی است؛ اگر مشخص‌کنندهٔ بخش وجود داشته باشد، تفکیک برای مسیرهای مطلق از ریشهٔ درایو مشخص‌شده و برای مسیرهای نسبی از دایرکتوری جاری در درایو مشخص‌شده آغاز می‌شود. اگر حرف درایو مشخص‌شده با درایو جاری متفاوت باشد، مسیر نسبی فاقد زمینه (context) خواهد بود: از آنجا که SCons یک برنامهٔ کنسولی (خط فرمانی) است، ممکن است وضعیت را از ترمینالی که در آن اجرا شده به ارث ببرد، از جمله دایرکتوری‌های جاری ذخیره‌شده برای سایر درایوها؛ SCons هیچ راهی برای دانستن آن‌ها ندارد. استفاده از حرف درایو در مسیر همچنین مانع از استفاده از شکل وابسته به ریشه (top-relative) می‌شود.

env.Program('bar', ['bar.c', 'foo.c'])
env.Program('bar', Split('bar.c foo.c'))
env.Program('bar', env.Split('bar.c foo.c'))
env.Program(source=['bar.c', 'foo.c'], target='bar')
env.Program(target='bar', source=Split('bar.c foo.c'))
env.Program(target='bar', source=env.Split('bar.c foo.c'))
env.Program('bar', source='bar.c foo.c'.split())

مسیرهای وابسته به ریشه فقط در جاهایی کار می‌کنند که SCons مسیر را تفسیر کند (به نمونه‌ها رجوع کنید). این رشته برای استفاده در زمینه‌های دیگر (مانند کد خالص Python که شامل فراخوانی API متعلق به SCons نمی‌شود)، ابتدا باید به یک مسیر نسبی یا مطلق تبدیل شود؛ یک رشتهٔ مناسب را می‌توان از Node ایجادشده از یک مسیر وابسته به ریشه استخراج کرد. علاوه بر این، برخی مسیرها توسط SCons مدیریت می‌شوند اما مستقیماً در ساخت مشارکت ندارند، بنابراین به دلیل عدم ایجاد Node، برای # ارزیابی نمی‌شوند. می‌توانید صراحتاً یک گرهٔ File یا Dir برای اجبار به ارزیابی ایجاد کنید، مانند هنگام تعیین مسیری برای حافظهٔ نهان فایل‌های مشتق‌شده: CacheDir(Dir('#cache')).

# The comments describing the targets that will be built
# assume these calls are in a SConscript file in the
# a subdirectory named "subdir".
# Builds the program "subdir/foo" from "subdir/foo.c":
env.Program('foo', 'foo.c')
# Builds the program "/tmp/bar" from "subdir/bar.c":
env.Program('/tmp/bar', 'bar.c')
# An initial '#' or '#/' are equivalent; the following
# calls build the programs "foo" and "bar" (in the
# top-level SConstruct directory) from "subdir/foo.c" and
# "subdir/bar.c", respectively:
env.Program('#foo', 'foo.c')
env.Program('#/bar', 'bar.c')
# Builds the program "other/foo" (relative to the top-level
# SConstruct directory) from "subdir/foo.c":
env.Program('#other/foo', 'foo.c')
# os.path.exists() is pure Python, so this fails:
if os.path.exists('#inc/foo.h'):
    env.Append(CPPPATH='#inc')
# create a Node to make it work:
if os.path.exists(File('#inc/foo.h')):
    env.Append(CPPPATH='#inc')

env.Program('build/prog', ['f1.c', 'f2.c'], srcdir='src')

env.Program('hello', 'hello.c', parse_flags='-Iinclude -DEBUG -lm')

# scons پیش از اجرای تابع کنش Copy، به زیردایرکتوری "sub/dir"
# تغییر مکان خواهد داد
env.Command(
    target='sub/dir/foo.out',
    source='sub/dir/foo.in',
    action=Copy('${TARGET.file}', '${SOURCE.file}'),
    chdir='sub/dir',
)
# در اینجا chdir رشته نیست، بنابراین scons برای اجرای کنش
# به دایرکتوری هدف ("sub/dir") تغییر مکان خواهد داد.
env.Command('
    target='sub/dir/foo.out',
    source='sub/dir/foo.in',
    action=Copy('${TARGET.file}', '${SOURCE.file}'),
    chdir=True
)

Python تنها یک مکان دایرکتوری جاری را دنبال می‌کند، حتی اگر چندین ریسهٔ در حال اجرا وجود داشته باشد. این بدان معناست که استفاده از آرگومان chdir با SCons در حالت چندریسه‌ای (گزینهٔ -j) کار نخواهد کرد، زیرا ریسه‌های کاری (worker threads) مجزایی که توسط SCons ایجاد می‌شوند، هنگام شروع به تغییر دایرکتوری با یکدیگر تداخل پیدا می‌کنند.

SCons هنگام بسط دادن متغیرهای ساخت (construction variables) مانند $TARGET و $SOURCE، chdir را در نظر نمی‌گیرد، بنابراین آن‌ها نسبت به دایرکتوری chdir نادرست خواهند بود. اگر از آرگومان کلیدواژه‌ای chdir استفاده کنید، معمولاً نیاز خواهید داشت که با استفاده از بسط‌هایی مانند ${TARGET.file} و ${SOURCE.file} که به بخش نام فایلِ هدف و منبع بسط می‌یابند، یک خط فرمان متفاوت مشخص کنید.

env.Program('hello', 'hello.c', LIBS=['gl', 'glut'])

env.SharedLibrary(
    target='word',
    source='word.cpp',
    SHLIBSUFFIX='.ocx',
    LIBSUFFIXES=['.ocx'],
)

Program('hello', 'hello.c')
SharedLibrary('word', 'word.cpp')

from SCons.Script import *

bar_obj_list = env.StaticObject('bar.c', CPPDEFINES='-DBAR')
env.Program("prog", ['foo.c', bar_obj_list, 'main.c'])

tgt = env.Program("prog", ["foo.c", "bar.c", "main.c"])
Default(tgt)

foo = Object('foo.c')
bar = Object('bar.c')
objects = ['begin.o'] + foo + ['middle.o'] + bar + ['end.o']
for obj in objects:
    print(str(obj))

foo = Object('foo.c')
bar = Object('bar.c')
objects = Flatten(['begin.o', foo, 'middle.o', bar, 'end.o'])
for obj in objects:
    print(str(obj))

از آن‌جا که فراخوانی‌های سازنده یک شیء شبیه لیست بازمی‌گردانند و نه یک لیست واقعی Python، مناسب نیست که از عملگر جمع Python (+ یا +=) برای الحاق نتایج سازنده به یک لیست Python استفاده شود. زیرا لیست و شیء از انواع متفاوتی هستند، و Python لیست اصلی را درجا به‌روزرسانی نخواهد کرد، بلکه در عوض یک شیء جدید از نوع NodeList حاوی پیوند عناصر لیست و نتایج سازنده ایجاد خواهد کرد. این امر برای هر متغیر دیگر Python در پیکربندی SCons شما که همچنان ارجاعی به لیست اصلی دارد، مشکل‌ساز خواهد شد. در عوض، از متد extend لیست در Python استفاده کنید تا اطمینان یابید لیست به‌صورت درجا (in-place) به‌روزرسانی می‌شود. مثال:

object_files = []
# Do NOT use += here:
#    object_files += Object('bar.c')
#
# It will not update the object_files list in place.
#
# Instead, use the list extend method:
object_files.extend(Object('bar.c'))

bar_obj_list = env.StaticObject('bar.c', CPPDEFINES='-DBAR')
print("The path to bar_obj is:", str(bar_obj_list[0]))

Program('hello', 'hello.c')
SharedLibrary('word', 'word.cpp')

CompilationDatabase یک سازندهٔ ویژه است که هدفی را برای ایجاد یک پایگاه دادهٔ کامپایل با قالب JSON و سازگار با ابزارهای clang اضافه می‌کند (به مشخصات LLVM[1] مراجعه کنید). این پایگاه داده برای استفاده توسط ابزارها و ویرایشگرهای مختلف مناسب است که می‌توانند از آن برای به‌دست آوردن اطلاعات ساخت و وابستگی‌ها استفاده کنند که در غیر این صورت برای SCons درونی می‌بود. این سازنده نیازی به مشخص کردن هیچ فایل سورسی ندارد، بلکه ترتیبی می‌دهد تا اطلاعات مربوط به تمام جفت‌های سورس/خروجی C، C++ و اسمبلی شناسایی‌شده در ساخت را که توسط فیلتر اختیاری $COMPILATIONDB_PATH_FILTER مستثنی نشده‌اند، خروجی دهد. این هدف مشمول قواعد معمول انتخاب هدف در SCons است.

اگر بدون آرگومان فراخوانی شود، نام هدف سازنده به‌طور پیش‌فرض compile_commands.json خواهد بود.

اگر با یک آرگومان موضعی تکی فراخوانی شود، scons نام هدف را از آن آرگومان سورس «استنتاج» می‌کند، همان نام را به آن می‌دهد و سپس سورس را نادیده می‌گیرد. این روش معمول برای فراخوانی سازنده در حالتی است که نام هدفی غیر از پیش‌فرض مورد نظر باشد.

اگر با هر یک از آرگومان‌های کلیدواژه‌ای target= یا source= فراخوانی شود، مقدار آن آرگومان به عنوان نام هدف در نظر گرفته می‌شود. اگر با هر دو فراخوانی شود، مقدار target= استفاده شده و source= نادیده گرفته می‌شود. اگر با چند سورس فراخوانی شود، فهرست سورس‌ها نادیده گرفته خواهد شد، زیرا راهی برای استنتاج قصد مورد نظر وجود ندارد؛ در این حالت از نام هدف پیش‌فرض استفاده خواهد شد.

env = Environment(tools=['docbook'])
env.DocbookEpub('manual.epub', 'manual.xml')

یا به سادگی

env = Environment(tools=['docbook'])
env.DocbookEpub('manual')

env = Environment(tools=['docbook'])
env.DocbookHtml('manual.html', 'manual.xml')

یا به سادگی

env = Environment(tools=['docbook'])
env.DocbookHtml('manual')

env = Environment(tools=['docbook'])
env.DocbookHtmlChunked('manual')

که در آن manual.xml فایل ورودی است.

اگر از پارامتر root.filename در شیوه‌نامه‌های سفارشی خود استفاده می‌کنید، باید نام هدف جدید را مشخص کنید. این کار تضمین می‌کند که وابستگی‌ها به درستی تنظیم شوند، به‌ویژه برای پاک‌سازی از طریق “scons -c”:

env = Environment(tools=['docbook'])
env.DocbookHtmlChunked('mymanual.html', 'manual', xsl='htmlchunk.xsl')

پشتیبانی اولیه‌ای برای پارامتر base.dir فراهم شده است. می‌توانید کلمه کلیدی base_dir را به فراخوانی Builder خود اضافه کنید، و پیشوند داده‌شده به ابتدای تمام نام‌های فایل ایجاد شده افزوده می‌شود:

env = Environment(tools=['docbook'])
env.DocbookHtmlChunked('manual', xsl='htmlchunk.xsl', base_dir='output/')

مطمئن شوید که اسلش پایانی را برای پوشه پایه فراموش نکنید، در غیر این صورت فایل‌های شما فقط تغییر نام خواهند یافت!

env = Environment(tools=['docbook'])
env.DocbookHtmlhelp('manual')

که در آن manual.xml فایل ورودی است.

اگر از پارامتر root.filename در شیوه‌نامه‌های سفارشی خود استفاده می‌کنید، باید نام هدف جدید را مشخص کنید. این کار تضمین می‌کند که وابستگی‌ها به درستی تعیین شوند، به‌ویژه برای پاک‌سازی از طریق “scons -c”:

env = Environment(tools=['docbook'])
env.DocbookHtmlhelp('mymanual.html', 'manual', xsl='htmlhelp.xsl')

پشتیبانی اولیه‌ای برای پارامتر base.dir فراهم شده است. می‌توانید کلمه کلیدی base_dir را به فراخوانی Builder خود اضافه کنید، و پیشوند داده‌شده به ابتدای تمام نام‌های فایل ایجاد شده افزوده می‌شود:

env = Environment(tools=['docbook'])
env.DocbookHtmlhelp('manual', xsl='htmlhelp.xsl', base_dir='output/')

مطمئن شوید که اسلش پایانی را برای پوشه پایه فراموش نکنید، در غیر این صورت فایل‌های شما فقط تغییر نام خواهند یافت!

env = Environment(tools=['docbook'])
env.DocbookMan('manual')

که در آن manual.xml فایل ورودی است. توجه داشته باشید که می‌توانید یک نام هدف تعیین کنید، اما نام‌های خروجی واقعی به‌طور خودکار از مدخل‌های refname در منبع XML شما تنظیم می‌شوند.

env = Environment(tools=['docbook'])
env.DocbookPdf('manual.pdf', 'manual.xml')

یا صرفاً:

env = Environment(tools=['docbook'])
env.DocbookPdf('manual')

env = Environment(tools=['docbook'])
env.DocbookSlidesHtml('manual')

اگر از پارامتر titlefoil.html در شیوه‌نامه‌های خود استفاده می‌کنید، باید نام هدف جدید را تعیین کنید. این کار تضمین می‌کند که وابستگی‌ها به‌درستی برقرار شوند، به‌ویژه برای پاک‌سازی از طریق “scons -c”:

env = Environment(tools=['docbook'])
env.DocbookSlidesHtml('mymanual.html','manual', xsl='slideshtml.xsl')

پشتیبانی اولیه‌ای از پارامتر base.dir فراهم شده است. می‌توانید کلیدواژهٔ base_dir را به فراخوانی سازندهٔ خود اضافه کنید، و پیشوند داده‌شده به ابتدای تمام نام‌های فایل‌های ایجادشده افزوده می‌شود:

env = Environment(tools=['docbook'])
env.DocbookSlidesHtml('manual', xsl='slideshtml.xsl', base_dir='output/')

مطمئن شوید که ممیز پایانی (trailing slash) را برای پوشه پایه فراموش نکنید، وگرنه فایل‌های شما فقط تغییر نام می‌یابند!

env = Environment(tools=['docbook'])
env.DocbookSlidesPdf('manual.pdf', 'manual.xml')

یا صرفاً:

env = Environment(tools=['docbook'])
env.DocbookSlidesPdf('manual')

env = Environment(tools=['docbook'])
env.DocbookXslt('manual_transformed.xml', 'manual.xml', xsl='transform.xslt')

توجه داشته باشید که این سازنده نیازمند تنظیم پارامتر xsl است.

پسوند .dvi (که به صورت سخت‌کدشده درون خود TeX قرار دارد) در صورتی که از قبل وجود نداشته باشد، به طور خودکار به هدف افزوده می‌شود. مثال‌ها:

# builds from aaa.tex
env.DVI(target = 'aaa.dvi', source = 'aaa.tex')
# builds bbb.dvi
env.DVI(target = 'bbb', source = 'bbb.ltx')
# builds from ccc.latex
env.DVI(target = 'ccc.dvi', source = 'ccc.latex')

env.Install(target='/usr/local/bin', source=['foo', 'bar'])

توجه داشته باشید که اگر مسیرهای هدف انتخاب‌شده برای سازنده‌ی Install (و سازندگان مرتبط InstallAs و InstallVersionedLib) خارج از درخت پروژه باشند، مانند مثال بالا، ممکن است به طور پیش‌فرض برای «ساخت» انتخاب نشوند، زیرا در صورت نبود دستورالعمل‌های دیگر، scons اهدافی را می‌سازد که در زیر دایرکتوری سطح بالا (دایرکتوری حاوی فایل SConstruct، معمولاً دایرکتوری جاری) قرار دارند. در این حالت از اهداف خط فرمان یا تابع Default استفاده کنید.

اگر گزینه‌ی --install-sandbox داده شود، مسیر دایرکتوری مشخص‌شده به عنوان پیشوند به دایرکتوری هدف اضافه خواهد شد. این قابلیت برای آزمایش رفتار نصب بدون نصب در یک مکان «فعال» در سیستم مفید است.

همچنین ببینید FindInstalledFiles. برای توضیحات و نکات بیشتر در مورد نصب، راهنمای کاربر را ببینید (به‌ویژه بخش اهداف خط فرمان (Command-Line Targets) و فصل‌های مربوط به نصب فایل‌ها (Installing Files) و اهداف نام مستعار (Alias Targets)).

env.InstallAs(target='/usr/local/bin/foo',
              source='foo_debug')
env.InstallAs(target=['../lib/libfoo.a', '../lib/libbar.a'],
              source=['libFOO.a', 'libBAR.a'])

یادداشت زیر Install را ببینید.

env.InstallVersionedLib(target='/usr/local/bin/foo',
                        source='libxyz.1.5.2.so')

یادداشت زیر Install را ببینید.

اگر مقدار $JARCHDIR تنظیم شده باشد، دستور jar با استفاده از گزینهٔ -C به پوشهٔ مشخص‌شده تغییر مسیر می‌دهد. اگر $JARCHDIR به‌طور صریح تنظیم نشده باشد، SCons از بالاترین سطح هر زیردرخت پوشه‌ای که فایل‌های .class جاوا در آن توسط سازندهٔ Java ساخته شده‌اند استفاده خواهد کرد.

اگر محتویات هر یک از فایل‌های منبع با رشتهٔ Manifest-Version آغاز شود، آن فایل یک مانیفست در نظر گرفته می‌شود و همراه با تنظیم گزینهٔ m به دستور jar ارسال می‌گردد.

env.Jar(target = 'foo.jar', source = 'classes')
env.Jar(target = 'bar.jar',
        source = ['bar1.java', 'bar2.java'])

ابزار SCons هر فایل منبع .java را برای یافتن کلاس‌های تعریف‌شده درون آن (از جمله کلاس‌های درونی) تجزیه می‌کند و از روی آن، فایل‌های هدف .class را که ایجاد خواهند شد تشخیص می‌دهد. فایل‌های کلاس زیر پوشهٔ هدفِ مشخص‌شده قرار خواهند گرفت.

همچنین SCons هر فایل جاوا را برای یافتن نام بسته‌بندی (package) جاوا جستجو می‌کند، با این فرض که این نام در خطی که با رشتهٔ package در ستون اول آغاز می‌شود یافت می‌شود؛ فایل‌های .class حاصل در پوشه‌ای متناسب با نام بستهٔ مشخص‌شده قرار داده می‌شوند. برای نمونه، فایل Foo.java که یک کلاس عمومی یکتای Foo را تعریف می‌کند و شامل نام بستهٔ sub.dir است، یک فایل کلاس متناظر sub/dir/Foo.class تولید خواهد کرد.

مثال‌ها:

env.Java(target='classes', source='src')
env.Java(target='classes', source=['src1', 'src2'])
env.Java(target='classes', source=['File1.java', 'File2.java'])

فایل‌های منبع جاوا می‌توانند از کدگذاری بومی سیستم‌عامل زیربنایی استفاده کنند. از آنجا که SCons به‌طور پیش‌فرض در حالت سادهٔ ASCII کامپایل می‌کند، کامپایلر هشدارهایی دربارهٔ نویسه‌های غیرقابل نگاشت تولید خواهد کرد که ممکن است در ادامهٔ پردازش فایل به خطا بیانجامد. در این حالت، کاربر باید متغیر محیطی LANG را مشخص کند تا به کامپایلر اعلام شود چه کدگذاری استفاده شده است. برای سازگاری و قابلیت حمل، بهتر است کدگذاری به‌صورت صریح تعیین (hard-code) شود تا کامپایل هنگام اجرا بر روی سیستمی با کدگذاری دیگر نیز کار کند.

env = Environment()
env['ENV']['LANG'] = 'en_GB.UTF-8'

اگر متغیر ساخت $JAVACLASSDIR چه در محیط و چه در فراخوانی خودِ متد سازندهٔ JavaH تنظیم شده باشد، آن‌گاه مقدار این متغیر از ابتدای هر نام فایل .class حذف خواهد شد.

مثال‌ها:

# builds java_native.h
classes = env.Java(target="classdir", source="src")
env.JavaH(target="java_native.h", source=classes)
# builds include/package_foo.h and include/package_bar.h
env.JavaH(target="include", source=["package/foo.class", "package/bar.class"])
# builds export/foo.h and export/bar.h
env.JavaH(
    target="export",
    source=["classes/foo.class", "classes/bar.class"],
    JAVACLASSDIR="classes",
)

مثال ۱. ایجاد pl.mo و en.mo با کامپایل pl.po و en.po:

env.MOFiles(['pl', 'en'])

مثال ۲. کامپایل فایل‌ها برای زبان‌های تعریف‌شده در فایل LINGUAS:

env.MOFiles(LINGUAS_FILE=True)

مثال ۳. ایجاد pl.mo و en.mo با کامپایل pl.po و en.po به‌همراه فایل‌های مربوط به زبان‌های تعریف‌شده در فایل LINGUAS:

env.MOFiles(['pl', 'en'], LINGUAS_FILE=True)

مثال ۴. کامپایل فایل‌ها برای زبان‌های تعریف‌شده در فایل LINGUAS (روشی دیگر):

env['LINGUAS_FILE'] = True
env.MOFiles()

یک فایل پروژه‌ی Microsoft Visual C++ را بر اساس نسخه‌ی پیکربندی‌شده‌ی Visual Studio (یا دقیق‌تر بگوییم، MSBuild) می‌سازد: یا جدیدترین نسخه‌ی نصب‌شده، یا نسخه‌ی مشخص‌شده توسط $MSVC_VERSION در محیط ساخت فعلی. برای Visual Studio 6.0 یک فایل .dsp تولید می‌شود. برای نسخه‌های ۲۰۰۲ تا ۲۰۰۸ ویژوال استودیو، یک فایل .vcproj تولید می‌شود. برای Visual Studio 2010 و بالاتر یک فایل .vcxproj تولید می‌شود. توجه داشته باشید که چندین طرح نسخه‌بندی در محیط کامپایل مایکروسافت دخیل هستند - برای دیدن معادل‌ها، توضیحات $MSVC_VERSION را ببینید. توجه داشته باشید که SCons نحوه‌ی ساخت فایل‌های پروژه را برای سایر زبان‌ها نمی‌داند (برای مثال .csproj برای #C، .vbproj برای Visual Basic یا .pyproject برای Python).

برای فایل .vcxproj، قالب زیربنایی همان شمای اکس‌ام‌ال (XML Schema) مربوط به MSBuild است و جزئیات آن مطابق با این پیوند است: https://learn.microsoft.com/en-us/cpp/build/reference/vcxproj-file-structure[3]. فایل راه‌حل تولید‌شده، Visual Studio را قادر می‌سازد ساختار پروژه را درک کند و این امکان را می‌دهد که با استفاده از MSBuild برای فراخوانی مجدد SCons ساخته شود. فایل پروژه حاوی نسخه‌ی مجموعه‌ابزاری (toolset) است که همان‌طور که در بالا توضیح داده شد توسط SCons انتخاب شده است. از آنجا که نسخه‌های جدید Visual Studio از چندین مجموعه‌ابزار هم‌زمان پشتیبانی می‌کنند، اگر مجموعه‌ابزار مورد نظر با پیش‌فرض SCons مطابقت ندارد، از $MSVC_VERSION برای انتخاب آن استفاده کنید. فایل پروژه همچنین شامل مدخل‌هایی است که نحوه‌ی فراخوانی SCons را برای ساخت پروژه از داخل Visual Studio (یا از خط فرمان MSBuild) شرح می‌دهند. در برخی شرایط ممکن است SCons این را به اشتباه تولید کند - به‌ویژه هنگام استفاده از توزیع scons-local، که به شیوه‌ای متناسب با خط فراخوانی پیش‌فرض نصب نشده است. در این صورت، متغیر ساخت $SCONS_HOME می‌تواند برای توصیف روش صحیح تعیین مکان کد SCons به‌منظور درون‌ریزی (import) آن استفاده شود.

به‌طور پیش‌فرض، یک فایل راه‌حل متناظر نیز برای پروژه تولید می‌شود. این رفتار می‌تواند با تعیین auto_build_solution=0 برای سازنده‌ی MSVSProject غیرفعال شود. فایل راه‌حل همچنین می‌تواند به‌طور مستقل با فراخوانی سازنده‌ی MSVSSolution تولید شود، مانند حالتی که یک راه‌حل باید چندین پروژه را توصیف کند. برای اطلاعات بیشتر، توضیحات MSVSSolution را ببینید.

سازنده‌ی MSVSProject چندین آرگومان کلیدواژه‌ای را می‌پذیرد که فهرست‌هایی از نام‌های فایل را برای قرار گرفتن در فایل پروژه توصیف می‌کنند. در حال حاضر، srcs، incs، localincs، resources و misc شناخته می‌شوند. این نام‌ها به‌گونه‌ای طراحی شده‌اند که خود‌توضیح باشند، اما توجه داشته باشید که نام‌های فایل باید به صورت رشته مشخص شوند، نه به عنوان گره‌های پرونده (File Nodes) در SCons (برای مثال اگر فایل‌هایی را برای گنجاندن با استفاده از تابع Glob تولید می‌کنید، نتایج باید قبل از ارسال به MSVSProject به فهرستی از رشته‌ها تبدیل شوند). دلیل این امر این است که Visual Studio و MSBuild چیزی درباره‌ی انواع گره‌های SCons نمی‌دانند. هر یک از فهرست‌های نام‌های فایل به‌صورت جداگانه اختیاری هستند، اما حداقل یک فهرست باید مشخص شود تا فایل پروژه‌ی حاصل خالی نباشد.

علاوه بر فهرست‌های مقادیر بالا، مقادیر زیر نیز می‌توانند به عنوان آرگومان‌های کلیدواژه‌ای مشخص شوند:

target

variant

cmdargs

cppdefines

cppflags

cpppaths

buildtarget

runfile

barsrcs = ['bar.cpp']
barincs = ['bar.h']
barlocalincs = ['StdAfx.h']
barresources = ['bar.rc', 'resource.h']
barmisc = ['bar_readme.txt']
dll = env.SharedLibrary(target='bar.dll', source=barsrcs)
buildtarget = [s for s in dll if str(s).endswith('dll')]
env.MSVSProject(
    target='Bar' + env['MSVSPROJECTSUFFIX'],
    srcs=barsrcs,
    incs=barincs,
    localincs=barlocalincs,
    resources=barresources,
    misc=barmisc,
    buildtarget=buildtarget,
    variant='Release',
)

DebugSettings

در حال حاضر، تنها Visual Studio نسخهٔ v9.0 و Visual Studio نسخهٔ v11 پیاده‌سازی شده‌اند؛ برای سایر نسخه‌ها فایلی تولید نمی‌شود. برای تولید فایل کاربر، کافی است یک دیکشنری DebugSettings با پارامترهای مناسب برای نسخهٔ MSVS خود به محیط بیفزایید. اگر دیکشنری خالی باشد یا حاوی هیچ مقدار معتبری نباشد، هیچ فایلی تولید نخواهد شد.

در ادامه مثالی جامع‌تر آورده شده است که شامل راه‌اندازی یک پروژه برای گونه‌ها و DebugSettings می‌شود:

# Assuming you store your defaults in a file
vars = Variables('variables.py')
msvcver = vars.args.get('vc', '9')
# Check command args to force one Microsoft Visual Studio version
if msvcver == '9' or msvcver == '11':
    env = Environment(MSVC_VERSION=msvcver + '.0', MSVC_BATCH=False)
else:
    env = Environment()
AddOption(
    '--userfile',
    action='store_true',
    dest='userfile',
    default=False,
    help="Create Visual C++ project file",
)
#
# 1. Configure your Debug Setting dictionary with options you want in the list
# of allowed options, for instance if you want to create a user file to launch
# a specific application for testing your dll with Microsoft Visual Studio 2008 (v9):
#
V9DebugSettings = {
    'Command': 'c:\\myapp\\using\\thisdll.exe',
    'WorkingDirectory': 'c:\\myapp\\using\\',
    'CommandArguments': '-p password',
    # 'Attach':'false',
    # 'DebuggerType':'3',
    # 'Remote':'1',
    # 'RemoteMachine': None,
    # 'RemoteCommand': None,
    # 'HttpUrl': None,
    # 'PDBPath': None,
    # 'SQLDebugging': None,
    # 'Environment': '',
    # 'EnvironmentMerge':'true',
    # 'DebuggerFlavor': None,
    # 'MPIRunCommand': None,
    # 'MPIRunArguments': None,
    # 'MPIRunWorkingDirectory': None,
    # 'ApplicationCommand': None,
    # 'ApplicationArguments': None,
    # 'ShimCommand': None,
    # 'MPIAcceptMode': None,
    # 'MPIAcceptFilter': None,
}
#
# 2. Because there are a lot of different options depending on the Microsoft
# Visual Studio version, if you use more than one version you have to
# define a dictionary per version, for instance if you want to create a user
# file to launch a specific application for testing your dll with Microsoft
# Visual Studio 2012 (v11):
#
V10DebugSettings = {
    'LocalDebuggerCommand': 'c:\\myapp\\using\\thisdll.exe',
    'LocalDebuggerWorkingDirectory': 'c:\\myapp\\using\\',
    'LocalDebuggerCommandArguments': '-p password',
    # 'LocalDebuggerEnvironment': None,
    # 'DebuggerFlavor': 'WindowsLocalDebugger',
    # 'LocalDebuggerAttach': None,
    # 'LocalDebuggerDebuggerType': None,
    # 'LocalDebuggerMergeEnvironment': None,
    # 'LocalDebuggerSQLDebugging': None,
    # 'RemoteDebuggerCommand': None,
    # 'RemoteDebuggerCommandArguments': None,
    # 'RemoteDebuggerWorkingDirectory': None,
    # 'RemoteDebuggerServerName': None,
    # 'RemoteDebuggerConnection': None,
    # 'RemoteDebuggerDebuggerType': None,
    # 'RemoteDebuggerAttach': None,
    # 'RemoteDebuggerSQLDebugging': None,
    # 'DeploymentDirectory': None,
    # 'AdditionalFiles': None,
    # 'RemoteDebuggerDeployDebugCppRuntime': None,
    # 'WebBrowserDebuggerHttpUrl': None,
    # 'WebBrowserDebuggerDebuggerType': None,
    # 'WebServiceDebuggerHttpUrl': None,
    # 'WebServiceDebuggerDebuggerType': None,
    # 'WebServiceDebuggerSQLDebugging': None,
}
#
# 3. Select the dictionary you want depending on the version of Visual Studio
# Files you want to generate.
#
if not env.GetOption('userfile'):
    dbgSettings = None
elif env.get('MSVC_VERSION', None) == '9.0':
    dbgSettings = V9DebugSettings
elif env.get('MSVC_VERSION', None) == '11.0':
    dbgSettings = V10DebugSettings
else:
    dbgSettings = None
#
# 4. Add the dictionary to the DebugSettings keyword.
#
barsrcs = ['bar.cpp', 'dllmain.cpp', 'stdafx.cpp']
barincs = ['targetver.h']
barlocalincs = ['StdAfx.h']
barresources = ['bar.rc', 'resource.h']
barmisc = ['ReadMe.txt']
dll = env.SharedLibrary(target='bar.dll', source=barsrcs)
env.MSVSProject(
    target='Bar' + env['MSVSPROJECTSUFFIX'],
    srcs=barsrcs,
    incs=barincs,
    localincs=barlocalincs,
    resources=barresources,
    misc=barmisc,
    buildtarget=[dll[0]] * 2,
    variant=('Debug|Win32', 'Release|Win32'),
    cmdargs=f'vc={msvcver}',
    DebugSettings=(dbgSettings, {}),
)

یک فایل راهکار Visual Studio را بر اساس نسخه پیکربندی‌شده Visual Studio می‌سازد: یا آخرین نسخه نصب‌شده، یا نسخه‌ای که توسط $MSVC_VERSION در محیط ساخت مشخص شده است. برای Visual Studio 6، یک فایل .dsw تولید می‌شود. برای Visual Studio .NET 2002 و جدیدتر، یک فایل .sln تولید خواهد شد. توجه داشته باشید که در محیط ترجمه و کامپایل مایکروسافت چندین طرح نسخه‌بندی دخیل هستند - برای معادل‌ها به توضیحات $MSVC_VERSION مراجعه کنید.

فایل راهکار محفظه‌ای برای یک یا چند پروژه است و از قالبی که در https://learn.microsoft.com/en-us/visualstudio/extensibility/internals/solution-dot-sln-file[4] توصیف شده، پیروی می‌کند.

مقادیر زیر باید مشخص شوند:

target

variant

projects

علاوه بر آرگومان‌های اجباری بالا، مقادیر اختیاری زیر می‌توانند به عنوان آرگومان‌های کلیدواژه‌ای مشخص شوند:

auto_filter_projects

نمونه کاربرد:

env.MSVSSolution(
    target="Bar" + env["MSVSSOLUTIONSUFFIX"],
    projects=["bar" + env["MSVSPROJECTSUFFIX"]],
    variant="Release",
)

# On the command line
--experimental=ninja
# Or in your SConstruct
SetOption('experimental', 'ninja')

python -m pip install ninja

اگر با یک تک‌آرگومان موضعی فراخوانی شود، scons نام هدف را از آن آرگومان منبع «استنتاج» کرده، همان نام را به آن اختصاص می‌دهد و سپس منبع را نادیده می‌گیرد. در صورتی که نام هدفی غیر از پیش‌فرض خواسته شده باشد، این روش معمول فراخوانی سازنده است.

اگر با هر یک از آرگومان‌های کلیدواژه‌ای target= یا source= فراخوانی شود، مقدار آرگومان به عنوان نام هدف در نظر گرفته می‌شود. اگر با هر دو فراخوانی شود، مقدار target= استفاده شده و source= نادیده گرفته می‌شود. اگر با چند منبع فراخوانی شود، فهرست منابع نادیده گرفته خواهد شد، زیرا راهی برای استنتاج هدف مورد نظر وجود ندارد؛ در این حالت نام هدف پیش‌فرض استفاده خواهد شد.

از scons 4.2 به بعد در دسترس است.

env = Environment(tools=['default', 'packaging'])

SCons می‌تواند بسته‌ها را در چندین قالب بسته‌بندی شناخته‌شده بسازد. نوع بستهٔ هدف می‌تواند با متغیر ساخت $PACKAGETYPE یا گزینهٔ خط فرمان --package-type انتخاب شود. نوع بسته می‌تواند یک فهرست باشد، که در این صورت SCons تلاش خواهد کرد تا بسته‌ها را برای هر نوع موجود در فهرست بسازد. مثال:

env.Package(PACKAGETYPE=['src_zip', 'src_targz'], ...other args...)

بسته‌بندهای پشتیبانی‌شده در حال حاضر عبارتند از:

فهرست فایل‌هایی که باید در بسته گنجانده شوند را می‌توان با آرگومان کلیدواژه‌ای source مشخص کرد. در صورت حذف، تابع FindInstalledFiles در پشت صحنه فراخوانی می‌شود تا تمام فایل‌هایی را که یک سازندهٔ Install، InstallAs یا InstallVersionedLib به آن‌ها متصل است، انتخاب کند. اگر آرگومان کلیدواژه‌ای target حذف شود، نام(های) هدف از روی نوع(های) بسته استنتاج خواهد شد.

فراداده تا حدی از ویژگی‌های فایل‌هایی که باید بسته‌بندی شوند، و تا حدی از برچسب‌های بسته‌بندی به دست می‌آید. برچسب‌ها را می‌توان به صورت آرگومان‌های کلیدواژه‌ای به فراخوانی سازندهٔ Package ارسال کرد، و همچنین می‌توان آن‌ها را با استفاده از تابع Tag به فایل‌ها (یا دقیق‌تر، گره‌هایی (Nodes) که نمایانگر فایل‌ها هستند) ضمیمه کرد. برخی از برچسب‌های سطح بسته اجباری هستند و در صورت حذف منجر به خطا خواهند شد. برچسب‌های اجباری بسته به نوع بسته متفاوت هستند.

هنگام بسته‌بندی، سازنده از یک مکان موقت مشخص‌شده با مقدار متغیر $PACKAGEROOT استفاده می‌کند - سورس‌های بسته پیش از بسته‌بندی در آنجا کپی می‌شوند.

مثال بسته‌بندی:

env = Environment(tools=["default", "packaging"])
env.Install("/bin/", "my_program")
env.Package(
    NAME="foo",
    VERSION="1.2.3",
    PACKAGEVERSION=0,
    PACKAGETYPE="rpm",
    LICENSE="gpl",
    SUMMARY="balalalalal",
    DESCRIPTION="this should be really really long",
    X_RPM_GROUP="Application/fu",
    SOURCE_URL="https://foo.org/foo-1.2.3.tar.gz",
)

در این مثال، هدف /bin/my_program ایجاد شده توسط فراخوانی Install به طور پیش‌فرض ساخته نخواهد شد زیرا زیر دایرکتوری اصلی پروژه قرار ندارد. با این حال، از آنجا که هیچ source مشخصی برای سازندهٔ Package تعیین نشده است، بر اساس قاعدهٔ سورس‌های پیش‌فرض برای بسته‌بندی انتخاب می‌شود. از آنجا که بسته‌بندی با استفاده از $PACKAGEROOT انجام می‌شود، در واقع هیچ نوشتنی در دایرکتوری /bin سیستم رخ نمی‌دهد، و هدف حتماً انتخاب خواهد شد، چرا که پس از تغییر مبنا به زیر $PACKAGEROOT اکنون زیر دایرکتوری اصلی پروژه قرار می‌گیرد.

گره‌های هدف تعریف‌شده از طریق POInit به طور پیش‌فرض ساخته نمی‌شوند (آن‌ها از گره '.' نادیده گرفته می‌شوند) اما به یک Alias ویژه (به طور پیش‌فرض 'po-create') افزوده می‌گردند. نام مستعار را می‌توان از طریق متغیر ساخت $POCREATE_ALIAS تغییر داد. تمام فایل‌های PO تعریف‌شده از طریق POInit را می‌توان به راحتی با دستور scons po-create مقداردهی اولیه کرد.

مثال ۱. مقداردهی اولیه en.po و pl.po از messages.pot:

env.POInit(['en', 'pl']) # messages.pot --> [en.po, pl.po]

مثال ۲. مقداردهی اولیه en.po و pl.po از foo.pot:

env.POInit(['en', 'pl'], ['foo']) # foo.pot --> [en.po, pl.po]

مثال ۳. مقداردهی اولیه en.po و pl.po از foo.pot اما با استفاده از متغیر ساخت $POTDOMAIN:

env.POInit(['en', 'pl'], POTDOMAIN='foo') # foo.pot --> [en.po, pl.po]

مثال ۴. مقداردهی اولیه فایل‌های PO برای زبان‌های تعریف‌شده در فایل LINGUAS. فایل‌ها از قالب messages.pot مقداردهی اولیه خواهند شد:

env.POInit(LINGUAS_FILE=True)  # needs 'LINGUAS' file

مثال ۵. مقداردهی اولیه فایل‌های PO en.po و pl.pl به علاوه فایل‌های مربوط به زبان‌های تعریف‌شده در فایل LINGUAS. فایل‌ها از قالب messages.pot مقداردهی اولیه خواهند شد:

env.POInit(['en', 'pl'], LINGUAS_FILE=True)

مثال ۶. می‌توانید ابتدا محیط خود را از پیش پیکربندی کنید، و سپس فایل‌های PO را مقداردهی اولیه نمایید:

env['POAUTOINIT'] = True
env['LINGUAS_FILE'] = True
env['POTDOMAIN'] = 'foo'
env.POInit()

که همان اثری را دارد که:

env.POInit(POAUTOINIT=True, LINGUAS_FILE=True, POTDOMAIN='foo')

مثال ۱. بیایید دایرکتوری po/ را ایجاد کرده و اسکریپت SConstruct زیر را در آن قرار دهیم:

# SConstruct in 'po/' subdir
env = Environment(tools=['default', 'xgettext'])
env.POTUpdate(['foo'], ['../a.cpp', '../b.cpp'])
env.POTUpdate(['bar'], ['../c.cpp', '../d.cpp'])

سپس scons را چند بار فراخوانی کنید:

$ scons             # Does not create foo.pot nor bar.pot
$ scons foo.pot     # Updates or creates foo.pot
$ scons pot-update  # Updates or creates foo.pot and bar.pot
$ scons -c          # Does not clean foo.pot nor bar.pot.

نتایج همان‌گونه خواهند بود که در توضیحات بالا آمده است.

مثال ۲. آرگومان target می‌تواند حذف شود، که در این حالت نام هدف پیش‌فرض messages.pot استفاده می‌شود. هدف همچنین می‌تواند با تنظیم متغیر ساخت $POTDOMAIN یا ارائهٔ آن به عنوان یک جایگزین به سازندهٔ POTUpdate بازنویسی شود:

# SConstruct script
env = Environment(tools=['default', 'xgettext'])
env['POTDOMAIN'] = "foo"
env.POTUpdate(source=["a.cpp", "b.cpp"])  # Creates foo.pot ...
env.POTUpdate(POTDOMAIN="bar", source=["c.cpp", "d.cpp"])  # and bar.pot

مثال ۳. پارامتر source نیز در صورتی که در یک فایل جداگانه، برای مثال POTFILES.in مشخص شده باشد، می‌تواند حذف شود:

# POTFILES.in in 'po/' subdirectory
../a.cpp
../b.cpp
# end of file

نام فایلی (POTFILES.in) که حاوی فهرست منابع است از طریق $XGETTEXTFROM ارائه می‌شود:

# SConstruct file in 'po/' subdirectory
env = Environment(tools=['default', 'xgettext'])
env.POTUpdate(XGETTEXTFROM='POTFILES.in')

مثال ۴. می‌توانید از $XGETTEXTPATH برای تعریف مسیر جستجوی منبع استفاده کنید. برای مثال فرض کنید فایل‌های a.cpp، b.cpp، po/SConstruct، po/POTFILES.in را دارید. در این صورت فایل‌های مرتبط با POT شما می‌توانند به این شکل باشند:

# POTFILES.in in 'po/' subdirectory
a.cpp
b.cpp
# end of file

# SConstruct file in 'po/' subdirectory
env = Environment(tools=['default', 'xgettext'])
env.POTUpdate(XGETTEXTFROM='POTFILES.in', XGETTEXTPATH='../')

مثال ۵. چندین دایرکتوری جستجو را می‌توان به‌صورت یک لیست تعریف کرد، یعنی XGETTEXTPATH=['dir1', 'dir2', ...]. ترتیب در لیست، ترتیب جستجوی فایل‌های منبع را مشخص می‌کند. مسیر اولین فایل یافت‌شده استفاده می‌شود.

بیایید اسکریپت 0/1/po/SConstruct را ایجاد کنیم:

# SConstruct file in '0/1/po/' subdirectory
env = Environment(tools=['default', 'xgettext'])
env.POTUpdate(XGETTEXTFROM='POTFILES.in', XGETTEXTPATH=['../', '../../'])

و همچنین 0/1/po/POTFILES.in:

# POTFILES.in in '0/1/po/' subdirectory
a.cpp
# end of file

دو فایل *.cpp بنویسید، اولی 0/a.cpp است:

/* 0/a.cpp */
gettext("Hello from ../../a.cpp")

و دومی 0/1/a.cpp است:

/* 0/1/a.cpp */
gettext("Hello from ../a.cpp")

سپس scons را اجرا کنید. شما 0/1/po/messages.pot را با پیام "Hello from ../a.cpp" به دست خواهید آورد. زمانی که ترتیب را در $XGETTEXTFOM معکوس کنید، یعنی هنگامی که SConscript را به‌صورت زیر بنویسید:

# SConstruct file in '0/1/po/' subdirectory
env = Environment(tools=['default', 'xgettext'])
env.POTUpdate(XGETTEXTFROM='POTFILES.in', XGETTEXTPATH=['../../', '../'])

آنگاه messages.pot شامل خط msgid "Hello from ../../a.cpp" خواهد بود و نه msgid "Hello from ../a.cpp".

گره‌های هدف به‌طور پیش‌فرض برای ساخت انتخاب نمی‌شوند (برای نمونه scons .). در عوض، آن‌ها به‌طور خودکار به یک Alias ویژه (به‌طور پیش‌فرض 'po-update') افزوده می‌شوند. نام مستعار را می‌توان از طریق متغیر ساخت $POUPDATE_ALIAS تغییر داد. می‌توانید به‌سادگی پرونده‌های PO را در پروژهٔ خود با دستور scons po-update به‌روزرسانی کنید. توجه داشته باشید که POUpdate برخلاف POInit، هدف‌های خود را به نام مستعار po-create نمی‌افزاید.

مثال ۱. به‌روزرسانی en.po و pl.po از قالب messages.pot (همچنین ببینید $POTDOMAIN)، با این فرض که مورد دوم وجود دارد یا قانونی برای ساخت آن تعریف شده است (ببینید POTUpdate):

env.POUpdate(['en','pl'])  # messages.pot --> [en.po, pl.po]

مثال ۲. به‌روزرسانی en.po و pl.po از قالب foo.pot:

env.POUpdate(['en', 'pl'], ['foo'])  # foo.pot -->  [en.po, pl.pl]

مثال ۳. به‌روزرسانی en.po و pl.po از foo.pot (روشی دیگر):

env.POUpdate(['en', 'pl'], POTDOMAIN='foo')  # foo.pot -- > [en.po, pl.pl]

مثال ۴. به‌روزرسانی پرونده‌ها برای زبان‌های تعریف‌شده در پروندهٔ LINGUAS. پرونده‌ها از قالب messages.pot به‌روزرسانی می‌شوند:

env.POUpdate(LINGUAS_FILE=True)  # needs 'LINGUAS' file

مثال ۵. مشابه بالا، اما به‌روزرسانی از قالب foo.pot:

env.POUpdate(LINGUAS_FILE=True, source=['foo'])

مثال ۶. به‌روزرسانی en.po و pl.po به‌همراه پرونده‌ها برای زبان‌های تعریف‌شده در پروندهٔ LINGUAS. پرونده‌ها از قالب messages.pot به‌روزرسانی می‌شوند:

# produce 'en.po', 'pl.po' + files defined in 'LINGUAS':
env.POUpdate(['en', 'pl' ], LINGUAS_FILE=True)

مثال ۷. استفاده از $POAUTOINIT برای مقداردهی اولیهٔ خودکار پروندهٔ PO در صورتی که وجود نداشته باشد:

env.POUpdate(LINGUAS_FILE=True, POAUTOINIT=True)

مثال ۸. به‌روزرسانی پرونده‌های PO برای زبان‌های تعریف‌شده در پروندهٔ LINGUAS. پرونده‌ها از قالب foo.pot به‌روزرسانی می‌شوند. تمام تنظیمات لازم از پیش از طریق محیط پیکربندی شده‌اند.

env['POAUTOINIT'] = True
env['LINGUAS_FILE'] = True
env['POTDOMAIN'] = 'foo'
env.POUpdate()

کدهای منبع D می‌توانند مانند منابع C و C++ به‌صورت فایل‌به‌فایل کامپایل شوند، و زبان D برای این مدل ساخت با سازنده‌های Object و Program در scons یکپارچه شده است. با این حال، کدهای D می‌توانند فرا-برنامه‌نویسی روی کل کد منبع (whole source meta-programming) انجام دهند (برخی از چارچوب‌های آزمون این کار را می‌کنند). برای این منظور ضروری است که تمام منابع در یک فراخوانی واحد به کامپایلر D، کامپایل و پیوند (link) داده شوند. این سازنده در خدمت این هدف است.

env.ProgramAllAtOnce('executable', ['mod_a.d, mod_b.d', 'mod_c.d'])

این دستور ماژول‌های mod_a، mod_b و mod_c را در یک فرایند کامپایل واحد بدون ایجاد فایل‌های شیء اولیه برای ماژول‌ها، کامپایل خواهد کرد. برخی از کامپایلرهای D فایل executable.o را ایجاد خواهند کرد و برخی دیگر ایجاد نخواهند کرد.

اگر متغیر ساخت $JAVACLASSDIR تنظیم شده باشد، چه در محیط و چه در فراخوانی خود متد سازنده RMIC، مقدار این متغیر از ابتدای هر نام فایل .class حذف خواهد شد.

classes = env.Java(target='classdir', source='src')
env.RMIC(target='outdir1', source=classes)
env.RMIC(
    target='outdir2',
    source=['package/foo.class', 'package/bar.class'],
)
env.RMIC(
    target='outdir3',
    source=['classes/foo.class', 'classes/bar.class'],
    JAVACLASSDIR='classes',
)

پیشوند فایل کتابخانه هدف، مشخص‌شده توسط متغیر ساخت $SHLIBPREFIX (به طور پیش‌فرض، lib در سیستم‌های POSIX، و بدون مقدار در سیستم‌های Windows)، و پسوند، مشخص‌شده توسط متغیر ساخت $SHLIBSUFFIX (به طور پیش‌فرض، .dll در سیستم‌های Windows، و .so در سیستم‌های POSIX)، به طور خودکار (اگر از قبل وجود نداشته باشد) به نام هدف اضافه می‌شوند تا نام فایل کتابخانه تشکیل شود. در یک سیستم POSIX، اگر متغیر ساخت $SHLIBVERSION تنظیم شده باشد، (پس از یک نقطه) به انتهای نام کتابخانه حاصل اضافه می‌شود.

مثال:

env.SharedLibrary(target='bar', source=['bar.c', 'foo.o'])

در سیستم‌های Windows، متد سازنده SharedLibrary همیشه علاوه بر کتابخانه مشترک (.dll)، یک کتابخانه واردات (.lib) نیز خواهد ساخت، و در صورتی که فایلی با پسوند .lib به طور صریح در اهداف فهرست نشده باشد، یک کتابخانه .lib با همان نام پایه اضافه می‌کند.

در سیستم‌های Cygwin، متد سازنده SharedLibrary همیشه علاوه بر کتابخانه مشترک (.dll)، یک کتابخانه واردات (.dll.a) نیز خواهد ساخت، و در صورتی که فایلی با پسوند .dll.a به طور صریح در اهداف فهرست نشده باشد، یک کتابخانه .dll.a با همان نام پایه اضافه می‌کند.

در برخی پلتفرم‌ها، میان یک کتابخانه مشترک (که برای حل ارجاعات خارجی به طور خودکار توسط سیستم بارگذاری می‌شود) و یک ماژول قابل بارگذاری (که با اقدام کاربر به طور صریح بارگذاری می‌شود) تمایز وجود دارد. برای بیشترین سازگاری و قابلیت حمل، برای مورد دوم از سازنده LoadableModule استفاده کنید.

اگر $SHLIBVERSION تعریف شده باشد، یک کتابخانه مشترک نسخه‌دار ایجاد می‌شود. این کار $SHLINKFLAGS را بر حسب نیاز تغییر می‌دهد، شماره نسخه را به نام کتابخانه اضافه می‌کند و هر پیوند نمادین مورد نیازی را می‌سازد.

env.SharedLibrary(target='bar', source=['bar.c', 'foo.o'], SHLIBVERSION='1.5.2')

در یک سیستم POSIX، ارائه یک رشته نسخه ساده (بدون نقطه) دقیقاً یک پیوند نمادین ایجاد می‌کند: SHLIBVERSION="1" (به عنوان مثال) کتابخانه libbar.so.1 و پیوند نمادین libbar.so را ایجاد می‌کند. ارائه یک رشته نسخه نقطه‌دار دو پیوند نمادین ایجاد خواهد کرد (بدون در نظر گرفتن تعداد بخش‌ها در نسخه): SHLIBVERSION="1.5.2" برای همان کتابخانه، کتابخانه libbar.so.1.5.2 و پیوندهای نمادین libbar.so و libbar.so.1 را ایجاد می‌کند. یک سیستم Darwin (OSX) در هر دو حالت یک پیوند نمادین ایجاد می‌کند؛ برای مثال دوم، کتابخانه libbar.1.5.2.dylib و پیوند libbar.dylib خواهد بود.

در سیستم‌های Windows، مشخص کردن آرگومان کلیدواژه‌ای register=1 باعث می‌شود که .dll پس از ساخته شدن ثبت شود. دستوری که اجرا می‌شود توسط متغیر ساخت $REGSVR (به طور پیش‌فرض regsvr32) تعیین شده و پرچم‌های ارسالی توسط $REGSVRFLAGS مشخص می‌شوند. به طور پیش‌فرض، $REGSVRFLAGS شامل گزینه /s است تا هنگام اجرا، از باز شدن کادرهای محاوره‌ای و نیاز به توجه کاربر جلوگیری کند. اگر $REGSVRFLAGS را تغییر می‌دهید، حتماً گزینه /s را بگنجانید. به عنوان مثال،

env.SharedLibrary(target='bar', source=['bar.cxx', 'foo.obj'], register=1)

پس از پایان پیوند دادن آن، bar.dll را به عنوان یک شیء COM ثبت خواهد کرد.

env.SharedObject(target='ddd', source='ddd.c')
env.SharedObject(target='eee.o', source='eee.cpp')
env.SharedObject(target='fff.obj', source='fff.for')
env.SharedObject(source=Glob('*.c'))

در برخی پلتفرم‌ها، ساخت یک شیء مشترک علاوه بر موارد مورد نیاز برای ساخت یک شیء معمولی (ایستا)، نیازمند گزینه(های) کامپایلر اضافی است (مانند -fPIC برای gcc). اگر اشیاء مشترک و ایستا تفاوت داشته باشند، SCons تنها اجازه می‌دهد اشیاء مشترک به یک کتابخانه مشترک پیوند داده شوند، و برای کمک به نمایش و ردیابی این تفاوت، از پسوند متفاوتی برای اشیاء مشترک استفاده خواهد کرد.

فایل‌های منبع بر اساس نگاشت‌های پسوند در شیء SourceFileScanner پویش خواهند شد. برای اطلاعات بیشتر به بخش "Scanner Objects" در صفحه راهنما مراجعه کنید.

env.StaticLibrary(target='bar', source=['bar.c', 'foo.o'])

هر فایل شیء فهرست‌شده در source باید برای یک کتابخانهٔ ایستا ساخته شده باشد (یعنی با استفاده از متد سازندهٔ StaticObject). در صورت وجود هرگونه عدم تطابق، scons خطایی صادر خواهد کرد.

.asm    فایل زبان اسمبلی
.ASM    فایل زبان اسمبلی
.c      فایل C
.C      Windows:  فایل C
        POSIX:  فایل C++
.cc     فایل C++
.cpp    فایل C++
.cxx    فایل C++
.cxx    فایل C++
.c++    فایل C++
.C++    فایل C++
.d      فایل D
.f      فایل Fortran
.F      Windows:  فایل Fortran
        POSIX:  فایل Fortran + پیش‌پردازندهٔ C
.for    فایل Fortran
.FOR    فایل Fortran
.fpp    فایل Fortran + پیش‌پردازندهٔ C
.FPP    فایل Fortran + پیش‌پردازندهٔ C
.m      فایل Object C
.mm     فایل Object C++
.s      فایل زبان اسمبلی
.S      Windows:  فایل زبان اسمبلی
        ARM: CodeSourcery Sourcery Lite
.sx     فایل زبان اسمبلی + پیش‌پردازندهٔ C
        POSIX:  فایل زبان اسمبلی + پیش‌پردازندهٔ C
.spp    فایل زبان اسمبلی + پیش‌پردازندهٔ C
.SPP    فایل زبان اسمبلی + پیش‌پردازندهٔ C

پیشوند فایل شیء هدف، که توسط متغیر ساخت $OBJPREFIX مشخص می‌شود (به‌طور پیش‌فرض رشتهٔ خالی)، و پسوند آن، که توسط متغیر ساخت $OBJSUFFIX مشخص می‌شود (.obj در سیستم‌های Windows و .o در سیستم‌های POSIX)، در صورتی که از قبل موجود نباشند، به‌طور خودکار به هدف افزوده می‌شوند. StaticObject یک سازندهٔ تک‌منبعی است. مثال‌ها:

env.StaticObject(target='aaa', source='aaa.c')
env.StaticObject(target='bbb.o', source='bbb.c++')
env.StaticObject(target='ccc.obj', source='ccc.f')
env.StaticObject(source=Glob('*.c'))

فایل‌های منبع مطابق با نگاشت‌های پسوند در شیء SourceFileScanner پویش خواهند شد. برای اطلاعات بیشتر بخش “Scanner Objects” در صفحهٔ راهنما را ببینید.

به‌طور پیش‌فرض، کدگذاری فایل هدف “utf-8” است و می‌تواند توسط $FILE_ENCODING تغییر کند. مثال‌ها:

اگر نام یک فایل منبع تکی مشخص شده باشد و دارای پسوند .in باشد، این پسوند حذف شده و باقیماندهٔ نام به عنوان نام هدف پیش‌فرض استفاده می‌شود.

پیشوند و پسوند مشخص‌شده توسط متغیرهای ساخت $SUBSTFILEPREFIX و $SUBSTFILESUFFIX (در هر دو مورد به‌طور پیش‌فرض یک رشتهٔ خالی)، در صورتی که از قبل موجود نباشند، به‌طور خودکار به هدف افزوده می‌شوند.

اگر متغیر ساختی به نام $SUBST_DICT وجود داشته باشد، می‌تواند یک دیکشنری Python یا توالی‌ای از چندتایی‌های (key, value) باشد. اگر یک دیکشنری باشد، به فهرستی از چندتایی‌ها با ترتیبی نامشخص تبدیل می‌شود؛ بنابراین اگر یک کلید پیشوندی از کلید دیگر باشد یا اگر یک جایگزینی بتواند با جایگزینی دیگر بیشتر بسط یابد، رخ دادن یا ندادن بسط غیرقابل پیش‌بینی خواهد بود.

هر بار وقوع یک کلید در منبع با مقدار متناظر آن جایگزین می‌شود، که می‌تواند یک تابع قابل فراخوانی در Python یا یک رشته باشد. اگر مقدار یک تابع قابل فراخوانی باشد، بدون هیچ آرگومانی فراخوانی می‌شود تا یک رشته به دست آید. رشته‌ها با subst بسط داده می‌شوند و نتیجه جایگزین کلید می‌شود.

env = Environment(tools=['default'])
env['prefix'] = '/usr/bin'
script_dict = {'@prefix@': '/bin', '@exec_prefix@': '$prefix'}
env.Substfile('script.in', SUBST_DICT=script_dict)
conf_dict = {'%VERSION%': '1.2.3', '%BASE%': 'MyProg'}
env.Substfile('config.h.in', conf_dict, SUBST_DICT=conf_dict)
# UNPREDICTABLE - one key is a prefix of another
bad_foo = {'$foo': '$foo', '$foobar': '$foobar'}
env.Substfile('foo.in', SUBST_DICT=bad_foo)
# PREDICTABLE - keys are applied longest first
good_foo = [('$foobar', '$foobar'), ('$foo', '$foo')]
env.Substfile('foo.in', SUBST_DICT=good_foo)
# UNPREDICTABLE - one substitution could be further expanded
bad_bar = {'@bar@': '@soap@', '@soap@': 'lye'}
env.Substfile('bar.in', SUBST_DICT=bad_bar)
# PREDICTABLE - substitutions are expanded in order
good_bar = (('@bar@', '@soap@'), ('@soap@', 'lye'))
env.Substfile('bar.in', SUBST_DICT=good_bar)
# the SUBST_DICT may be in common (and not an override)
substutions = {}
subst = Environment(tools=['textfile'], SUBST_DICT=substitutions)
substitutions['@foo@'] = 'foo'
subst['SUBST_DICT']['@bar@'] = 'bar'
subst.Substfile(
    'pgm1.c',
    [Value('#include "@foo@.h"'), Value('#include "@bar@.h"'), "common.in", "pgm1.in"],
)
subst.Substfile(
    'pgm2.c',
    [Value('#include "@foo@.h"'), Value('#include "@bar@.h"'), "common.in", "pgm2.in"],
)

پیشوند و پسوند مشخص‌شده توسط متغیرهای ساخت $TEXTFILEPREFIX و $TEXTFILESUFFIX (به‌طور پیش‌فرض به ترتیب یک رشتهٔ خالی و .txt) در صورتی که از قبل وجود نداشته باشند، به‌طور خودکار به هدف اضافه می‌شوند.

به‌طور پیش‌فرض، کدبندی فایل هدف "utf-8" است و می‌تواند با $FILE_ENCODING تغییر کند. مثال‌ها:

# builds/writes foo.txt
env.Textfile(target='foo.txt', source=['Goethe', 42, 'Schiller'])
# builds/writes bar.txt
env.Textfile(target='bar', source=['lalala', 'tanteratei'], LINESEPARATOR='|*')
# nested lists are flattened automatically
env.Textfile(target='blob', source=['lalala', ['Goethe', 42, 'Schiller'], 'tanteratei'])
# files may be used as input by wrapping them in File()
env.Textfile(
    target='concat',  # concatenate files with a marker between
    source=[File('concat1'), File('concat2')],
    LINESEPARATOR='====================\n',
)

نتایج:

foo.txt

Goethe
42
Schiller

bar.txt

lalala|*tanteratei

blob.txt

lalala
Goethe
42
Schiller
tanteratei

مثال ۱. ساده‌ترین راه، تعیین فایل‌های ورودی و زبان‌های خروجی به‌صورت درون‌خطی در یک اسکریپت SCons هنگام فراخوانی Translate است:

# SConscript in 'po/' directory
env = Environment(tools=["default", "gettext"])
env['POAUTOINIT'] = True
env.Translate(['en', 'pl'], ['../a.cpp', '../b.cpp'])

مثال ۲. در صورت تمایل، می‌توانید به سبک مرسوم شناخته‌شده از autotools نیز پایبند باشید، یعنی استفاده از فایل‌های POTFILES.in و LINGUAS برای مشخص کردن هدف‌ها و مبدأها:

# LINGUAS
en pl
# end

# POTFILES.in
a.cpp
b.cpp
# end

# SConscript
env = Environment(tools=["default", "gettext"])
env['POAUTOINIT'] = True
env['XGETTEXTPATH'] = ['../']
env.Translate(LINGUAS_FILE=True, XGETTEXTFROM='POTFILES.in')

رویکرد آخر احتمالاً روش توصیه‌شده است. این رویکرد امکان تفکیک آسان بین‌المللی‌سازی/محلی‌سازی را در اسکریپت‌های جداگانهٔ SCons فراهم می‌کند؛ به‌گونه‌ای که یک اسکریپت در درخت مبدأ مسئول ترجمه‌ها (از فایل‌های مبدأ به فایل‌های PO) است و اسکریپت(ها) در دایرکتوری‌های متغیر (variant directories) مسئول کامپایل فایل‌های PO به فایل‌های MO و همچنین نصب فایل‌های MO هستند. در این حالت «عامل پیونددهنده» که این دو اسکریپت را همگام می‌کند، محتوای فایل LINGUAS است. توجه داشته باشید که فایل‌های به‌روزشدهٔ POT و PO معمولاً قرار است به مخزن ثبت (commit) شوند، بنابراین باید در داخل دایرکتوری مبدأ به‌روز شوند (و نه در دایرکتوری‌های متغیر). علاوه بر این، فهرست فایل‌های دایرکتوری po/ شامل فایل LINGUAS است، بنابراین درخت مبدأ برای مترجمان آشنا به نظر می‌رسد و آن‌ها می‌توانند به شیوهٔ معمول خود با پروژه کار کنند.

مثال ۳. بیایید یک درخت توسعه را به‌صورت زیر آماده کنیم:

project/
 + SConstruct
 + build/
 + src/
     + po/
         + SConscript
         + SConscript.i18n
         + POTFILES.in
         + LINGUAS

که در آن build دایرکتوری متغیر باشد. اسکریپت سطح بالای SConstruct را به‌صورت زیر بنویسید:

# SConstruct
env = Environment(tools=["default", "gettext"])
VariantDir('build', 'src', duplicate=False)
env['POAUTOINIT'] = True
SConscript('src/po/SConscript.i18n', exports='env')
SConscript('build/po/SConscript', exports='env')

اسکریپت src/po/SConscript.i18n به‌صورت:

# src/po/SConscript.i18n
Import('env')
env.Translate(LINGUAS_FILE=True, XGETTEXTFROM='POTFILES.in', XGETTEXTPATH=['../'])

و اسکریپت src/po/SConscript

# src/po/SConscript
Import('env')
env.MOFiles(LINGUAS_FILE=True)

چنین پیکربندی‌ای فایل‌های POT و PO را در درخت مبدأ در src/po/ و فایل‌های باینری MO را در درخت متغیر در build/po/ تولید می‌کند. بدین‌ترتیب فایل‌های POT و PO از سایر فایل‌های خروجی که نباید به مخازن مبدأ بازگردانده (کامیت) شوند (مانند فایل‌های MO) تفکیک می‌شوند.

env.TypeLibrary(source="foo.idl")

فایل‌های foo.tlb، foo.h، foo_i.c، foo_p.c و foo_data.c را ایجاد خواهد کرد.

Function(arguments, [optional arguments, ...])  # Global function
env.Function(arguments, [optional arguments, ...])  # Environment method

توجه داشته باشید که شکل فراخوانی env.Action متغیرهای ساخت را در تمام رشته‌های آرگومان، از جمله آرگومان action، در هنگام فراخوانی با استفاده از متغیرهای ساخت در همان محیط ساختی که env.Action از طریق آن فراخوانی شده است، بسط می‌دهد. شکل تابع سراسری Action تمام بسط‌های متغیر را تا زمانی که شیء Action واقعاً مورد استفاده قرار گیرد به تعویق می‌اندازد.

هنگامی که تابع سراسری AddMethod فراخوانی می‌شود، شیئی که قرار است متد به آن افزوده شود باید به عنوان نخستین آرگومان ارسال گردد؛ معمولاً این شیء Environment خواهد بود تا متدی ایجاد شود که بر تمام محیط‌های ساختی که پس از آن ساخته می‌شوند اعمال گردد. هنگامی که با استفاده از شکل env.AddMethod فراخوانی شود، متد فقط به همان محیط ساختِ مشخص‌شده افزوده می‌شود. متدهای افزوده شده از طریق فراخوانی‌های env.Clone نیز انتشار می‌یابند.

نمونه‌های بیشتر:

# Function to add must accept an instance argument.
# The Python convention is to call this 'self'.
def my_method(self, arg):
    print("my_method() got", arg)
# Use the global function to add a method to the Environment class:
AddMethod(Environment, my_method)
env = Environment()
env.my_method('arg')
# Use the optional name argument to set the name of the method:
env.AddMethod(my_method, 'other_method_name')
env.other_method_name('another arg')

علاوه بر آرگومان‌ها و مقادیر پشتیبانی‌شده توسط متد add_option در optparse، AddOption امکان تنظیم مقدار کلیدواژهٔ nargs به یک رشتهٔ '?' (علامت سوال) را می‌دهد تا نشان دهد که آرگومان گزینه برای آن رشتهٔ گزینه می‌تواند حذف شود. اگر رشتهٔ گزینه در خط فرمان وجود داشته باشد اما هیچ آرگومان گزینهٔ منطبقی نداشته باشد، مقدار آرگومان کلیدواژه‌ای const به‌عنوان مقدار گزینه تولید می‌شود. اگر رشتهٔ گزینه از خط فرمان حذف شود، طبق معمول مقدار آرگومان کلیدواژه‌ای default تولید می‌شود؛ اگر هیچ آرگومان کلیدواژه‌ای default در فراخوانی AddOption وجود نداشته باشد، None تولید می‌شود.

optparse مخفف‌های نام‌های گزینه‌های طولانی را تا زمانی که بتوان آن‌ها را به‌طور یکتا و بدون ابهام تشخیص داد، شناسایی می‌کند. برای نمونه، اگر add_option برای تعریف گزینهٔ --devicename فراخوانی شود، --device، --dev و غیره را نیز تا زمانی که هیچ گزینهٔ دیگری نتواند با همان مخفف مطابقت داشته باشد، تشخیص می‌دهد. گزینه‌های افزوده‌شده از طریق AddOption از تشخیص خودکار مخفف‌ها پشتیبانی نمی‌کنند. در عوض، برای مجاز کردن مخفف‌های خاص، آن‌ها را به عنوان مترادف در خود فراخوانی AddOption بگنجانید.

پس از اضافه شدن یک گزینهٔ خط فرمان جدید با AddOption، مقدار گزینه را می‌توان با استفاده از GetOption یا env.GetOption دریافت کرد. اگر آرگومان settable=True در فراخوانی AddOption داده شده باشد، در صورتی که شرایط در یک فایل SConscript نیاز به بازنویسی مقدار پیش‌فرض داشته باشد، می‌توان مقدار را بعداً با استفاده از SetOption یا env.SetOption نیز تنظیم کرد. با این حال توجه داشته باشید مقداری که در خط فرمان مشخص شده باشد همیشه مقداری را که در یک فایل SConscript تنظیم شده بازنویسی خواهد کرد.

تغییر یافته در نسخهٔ 4.8.0: آرگومان کلیدواژه‌ای settable اضافه شد تا امکان تنظیم یک گزینهٔ افزوده‌شده از طریق SetOption فراهم شود.

متن راهنما برای یک گزینه، ترکیبی از رشتهٔ ارائه‌شده در آرگومان کلیدواژه‌ای help به AddOption و اطلاعات جمع‌آوری‌شده از سایر آرگومان‌های کلیدواژه‌ای است. چنین راهنمایی در صورت استفاده از گزینهٔ خط فرمان -h نمایش داده می‌شود (اما نه با -H). راهنمای همهٔ گزینه‌های محلی ذیل عنوان مجزای Local Options نمایش داده می‌شود. گزینه‌ها مرتب‌نشده هستند - آن‌ها در متن راهنما به همان ترتیبی که فراخوانی‌های AddOption رخ می‌دهند ظاهر خواهند شد.

مثال:

AddOption(
    '--prefix',
    dest='prefix',
    nargs=1,
    type='string',
    action='store',
    metavar='DIR',
    help='installation prefix',
)
env = Environment(PREFIX=GetOption('prefix'))

برای این مثال، متن راهنمای زیر تولید خواهد شد:

Local Options:
  --prefix=DIR                installation prefix

در صورتی که تابع Help فراخوانی شده باشد، ممکن است متن راهنما برای گزینه‌های محلی در دسترس نباشد؛ برای جزئیات به مستندات Help مراجعه کنید.

هنگامی که چند هدف ارائه شود، ممکن است کنش چندین بار فراخوانی شود؛ یک بار پس از هر کنشی که یک یا چند هدف از فهرست را تولید می‌کند.

foo = Program('foo.c')
# remove execute permission from binary:
AddPostAction(foo, Chmod('$TARGET', "a-x"))

اگر یک target یک Alias باشد، action در صورت مشخص بودن، به کنش آن نام مستعار پیوند می‌یابد.

هنگامی که چندین هدف مشخص شده باشند، کنش(ها) ممکن است چندین بار فراخوانی شوند؛ یک بار پیش از هر کنشی که یک یا چند هدف از فهرست را تولید می‌کند.

توجه داشته باشید که اگر هر یک از هدف‌ها در چند مرحله ساخته شوند، کنش درست پیش از مرحله‌ای فراخوانی می‌شود که مشخصاً هدف(های) تعیین‌شده را تولید می‌کند. شاید همیشه آشکار نباشد که یک فرایند چندمرحله‌ای است یا خیر - برای نمونه، اگر از سازندهٔ Program برای ساخت یک برنامهٔ اجرایی از یک فایل مبدأ .c استفاده کنید، scons ابتدا یک فایل شیء واسط می‌سازد؛ پیش‌کنش (pre-action) پس از این مرحله و درست پیش از دستور پیوند (link) برای تولید دودویی برنامه اجرایی فراخوانی می‌شود. مثال:

foo = Program('foo.c')
AddPreAction(foo, 'echo "Running pre-action"')

$ scons -Q
gcc -o foo.o -c foo.c
echo "Running pre-action"
Running pre-action
gcc -o foo foo.o

اگر یک target یک Alias باشد، action به کنشِ آن نام مستعار (در صورت تعیین شدن) مرتبط می‌شود.

alias و source هر یک می‌توانند یک رشته یا شیء Node، یا فهرستی از رشته‌ها یا اشیاء Node باشند؛ اگر برای alias از شیء Node استفاده شود، باید گره‌های Alias باشند. اگر source حذف شود، نام مستعار ایجاد می‌شود اما مرجعی نخواهد داشت؛ اگر برای ساخت انتخاب شود، این وضعیت به پیام “Nothing to be done.” منجر خواهد شد. یک نام مستعار خالی می‌تواند برای تعریف نام مستعار در مکانی مشخص از پروژه به کار رود؛ سپس می‌توان در یک فایل SConscript فرعی، هدف(های) واقعی را برای ارجاع به آن اضافه کرد. پارامتر اختیاری action یک کنش یا فهرستی از کنش‌ها را تعیین می‌کند که هرگاه هر یک از اهداف نام مستعار قدیمی (out-of-date) باشند، اجرا خواهند شد.

Alias می‌تواند برای یک نام مستعار از پیش موجود فراخوانی شود، که آرگومان‌های alias و/یا action را به فهرست‌های موجود برای آن نام مستعار اضافه می‌کند.

فهرستی از اشیاء Alias Node را برمی‌گرداند که بیانگر نام(های) مستعار هستند و خارج از هر سیستم‌فایل فیزیکی وجود دارند. فضای نامِ نام‌های مستعار از فضای نام اهداف ملموس جدا است؛ برای جلوگیری از سردرگمی، نام اهداف را مجدداً به عنوان نام مستعار به کار نبرید.

مثال‌ها:

Alias('install')
Alias('install', '/usr/bin')
Alias(['install', 'install-lib'], '/usr/local/lib')
env.Alias('install', ['/usr/local/bin', '/usr/local/lib'])
env.Alias('install', ['/usr/local/man'])
env.Alias('update', ['file1', 'file2'], "update_database $SOURCES")

اگر AllowSubstExceptions چندین بار فراخوانی شود، هر فراخوانی به‌طور کامل فهرست قبلی استثناهای نادیده‌گرفته‌شده را بازنویسی می‌کند. فراخوانی آن بدون هیچ آرگومانی بدان معناست که هیچ استثنایی نادیده گرفته نخواهد شد.

مثال:

# Requires that all construction variable names exist.
# (You may wish to do this if you want to enforce strictly
# that all construction variables must be defined before use.)
AllowSubstExceptions()
# Also allow a string containing a zero-division expansion
# like '${1 / 0}' to evaluate to ''.
AllowSubstExceptions(IndexError, NameError, ZeroDivisionError)

توضیحات زیر هم برای متدهای Append و Prepend و هم برای گونه‌های Unique آن‌ها صدق می‌کند، با این تفاوت که نقطه درج مقادیر افزوده شده و مجاز بودن یا نبودن تکرار با هم تفاوت دارد.

val تقریباً می‌تواند از هر نوعی باشد. اگر env متغیر ساختی به نام key نداشته باشد، آن‌گاه key صرفاً با مقدار val ذخیره می‌شود. در غیر این صورت، val با مقدار موجود ترکیب می‌شود، و احتمالاً به نوع مناسبی که بتواند محتوای بسط‌یافته را نگه‌داری کند تبدیل می‌شود. چند حالت خاص وجود دارد که باید به آن‌ها توجه کرد. در حالت عادی، هنگامی که دو رشته ترکیب می‌شوند، نتیجه یک رشته جدید حاوی الحاق آن‌ها است (و شما مسئول فراهم کردن هرگونه فاصله‌گذاری مورد نیاز هستید)؛ با این حال، محتویات $CPPDEFINES هنگام تولید خط فرمان با افزودن یک پیشوند و/یا پسوند به هر مدخل پس‌پردازش می‌شود، بنابراین SCons آن‌ها را جدا نگه می‌دارد - افزودن یک رشته منجر به یک مدخل رشته‌ای جداگانه می‌شود، نه یک رشته ترکیب‌شده. برای $CPPDEFINES و همچنین $LIBS و متغیرهای گوناگون *PATH، دستور SCons متغیر را با ارائه نحو خاص کامپایلر اصلاح خواهد کرد (برای نمونه با پیشوند قرار دادن -D یا /D برای $CPPDEFINES)، بنابراین هنگام افزودن مقادیر به این متغیرها باید از ذکر این نحو خودداری کنید. مثال‌ها (نحو gcc در بسط CPPDEFINES نشان داده شده است):

env = Environment(CXXFLAGS="-std=c11", CPPDEFINES="RELEASE")
print(f"CXXFLAGS = {env['CXXFLAGS']}, CPPDEFINES = {env['CPPDEFINES']}")
# notice including a leading space in CXXFLAGS addition
env.Append(CXXFLAGS=" -O", CPPDEFINES="EXTRA")
print(f"CXXFLAGS = {env['CXXFLAGS']}, CPPDEFINES = {env['CPPDEFINES']}")
print("CPPDEFINES will expand to", env.subst('$_CPPDEFFLAGS'))

$ scons -Q
CXXFLAGS = -std=c11, CPPDEFINES = RELEASE
CXXFLAGS = -std=c11 -O, CPPDEFINES = deque(['RELEASE', 'EXTRA'])
CPPDEFINES will expand to -DRELEASE -DEXTRA
scons: `.' is up to date.

از آنجا که $CPPDEFINES برای تعیین ماکروهای پیش‌پردازنده C/C++ در خط فرمان در نظر گرفته شده است، هنگام افزودن به آن نحوهای بیشتری پذیرفته می‌شود. پیش‌پردازنده آرگومان‌هایی را برای پیش‌تعریف نام یک ماکرو به تنهایی می‌پذیرد (برای بیشتر کامپایلرها -DFOO و برای Microsoft C++ به صورت /DFOO) که به آن مقدار ضمنی 1 می‌دهد، یا می‌تواند همراه با یک مقدار جایگزین ارائه شود (-DBAR=TEXT). SCons هنگام افزودن به $CPPDEFINES از این قوانین پیروی می‌کند:

مثال‌ها:

env = Environment(CPPDEFINES="FOO")
print("CPPDEFINES =", env['CPPDEFINES'])
env.Append(CPPDEFINES="BAR=1")
print("CPPDEFINES =", env['CPPDEFINES'])
env.Append(CPPDEFINES=[("OTHER", 2)])
print("CPPDEFINES =", env['CPPDEFINES'])
env.Append(CPPDEFINES={"EXTRA": "arg"})
print("CPPDEFINES =", env['CPPDEFINES'])
print("CPPDEFINES will expand to", env.subst('$_CPPDEFFLAGS'))

$ scons -Q
CPPDEFINES = FOO
CPPDEFINES = deque(['FOO', 'BAR=1'])
CPPDEFINES = deque(['FOO', 'BAR=1', ('OTHER', 2)])
CPPDEFINES = deque(['FOO', 'BAR=1', ('OTHER', 2), ('EXTRA', 'arg')])
CPPDEFINES will expand to -DFOO -DBAR=1 -DOTHER=2 -DEXTRA=arg
scons: `.' is up to date.

مثال‌هایی از افزودن چندین ماکرو:

env = Environment()
env.Append(CPPDEFINES=[("ONE", 1), "TWO", ("THREE", )])
print("CPPDEFINES =", env['CPPDEFINES'])
env.Append(CPPDEFINES={"FOUR": 4, "FIVE": None})
print("CPPDEFINES =", env['CPPDEFINES'])
print("CPPDEFINES will expand to", env.subst('$_CPPDEFFLAGS'))

$ scons -Q
CPPDEFINES = [('ONE', 1), 'TWO', ('THREE',)]
CPPDEFINES = deque([('ONE', 1), 'TWO', ('THREE',), ('FOUR', 4), ('FIVE', None)])
CPPDEFINES will expand to -DONE=1 -DTWO -DTHREE -DFOUR=4 -DFIVE
scons: `.' is up to date.

تغییریافته در نسخه 4.5: استفاده از تاپل‌ها در برابر سایر انواع شفاف‌سازی شد، اکنون نحوه رفتار در سراسر چهار تابع سازگار است.

env = Environment()
env.Append(CPPDEFINES=("MACRO1", "MACRO2"))
print("CPPDEFINES =", env['CPPDEFINES'])
env.Append(CPPDEFINES=[("MACRO3", "MACRO4")])
print("CPPDEFINES =", env['CPPDEFINES'])
print("CPPDEFINES will expand to", env.subst('$_CPPDEFFLAGS'))

$ scons -Q
CPPDEFINES = ('MACRO1', 'MACRO2')
CPPDEFINES = deque(['MACRO1', 'MACRO2', ('MACRO3', 'MACRO4')])
CPPDEFINES will expand to -DMACRO1 -DMACRO2 -DMACRO3=MACRO4
scons: `.' is up to date.

برای جزئیات بیشتر $CPPDEFINES را ببینید.

افزودن یک رشته val به یک متغیر ساخت از نوع دیکشنری، val را به عنوان کلید در دیکشنری و None را به عنوان مقدار آن وارد می‌کند. استفاده از نوع تاپل برای فراهم کردن یک جفت کلید-مقدار تنها برای مورد خاص $CPPDEFINES که در بالا توضیح داده شد کار می‌کند.

اگرچه بیشتر ترکیب‌های انواع بدون نیاز به دانستن جزئیات کار می‌کنند، برخی ترکیب‌ها معنادار نیستند و Python یک استثنا (exception) ایجاد می‌کند.

هنگام استفاده از env.Append برای تغییر متغیرهای ساختی که مشخص‌کننده مسیر هستند (طبق قرارداد، نام این متغیرها به PATH ختم می‌شود)، توصیه می‌شود مقادیر را به عنوان فهرستی از رشته‌ها اضافه کنید، حتی اگر فقط یک رشته تکی را اضافه می‌کنید. همین موضوع در مورد افزودن نام کتابخانه‌ها به $LIBS نیز صدق می‌کند.

env.Append(CPPPATH=["#/include"])

همچنین ببینید: env.AppendUnique، env.Prepend و env.PrependUnique.

مسیرها تنها یک‌بار ظاهر خواهند شد. مسیرهای تکراری در newpath حذف می‌شوند و آخرین مورد برای حفظ ترتیب مسیر نگه‌داشته می‌شود. اگر delete_existing برابر با درست (true) باشد (پیش‌فرض)، موارد تکراری موجود پیش از الحاق حذف می‌شوند، در غیر این صورت، از موارد تکراری جدید صرف‌نظر می‌شود. هنگام مقایسه‌ها، مسیرها نرمال‌سازی می‌شوند تا از بروز مشکلات ناشی از تفاوت بزرگی و کوچکی حروف (در فایل‌سیستم‌های غیرحساس به حروف بزرگ و کوچک) و مسیرهای نسبی که ممکن است به همان دایرکتوری بازگردند جلوگیری شود. مقادیر ذخیره‌شده توسط این فرآیند تغییر نمی‌کنند.

مثال:

print('before:', env['ENV']['INCLUDE'])
include_path = '/foo/bar:/foo'
env.AppendENVPath('INCLUDE', include_path)
print('after:', env['ENV']['INCLUDE'])

خروجی:

before: /foo:/biz
after: /biz:/foo/bar:/foo

همچنین ببینید: env.PrependENVPath.

مثال:

env.AppendUnique(CCFLAGS='-g', FOO=['foo.yyy'])

همچنین ببینید: env.Append، env.Prepend و env.PrependUnique.

توجه داشته باشید که فرم فراخوانی env.Builder() متغیرهای ساخت را در تمام رشته‌های آرگومان، از جمله آرگومان action، در زمان فراخوانی با استفاده از متغیرهای ساخت در محیط ساخت env که env.Builder از طریق آن فراخوانی شده است، بسط می‌دهد. فرم Builder بسط متغیرها را تا پس از فراخوانی واقعی شیء Builder به تعویق می‌اندازد.

متد محیطی env.CacheDir حافظه موقت را تنها برای هدف‌هایی اعمال می‌کند که از طریق آن محیط ساخت خاص ساخته شده باشند. تابع سراسری CacheDir یک مقدار پیش‌فرض تعیین می‌کند که بر همه اهداف اعمال می‌شود مگر آنکه با فراخوانی مختص به محیط بازنویسی شود.

رفتار حافظه موقت را می‌توان با ارسال زیرکلاسی از SCons.CacheDir.CacheDir به عنوان پارامتر اختیاری custom_class سفارشی‌سازی کرد. اگر حذف شود یا روی None تنظیم گردد، SCons از کلاس پیش‌فرض استفاده می‌کند.

هنگامی که حافظه موقت فعال است و scons نیاز دارد یک فایل مشتق‌شده را دوباره بسازد، ابتدا حافظه موقت را برای یک امضای ساخت (build signature) تطبیق‌پذیر بررسی می‌کند (که نشان‌دهنده ورودی‌ها و کنش‌های ساخت یکسان است). در صورت یافتن، فایل از حافظه موقت بازیابی می‌شود. در غیر این صورت، scons فایل را می‌سازد و رونوشتی از آن را تحت امضای ساخت خود در حافظه موقت ذخیره می‌کند.

به طور پیش‌فرض، scons هنگام برخورد موفق در حافظه موقت (cache hits)، عبارت Retrieved `file' from cache را گزارش می‌دهد. از گزینه --cache-show برای پنهان کردن دخالت حافظه موقت و نمایش رشته ساخت عادی در عوض آن، جهت یکدستی خروجی لاگ، استفاده کنید.

کش کردن را برای یک فراخوانی مشخص با گزینه --cache-disable غیرفعال کنید. برای مجاز کردن بازیابی اما جلوگیری از به‌روزرسانی‌ها، از --cache-readonly استفاده کنید.

گزینه --cache-force همه فایل‌های مشتق‌شده را در حافظه موقت کپی می‌کند، حتی فایل‌هایی که از قبل وجود دارند. این کار به پر کردن یک حافظه موقت تازه یا به‌روزرسانی آن پس از ساخت با به‌روزرسانی حافظه موقت غیرفعال شده (--cache-disable یا --cache-readonly) کمک می‌کند.

از NoCache برای مستثنی کردن فایل‌های خاص از قرارگیری در حافظه موقت استفاده کنید، مانند مواردی با ورودی‌ها یا خروجی‌های غیرقابل‌پیش‌بینی، یا فایل‌های خروجی بیش از اندازه بزرگ.

SCons ابزارهای توکاری برای مدیریت حافظه موقت ارائه نمی‌دهد. شما باید پاک‌سازی (pruning)، انقضا، کنترل دسترسی و سایر وظایف نگهداری را به صورت دستی مدیریت کنید.

متد مرتبط NoClean اولویت بالاتری دارد: هر هدفی که برای NoClean مشخص شود، پاک‌سازی نخواهد شد حتی اگر به عنوان پارامتر files به Clean داده شده باشد.

مثال‌ها:

Clean('foo', ['bar', 'baz'])
Clean('dist', env.Program('hello', 'hello.c'))
Clean(['foo', 'bar'], 'something_else_to_clean')

ابزار SCons دایرکتوری‌ها را مستقیماً به عنوان هدف ردیابی نمی‌کند - آن‌ها در صورت نیاز ایجاد می‌شوند و در حالت پاک‌سازی معمولاً حذف نمی‌شوند. در این مثال، نصب پروژه یک زیردایرکتوری برای مستندات ایجاد می‌کند. فراخوانی Clean تضمین می‌کند که در صورت حذف نصب پروژه، این زیردایرکتوری حذف شود.

Clean(docdir, os.path.join(docdir, projectname))

مثال:

env2 = env.Clone()
env3 = env.Clone(CCFLAGS='-g')

مشابه سازنده Environment، می‌توان فهرستی از tools و یک toolpath را مشخص کرد:

def MyTool(env):
    env['FOO'] = 'bar'
env4 = env.Clone(tools=['msvc', MyTool])

آرگومان کلیدواژه‌ای parse_flags نیز شناخته می‌شود، تا ادغام آرگومان‌های به سبک خط فرمان در متغیرهای ساخت مربوطه امکان‌پذیر شود (نگاه کنید به env.MergeFlags).

# create an environment for compiling programs that use wxWidgets
wx_env = env.Clone(parse_flags='!wx-config --cflags --cxxflags')

آرگومان کلیدواژه‌ای variables نیز شناخته می‌شود تا امکان مقداردهی (مجدد) متغیرهای ساخت از روی یک شیء Variables فراهم گردد.

تغییریافته در نسخه 4.8.0: پارامتر variables اضافه شد.

تابع Command آرگومان‌های کلیدواژه‌ای source_scanner و target_scanner را می‌پذیرد که برای تعیین اسکنرهای سفارشی برای مبداها یا اهداف مشخص‌شده به کار می‌روند. مقدار باید یک شیء Scanner باشد. برای نمونه، می‌توان از شیء سراسری DirScanner استفاده کرد اگر هر یک از مبداها دایرکتوری‌هایی باشند که باید روی دیسک برای تغییرات فایل‌هایی که قبلاً در سایر Builderها یا فراخوانی‌های توابع مشخص نشده‌اند، اسکن شوند.

تابع Command همچنین آرگومان‌های کلیدواژه‌ای source_factory و target_factory را می‌پذیرد که برای مشخص کردن توابع کارخانه‌ای جهت ساخت گره‌های SCons از هر مبدا یا هدف مشخص‌شده به عنوان رشته استفاده می‌شوند. اگر هر مبدا یا هدفی از قبل شیء Node باشد، حتی در صورت تعیین یک کارخانه برای آن‌ها، دگرگونی بیشتری نخواهند یافت. پیش‌فرض برای هر کدام، کارخانه Entry است.

این چهار آرگومان در صورت مشخص شدن، در ایجاد Builder به کار گرفته می‌شوند. سایر آرگومان‌های کلیدواژه‌ای مختص Builder به عنوان چنین مواردی شناخته نمی‌شوند. برای اطلاعات بیشتر درباره نحوه کار این آرگومان‌ها در یک Builder، به بخش «اشیای سازنده» (Builder Objects) در صفحه راهنما مراجعه کنید.

هر آرگومان کلیدواژه‌ای باقی‌مانده، هنگام فراخوانی به سازنده ایجادشده منتقل می‌شود و طبق آنچه در بخش «متدهای سازنده» (Builder Methods) در صفحه راهنما توضیح داده شده عمل می‌کند؛ به طور خلاصه: آرگومان‌های شناخته‌شده معانی مشخص خود را دارند، در حالی که باقی آن‌ها برای بازنویسی هر متغیر ساخت هم‌نام موجود از محیط ساخت استفاده می‌شوند.

پارامتر action می‌تواند یک دستور خارجی (مشخص‌شده به عنوان یک رشته) یا یک شیء قابل فراخوانی Python باشد؛ برای اطلاعات کامل‌تر به بخش «اشیای اقدام» (Action Objects) در صفحه راهنما مراجعه کنید. همچنین توجه داشته باشید که قبل از رشته مشخص‌کننده دستور خارجی می‌تواند یک علامت اتساین (@) برای جلوگیری از چاپ دستور مربوطه، یا یک خط تیره (-) برای نادیده گرفتن وضعیت خروج (exit status) دستور خارجی قرار گیرد.

مثال‌ها:

env.Command(
    target='foo.out',
    source='foo.in',
    action="$FOO_BUILD < $SOURCES > $TARGET"
)
env.Command(
    target='bar.out',
    source='bar.in',
    action=["rm -f $TARGET", "$BAR_BUILD < $SOURCES > $TARGET"],
    ENV={'PATH': '/usr/local/bin/'},
)
import os
def rename(env, target, source):
    os.rename('.tmp', target[0])
env.Command(
    target='baz.out',
    source='baz.in',
    action=["$BAZ_BUILD < $SOURCES > .tmp", rename],
)

توجه داشته باشید که تابع Command معمولاً به طور پیش‌فرض فرض می‌کند که اهداف و/یا مبداهای مشخص‌شده فایل هستند، اگر بخش دیگری از پیکربندی نوع ورودی‌های آن‌ها را مشخص نکند. در صورت نیاز، می‌توانید با استفاده از توابع Dir یا env.Dir صراحتاً مشخص کنید که گره‌های هدف یا مبدا باید به عنوان دایرکتوری در نظر گرفته شوند.

مثال‌ها:

env.Command('ddd.list', Dir('ddd'), 'ls -l $SOURCE > $TARGET')
env['DISTDIR'] = 'destination/directory'
env.Command(env.Dir('$DISTDIR')), None, make_distdir)

همچنین توجه داشته باشید که SCons معمولاً هر دایرکتوری لازم برای نگهداری یک فایل هدف را به طور خودکار ایجاد می‌کند، بنابراین معمولاً نیازی ندارید که دایرکتوری‌ها را به صورت دستی ایجاد کنید.

DebugOptions(json='#/build/output/scons_stats.json')

جدید در نسخهٔ 4.6.0.

"content"

"content-timestamp"

"timestamp-newer"

"timestamp-match"

مثال‌ها:

# Use exact timestamp matches by default.
Decider('timestamp-match')
# Use hash content signatures for any targets built
# with the attached construction environment.
env.Decider('content')

علاوه بر توابع از پیش موجود بالا، آرگومان function می‌تواند یک تابع Python باشد که شما ارائه می‌دهید. چنین تابعی باید چهار آرگومان زیر را بپذیرد:

dependency

target

prev_ni

repo_node

تابع function باید در صورتی که dependency از زمان آخرین ساخت target «تغییر» کرده باشد، مقداری را برگرداند که برابر با True ارزیابی شود (که نشان می‌دهد هدف باید بازسازی شود)، و در غیر این صورت مقداری که برابر با False ارزیابی شود (که نشان می‌دهد هدف نباید بازسازی شود). توجه داشته باشید که این تصمیم‌گیری می‌تواند با استفاده از هر معیار مناسبی انجام شود. نادیده گرفتن برخی یا همهٔ آرگومان‌های تابع کاملاً طبیعی است.

مثال:

def my_decider(dependency, target, prev_ni, repo_node=None):
    return not os.path.exists(str(target))
env.Decider(my_decider)

target می‌تواند یک یا چند رشته، فهرستی از رشته‌ها، یک NodeList برگشتی از یک Builder، یا None باشد. یک رشته‌ی target می‌تواند نام یک فایل یا دایرکتوری باشد، یا هدفی که پیش‌تر با فراخوانی Alias تعریف شده است (تعریف نام مستعار پس از آن همچنان نام مستعار را ایجاد می‌کند، اما به عنوان پیش‌فرض شناخته نخواهد شد). فراخوانی‌های Default تجمیعی هستند. مقدار None برای target هرگونه فهرست اهداف پیش‌فرض موجود را پاک می‌کند؛ فراخوانی‌های بعدی Default طبق معمول به فهرست اهداف پیش‌فرض (که اکنون خالی است) اضافه خواهند شد.

هر دو شکل این فراخوانی بر همان فهرست سراسری اهداف پیش‌فرض اثر می‌گذارند؛ متد محیط ساخت، بسط متغیرهای ساخت را روی اهداف اعمال می‌کند.

فهرست فعلی اهداف اضافه‌شده با استفاده از Default در فهرست DEFAULT_TARGETS در دسترس است (پایین را ببینید).

مثال‌ها:

Default('foo', 'bar', 'baz')
env.Default(['a', 'b', 'c'])
hello = env.Program('hello', 'hello.c')
env.Default(hello)

در نخستین فراخوانی، آرگومان‌ها مانند تابع Environment تفسیر می‌شوند. محیط پیش‌فرض یک شیء یگانه (singleton) است؛ فراخوانی‌های بعدی DefaultEnvironment شیء ساخته‌شده‌ی پیشین را برمی‌گردانند، و هرگونه آرگومان کلیدواژه‌ای بدون اعلام نادیده گرفته می‌شود.

محیط پیش‌فرض را می‌توان پس از نمونه‌سازی، مشابه سایر محیط‌های ساخت تغییر داد، هرچند ممکن است برخی از متدهای محیط ساخت در دسترس نباشند. تغییر محیط پیش‌فرض هیچ اثری بر سایر محیط‌های ساخت، چه موجود و چه نوساخته، ندارد.

نیازی به فراخوانی صریح DefaultEnvironment نیست. SCons چنانچه تاکنون انجام نشده باشد، در زمان آغاز فاز ساخت، محیط پیش‌فرض را به طور خودکار نمونه‌سازی می‌کند. با این حال، فراخوانی صریح آن این فرصت را فراهم می‌آورد تا محتویات آن را تحت تأثیر قرار داده و بررسی کنید. به دلیل استفاده‌های داخلی، نمونه‌سازی حتی اگر به نظر برسد چیزی در سامانه ساخت از آن استفاده نمی‌کند نیز رخ می‌دهد.

اگر فایل‌های SConscript پروژه از توابع سراسری یا Builderها استفاده نمی‌کنند، ممکن است با فراخوانی DefaultEnvironment با یک فهرست ابزار خالی (DefaultEnvironment(tools=[])) سود اندکی در عملکرد حاصل شود. این کار از هزینه مقداردهی اولیه‌ی ابزارها برای محیط پیش‌فرض جلوگیری می‌کند، که عمدتاً در مجموعه‌ی آزمون که scons در آن به طور مکرر در یک بازه زمانی کوتاه اجرا می‌شود اهمیت دارد.

مثال:

env.Depends('foo', 'other-input-file-for-foo')
mylib = env.Library('mylib.c')
installed_lib = env.Install('lib', mylib)
bar = env.Program('bar.c')
# Arrange for the library to be copied into the installation
# directory before trying to build the "bar" program.
# (Note that this is for example only.  A "real" library
# dependency would normally be configured through the $LIBS
# and $LIBPATH variables, not using an env.Depends() call.)
env.Depends(bar, installed_lib)

مثال:

cvars = env.Dictionary()
cc_values = env.Dictionary('CC', 'CCFLAGS', 'CCCOM')

اگر name یک مسیر منفرد باشد، گره متناظر بازگردانده می‌شود. اگر name یک فهرست باشد، SCons فهرستی از گره‌ها را بازمی‌گرداند. متغیرهای ساخت در name بسط داده می‌شوند.

گره‌های دایرکتوری را می‌توان در هر جایی که یک رشته به عنوان نام دایرکتوری به یک متد سازنده (Builder) یا تابع تحویل داده می‌شود، استفاده کرد. گره‌های دایرکتوری دارای مشخصه‌ها و متدهایی هستند که در موقعیت‌های بسیاری کاربردی‌اند؛ برای اطلاعات بیشتر بخش "Filesystem Nodes" در صفحهٔ راهنما را ببینید.

رشتهٔ اختیاری format قالب سریال‌سازی را تعیین می‌کند:

pretty

json

تغییر یافته در 4.9.0: بیش از یک key می‌تواند مشخص شود. رشتهٔ بازگردانده‌شده همواره مانند یک dict (یا معادل آن در سایر قالب‌ها) خواهد بود؛ پیش از این، یک کلید تکی فقط مقدار را سریال‌سازی می‌کرد، نه کلید را به همراه مقدار.

مثال‌ها: این SConstruct

env = Environment()
print(env.Dump('CCCOM'))
print(env.Dump('CC', 'CCFLAGS', format='json'))

چیزی شبیه به این چاپ خواهد کرد:

{'CCCOM': '$CC -o $TARGET -c $CFLAGS $CCFLAGS $_CCCOMCOM $SOURCES'}
{
    "CC": "gcc",
    "CCFLAGS": []
}

در حالی که این SConstruct:

env = Environment()
print(env.Dump())

چیزی شبیه به این چاپ خواهد کرد:

{ 'AR': 'ar',
  'ARCOM': '$AR $ARFLAGS $TARGET $SOURCES\n$RANLIB $RANLIBFLAGS $TARGET',
  'ARFLAGS': ['r'],
  'AS': 'as',
  'ASCOM': '$AS $ASFLAGS -o $TARGET $SOURCES',
  'ASFLAGS': [],
  ...

مثال:

EnsurePythonVersion(2,2)

مثال‌ها:

EnsureSConsVersion(0,14)
EnsureSConsVersion(0,96,90)

Execute(Copy('file.out', 'file.in'))

دستور Execute کنش خود را فوراً، به عنوان بخشی از مرحلهٔ خواندن SConscript انجام می‌دهد. در فراخوانی Execute هیچ منبع یا هدفی اعلان نمی‌شود، بنابراین هر شیئی که توسط آن دستکاری شود، به عنوان بخشی از گراف وابستگی SCons ردیابی نخواهد شد. در مثال بالا، نه file.out و نه file.in اشیاء ردیابی‌شده نخواهند بود.

Execute مقدار خروج دستور یا مقدار بازگشتی تابع Python را برمی‌گرداند. اگر action اجراشده ناموفق باشد (با یک مقدار غیرصفر خارج شود یا مقداری غیرصفر برگرداند)، scons پیام خطایی چاپ می‌کند، با این وجود ساخت را برای چنین شکستی به‌طور خودکار متوقف نمی‌کند. اگر می‌خواهید فرآیند ساخت در واکنش به شکست فراخوانی Execute متوقف شود، باید صراحتاً مقدار بازگشتی غیرصفر را بررسی کنید:

if Execute("mkdir sub/dir/ectory"):
    # The mkdir failed, don't try to build.
    Exit(1)

یک آرگومان vars همچنین می‌تواند یک دیکشنری یا آرگومان‌های کلیدواژه‌ای جداگانه باشد؛ طبق قواعد نحوی Python، آرگومان‌های کلیدواژه‌ای باید پس از هرگونه آرگومان غیرکلیدواژه‌ای بیایند. شکل دیکشنری/کلیدواژه‌ای را می‌توان برای نگاشت نام محلی یک متغیر به نامی متفاوت جهت استفاده برای وارد کردن‌ها به کار برد. برای نمایشی از این نحو، مثال‌ها را ببینید.

فراخوانی‌های Export تجمعی هستند. مشخص کردن متغیری که پیش‌تر صادر شده است، مقدار قبلی آن را در مجموعه جایگزین خواهد کرد. هم متغیرهای محلی و هم متغیرهای سراسری را می‌توان صادر کرد.

برای استفاده از یک متغیر صادرشده، یک SConscript باید Import را فراخوانی کند تا آن را به دامنهٔ خود وارد کند. وارد کردن، یک ارجاع اضافی به شیئی ایجاد می‌کند که در ابتدا صادر شده بود؛ بنابراین اگر آن شیء تغییرپذیر (mutable) باشد، تغییرات اعمال‌شده برای سایر استفاده‌کنندگان آن شیء نمایان خواهد بود.

مثال‌ها:

env = Environment()
# Make env available for all SConscript files to Import().
Export("env")
package = 'my_name'
# Make env and package available for all SConscript files:.
Export("env", "package")
# Make env and package available for all SConscript files:
Export(["env", "package"])
# Make env available using the name debug:
Export(debug=env)
# Make env available using the name debug:
Export({"debug": env})

توجه داشته باشید که تابع SConscript همچنین از آرگومان exports پشتیبانی می‌کند که امکان صادر کردن یک یا چند متغیر را (تنها) به فایل‌های SConscript فراخوانی‌شده توسط آن فراخوانی فراهم می‌کند. برای جزئیات بیشتر به توضیحات آن تابع مراجعه کنید.

اگر name یک نام مسیر تکی باشد، گره متناظر بازگردانده می‌شود. اگر name یک فهرست باشد، SCons فهرستی از گره‌ها را بازمی‌گرداند. متغیرهای ساخت (Construction variables) در name بسط داده می‌شوند.

از File Nodeها می‌توان در هر جایی که یک رشته به عنوان نام فایل به یک متد یا تابع Builder داده می‌شود استفاده کرد. File Nodeها ویژگی‌ها و متدهایی دارند که در بسیاری از شرایط مفید هستند؛ برای اطلاعات بیشتر بخش "Filesystem Nodes" در این صفحهٔ راهنما را ببینید.

مثال:

# Searches for 'foo' in 'dir1' and 'dir2', returning the node if found
foo = env.FindFile('foo', ['dir1', 'dir2'])

مثال:

Install('/bin', ['executable_a', 'executable_b'])
# Returns the file node list
# ['/bin/executable_a', '/bin/executable_b']
FindInstalledFiles()
Install('/lib', ['some_library'])
# Returns the file node list
# ['/bin/executable_a', '/bin/executable_b', '/lib/some_library']
FindInstalledFiles()

استفاده از FindPathDirs عموماً نسبت به نوشتن path_function شخصی ترجیح داده می‌شود، زیرا موارد معمول پویش در SCons را به درستی و به طور کارآمد مدیریت می‌کند: (۱) هنگامی که از یک دایرکتوری متغیر (variant directory) استفاده می‌شود تمام دایرکتوری‌های مناسب را از درخت‌های منبع، و هنگامی که Repository یا گزینهٔ -Y/--repository فعال است از مخازن برمی‌گرداند. (۲) تشخیص می‌دهد چه زمانی مقادیر مختلف variable به فهرست دایرکتوری یکسانی منتهی می‌شوند و به جای پویش مجدد همان دایرکتوری‌ها، از آن نتیجه دوباره استفاده می‌کند که از انجام کارهای تکراری جلوگیری می‌نماید.

مثال:

def my_scan(node, env, path, arg):
    # Code to scan file contents goes here...
    return include_files
scanner = Scanner(
    name='myscanner', function=my_scan, path_function=FindPathDirs('MYPATH')
)

مثال:

Program('src/main_a.c')
Program('src/main_b.c')
Program('main_c.c')
# returns ['main_c.c', 'src/main_a.c', 'SConstruct', 'src/main_b.c']
FindSourceFiles()
# returns ['src/main_b.c', 'src/main_a.c' ]
FindSourceFiles('src')

توجه داشته باشید که فایل‌های پشتیبان ساخت موجود در درخت (مانند SConstruct در مثال بالا) نیز بازگردانده می‌شوند.

مثال‌ها:

foo = Object('foo.c')
bar = Object('bar.c')
# از آنجا که `foo' و `bar' لیست‌های بازگردانده‌شده توسط سازنده ()Object هستند،
# `objects' لیستی شامل لیست‌های تودرتو خواهد بود:
objects = ['f1.o', foo, 'f2.o', bar, 'f3.o']
# ارسال چنین لیستی به سازنده‌ای دیگر مشکلی ندارد زیرا
# سازنده لیست را به طور خودکار مسطح می‌کند:
Program(source = objects)
# اگر نیاز دارید لیست را مستقیماً با استفاده از Python دستکاری کنید، باید
# خودتان ()Flatten را فراخوانی کنید، یا به شکل دیگری لیست‌های تودرتو را مدیریت نمایید:
for object in Flatten(objects):
    print(str(object))

.node گره‌ای که هنگام رخ دادن شکست ساخت، در حال ساخته شدن بود.

.status وضعیت خروج عددی بازگردانده‌شده توسط دستور یا تابع Python که هنگام تلاش برای ساخت Node مشخص‌شده شکست خورد.

.errstr رشته خطای SCons که شکست ساخت را توصیف می‌کند. (این اغلب یک پیام عمومی مانند "Error 2" است تا نشان دهد دستور اجرا شده با وضعیت ۲ خارج شده است.)

.filename نام فایل یا دایرکتوری که در واقع باعث بروز شکست شده است. این مقدار ممکن است با ویژگی .node متفاوت باشد. به عنوان مثال، اگر تلاشی برای ساخت هدفی به نام sub/dir/target شکست بخورد زیرا دایرکتوری sub/dir نتوانست ایجاد شود، در این صورت ویژگی .node برابر sub/dir/target خواهد بود اما ویژگی .filename برابر sub/dir خواهد بود.

.executor شیء Executor در SCons برای Node هدفی که در حال ساخته شدن بود. این می‌تواند برای بازیابی محیط ساخت مورد استفاده برای اقدام شکست‌خورده به کار رود.

.action شیء واقعی Action در SCons که شکست خورده است. این شیء یک اقدام مشخص از میان فهرست اقدامات ممکنی خواهد بود که قرار بود برای ساخت هدف اجرا شوند.

.command دستور گسترش‌یافته واقعی که اجرا شد و شکست خورد، پس از بسط متغیرهای ساخت $TARGET، $SOURCE و سایر متغیرهای ساخت.

توجه داشته باشید که تابع GetBuildFailures همواره تا زمانی که هیچ شکست ساختی رخ نداده باشد یک لیست خالی برمی‌گرداند، به این معنی که GetBuildFailures در حین خوانده شدن فایل‌های SConscript همیشه یک لیست خالی برمی‌گرداند. کاربرد اصلی در نظر گرفته‌شده برای آن در توابعی است که با ارسال به تابع استاندارد atexit.register در Python، پیش از خروج SCons اجرا خواهند شد. مثال:

import atexit
def print_build_failures():
    from SCons.Script import GetBuildFailures
    for bf in GetBuildFailures():
        print("%s failed: %s" % (bf.node, bf.errstr))
atexit.register(print_build_failures)

pattern می‌تواند شامل نویسه‌های عام شل با سبک POSIX برای تطابق باشد:

برای یک تطابق دقیق، نویسهٔ عام را در قلاب قرار دهید تا از رفتار عادی آن صرف‌نظر شود. برای مثال، '[?]' با نویسهٔ '?' مطابقت می‌یابد.

با نام‌های فایلی که با نقطه شروع می‌شوند به‌طور خاص رفتار می‌شود - آن‌ها فقط با الگوهایی مطابقت می‌یابند که با یک نقطه آغاز شوند (یا بلافاصله پس از یک نویسهٔ جداکنندهٔ مسیر یا ممیز، یک نقطه داشته باشند)، و توسط نویسه‌های عام مطابقت داده نمی‌شوند. تطابق‌های نویسهٔ عام همچنین شامل جداکننده‌های دایرکتوری نمی‌شوند.

Glob مخازن (به تابع Repository مراجعه کنید) و دایرکتوری‌های منبع (به تابع VariantDir مراجعه کنید) را تشخیص می‌دهد و اگر یک Node منطبق در هر کجای مخزن یا دایرکتوری منبع متناظر پیدا شود، یک Node (یا در صورت پیکربندی، رشته) منطبق در دایرکتوری محلی (SConscript) برمی‌گرداند.

اگر آرگومان اختیاری ondisk نادرست (false) ارزیابی شود، جستجو برای تطابق‌ها روی دیسک غیرفعال می‌شود و تنها تطابق‌های حاصل از Nodeهای File یا Dir که از قبل پیکربندی شده‌اند بازگردانده می‌شوند. مقدار پیش‌فرض این است که Nodeهای حاصل از تطابق روی دیسک نیز برگردانده شوند.

اگر آرگومان اختیاری source درست (true) ارزیابی شود، و دایرکتوری محلی یک دایرکتوری مشتق (variant directory) باشد، آنگاه Glob به‌جای دایرکتوری محلی، Nodeها را از دایرکتوری منبع متناظر برمی‌گرداند.

اگر آرگومان اختیاری strings درست (true) ارزیابی شود، Glob تطابق‌ها را به‌جای Nodeها در قالب رشته برمی‌گرداند. رشته‌های برگشتی نسبت به دایرکتوری محلی (SConscript) خواهند بود. (توجه داشته باشید که گرچه این امر ممکن است انجام دستکاری‌های دلخواه روی نام‌های فایل را آسان‌تر کند، زمینه‌ای را که SCons در Node نگه می‌داشت از بین می‌برد؛ بنابراین اگر رشته‌های برگشتی به یک فایل SConscript دیگر فرستاده شوند، هرگونه تبدیل Node در آنجا نسبت به دایرکتوری آن SConscript خواهد بود، نه نسبت به دایرکتوری SConscript اصلی.)

آرگومان اختیاری exclude می‌تواند روی یک الگو یا فهرستی از الگوها تنظیم شود که فایل‌ها یا دایرکتوری‌ها را برای حذف از فهرست تطابق شرح می‌دهند. عناصری که حداقل با یکی از الگوهای مشخص‌شده مطابقت داشته باشند حذف خواهند شد. این الگوها از همان ساختار نحوی pattern استفاده می‌کنند.

مثال‌ها:

Program("foo", Glob("*.c"))
Zip("/tmp/everything", Glob(".??*") + Glob("*"))
sources = Glob("*.cpp", exclude=["os_*_specific_*.cpp"]) \
    + Glob("os_%s_specific_*.cpp" % currentOS)

در نخستین فراخوانی Help، اگر append برابر False (پیش‌فرض) باشد، هرگونه متن راهنمای موجود دور ریخته می‌شود. متن راهنمای پیش‌فرض شامل راهنمای خودِ دستور scons به‌علاوهٔ راهنماهای جمع‌آوری‌شده از فراخوانی‌های محلی پروژهٔ AddOption است. این همان راهنمایی است که اگر Help هرگز فراخوانی نشده باشد، چاپ می‌شود. اگر append برابر True باشد، text به متن راهنمای موجود الحاق می‌شود. اگر local_only نیز True باشد (پیش‌فرض False است)، راهنمای محلی پروژه از فراخوانی‌های AddOption در پیام راهنما حفظ می‌شود اما راهنمای دستور scons حذف خواهد شد.

فراخوانی‌های بعدی Help آرگومان‌های کلیدواژه‌ای append و local_only را نادیده می‌گیرند و همواره به متن راهنمای موجود اضافه می‌کنند.

در نسخهٔ 4.6.0 تغییر یافت: local_only اضافه شد.

از Ignore همچنین می‌توان برای حذف یک هدف از ساخت پیش‌فرض استفاده کرد؛ با مشخص کردن دایرکتوری‌ای که هدف در آن ساخته می‌شود به‌عنوان target و فایلی که می‌خواهید از انتخاب برای ساخت کنار گذاشته شود به‌عنوان dependency. توجه داشته باشید که این کار تنها هدف را از الگوریتم انتخاب هدف پیش‌فرض حذف می‌کند: اگر آن فایل وابستگی شیء دیگری باشد که در حال ساخت است، SCons همچنان آن را طبق روال معمول می‌سازد. مثال‌های سوم و چهارم در ادامه را ببینید.

مثال‌ها:

env.Ignore('foo', 'foo.c')
env.Ignore('bar', ['bar1.h', 'bar2.h'])
env.Ignore('.', 'foobar.obj')
env.Ignore('bar', 'bar/foobar.obj')

اگر متغیرِ واردشده تغییرپذیر باشد، تغییرات اعمال‌شده به صورت محلی در شیئی که متغیر به آن مقید شده است بازتاب خواهد یافت. این امر به فایل‌های SConscript فرعی اجازه می‌دهد تا به عنوان مثال در شکل‌دهی یک محیط ساخت مشارکت داشته باشند.

مثال‌ها:

Import("env")
Import("env", "variable")
Import(["env", "variable"])
Import("*")

اگر unique برابر با true (پیش‌فرض) باشد، مقادیر تکراری حفظ نمی‌شوند. در صورت وجود موارد تکراری، هر نام متغیر ساختی که به PATH ختم شود، چپ‌ترین مقدار را نگه می‌دارد تا ترتیب جستجوی مسیر تغییر نکند. همهٔ دیگر متغیرهای ساخت، راست‌ترین مقدار را نگه می‌دارند. اگر unique برابر با false باشد، مقادیر حتی در صورت تکراری بودن الحاق می‌شوند.

مثال‌ها:

# Add an optimization flag to $CCFLAGS.
env.MergeFlags({'CCFLAGS': '-O3'})
# Combine the flags returned from running pkg-config with an optimization
# flag and merge the result into the construction variables.
env.MergeFlags(['!pkg-config gtk+-2.0 --cflags', '-O3'])
# Combine an optimization flag with the flags returned from running pkg-config
# for two distinct packages and merge into the construction variables.
env.MergeFlags(
    [
        '-O3',
        '!pkg-config gtk+-2.0 --cflags --libs',
        '!pkg-config libpng12 --cflags --libs',
    ]
)

چندین فایل را می‌توان یا به عنوان آرگومان‌های مجزا برای متد NoCache یا به صورت یک لیست مشخص کرد. NoCache همچنین مقدار بازگشتی هر یک از متدهای سازنده (Builder) در محیط ساخت را می‌پذیرد.

فراخوانی NoCache روی دایرکتوری‌ها و دیگر انواع گره‌های غیرفایلی هیچ اثری ندارد، زیرا تنها گره‌های فایلی در حافظه پنهان ذخیره می‌شوند.

مثال‌ها:

NoCache('foo.elf')
NoCache(env.Program('hello', 'hello.c'))

فراخوانی NoClean برای یک هدف، بر فراخوانی Clean برای همان هدف اولویت دارد؛ بنابراین هر هدفی که به هر دو تابع داده شود در حالت پاک‌سازی حذف نخواهد شد.

مثال‌ها:

NoClean('foo.elf')
NoClean(env.Program('hello', 'hello.c'))

command با استفاده از محیط اجرای SCons (یعنی متغیر ساخت $ENV در محیط ساخت فعلی) اجرا می‌شود. اگر command برای عملکرد صحیح به اطلاعات بیشتری نیاز داشته باشد، آن اطلاعات باید در محیط اجرا تنظیم شوند. برای مثال، pkg-config ممکن است به تنظیم یک مقدار سفارشی در متغیر محیطی PKG_CONFIG_PATH نیاز داشته باشد.

env.MergeFlags برای توزیع خروجی تولیدشده توسط command بین متغیرهای ساخت مناسب، باید ساختار آن را درک کند. env.MergeFlags برای انجام این پردازش از تابع مجزایی استفاده می‌کند - برای جزئیات بیشتر، از جمله جدول گزینه‌ها و متغیرهای ساخت متناظر، به env.ParseFlags مراجعه کنید. برای ارائه پردازش سفارشی روی خروجی command، می‌توانید یک function دلخواه تعریف کنید که باید سه آرگومان را بپذیرد: محیط ساخت برای تغییر، یک آرگومان رشته‌ای حاوی خروجی حاصل از اجرای command، و پرچم اختیاری unique.

به طور پیش‌فرض، عدم وجود filename خطا محسوب نمی‌شود. آرگومان اختیاری must_exist می‌تواند روی True تنظیم شود تا در صورتی که فایل وجود نداشته باشد یا به هر دلیلی غیرقابل دسترسی باشد، SCons یک استثنا صادر کند.

آرگومان اختیاری only_one می‌تواند روی True تنظیم شود تا در صورتی که فایل حاوی اطلاعات وابستگی برای بیش از یک هدف باشد، SCons یک استثنا صادر کند. این قابلیت می‌تواند یک اعتبارسنجی اولیه برای فایل‌هایی فراهم کند که برای نمونه قرار است توسط پرچم gcc -M تولید شوند؛ پرچمی که معمولاً باید اطلاعات وابستگی را فقط برای یک فایل خروجی در فایل متناظر .d بنویسد.

filename و تمامی فایل‌های فهرست‌شده در آن نسبت به دایرکتوری فایل SConscript فراخواننده تابع ParseDepends تفسیر خواهند شد.

اگر نخستین نویسه در هر رشته یک علامت تعجب (!) باشد، باقی‌مانده رشته به عنوان یک دستور اجرا می‌شود و خروجی حاصل از دستور به عنوان پرچم‌های خط فرمان زنجیره ابزار GCC تجزیه شده و به دیکشنری حاصل افزوده می‌شود. این قابلیت می‌تواند برای فراخوانی دستورهای *-config رایج در محیط برنامه‌نویسی POSIX (برای نمونه، pkg-config) استفاده شود. توجه داشته باشید که چنین دستوری با استفاده از محیط اجرای SCons اجرا می‌شود؛ در صورتی که دستور به اطلاعات بیشتری نیاز داشته باشد، آن اطلاعات باید صریحاً ارائه شود. برای جزئیات بیشتر به ParseConfig مراجعه کنید.

مقادیر پرچم‌ها بر اساس پیشوند یافت‌شده ترجمه شده و به متغیرهای ساخت زیر افزوده می‌شوند:

-arch                   CCFLAGS, LINKFLAGS
-D                      CPPDEFINES
-framework              FRAMEWORKS
-frameworkdir=          FRAMEWORKPATH
-fmerge-all-constants   CCFLAGS, LINKFLAGS
-fopenmp                CCFLAGS, LINKFLAGS
-fsanitize              CCFLAGS, LINKFLAGS
-include                CCFLAGS
-imacros                CCFLAGS
-isysroot               CCFLAGS, LINKFLAGS
-isystem                CCFLAGS
-iquote                 CCFLAGS
-idirafter              CCFLAGS
-I                      CPPPATH
-l                      LIBS
-L                      LIBPATH
-mno-cygwin             CCFLAGS, LINKFLAGS
-mwindows               LINKFLAGS
-openmp                 CCFLAGS, LINKFLAGS
-pthread                CCFLAGS, LINKFLAGS
-std=                   CFLAGS
-stdlib=                CXXFLAGS
-Wa,                    ASFLAGS, CCFLAGS
-Wl,-rpath=             RPATH
-Wl,-R,                 RPATH
-Wl,-R                  RPATH
-Wl,                    LINKFLAGS
-Wp,                    CPPFLAGS
-                       CCFLAGS
+                       CCFLAGS, LINKFLAGS

هر رشته دیگری که به گزینه‌ها مرتبط نباشد، به عنوان نام کتابخانه‌ها در نظر گرفته شده و به متغیر ساخت $LIBS اضافه می‌شود.

مثال‌ها (که همگی نتیجه یکسانی ایجاد می‌کنند):

dict = env.ParseFlags('-O2 -Dfoo -Dbar=1')
dict = env.ParseFlags('-O2', '-Dfoo', '-Dbar=1')
dict = env.ParseFlags(['-O2', '-Dfoo -Dbar=1'])
dict = env.ParseFlags('-O2', '!echo -Dfoo -Dbar=1')

مثال:

env = Environment(platform=Platform('win32'))

هنگامی که به عنوان متدی از یک محیط فراخوانی شود، شیء پلتفرم مشخص‌شده توسط plat را برای به‌روزرسانی آن محیط فراخوانی می‌کند.

env.Platform('posix')

برای جزئیات بیشتر به بخش "Construction Environments" در صفحه راهنما مراجعه کنید.

مثال:

env.Prepend(CCFLAGS='-g ', FOO=['foo.yyy'])

همچنین ببینید: env.Append، env.AppendUnique و env.PrependUnique.

مسیرها تنها یک بار ظاهر خواهند شد. مسیرهای تکراری در newpath حذف می‌شوند و نخستین رخداد برای حفظ ترتیب مسیر نگه داشته می‌شود. اگر delete_existing درست باشد (پیش‌فرض)، تکرارهای موجود پیش از افزودن به ابتدا حذف می‌شوند؛ در غیر این صورت، از تکرارهای جدید صرف‌نظر می‌شود. در طول مقایسه‌ها، مسیرها نرمال‌سازی می‌شوند تا از بروز مشکل با تفاوت حروف بزرگ و کوچک (در سامانه‌های فایلی غیرحساس به بزرگی و کوچکی حروف) و مسیرهای نسبی که ممکن است به همان دایرکتوری اشاره کنند، جلوگیری شود. مقادیر ذخیره‌شده توسط این فرآیند تغییر نمی‌کنند.

مثال:

print('before:', env['ENV']['INCLUDE'])
include_path = '/foo/bar:/foo'
env.PrependENVPath('INCLUDE', include_path)
print('after:', env['ENV']['INCLUDE'])

نتیجه می‌دهد:

before: /biz:/foo
after: /foo/bar:/foo:/biz

همچنین ببینید env.AppendENVPath.

مثال:

env.PrependUnique(CCFLAGS='-g', FOO=['foo.yyy'])

همچنین ببینید env.Append، env.AppendUnique و env.Prepend.

اگر نخستین آرگومان تعیین‌شده یک فراخوان‌پذیر (callable) در Python باشد (یک تابع یا شیئی که متد __call__ دارد)، تابع به ازای هر interval بار ارزیابی یک گره، یک بار فراخوانی می‌شود (پیش‌فرض 1 است). گره ارزیابی‌شده به عنوان تنها آرگومان به فراخوان‌پذیر ارسال می‌شود. (برای سازگاری با آینده، ایده خوبی است که *args و **kwargs را نیز به عنوان آرگومان به امضای تابع یا متد خود اضافه کنید. این کار در صورتی که SCons در آینده واسط را برای فراخوانی تابع با آرگومان‌های اضافی تغییر دهد، از شکسته‌شدن کد جلوگیری می‌کند.)

نمونه‌ای از یک تابع پیشرفت سفارشی ساده که به ازای هر ۱۰ گره، رشته‌ای شامل نام گره را چاپ می‌کند:

def my_progress_function(node, *args, **kwargs):
    print('Evaluating node %s!' % node)
Progress(my_progress_function, interval=10)

نمونه‌ای پیچیده‌تر از یک شیء سفارشی نمایش پیشرفت که به ازای هر ۱۰۰ گره ارزیابی‌شده، رشته‌ای شامل یک شمارنده را چاپ می‌کند. به استفاده از \r (بازگشت به ابتدای سطر) در انتها توجه کنید تا رشته خودش را روی صفحه نمایش بازنویسی کند:

import sys
class ProgressCounter(object):
    count = 0
    def __call__(self, node, *args, **kw):
        self.count += 100
        sys.stderr.write('Evaluated %s nodes\r' % self.count)
Progress(ProgressCounter(), interval=100)

اگر آرگومان نخست برای Progress یک رشته یا فهرستی از رشته‌ها باشد، به عنوان متنی در نظر گرفته می‌شود که به ازای هر interval گره ارزیابی‌شده نمایش داده شود. اگر آرگومان نخست فهرستی از رشته‌ها باشد، آنگاه هر رشته در فهرست به صورت چرخشی به ازای هر interval گره ارزیابی‌شده نمایش داده خواهد شد.

پیش‌فرض، چاپ رشته در خروجی استاندارد است. یک جریان خروجی جایگزین را می‌توان با آرگومان کلیدواژه‌ای file مشخص کرد، که فراخواننده باید آن را از قبل بازشده ارسال کند.

کد زیر مجموعه‌ای از نقطه‌ها را در خروجی خطا چاپ می‌کند، یک نقطه به ازای هر ۱۰۰ گره ارزیابی‌شده:

import sys
Progress('.', interval=100, file=sys.stderr)

اگر رشته دقیقاً حاوی زیررشته $TARGET; باشد، با گره جایگزین خواهد شد. توجه داشته باشید که به دلایل کارایی، این not یک جایگزینی معمول متغیر SCons نیست، بنابراین نمی‌توانید از متغیرهای دیگر یا از آکولادها استفاده کنید. مثال زیر نام هر گره ارزیابی‌شده را چاپ می‌کند، با استفاده از بازگشت به ابتدای سطر (\r) تا هر خط توسط خط بعدی بازنویسی شود، و آرگومان کلیدواژه‌ای overwrite (پیش‌فرض False) برای اطمینان از اینکه نام فایل چاپ‌شدهٔ قبلی با نویسه‌های فاصله بازنویسی شود:

import sys
Progress('$TARGET\r', overwrite=True)

می‌توان از فهرستی از رشته‌ها برای پیاده‌سازی یک نشانگر چرخان (spinner) بر روی صفحه نمایش کاربر به شرح زیر استفاده کرد که به ازای هر پنج گره ارزیابی‌شده تغییر می‌کند:

Progress(['-\r', '\\\r', '|\r', '/\r'], interval=5)

Pseudo ممکن است همراه با یک فراخوانی سازنده (مانند Command) مفید باشد که هیچ هدف فیزیکی تولید نمی‌کند، و اگر هدف به‌طور تصادفی از قبل وجود داشته باشد، رفتار آن نادرست خواهد بود. این مفهوم مشابه هدف .PHONY در GNU make است. همچنین SCons یک قابلیت قدرتمند نام مستعار هدف (به Alias مراجعه کنید) ارائه می‌دهد که ممکن است در بسیاری از موقعیت‌ها هنگام تعریف نام‌های هدفی که مستقیماً ساخته نمی‌شوند، انعطاف‌پذیری بیشتری فراهم کند.

هنگامی که یک ماژول ابزار (Tool) که به عنوان یک ماژول Python نصب شده استفاده می‌شود، باید یک آرگومان toolpath را به Tool، Environment یا Clone مشخص کنید، زیرا در غیر این صورت ابزارهای خارج از مکان‌های استاندارد پروژه (site_scons/site_tools) پیدا نخواهند شد. استفاده از PyPackageDir اجازه می‌دهد این مسیر به جای درج ثابت در کد (hardcode)، در زمان اجرا کشف شود.

مثال:

env = Environment(
    tools=["default", "ExampleTool"],
    toolpath=[PyPackageDir("example_tool")]
)

مثال:

env.Replace(CCFLAGS='-g', FOO='foo.xxx')

در scons، یک مخزن، یک نسخه جزئی یا کامل از درخت منبع از بالاترین سطح دایرکتوری به پایین است که شامل فایل‌های منبعی است که می‌توانند برای ساخت اهداف در درخت کاری (worktree) فعلی استفاده شوند. مخازن همچنین می‌توانند حاوی فایل‌های اشتقاقی (derived files) باشند. یک نمونه می‌تواند درخت منبع رسمی باشد که توسط یک یکپارچه‌ساز نگهداری می‌شود. اگر مخزنی حاوی فایل‌های اشتقاقی باشد، آنها باید نتیجه ساخت با SCons باشند، تا پایگاه داده امضا (sconsign) در مخزن وجود داشته باشد و تصمیم‌گیری بهتری در مورد به‌روز بودن یا نبودن آنها امکان‌پذیر شود.

توجه داشته باشید که اگر یک فایل اشتقاقی به‌روز از قبل در یک مخزن موجود باشد، scons نسخه‌ای از آن را در درخت دایرکتوری محلی ایجاد نخواهد کرد. اگر نیاز دارید که یک کپی محلی ساخته شود، از متد Local استفاده کنید.

مثال:

env.Requires('foo', 'file-that-must-be-built-before-foo')

به‌طور پیش‌فرض Return پردازش SConscript فعلی را متوقف کرده و بلافاصله بازمی‌گردد. آرگومان کلیدواژه‌ای اختیاری stop می‌تواند روی یک مقدار نادرست (False) تنظیم شود تا پردازش ادامه فایل SConscript پس از فراخوانی Return ادامه یابد (این رفتار پیش‌فرض قبل از SCons 0.98 بود). با این حال، مقادیر بازگردانده‌شده همچنان مقادیر متغیرهای نام‌برده در vars در نقطه فراخوانی Return هستند.

مثال‌ها:

# هیچ مقداری برنمی‌گرداند (ارزیابی نادرست / False)
Return()
# مقدار متغیر پایتونی 'foo' را برمی‌گرداند.
Return("foo")
# مقادیر متغیرهای پایتونی 'foo' و 'bar' را برمی‌گرداند.
Return("foo", "bar")
# مقادیر متغیرهای پایتونی 'val1' و 'val2' را برمی‌گرداند.
Return('val1 val2')

روش نخست فراخوانی، ارائه یک یا چند نام فایل SConscript به عنوان اولین آرگومان موضعی است که می‌تواند یک رشته یا فهرستی از رشته‌ها باشد. اگر آرگومان موضعی دومی وجود داشته باشد، با آن به گونه‌ای رفتار می‌شود که گویی آرگومان کلیدواژه‌ای exports داده شده است (به ادامه مطلب مراجعه کنید). مثال‌ها:

SConscript('SConscript')  # run SConscript in the current directory
SConscript('src/SConscript')  # run SConscript in the src directory
SConscript(['src/SConscript', 'doc/SConscript'])
SConscript(Split('src/SConscript doc/SConscript'))
config = SConscript('MyConfig.py')

روش دوم فراخوانی، حذف آرگومان موضعیِ نام‌گذاری اسکریپت و در عوض تعیین نام دایرکتوری‌ها با استفاده از آرگومان کلیدواژه‌ای dirs است. مقدار می‌تواند یک رشته یا فهرستی از رشته‌ها باشد. در این حالت، scons یک فایل پیکربندی فرعی به نام SConscript (به‌طور پیش‌فرض) را در هر یک از دایرکتوری‌های مشخص‌شده اجرا خواهد کرد. می‌توانید با ارائه یک آرگومان کلیدواژه‌ای اختیاری name=scriptname نامی غیر از SConscript را تعیین کنید. سه مثال نخست زیر اثری مشابه سه مثال نخست بالا دارند:

SConscript(dirs='.')  # run SConscript in the current directory
SConscript(dirs='src')  # run SConscript in the src directory
SConscript(dirs=['src', 'doc'])
SConscript(dirs=['sub1', 'sub2'], name='MySConscript')

آرگومان کلیدواژه‌ای اختیاری exports متغیرهایی را مشخص می‌کند تا برای استفاده در SConscriptهای فراخوانی‌شده در دسترس قرار گیرند؛ این اسکریپت‌ها در محیطی ایزوله ارزیابی می‌شوند و در غیر این صورت به متغیرهای محلی SConscript فراخواننده دسترسی ندارند. این مقدار می‌تواند یک رشته یا فهرستی از رشته‌ها شامل نام متغیرها باشد، یا یک دیکشنری که نام‌های محلی را به نام‌هایی نگاشت می‌کند که می‌توانند با آن‌ها وارد شوند. در روش فراخوانی نخست (scriptnames)، دومین آرگومان موضعی نیز به عنوان exports تفسیر خواهد شد؛ روش فراخوانی دوم (دایرکتوری) هیچ آرگومان موضعی را نمی‌پذیرد و باید از فرم کلیدواژه‌ای استفاده کند. این متغیرها تنها برای فایل(های) SConscript فراخوانی‌شده به‌طور محلی صادر (export) می‌شوند، و نسبت به هر متغیر هم‌نام در مخزن سراسری که توسط تابع Export مدیریت می‌شود، اولویت دارند. فایل‌های فرعی SConscript باید از تابع Import برای وارد کردن متغیرها به حوزه محلی خود استفاده کنند. مثال‌ها:

foo = SConscript('sub/SConscript', exports='env')
SConscript('dir/SConscript', exports=['env', 'variable'])
SConscript(dirs='subdir', exports='env variable')
SConscript(dirs=['one', 'two', 'three'], exports='shared_info')

اگر آرگومان اختیاری variant_dir وجود داشته باشد، اثری معادل با تابع VariantDir ایجاد می‌کند، اما فقط در حوزه فراخوانی SConscript معتبر است. آرگومان variant_dir نسبت به دایرکتوریِ فایل SConscript فراخواننده تفسیر می‌شود. دایرکتوری مبدا، دایرکتوری‌ای است که فایل SConscript فراخوانی‌شده در آن قرار دارد و فایل SConscript به گونه‌ای ارزیابی می‌شود که گویی در دایرکتوری variant_dir قرار دارد. بنابراین:

SConscript('src/SConscript', variant_dir='build')

معادل است با:

VariantDir('build', 'src')
SConscript('build/SConscript')

اگر فایل‌های مبدا در همان دایرکتوریِ SConstruct باشند،

SConscript('SConscript', variant_dir='build')

معادل است با:

VariantDir('build', '.')
SConscript('build/SConscript')

آرگومان اختیاری duplicate همانند VariantDir تفسیر می‌شود. اگر آرگومان variant_dir حذف شود، آرگومان duplicate نادیده گرفته خواهد شد. برای جزئیات و محدودیت‌های بیشتر، به توضیحات VariantDir مراجعه کنید.

اگر مقدار اختیاری must_exist برابر True باشد (پیش‌فرض)، در صورت پیدا نشدن فایل SConscript درخواستی، یک استثنا ایجاد می‌شود. برای نادیده‌گرفتن خاموش اسکریپت‌های ناموجود (رفتار پیش‌فرض پیش از نسخه 3.1 SCons)، مقدار must_exist=False را در فراخوانی SConscript پاس دهید.

تغییریافته در 4.6.0: اکنون مقدار پیش‌فرض must_exist برابر True است.

در اینجا چند مثال ترکیبی آورده شده است:

# collect the configuration information and use it to build src and doc
shared_info = SConscript('MyConfig.py')
SConscript('src/SConscript', exports='shared_info')
SConscript('doc/SConscript', exports='shared_info')

# build debugging and production versions.  SConscript
# can use Dir('.').path to determine variant.
SConscript('SConscript', variant_dir='debug', duplicate=0)
SConscript('SConscript', variant_dir='prod', duplicate=0)

# build debugging and production versions.  SConscript
# is passed flags to use.
opts = { 'CPPDEFINES' : ['DEBUG'], 'CCFLAGS' : '-pgdb' }
SConscript('SConscript', variant_dir='debug', duplicate=0, exports=opts)
opts = { 'CPPDEFINES' : ['NODEBUG'], 'CCFLAGS' : '-O' }
SConscript('SConscript', variant_dir='prod', duplicate=0, exports=opts)

# build common documentation and compile for different architectures
SConscript('doc/SConscript', variant_dir='build/doc', duplicate=0)
SConscript('src/SConscript', variant_dir='build/x86', duplicate=0)
SConscript('src/SConscript', variant_dir='build/ppc', duplicate=0)

SConscript مقادیر هر متغیری را که توسط فایل(های) SConscript اجراشده در آرگومان‌های تابع Return تعیین شده باشد، بازمی‌گرداند. اگر یک فراخوانیِ تک‌گانه SConscript باعث اجرای چندین اسکریپت شود، مقدار بازگشتی یک چندتایی (tuple) شامل مقادیر بازگشتی هر یک از اسکریپت‌ها خواهد بود. اگر یک اسکریپت اجراشده صراحتاً تابع Return را فراخوانی نکند، None بازمی‌گرداند.

مثال:

SConscriptChdir(False)
SConscript('foo/SConscript')	# به foo تغییر دایرکتوری نخواهد داد
SConscriptChdir(True)
SConscript('bar/SConscript')	# به bar تغییر دایرکتوری خواهد داد

آرگومان اختیاری name نام پایهٔ فایل(های) پایگاه‌داده است. پایگاه‌داده نسبت به دایرکتوری حاوی فایل سطح بالای SConstruct قرار می‌گیرد، مگر اینکه name یک مسیر مطلق باشد. مقدار پیش‌فرض .sconsign است. فایل(های) واقعی پایگاه‌داده که روی دیسک ذخیره می‌شوند ممکن است پسوند مناسبی داشته باشند که توسط dbm_module انتخابی اضافه شده است، و همچنین ممکن است شامل نام قالب هش نیز باشند (نگاه کنید به --hash-format).

آرگومان اختیاری dbm_module مشخص می‌کند که از کدام ماژول پایگاه‌دادهٔ Python برای خواندن/نوشتن فایل استفاده شود. ماژول ابتدا باید وارد (import) شود؛ سپس نام ماژول واردشده به عنوان آرگومان ارسال می‌گردد. پیش‌فرض، یک ماژول سفارشی SCons.dblite است که از ساختارهای دادهٔ serialize‌شدهٔ Python (به کمک pickle) استفاده می‌کند و روی تمام نسخه‌های Python کار می‌کند. برای مشاهدهٔ سایر انواع موجود، به مستندات ماژول dbm در Python مراجعه کنید.

در صورت فراخوانی بدون آرگومان، پایگاه‌داده به‌طور پیش‌فرض در .sconsign.dblite در دایرکتوری اصلی پروژه قرار خواهد گرفت، که در صورت فراخوانی نشدن SConsignFile نیز همین رفتار پیش‌فرض است.

این تنظیم به‌صورت سراسری است، بنابراین تنها تفاوت بین تابع سراسری و حالت متد محیطی، بسط متغیرها روی name است. در یک پیکربندی ساخت مشخص، تنها باید یک فراخوانی فعال از این تابع/متد وجود داشته باشد.

اگر name روی None تنظیم شود، scons امضاهای فایل را در یک فایل .sconsign مجزا در هر دایرکتوری ذخیره خواهد کرد، نه در یک فایل پایگاه‌دادهٔ تجمیعی واحد. این تمهیدی برای سازگاری عقبرو به‌منظور پشتیبانی از رفتاری است که قبل از SCons 0.97 (یعنی قبل از سال ۲۰۰۸) پیش‌فرض بود. استفاده از این حالت منسوخ شده است و نباید در پروژه‌های جدید استفاده شود.

از نسخهٔ 4.11.0 منسوخ شده است: حالت یک فایل امضا به ازای هر دایرکتوری منسوخ شده است و در انتشار‌های آینده حذف خواهد شد.

مثال‌ها:

# به‌طور صریح امضاها را در ".sconsign.dblite"
# در دایرکتوری سطح بالای SConstruct ذخیره می‌کند (رفتار پیش‌فرض).
SConsignFile()
# امضاها را در فایل "etc/scons-signatures"
# نسبت به دایرکتوری سطح بالای SConstruct ذخیره می‌کند.
# SCons یک پسوند پایگاه‌داده به این نام اضافه خواهد کرد.
SConsignFile("etc/scons-signatures")
# امضاها را در نام فایل مطلق مشخص‌شده ذخیره می‌کند.
# SCons یک پسوند پایگاه‌داده به این نام اضافه خواهد کرد.
SConsignFile("/home/me/SCons/signatures")
# امضاها را در یک فایل .sconsign جداگانه
# در هر دایرکتوری ذخیره می‌کند.
SConsignFile(None)
# امضاها را در یک فایل .sconsign با قالب GNU dbm ذخیره می‌کند
import dbm.gnu
SConsignFile(dbm_module=dbm.gnu)

رفتار گزینه‌ها در مدخل مربوط به گزینهٔ خط فرمان مرتبط در صفحهٔ راهنما (manpage) شرح داده شده است. پارامتر value اجباری است؛ برای مقادیر گزینه‌های بولی (در مواردی که گزینهٔ خط فرمان آرگومان دریافت نمی‌کند)، از یک value استفاده کنید که به مقدار درست (مانند True، 1) یا نادرست (مانند False، 0) ارزیابی شود.

گزینه‌هایی که بر خواندن و پردازش فایل‌های SConscript تأثیر می‌گذارند با استفاده از SetOption قابل تنظیم نیستند، زیرا آن فایل‌ها در وهلهٔ اول باید خوانده شوند تا فراخوانی SetOption یافت شود.

برای گزینه‌های خاص پروژه (که گاهی گزینه‌های محلی نامیده می‌شوند) که از طریق فراخوانی AddOption اضافه شده‌اند، استفاده از SetOption تنها پس از پایان موفقیت‌آمیز فراخوانی AddOption مجاز است، و فقط در صورتی که آن فراخوانی شامل آرگومان کلیدواژه‌ای settable=True بوده باشد.

متغیرهای قابل تنظیم به همراه گزینه‌های خط فرمان متناظر با آن‌ها عبارتند از:

مثال:

SetOption('max_drift', 0)

از آنجا که چندین دستور ساخت ممکن است یک فایل اثر جانبی یکسان را به‌روزرسانی کنند، به طور پیش‌فرض هنگام حذف target توسط گزینه -c، هدف side_effect به طور خودکار حذف نمی‌شود. (البته توجه داشته باشید که ممکن است side_effect به عنوان بخشی از پاکسازی دایرکتوری‌ای که در آن قرار دارد حذف شود.) اگر می‌خواهید مطمئن شوید هر زمان که یک target خاص پاکسازی می‌شود، side_effect نیز پاکسازی شود، باید این مورد را صراحتاً با تابع Clean یا env.Clean مشخص کنید.

این تابع فهرستی از شیءهای Node اثر جانبی را که با موفقیت اضافه شده‌اند برمی‌گرداند. اگر فهرست اثرات جانبی شامل مواردی باشد که از قبل اضافه شده‌اند، آن‌ها اضافه نشده و در فهرست بازگردانده‌شده قرار نمی‌گیرند.

مثال:

files = Split("f1.c f2.c f3.c")
files = env.Split("f4.c f5.c f6.c")
files = Split("""
    f7.c
    f8.c
    f9.c
""")

به طور پیش‌فرض، فاصله‌های خالی ابتدا و انتهای نتیجه حذف خواهند شد و تمام توالی‌های فاصله‌های خالی به یک نویسه فاصله فشرده می‌شوند. علاوه بر این، هرگونه توالی نویسه‌ای $( و $) از رشته بازگردانده‌شده حذف خواهد شد. آرگومان اختیاری raw اگر می‌خواهید فاصله‌های خالی و توالی‌های $(-$) حفظ شوند، می‌تواند روی 1 تنظیم شود. همچنین اگر بخواهید علاوه بر این تمام نویسه‌های بین هر جفت $( و $) نیز دور ریخته شوند (همان‌طور که برای محاسبه امضا انجام می‌شود)، آرگومان raw می‌تواند روی 2 تنظیم شود.

اگر input یک توالی (لیست یا تاپل) باشد، تک‌تک عناصر توالی بسط داده شده و نتایج به عنوان یک لیست بازگردانده می‌شوند.

اگر می‌خواهید $TARGET، $TARGETS، $SOURCE و $SOURCES برای بسط در دسترس باشند، آرگومان‌های اختیاری کلیدواژه‌ای target و source باید به ترتیب روی فهرست‌هایی از گره‌های هدف و منبع تنظیم شوند. این کار معمولاً زمانی لازم است که شما env.subst را از داخل یک تابع Python که به عنوان یک عمل (action) در SCons استفاده شده فراخوانی می‌کنید.

مقادیر رشته‌ای بازگردانده‌شده یا عناصر توالی به طور پیش‌فرض به نمایش رشته‌ای‌شان تبدیل می‌شوند. آرگومان اختیاری conv می‌تواند یک تابع تبدیل را مشخص کند که به جای حالت پیش‌فرض استفاده خواهد شد. به عنوان مثال، اگر می‌خواهید شیءهای Python (شامل گره‌های SCons) به عنوان شیءهای Python بازگردانده شوند، می‌توانید از یک عبارت lambda در Python استفاده کنید تا تابعی بی‌نام را ارسال کنید که صرفاً آرگومانِ تبدیل‌نشده خود را برمی‌گرداند.

مثال:

print(env.subst("The C compiler is: $CC"))
def compile(target, source, env):
    sourceDir = env.subst(
        "${SOURCE.srcdir}",
        target=target,
        source=source
    )
source_nodes = env.subst('$EXPAND_TO_NODELIST', conv=lambda x: x)

مثال‌ها:

# اطمینان حاصل می‌کند که کتابخانه ساخته‌شده با حالت دسترسی فایل 644 نصب خواهد شد
Tag(Library('lib.c'), UNIX_ATTR="0o644")
# فایل file2.txt را به عنوان یک فایل مستندات نشانه‌گذاری می‌کند
Tag('file2.txt', DOC)

ماژول ابزار در مسیرهای جستجوی ابزار (برای جزئیات به بخش Tools در صفحه راهنما مراجعه کنید) و در هر مسیری که توسط پارامتر اختیاری toolpath مشخص شده باشد، جستجو می‌شود؛ این پارامتر باید فهرستی از رشته‌ها باشد. اگر toolpath مشخص نشود، از toolpath ارائه‌شده هنگام ایجاد محیط (در صورت وجود) استفاده می‌شود.

هر آرگومان کلیدواژه‌ای باقی‌مانده در شیء ابزار ذخیره شده، و هنگام فراخوانی واقعی شیء ابزار به تابع generate ماژول ابزار ارسال خواهد شد. تابع generate می‌تواند محیط ساخت را با متغیرهای ساخت به‌روزرسانی کند و هرگونه مقداردهی اولیه دیگری که برای استفاده از سازوکارهای توصیف‌شده توسط ابزار لازم است را ترتیب دهد، و می‌تواند از این آرگومان‌های اضافی برای هدایت اقدامات خود بهره ببرد.

تغییریافته در نسخه 4.2: اکنون env.Tool شیء ابزار را برمی‌گرداند؛ پیش از این مقداری برنمی‌گرداند (یعنی None برمی‌گرداند).

مثال‌ها:

env.Tool('gcc')
env.Tool('opengl', toolpath=['build/tools'])

شیء ابزارِ بازگردانده‌شده می‌تواند به عنوان بخشی از آرگومان کلیدواژه‌ای tools به یک فراخوانی Environment یا Clone ارسال شود، که در این حالت ابزار به محیطِ در حال ساخت اعمال می‌شود؛ یا می‌تواند مستقیماً فراخوانی شود، که در این حالت باید یک محیط ساخت برای به‌روزرسانی به عنوان آرگومان به آن ارسال گردد. هر یک از این دو روش، متغیر ساخت $TOOLS را نیز به‌روزرسانی خواهد کرد.

مثال‌ها:

env = Environment(tools=[Tool('msvc')])
env = Environment()
msvctool = Tool('msvc')
msvctool(env)  # مقدار 'msvc' را به متغیر TOOLS اضافه می‌کند
gltool = Tool('opengl', toolpath = ['tools'])
gltool(env)  # مقدار 'opengl' را به متغیر TOOLS اضافه می‌کند

این تابع باید تنها پس از آخرین فراخوانی AddOption در منطق SConscript شما فراخوانی شود. توجه داشته باشید که برخی از ابزارها AddOption را فراخوانی می‌کنند؛ اگر برای آرگومان‌هایی که آن‌ها اضافه می‌کنند پیام خطا دریافت می‌کنید، باید اطمینان حاصل کنید که آن ابزارها پیش از فراخوانی ValidateOptions بارگذاری شده باشند.

اگر گزینه ناشناخته‌ای در خط فرمان وجود داشته باشد، ValidateOptions یک پیام خطا چاپ کرده و با وضعیت خروج خطا خارج می‌شود. اگر آرگومان اختیاری throw_exception برابر با True باشد (پیش‌فرض False است)، یک SConsBadOptionError صادر می‌شود (raise)، که به منطق SConscript این امکان را می‌دهد تا آن استثنا را دریافت کرده و گزینه‌های نامعتبر را به شکل مناسب مدیریت کند. توجه داشته باشید که این نام استثنا باید وارد (import) شود (به مثال زیر مراجعه کنید).

یک مشکل رایج در ساخت، اشتباهات تایپی (یا اشتباهات لپی و سهوی) است - کاربر گزینه‌ای را وارد می‌کند که اندکی با مقدار مورد انتظار تفاوت دارد، یا شاید واژه‌ای دیگر با معنای مشابه باشد. متوقف کردن ساخت پیش از پیشروی بیش از حد در مسیری نادرست می‌تواند مفید باشد. برای مثال:

$ scons --complier=mingw  # پرچم درست --compiler است

در اینجا ممکن بود SCons به کار خود ادامه دهد و مجموعه‌ای از مراحل پیکربندی (configure) را با استفاده از مقدار پیش‌فرض --compiler اجرا کند، چرا که گزینه دارای غلط املایی باعث می‌شود مقدار مدنظر به آن عرضه نشود؛ امری که زمان توسعه‌دهنده را برای ردیابی این که چرا منطق پیکربندی گزینه‌های «اشتباه» را انتخاب کرده تلف می‌کند. این مثال گرفتن و مدیریت این وضعیت را نشان می‌دهد:

from SCons.Script.SConsOptions import SConsBadOptionError
AddOption(
    '--compiler',
    dest='compiler',
    action='store',
    default='gcc',
    type='string',
)
# ... سایر منطق‌های SConscript ...
try:
    ValidateOptions(throw_exception=True)
except SConsBadOptionError as e:
    print(f"ValidateOptions detects a fail: ", e.opt_str)
    Exit(3)

جدید در نسخه 4.5.0

آرگومان اختیاری built_value را می‌توان هنگام ایجاد گره Value مشخص کرد تا نشان دهد که این Node باید از قبل «ساخته‌شده» در نظر گرفته شود.

پارامتر اختیاری name می‌تواند به عنوان نامی جایگزین برای گره Value حاصل ارائه شود؛ در صورتی که پارامتر value نتواند به یک رشته تبدیل شود، استفاده از این پارامتر توصیه می‌شود.

گره‌های Value متدی به نام write دارند که می‌توان با تنظیم مقداری جدید، از آن برای «ساختن» یک گره Value استفاده کرد. متد متناظرِ read مقدار ساخته‌شدهٔ Node را برمی‌گرداند.

تغییریافته در نسخهٔ 4.0: پارامتر name اضافه شد.

مثال‌ها:

env = Environment()
def create(target, source, env):
    """Action function to create a file from a Value.
    Writes 'prefix=$SOURCE' into the file name given as $TARGET.
    """
    with open(target[0], 'wb') as f:
        f.write(b'prefix=' + source[0].get_contents() + b'\n')
# Fetch the prefix= argument, if any, from the command line.
# Use /usr/local as the default.
prefix = ARGUMENTS.get('prefix', '/usr/local')
# Attach builder named Config to the construction environment
# using the 'create' action function above.
env['BUILDERS']['Config'] = Builder(action=create)
env.Config(target='package-config', source=Value(prefix))
def build_value(target, source, env):
    """Action function to "build" a Value.
    Writes contents of $SOURCE into $TARGET, thus updating if it existed.
    """
    target[0].write(source[0].get_contents())
output = env.Value('before')
input = env.Value('after')
# Attach a builder named UpdateValue to the construction environment
# using the 'build_value' action function above.
env['BUILDERS']['UpdateValue'] = Builder(action=build_value)
env.UpdateValue(target=Value(output), source=Value(input))

توجه داشته باشید که اگرچه variant_dir می‌تواند هر مکان مناسبی باشد، اما اگر زیر دایرکتوری اصلی پروژه نباشد، قواعد معمول انتخاب هدف، هدف‌های موجود در دایرکتوری متغیر را انتخاب نخواهند کرد مگر اینکه به صورت صریح مشخص شوند.

هنگامی که به فایل‌های درون variant_dir ارجاع داده می‌شود، SCons فایل‌های ناموجود را بر حسب نیاز از src_dir تأمین می‌کند تا یک درخت ساخت کامل ایجاد کند. به طور پیش‌فرض، SCons فایل‌های منبع، فایل‌های فرعی SConscript و هر ساختار دایرکتوری مورد نیاز را به طور فیزیکی در دایرکتوری متغیر تکثیر می‌کند. این کار ساخت در دایرکتوری متغیر را معادل ساخت در درخت منبع می‌سازد، حتی در شرایطی که فایل‌های منبع میانی تولید می‌شوند، اسکنرها فایل‌های ضمیمه‌شده را با استفاده از مسیرهای نسبی نسبت به منبع جستجو می‌کنند، یا ابزارها طوری کدگذاری ثابت شده‌اند که فایل‌های اشتقاقی را در کنار منابعشان ایجاد کنند. تنها فایل‌هایی که SCons تشخیص دهد برای ساخت لازم هستند در variant_dir تکثیر می‌شوند. در صورت امکان، تکثیر به جای کپی کردن از طریق پیوند دادن (linking) انجام می‌گیرد. راهبرد تکثیر را می‌توان با استفاده از گزینهٔ خط فرمان --duplicate یا SetOption تنظیم کرد.

اگر آرگومان duplicate روی False تنظیم شود، SCons فایل‌های منبع را تکثیر نمی‌کند. در عوض، سازنده‌ها را با استفاده از مسیرهای اصلی منبع در src_dir و مسیرهای فایل‌های اشتقاقی در variant_dir به صورت خودکار فراخوانی می‌کند. این روش کارآمدتر از تکثیر است و برای اغلب ساخت‌ها ایمن می‌باشد؛ اگر مشکلی ایجاد کرد، از duplicate=True (پیش‌فرض) استفاده کنید.

مثال‌ها:

# use names in the build directory, not the source directory
VariantDir('build', 'src', duplicate=False)
Program('build/prog', 'build/source.c')
# this builds both the source and docs in a separate subtree
VariantDir('build', '.', duplicate=False)
SConscript(dirs=['build/src', 'build/doc'])
# same as previous example, but only uses SConscript
SConscript(dirs='src', variant_dir='build/src', duplicate=False)
SConscript(dirs='doc', variant_dir='build/doc', duplicate=False)

VariantDir هنگامی که به همراه یک فایل فرعی SConscript به کار رود، طبیعی‌ترین رفتار را دارد. فایل فرعی SConscript باید به گونه‌ای فراخوانی شود که گویی در variant_dir قرار دارد، صرف‌نظر از اینکه مقدار duplicate چه باشد. از آرگومان کلیدواژه‌ای exports برای ارسال پارامترها یا یک شیء محیطیِ پیکربندی‌شده استفاده کنید تا SConscript فرعی بتواند تنظیمات مناسب آن ساخت متغیر را به کار گیرد. فایل SConscript باید پیش از استفاده از این مقادیر صادرشده، آن‌ها را با Import وارد کند.

env1 = Environment(...settings for variant1...)
env2 = Environment(...settings for variant2...)
# run src/SConscript by using the variant dir paths
VariantDir('build/variant1', 'src')
SConscript('build/variant1/SConscript', exports={"env": env1})
VariantDir('build/variant2', 'src')
SConscript('build/variant2/SConscript', exports={"env": env2})

هنگامی که به عنوان یک متدِ محیط ساخت (construction environment) فراخوانی شود، مسیرهای موجود در آرگومان کلیدواژه‌ایِ path یا در صورت None بودن (پیش‌فرض)، مسیرهای فهرست‌شده در محیط ساخت (env['ENV']['PATH']) را جستجو می‌کند. در صورتی که کلید env['ENV']['PATH'] وجود نداشته باشد، از فهرست مسیرهای محیط خارجی (os.environ['PATH']) به عنوان جایگزین استفاده می‌شود.

در سیستم‌های Windows، به دنبال برنامه‌های اجرایی با هر یک از پسوندهای فایل فهرست‌شده در آرگومان کلیدواژه‌ایِ pathext می‌گردد، یا در صورت None بودن (پیش‌فرض)، پسوندهای نام مسیر فهرست‌شده در محیط ساخت (env['ENV']['PATHEXT']). در صورتی که کلید env['ENV']['PATHEXT'] وجود نداشته باشد، از فهرست پسوندهای نام مسیر محیط خارجی (os.environ['PATHEXT']) به عنوان جایگزین استفاده می‌شود.

هنگامی که به عنوان یک تابع سراسری فراخوانی شود، در صورتی که path و pathext برابر None باشند، به ترتیب از مسیر محیط خارجی os.environ['PATH'] و پسوندهای مسیر os.environ['PATHEXT'] استفاده می‌کند.

هیچ‌یک از نام مسیرها یا نام‌های موجود در فهرست اختیاریِ reject را انتخاب نخواهد کرد.

print("first variable, value =", ARGLIST[0][0], ARGLIST[0][1])
print("second variable, value =", ARGLIST[1][0], ARGLIST[1][1])
var, value = ARGLIST[2]
print("third variable, value =", var, value)
for var, value in ARGLIST:
    # process variable and value

مقادیر به‌دست‌آمده از ARGLIST (یا از ARGUMENTS) همواره رشته هستند، زیرا از خارج فرایند SCons سرچشمه می‌گیرند. به عنوان «داده‌های غیرقابل اعتماد»، آن‌ها باید پیش از استفاده اعتبارسنجی شوند و ممکن است نیاز به تبدیل به یک نوع مناسب داشته باشند.

مثال:

if ARGUMENTS.get("debug", ""):
    env = Environment(CCFLAGS="-g")
else:
    env = Environment()

همچنین ببینید: ARGLIST.

عناصر این فهرست ممکن است رشته یا گره (Node) باشند، بنابراین باید فهرست را از طریق تابع str در Python پردازش کنید تا مطمئن شوید هرگونه نام مسیر Node به رشته تبدیل می‌شود.

از آنجا که این فهرست ممکن است از فهرست هدف‌های مشخص‌شده با استفاده از تابع Default گرفته شده باشد، محتویات فهرست ممکن است با هر بار فراخوانی متوالیِ Default تغییر کند. برای اطلاعات تکمیلی، DEFAULT_TARGETS را ببینید.

مثال:

if 'foo' in BUILD_TARGETS:
    print("Don't forget to test the `foo' program!")
if 'special/program' in BUILD_TARGETS:
    SConscript('special')

مثال:

if 'foo' in COMMAND_LINE_TARGETS:
    print("Don't forget to test the `foo' program!")
if 'special/program' in COMMAND_LINE_TARGETS:
    SConscript('special')

مثال:

print(str(DEFAULT_TARGETS[0]))
if 'foo' in [str(t) for t in DEFAULT_TARGETS]:
    print("Don't forget to test the `foo' program!")

محتوای فهرست DEFAULT_TARGETS با هر بار فراخوانی متوالی تابع Default تغییر می‌کند:

print([str(t) for t in DEFAULT_TARGETS])   # originally []
Default('foo')
print([str(t) for t in DEFAULT_TARGETS])   # now a node ['foo']
Default('bar')
print([str(t) for t in DEFAULT_TARGETS])   # now a node ['foo', 'bar']
Default(None)
print([str(t) for t in DEFAULT_TARGETS])   # back to []

در نتیجه، مطمئن شوید که از DEFAULT_TARGETS تنها پس از انجام تمام فراخوانی‌های Default() خود استفاده کنید، یا در غیر این صورت صرفاً مراقب ترتیب این دستورها در فایل‌های SConscript خود باشید تا قبل از اینکه یک هدف پیش‌فرض خاص واقعاً به فهرست اضافه شود، به دنبال آن نگردید.

from SCons.Script import *

env["CC"] = "cc"
flags = env.get("CPPDEFINES", [])

cvars = env.Dictionary()
cvars["CC"] = "cc"

env = Environment(CC="cc")

env2 = env.Clone(CC="cl.exe")

env.Program('hello', 'hello.c', LIBS=['gl', 'glut'])

مقدار به صورت X[.Y[.Z]] مشخص می‌شود که در آن X عددی بین 1 و 65535 است، Y می‌تواند حذف شود یا بین 1 و 255 باشد، و Z می‌تواند حذف شود یا بین 1 و 255 باشد. در صورت عدم تعیین، این مقدار از $SHLIBVERSION مشتق خواهد شد. کم‌ارزش‌ترین رقم حذف شده و با یک 0 جایگزین می‌شود.

اگر $APPLELINK_NO_COMPATIBILITY_VERSION تنظیم شده باشد، هیچ -compatibility_version در خروجی قرار نخواهد گرفت.

برای جزئیات بیشتر به صفحه راهنمای ld در MacOS مراجعه کنید.

مقدار به صورت X[.Y[.Z]] مشخص می‌شود که در آن X عددی بین 1 و 65535 است، Y می‌تواند حذف شود یا بین 1 و 255 باشد، و Z می‌تواند حذف شود یا بین 1 و 255 باشد. در صورت عدم تعیین، این مقدار برابر با $SHLIBVERSION تنظیم خواهد شد.

اگر $APPLELINK_NO_CURRENT_VERSION تنظیم شده باشد، هیچ -current_version در خروجی قرار نخواهد گرفت.

برای جزئیات بیشتر به صفحه راهنمای ld در MacOS مراجعه کنید.

این متغیر بر $APPLELINK_COMPATIBILITY_VERSION اولویت دارد.

این متغیر بر $APPLELINK_CURRENT_VERSION اولویت دارد.

سازنده Package را ببینید.

فهرستی پیش‌فرض و وابسته به پلتفرم از سازنده‌ها مانند Program، Library و غیره، هنگام مقداردهی اولیهٔ محیط ساخت بر اساس وجود یا عدم وجود ابزارهایی که این سازنده‌ها به آن‌ها وابسته‌اند، برای مقداردهی به این متغیر ساخت استفاده می‌شود. $BUILDERS می‌تواند بررسی شود تا مشخص گردد کدام سازنده‌ها در زمان اجرا واقعاً در دسترس خواهند بود.

توجه داشته باشید که اگر این متغیر ساخت را هنگام ایجاد محیط ساخت از طریق انتساب مقداردهی اولیه کنید، آن مقدار برای $BUILDERS جایگزین مقادیر پیش‌فرض خواهد شد:

bld = Builder(action='foobuild < $SOURCE > $TARGET')
env = Environment(BUILDERS={'NewBuilder': bld})

برای استفاده از یک شیء Builder جدید در کنار سازنده‌های پیش‌فرض، شیء Builder جدید خود را به این صورت اضافه کنید:

env = Environment()
env.Append(BUILDERS={'NewBuilder': bld})

یا به این صورت:

env = Environment()
env['BUILDERS']['NewBuilder'] = bld

این متغیر فقط توسط کامپایلرهایی که از این قابلیت پشتیبانی می‌کنند تنظیم می‌شود. (در حال حاضر gcc، clang و msvc)

گزینه کامپایلر Microsoft Visual C++ که SCons به‌طور پیش‌فرض برای تولید اطلاعات PDB استفاده می‌کند، /Z7 است. این گزینه به‌درستی با ساخت‌های موازی (-j) کار می‌کند زیرا اطلاعات اشکال‌زدایی را در فایل‌های شیء واسط جاسازی می‌کند، بر خلاف به اشتراک گذاشتن یک فایل PDB واحد بین چندین فایل شیء. این همچنین تنها روش برای جاسازی اطلاعات اشکال‌زدایی در یک کتابخانه استاتیک است. استفاده از /Zi در عوض ممکن است کارایی زمان پیوند را بهبود بخشد، هرچند ساخت‌های موازی دیگر کار نخواهند کرد.

می‌توانید با بازنویسی متغیر پیش‌فرض $CCPDBFLAGS به صورت زیر، فایل‌های PDB را با سوئیچ /Zi تولید کنید:

env['CCPDBFLAGS'] = ['${(PDB and "/Zi /Fd%s" % File(PDB)) or ""}']

یک راهکار جایگزین، استفاده از /Zi برای قرار دادن اطلاعات اشکال‌زدایی در یک فایل .pdb جداگانه برای هر فایل شیء از طریق بازنویسی متغیر $CCPDBFLAGS به صورت زیر است:

env['CCPDBFLAGS'] = '/Zi /Fd${TARGET}.pdb'

سازنده Package را ببینید.

سازنده Package را ببینید.

مقدار پیش‌فرض یک رشتهٔ خالی '' است که فیلتر کردن را غیرفعال می‌کند.

مقدار پیش‌فرض False است (استفاده از مسیرهای نسبی).

اگر دایرکتوری‌های گونه (variant directories) در حال استفاده باشند و نتایج بررسی configure نباید بین گونه‌ها به اشتراک گذاشته شوند، می‌توانید $CONFIGUREDIR و $CONFIGURELOG را طوری تنظیم کنید که به ازای هر دایرکتوری گونه یکتا باشند.

اگر دایرکتوری‌های گونه در حال استفاده باشند و نتایج بررسی configure نباید بین گونه‌ها به اشتراک گذاشته شوند، می‌توانید $CONFIGUREDIR و $CONFIGURELOG را طوری تنظیم کنید که به ازای هر دایرکتوری گونه یکتا باشند.

# Adds -Dxyz to POSIX compiler command lines,
# and /Dxyz to Microsoft Visual C++ command lines.
env = Environment(CPPDEFINES='xyz')

# Adds -DB=2 -DA to POSIX compiler command lines,
# and /DB=2 /DA to Microsoft Visual C++ command lines.
env = Environment(CPPDEFINES=[('B', 2), 'A'])

# Adds -DA -DB=2 to POSIX compiler command lines,
# or /DA /DB=2 to Microsoft Visual C++ command lines.
env = Environment(CPPDEFINES={'B':2, 'A':None})

بسته به نحوهٔ افزودن محتویات به $CPPDEFINES، ممکن است به یک نوع مرکب تبدیل شود؛ برای نمونه فهرستی حاوی رشته‌ها، چندتایی‌ها و/یا فرهنگ‌لغت‌ها. SCons می‌تواند چنین نوع مرکبی را به‌درستی بسط دهد.

توجه داشته باشید که SCons ممکن است کامپایلر را از طریق یک شل فراخوانی کند. اگر تعریف یک ماکرو حاوی نویسه‌هایی مانند فاصله‌ها باشد که برای شل معنای خاصی دارند، یا در نظر باشد که یک مقدار رشته‌ای باشد، ممکن است لازم باشد از نحو نقل‌قول (quoting) شل استفاده کنید تا پیش از دیده‌شدن توسط پیش‌پردازنده، توسط شل تفسیر نشود. ماکروهای تابع‌گونه (function-like) از طریق این سازوکار پشتیبانی نمی‌شوند (و برخی کامپایلرها حتی چنین قابلیتی را از طریق خط فرمان پیاده‌سازی نمی‌کنند). هنگام استفاده از نقل‌قول، توجه داشته باشید که یک جفت نویسهٔ نقل‌قول برای تعریف یک رشته در Python استفاده می‌شود و نقل‌قول‌های جاسازی‌شده در درون آن، مگر اینکه گریز داده شده باشند (escaped)، توسط شل مصرف خواهند شد. این مثال‌ها ممکن است به درک موضوع کمک کنند:

env = Environment(CPPDEFINES=['USE_ALT_HEADER=\\"foo_alt.h\\"'])
env = Environment(CPPDEFINES=[('USE_ALT_HEADER', '\\"foo_alt.h\\"')])

:تغییریافته در نسخهٔ 4.5: SCons دیگر مقادیر $CPPDEFINES که در قالب فرهنگ‌لغت وارد شده‌اند را مرتب‌سازی نمی‌کند. Python اکنون کلیدهای فرهنگ‌لغت را به ترتیبی که وارد شده‌اند نگه‌داری می‌کند، بنابراین برای تضمین یک خط فرمان پایدار دیگر نیازی به مرتب‌سازی آن‌ها نیست.

نکته: نام‌های دایرکتوری در $CPPPATH هنگامی که در یک دستور به کار می‌روند، نسبت به دایرکتوری فایل SConscript جستجو خواهند شد. برای وادار کردن scons به جستجوی یک دایرکتوری نسبت به ریشهٔ درخت منبع، از پیشوند # استفاده کنید:

env = Environment(CPPPATH='#/include')

همچنین می‌توان جستجوی دایرکتوری را با استفاده از تابع Dir اجبار کرد:

include = Dir('include')
env = Environment(CPPPATH=include)

فهرست دایرکتوری‌ها از طریق متغیر ساخت تولیدشده به‌طور خودکارِ $_CPPINCFLAGS به خطوط فرمان اضافه می‌شود؛ این متغیر با افزودن مقادیر متغیرهای ساخت $INCPREFIX و $INCSUFFIX به ترتیب به ابتدا و انتهای هر دایرکتوری در $CPPPATH ساخته می‌شود. هر خط فرمانی که تعریف می‌کنید و به فهرست دایرکتوری‌های $CPPPATH نیاز دارد باید شامل $_CPPINCFLAGS باشد:

env = Environment(CCCOM="my_compiler $_CPPINCFLAGS -c -o $TARGET $SOURCE")

سازنده Package را ببینید.

سازنده Package را ببینید.

توجه داشته باشید که به‌طور پیش‌فرض، SCons محیط فعال در زمان اجرای scons («محیط شل») را به محیط اجرا منتقل نمی‌کند. این امر بدان جهت است که صرف‌نظر از متغیرهای محیطی تنظیم‌شده در زمان فراخوانی scons، تکرارپذیری ساخت تضمین شود. اگر می‌خواهید متغیری از محیط شل را به دستورهای اجراشده برای ساخت فایل‌های هدف منتقل کنید، باید صریحاً این کار را انجام دهید. یک مثال متداول، متغیر محیطی سیستمی PATH است تا scons بتواند برنامه‌ها و ابزارها را همانند شل فراخوان (یا فرآیندهای دیگر) پیدا کند:

import os
env = Environment(ENV={'PATH': os.environ['PATH']})

هرچند معمولاً توصیه نمی‌شود، اما می‌توانید کل محیط شل را یک‌باره منتقل کنید:

import os
env = Environment(ENV=os.environ.copy())

env = Environment(F03PATH='#/include')

جستجوی دایرکتوری را می‌توان با استفاده از تابع Dir() نیز اجبار کرد:

include = Dir('include')
env = Environment(F03PATH=include)

فهرست دایرکتوری‌ها از طریق متغیر ساخت خودکار تولیدشده‌ی $_F03INCFLAGS به خطوط فرمان افزوده خواهد شد، که با الحاق مقادیر متغیرهای ساخت $INCPREFIX و $INCSUFFIX به ابتدا و انتهای هر دایرکتوری در $F03PATH ساخته می‌شود. هر خط فرمانی که تعریف می‌کنید و به فهرست دایرکتوری F03PATH نیاز دارد، باید شامل $_F03INCFLAGS باشد:

env = Environment(F03COM="my_compiler $_F03INCFLAGS -c -o $TARGET $SOURCE")

env = Environment(F08PATH='#/include')

جستجوی دایرکتوری همچنین می‌تواند با استفاده از تابع Dir() اجبار شود:

include = Dir('include')
env = Environment(F08PATH=include)

فهرست دایرکتوری‌ها از طریق متغیر ساخت خودکار تولیدشده‌ی $_F08INCFLAGS به خطوط دستور اضافه خواهد شد؛ این متغیر با افزودن مقادیر متغیرهای ساخت $INCPREFIX و $INCSUFFIX به ابتدا و انتهای هر دایرکتوری در $F08PATH ساخته می‌شود. هر خط دستوری که تعریف می‌کنید و به فهرست دایرکتوری‌های F08PATH نیاز دارد، باید شامل $_F08INCFLAGS باشد:

env = Environment(F08COM="my_compiler $_F08INCFLAGS -c -o $TARGET $SOURCE")

env = Environment(F77PATH='#/include')

جستجوی دایرکتوری همچنین می‌تواند با استفاده از تابع Dir() اجبار شود:

include = Dir('include')
env = Environment(F77PATH=include)

فهرست دایرکتوری‌ها از طریق متغیر ساخت خودکار تولیدشده‌ی $_F77INCFLAGS به خطوط دستور اضافه خواهد شد؛ این متغیر با افزودن مقادیر متغیرهای ساخت $INCPREFIX و $INCSUFFIX به ابتدا و انتهای هر دایرکتوری در $F77PATH ساخته می‌شود. هر خط دستوری که تعریف می‌کنید و به فهرست دایرکتوری‌های F77PATH نیاز دارد، باید شامل $_F77INCFLAGS باشد:

env = Environment(F77COM="my_compiler $_F77INCFLAGS -c -o $TARGET $SOURCE")

env = Environment(F90PATH='#/include')

همچنین جستجوی دایرکتوری می‌تواند با استفاده از تابع Dir() اجبار شود:

include = Dir('include')
env = Environment(F90PATH=include)

فهرست دایرکتوری‌ها از طریق متغیر ساخت خودکار ایجاد‌شده $_F90INCFLAGS به خطوط فرمان اضافه می‌شود؛ متغیری که با الصاق مقادیر متغیرهای ساخت $INCPREFIX و $INCSUFFIX به ابتدا و انتهای هر دایرکتوری در $F90PATH ساخته می‌شود. هر خط فرمانی که تعریف می‌کنید و به فهرست دایرکتوری F90PATH نیاز دارد باید شامل $_F90INCFLAGS باشد:

env = Environment(F90COM="my_compiler $_F90INCFLAGS -c -o $TARGET $SOURCE")

env = Environment(F95PATH='#/include')

همچنین می‌توان جستجوی دایرکتوری را با استفاده از تابع Dir() اجبار کرد:

include = Dir('include')
env = Environment(F95PATH=include)

فهرست دایرکتوری‌ها از طریق متغیر ساخت به‌طور خودکار تولید شده‌ی $_F95INCFLAGS به خطوط فرمان اضافه خواهد شد که با الحاق مقادیر متغیرهای ساخت $INCPREFIX و $INCSUFFIX به ابتدا و انتهای هر دایرکتوری در $F95PATH ساخته می‌شود. هر خط فرمانی که تعریف می‌کنید و به فهرست دایرکتوری‌های F95PATH نیاز دارد باید شامل $_F95INCFLAGS باشد:

env = Environment(F95COM="my_compiler $_F95INCFLAGS -c -o $TARGET $SOURCE")

جدید در نگارش 4.5.0.

جدید در نگارش 4.4.

env = Environment(FORTRANPATH='#/include')

جستجوی دایرکتوری را می‌توان با استفاده از تابع Dir() نیز اجبار کرد:

include = Dir('include')
env = Environment(FORTRANPATH=include)

فهرست دایرکتوری‌ها از طریق متغیر ساخت تولیدشده به صورت خودکار $_FORTRANINCFLAGS به خطوط فرمان اضافه خواهد شد؛ این متغیر با افزودن مقادیر متغیرهای ساخت $INCPREFIX و $INCSUFFIX به ترتیب به ابتدا و انتهای هر دایرکتوری در $FORTRANPATH ساخته می‌شود. هر خط فرمانی که تعریف می‌کنید و به فهرست دایرکتوری‌های FORTRANPATH نیاز دارد، باید شامل $_FORTRANINCFLAGS باشد:

env = Environment(FORTRANCOM="my_compiler $_FORTRANINCFLAGS -c -o $TARGET $SOURCE")

env.AppendUnique(FRAMEWORKPATH='#myframeworkdir')

عبارت

... -Fmyframeworkdir

را به خطوط فرمان کامپایلر و پیونددهنده اضافه خواهد کرد.

در پلتفرم win32، اگر کامپایلر Microsoft Visual C++ در دسترس باشد، راه‌اندازی ابزار msvc با استفاده از $HOST_ARCH و $TARGET_ARCH انجام می‌شود. تغییر دادن این مقادیر در زمان‌های بعدی باعث مقداردهی اولیه مجدد ابزار نخواهد شد. مقادیر معتبر معماری میزبان عبارتند از x86 و arm برای میزبان‌های ۳۲ بیتی، و amd64، arm64 و x86_64 برای میزبان‌های ۶۴ بیتی.

باید تغییرناپذیر در نظر گرفته شود. $HOST_ARCH در حال حاضر توسط سایر پلتفرم‌ها استفاده نمی‌شود، اما این گزینه برای استفاده در آینده محفوظ است.

باید تغییرناپذیر در نظر گرفته شود. $HOST_OS در حال حاضر توسط SCons استفاده نمی‌شود، اما این گزینه برای استفاده در آینده محفوظ است.

اگر $IMPLICIT_COMMAND_DEPENDENCIES روی یک مقدار نادرست ("none" یا "false" یا "no" یا "off" یا "0" یا عدد صحیح 0) تنظیم شود، هیچ وابستگی ضمنی از رشته‌های کنش اضافه نمی‌شود. اگر روی یک مقدار عددی صحیح بزرگتر از 1 یا روی "all" تنظیم شود، آرگومان‌های خط فرمان اضافی بررسی می‌شوند. مقدار عددی N تعداد N آرگومان اول را بررسی می‌کند، در حالی که "all" تمام آرگومان‌ها را بررسی می‌کند. یک آرگومان بررسی‌شده فراتر از آرگومان نخست، در صورتی که یک مسیر مطلق باشد یا به فایلی موجود در سیستم فایل اشاره کند، به عنوان یک وابستگی افزوده می‌شود؛ برخلاف نخستین آرگومان، این آرگومان‌های اضافی با استفاده از مسیر جستجوی محیط اجرا جستجو نمی‌شوند. با سایر مقادیر $IMPLICIT_COMMAND_DEPENDENCIES مانند حالت پیش‌فرض رفتار می‌شود. مقدار $IMPLICIT_COMMAND_DEPENDENCIES پیش از استفاده مشمول جایگزینی است، بنابراین می‌تواند شامل ارجاعی به یک متغیر ساخت باشد.

رشته‌های کنش ممکن است با یک عملگر AND منطقی (&&) بخش‌بندی شده باشند، که نشان می‌دهد هر بخش به صورت ترتیبی اجرا می‌شود، اما تنها در صورتی که بخش قبلی با موفقیت به پایان رسیده باشد. اگر $IMPLICIT_COMMAND_DEPENDENCIES روی "all" یا یک عدد صحیح بزرگتر از 1 تنظیم شده باشد، هر بخش برای محاسبهٔ وابستگی‌ها به عنوان یک خط فرمان مجزا در نظر گرفته می‌شود؛ در غیر این صورت، تنها بخش نخست بررسی می‌شود.

def install(dest, source, env):

dest نام مسیر فایل مقصد است. source نام مسیر فایل منبع است. env محیط ساخت (دیکشنری‌ای از مقادیر ساخت) است که برای نصب این فایل اعمال می‌شود.

این مقدار از طریق گزینه -bootclasspath به خطوط فرمان JDK اضافه خواهد شد، که نیازمند جداکننده مسیر جستجوی وابسته به سیستم است. در صورتی که $JAVABOOTCLASSPATH به صورت فهرست ارائه شده باشد، این مقدار در صورت نیاز هنگام ساخت خط فرمان توسط SCons تأمین خواهد شد. اگر $JAVABOOTCLASSPATH یک رشته منفرد حاوی نویسه‌های جداکننده مسیر جستجو باشد (: برای سیستم‌های POSIX یا ; برای Windows)، اصلاح نخواهد شد؛ و از این رو ذاتاً وابسته به سیستم است؛ برای ارائه مسیر به روشی مستقل از سیستم، در عوض $JAVABOOTCLASSPATH را به صورت فهرستی از مسیرها مشخص کنید.

این مقدار از طریق گزینه -classpath به خطوط فرمان JDK افزوده خواهد شد، که نیازمند جداکننده مسیر جستجوی مختص به سیستم است. این مورد در صورت نیاز توسط SCons هنگام ساخت خط فرمان، در صورتی که $JAVACLASSPATH به شکل فهرست ارائه شده باشد، تأمین می‌شود. اگر $JAVACLASSPATH یک رشته تکی حاوی نویسه‌های جداکننده مسیر جستجو (: برای سیستم‌های POSIX یا ; برای Windows) باشد، به منظور پایش وابستگی‌ها بر اساس جداکننده به فهرستی از مسیرهای مجزا تقسیم می‌شود. این رشته برای استفاده در خط فرمان JDK تغییر نخواهد کرد، بنابراین چنین رشته‌ای ذاتا وابسته به سیستم است؛ برای مشخص کردن مسیر به روشی مستقل از سیستم، به جای آن $JAVACLASSPATH را به صورت فهرستی از مسیرها ارائه دهید.

این مقدار از طریق گزینه -processorpath به خطوط فرمان JDK افزوده خواهد شد، که نیازمند جداکننده مسیر جستجوی مختص به سیستم است. این مورد در صورت نیاز توسط SCons هنگام ساخت خط فرمان، در صورتی که $JAVAPROCESSORPATH به صورت فهرست ارائه شده باشد، تأمین می‌شود. اگر $JAVAPROCESSORPATH یک رشته تکی حاوی نویسه‌های جداکننده مسیر جستجو (: برای سیستم‌های POSIX یا ; برای Windows) باشد، تغییر داده نخواهد شد؛ بنابراین ذاتا وابسته به سیستم است؛ برای تعیین مسیر به روشی مستقل از سیستم، به جای آن $JAVAPROCESSORPATH را به صورت فهرستی از مسیرها ارائه دهید.

جدید در نسخه 4.5.0

این مقدار از طریق گزینه -sourcepath به خطوط فرمان JDK اضافه خواهد شد، که نیازمند یک جداکننده مسیر جستجوی مختص به سیستم است. این مورد در صورت نیاز توسط SCons هنگام ایجاد خط فرمان، در صورتی که $JAVASOURCEPATH به صورت فهرست ارائه شده باشد، تأمین می‌شود. اگر $JAVASOURCEPATH یک رشته تکی حاوی نویسه‌های جداکننده مسیر جستجو (: برای سیستم‌های POSIX یا ; برای Windows) باشد، تغییر نخواهد کرد و در نتیجه ذاتا وابسته به سیستم است؛ برای ارائه مسیر به شیوه‌ای مستقل از سیستم، به جای آن $JAVASOURCEPATH را به صورت فهرستی از مسیرها تعیین کنید.

توجه داشته باشید که دایرکتوری‌های مشخص‌شده تنها از طریق گزینه -sourcepath به خط فرمان افزوده می‌شوند. SCons در حال حاضر دایرکتوری‌های $JAVASOURCEPATH را برای فایل‌های وابسته .java جستجو نمی‌کند.

اگرچه این متغیر در درجه اول برای انتخاب یک نسخه از کامپایلر Java در برابر نسخه‌ای دیگر در نظر گرفته نشده است، اما در بستر Windows چنین تأثیری دارد. رویکرد دقیق‌تر این است که در صورتی که کامپایلر مد نظر شما کامپایلر پیش‌فرض نیست، $JAVAC (و متغیرهای ساخت مربوطه برای ابزارهای مرتبط) را روی مسیر کامپایلر Java خاصی که می‌خواهید تنظیم کنید. در بسترهای غیر از Windows، سامانهٔ alternatives ممکن است روشی برای تنظیم کامپایلر پیش‌فرض Java بدون نیاز به مشخص کردن صریح مسیرها فراهم کند.