Coder Social home page Coder Social logo

scons / scons Goto Github PK

View Code? Open in Web Editor NEW
1.9K 63.0 309.0 23.34 MB

SCons - a software construction tool

Home Page: http://scons.org

License: MIT License

Python 87.54% Shell 0.49% Makefile 0.07% HTML 8.56% CSS 0.19% Ruby 0.11% Perl 0.31% JavaScript 2.24% Java 0.11% Batchfile 0.07% C 0.06% C++ 0.02% D 0.04% Yacc 0.01% Roff 0.01% Fortran 0.03% PowerShell 0.02% Dockerfile 0.03% XSLT 0.07% Lex 0.01%
build-tool python3 python-3-5 python-3-6 scons python37 python38 build-automation build-tools

scons's Introduction

SCons - a Software Construction Tool

IRC

Sourceforge Monthly Downloads

Sourceforge Total Downloads

Travis CI build status

AppVeyor CI build Status

CodeCov Coverage Status

Github Actions

What is SCons?

SCons is an Open Source software construction tool which orchestrates the construction of software (and other tangible products such as documentation files) by determining which component pieces must be built or rebuilt and invoking the necessary commands to build them.

Features:

  • Configuration files are Python scripts -use the power of a real programming language to solve build problems; no complex domain-specific language to learn.
  • Reliable, automatic dependency analysis built-in for C, C++ and FORTRAN. No more "make depend" or "make clean" to get all of the dependencies. Dependency analysis is easily extensible through user-defined dependency Scanners for other languages or file types.
  • Built-in support for C, C++, D, Java, FORTRAN, Yacc, Lex, Qt and SWIG, and building TeX and LaTeX documents. Easily extensible through user-defined Builders for other languages or file types.
  • Building from central repositories of source code and/or pre-built targets.
  • Built-in support for Microsoft Visual Studio, including generation of .dsp, .dsw, .sln and .vcproj files.
  • Reliable detection of build changes using cryptographic hashes; optionally can configure other algorithms including traditional timestamps.
  • Support for parallel builds - can keep multiple jobs running simultaneously regardless of directory hierarchy.
  • Integrated Autoconf-like support for finding #include files, libraries, functions and typedefs.
  • Global view of all dependencies - no more multiple build passes or reordering targets to build everything.
  • Ability to share built files in a cache to speed up multiple builds.
  • Designed from the ground up for cross-platform builds, and known to work on Linux, other POSIX systems (including AIX, BSD systems, HP/UX, IRIX and Solaris), Windows 7/8/10, MacOS, and OS/2.
  • Written in Python.

Documentation

Documentation for SCons is available at http://www.scons.org/documentation.html.

Latest Version

If you already have SCons installed, you can check that the package you have is the latest version at the SCons download page.

Execution Requirements

Running SCons requires Python 3.6 or higher. There should be no other dependencies or requirements to run standard SCons. The last release to support Python 3.5 was 4.2.0.

Some experimental features may require additional Python packages to be installed - at the moment the Ninja feature requires the supporting ninja package.

The default SCons configuration assumes use of the Microsoft Visual C++ compiler suite on Win32 systems, and assumes a C compiler named cc, a C++ compiler named c++, and a FORTRAN compiler named gfortran (such as found in the GNU Compiler Collection) on any other type of system. You may override these default values by appropriate configuration of variables in a Construction Environment, or in the case of Cygwin on a Win32 system, by selecting the 'cygwin' platform, which will set some of those Construction Variables for you.

By default, SCons knows how to search for available programming tools on various systems - see the SCons man page for details. You can override the default SCons choices made by appropriate configuration of construction variables.

Installation Requirements

SCons has no installation dependencies beyond a compatible version of Python. The tools which will be used to actually construct the project, such as compilers, documentation production tools, etc. should of course be installed by the appropriate means.

Installation

The preferred way to install SCons is through the Python installer, pip (or equivalent alternatives, such as the Anaconda installer, conda). You can install either from a wheel package or from the source directory. To work on a project that builds using SCons, installation lets you just use scons as a command and not worry about things. In this case, we usually suggest using a virtualenv, to isolate the Python environment to that project (some notes on that: Python Packaging User Guide: Creating and using virtual environments).

Some installation examples:

# to do a system-level install:
$ python -m pip install --user scons

# Windows variant, assuming Python Launcher:
C:\Users\me> py -m pip install --user scons

# inside a virtualenv it's safe to use bare pip:
(myvenv) $ pip install scons

# install in a virtualenv from a wheel file:
(myvenv) $ pip install SCons-4.3.0-py3-none-any.whl

# install in a virtualenv from source directory:
(myvenv) $ pip install --editable .

Note that on Windows, SCons installed via pip puts an executable scons.exe in the script directory of the Python installation, or in a shadow script directory if you did a User Install. To run scons as a command, you'll need this in your search path.

Fortunately, pip will warn you about this - pay attention to any messages during installation like this:

WARNING: The scripts scons-configure-cache.exe, scons.exe and sconsign.exe
are installed in 'C:\Users\me\AppData\Roaming\Python\Python310\Scripts'
which is not on PATH.
Consider adding this directory to PATH or, if you prefer to suppress this warning,
use --no-warn-script-location.

If you are running on a system which uses a package manager (for example most Linux distributions), you may, at your option, use the package manager (e.g. apt, dnf, yum, zypper, brew, pacman etc.) to install a version of SCons. Some distributions keep up to date with SCons releases very quickly, while others may delay, so the version of SCons you want to run may factor into your choice.

Getting Started Using SCons

If you're new to SCons, the first couple of chapters of the SCons User Guide provide an excellent starting spot.

Contributing to SCons

Please see CONTRIBUTING.rst

License

SCons is distributed under the MIT license, a full copy of which is available in the LICENSE file.

Reporting Bugs

The SCons project welcomes bug reports and feature requests.

Please make sure you send email with the problem or feature request to the SCons users mailing list, which you can join at https://two.pairlist.net/mailman/listinfo/scons-users, or on the SCons Discord server in #scons-help.

Once you have discussed your issue on the users mailing list and the community has confirmed that it is either a new bug or a duplicate of an existing bug, then please follow the instructions the community provides (including the issue template presented by GitHub) to file a new bug or to add yourself to the CC list for an existing bug.

You can explore the list of existing bugs, which may include workarounds for the problem you've run into, on the GitHub issue tracker.

Bug-fix Policy

At this time, the application of bug-fix pull requests normally happens at the head of the main branch. In other words fixes are likely to appear in the next regular release and there probably won't be a bugfix update to a past release. Consumers are of course free to internally maintain releases on their own by taking submitted patches and applying them.

Mailing Lists and Other Contacts

In addition to the scons-users list, an active mailing list for developers of SCons is available. You may send questions or comments to the list at [email protected].

You may subscribe to the developer's mailing list using the form at https://two.pairlist.net/mailman/listinfo/scons-dev. The same page contains archives of past postings.

Subscription to the developer's mailing list is by approval. In practice, no one is refused list membership, but we reserve the right to limit membership in the future and/or weed out lurkers.

There are other ways to contact the SCons community. An active Discord server is the most direct. The server includes a channel for code notifications and other GitHub events (#github-update), if those are of interest. See the website for more contact information: https://scons.org/contact.html.

Donations

If you find SCons helpful, please consider making a donation (of cash, software, or hardware) to support continued work on the project. Information is available at https://www.scons.org/donate.html or the GitHub Sponsors button on https://github.com/scons/scons.

Reproducible Builds

In order to suppor those users who which to produce reproducible builds (https://reproducible-builds.org/specs/source-date-epoch/) we're now including logic to force SCons to propagate SOURCE_DATE_EPOCH from your shell environment for all SCons builds to support reproducible builds we're now providing an example site_init.py and a script to install it in your ~/.scons. See packaging/etc/README.txt for more info

For More Information

Check the SCons web site at https://www.scons.org/

Author Info

SCons was originally written by Steven Knight, knight at baldmt dot com. Since around 2010 it has been maintained by the SCons development team, co-managed by Bill Deegan and Gary Oberbrunner, with many contributors, including but not at all limited to:

  • Chad Austin
  • Dirk Baechle
  • Charles Crain
  • William Deegan
  • Steve Leblanc
  • Rob Managan
  • Greg Noel
  • Gary Oberbrunner
  • Anthony Roach
  • Greg Spencer
  • Tom Tanner
  • Anatoly Techtonik
  • Christoph Wiedemann
  • Russel Winder
  • Mats Wichmann

... and many others.

Copyright (c) 2001 - 2024 The SCons Foundation

scons's People

Contributors

abitrolly avatar acmorrow avatar ajf58 avatar alexibu avatar bdbaddog avatar chasinglogic avatar cournape avatar dholth avatar dirkbaechle avatar dmoody256 avatar garyo avatar gauravjuvekar avatar grossag avatar hecatron avatar iesmat avatar ivankravets avatar jcassagnol-public avatar jcbrill avatar maiphi avatar managan avatar mwichmann avatar ptomulik avatar rodrigc avatar russel avatar stengruener avatar stevenknight avatar techtonik avatar thosrtanner avatar userzimmermann avatar williamblevins avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

scons's Issues

Add -o support.

This issue was originally created at: 2001-09-23 22:00:00.
This issue was reported by: stevenknight.
stevenknight said at 2001-09-23 22:00:00

Don't rebuild a file even if it needs it.

issues@scons said at 2001-09-23 22:00:00

Converted from SourceForge task item 39023

Windows NT portability.

This issue was originally created at: 2001-09-30 22:00:00.
This issue was reported by: stevenknight.
stevenknight said at 2001-09-30 22:00:00

Tests and other things.

issues@scons said at 2001-09-30 22:00:00

Converted from SourceForge task item 39578

stevenknight said at 2006-05-20 20:54:39

No white space in keyword.

Add Library() method.

This issue was originally created at: 2001-09-23 22:00:00.
This issue was reported by: stevenknight.
stevenknight said at 2001-09-23 22:00:00

A test prototype already exists in test/Library.py.

issues@scons said at 2001-09-23 22:00:00

Converted from SourceForge task item 38980

stevenknight said at 2006-05-20 20:53:26

No white space in keyword.

Handle multi-line build commands

This issue was originally created at: 2001-09-24 22:00:00.
This issue was reported by: stevenknight.
stevenknight said at 2001-09-24 22:00:00

Make sure processing stops if one of the commands returns error.

issues@scons said at 2001-09-24 22:00:00

Converted from SourceForge task item 39201

stevenknight said at 2006-05-20 20:53:50

No white space in keyword.

Add -[rR] support

This issue was originally created at: 2001-09-23 22:00:00.
This issue was reported by: stevenknight.
stevenknight said at 2001-09-23 22:00:00

Clear out (don't use) default environment/objects. These meant different things to Gnu Make, but they're probably the same for us. Or should we separate them somehow?

issues@scons said at 2001-09-23 22:00:00

Converted from SourceForge task item 39026

SCONS_LIB_DIR doesn't work

This issue was originally created at: 2001-12-16 17:25:56.
This issue was reported by: aroach.
aroach said at 2001-12-16 17:25:56

This is a really stupid bug in scons.py. I should have
added a test for this.

issues@scons said at 2001-12-16 17:25:56

Converted from SourceForge tracker item 494036

gregnoel said at 2008-03-18 03:51:18

Change anthonyroach to aroach. Are you still out there?

gregnoel said at 2008-03-18 04:59:27

Gack! Changing the name shouldn't have changed the status!

gregnoel said at 2008-03-18 05:05:24

Gack! Changing the name shouldn't have changed the status!

Default() doesn't work with subdirs

This issue was originally created at: 2001-12-16 18:27:35.
This issue was reported by: aroach.
aroach said at 2001-12-16 18:27:35

Peter Haight says that Default() work right with
relative paths when called from a SConscript in a
sub-directory.

issues@scons said at 2001-12-16 18:27:35

Converted from SourceForge tracker item 494049

Support LIBS

This issue was originally created at: 2001-09-23 22:00:00.
This issue was reported by: stevenknight.
stevenknight said at 2001-09-23 22:00:00

Support specification of libraries with which we'll link Program() files in a LIBS construction variable.

issues@scons said at 2001-09-23 22:00:00

Converted from SourceForge task item 38995

stevenknight said at 2006-05-20 20:52:43

No white space in keyword.

Handle (sub)directories as targets.

This issue was originally created at: 2001-09-23 22:00:00.
This issue was reported by: stevenknight.
stevenknight said at 2001-09-23 22:00:00

From email from Knight, 24 Sept 2001:

Vague outline: A directory's entries should probably be entries in the sources[] attribute. Or better yet, turn that attribute into a _sources[] attribute, and use an accessor sources() method to get at it. The the Dir class can override sources() to just return its entries[] (minus '.' and '..').

A directory should always be "out of date" so that we always descend the tree and try to build the entries therein. I think this could be done by never giving it a real value for its signature, in which case the collected signatures of its entries would always be non-null and indicate the directory would need to be "rebuilt," but not before we've built its "source" entires.

The actual directory builder, then, would be just an internal do-nothing builder that updates status to indicate the directory has now been "built" (that is, all of its entries have been built).

A directory should never have a signature written to a .sconsign file.

issues@scons said at 2001-09-23 22:00:00

Converted from SourceForge task item 38970

stevenknight said at 2006-05-20 20:52:55

No white space in keyword.

Default() doesn't accept a node

This issue was originally created at: 2001-12-16 17:20:17.
This issue was reported by: aroach.
aroach said at 2001-12-16 17:20:17

Default() should take a node, which would allow this:

env = Environment()
Default(env.Program('foo', 'foo.c'))

which would make platform independant default targets
easy to use.

issues@scons said at 2001-12-16 17:20:17

Converted from SourceForge tracker item 494033

gregnoel said at 2008-03-18 03:51:23

Change anthonyroach to aroach. Are you still out there?

gregnoel said at 2008-03-18 04:59:28

Gack! Changing the name shouldn't have changed the status!

gregnoel said at 2008-03-18 05:05:26

Gack! Changing the name shouldn't have changed the status!

Add --write-filenames

This issue was originally created at: 2001-09-23 22:00:00.
This issue was reported by: stevenknight.
stevenknight said at 2001-09-23 22:00:00

This is a Cons classic option that we might not need if we have other, more GNU-like ways to do the same thing.

issues@scons said at 2001-09-23 22:00:00

Converted from SourceForge task item 39030

Add man pages to Debian package.

This issue was originally created at: 2001-10-05 22:00:00.
This issue was reported by: stevenknight.
stevenknight said at 2001-10-05 22:00:00

Generate them with jw -b man

issues@scons said at 2001-10-05 22:00:00

Converted from SourceForge task item 39900

stevenknight said at 2006-05-20 20:54:52

No white space in keyword.

CPPPATH not in man page

This issue was originally created at: 2001-12-14 15:59:08.
This issue was reported by: stevenknight.
stevenknight said at 2001-12-14 15:59:08

From Stephen Kennedy:

I ran into a few gotchas when trying it on some of our
projects:
(is the sourceforge bug tracker being used? there were
zero bugs entered)

  • if the include path is set through CXXFLAGS instead
    of
    CPPPATH (not in the man page!) then dependency
    generation
    silently fails. (i.e. foo.o only depends on foo.cpp)

steve9000 said at 2001-12-14 17:25:17

Also perhaps it should be an error for an include switch
to be specified in CXXFLAGS.

I'd suggest that all variables which are created from
other variables have some kind of checking to ensure
that each part comes from the correct source.

stevenknight said at 2001-12-16 20:31:42

Steve9000--

The problem I see with trying to warn about this is that
whether or not a given flag should come from one variable or
another depends on the compiler being used. Complaining
about someone specifying '-Ifoo' in CXXFLAGS isn't
Builder-specific, it's specific to that fact that the $CXX
variable happens to be 'gcc'. Someone using Microsoft VC++
would have to have a different check.

I agree that warnings would be useful, though, so I'm going
to add a TODO item to track whether or not we can think of
some way to generalize this. If you have any suggestions,
I'm all ears.

issues@scons said at 2001-12-16 20:31:42

Converted from SourceForge tracker item 493515

gregnoel said at 2008-03-18 03:51:23

Change anthonyroach to aroach. Are you still out there?

gregnoel said at 2008-03-18 04:59:28

Gack! Changing the name shouldn't have changed the status!

gregnoel said at 2008-03-18 05:05:26

Gack! Changing the name shouldn't have changed the status!

Repository support

This issue was originally created at: 2001-09-23 22:00:00.
This issue was reported by: stevenknight.
stevenknight said at 2001-09-23 22:00:00

Add support for the Repository() method and the -Y command-line option.

issues@scons said at 2001-09-23 22:00:00

Converted from SourceForge task item 39012

Microsoft Visual C++ compiler support

This issue was originally created at: 2001-09-23 22:00:00.
This issue was reported by: stevenknight.
stevenknight said at 2001-09-23 22:00:00

Pick up all the grungy registry logic that we'll need to make this transparent from distutils.

issues@scons said at 2001-09-23 22:00:00

Converted from SourceForge task item 39033

I18N

This issue was originally created at: 2001-09-23 22:00:00.
This issue was reported by: stevenknight.
stevenknight said at 2001-09-23 22:00:00

Use GNU gettext to put in the infrastructure for multiple-language support earlier rather than later.

issues@scons said at 2001-09-23 22:00:00

Converted from SourceForge task item 39008

BuildDir support

This issue was originally created at: 2001-09-23 22:00:00.
This issue was reported by: stevenknight.
stevenknight said at 2001-09-23 22:00:00

This used to be called Link(), but I'm going to change the name in the design doc.

issues@scons said at 2001-09-23 22:00:00

Converted from SourceForge task item 39010

Add -p support

This issue was originally created at: 2001-09-23 22:00:00.
This issue was reported by: stevenknight.
stevenknight said at 2001-09-23 22:00:00

This "prints internal environments/objects" a la the Gnu Make dump of its internal database. This should actually incorporate whatever's defined for local defaults, too, so the user can see what the system administrator or buildmeister has provided for them. Maybe it includes commentary, too, to explain what's what.

issues@scons said at 2001-09-23 22:00:00

Converted from SourceForge task item 39024

Cache support

This issue was originally created at: 2001-09-23 22:00:00.
This issue was reported by: stevenknight.
stevenknight said at 2001-09-23 22:00:00

Store derived files in a central cache, with a directory of MD5 signatures. (Does this mean you don't get to use Cache() if you use timestamps?)

issues@scons said at 2001-09-23 22:00:00

Converted from SourceForge task item 39018

Add a warning if a user tries to use TARGET[S] or SOURCE[S]

This issue was originally created at: 2001-11-04 22:00:00.
This issue was reported by: stevenknight.
stevenknight said at 2001-11-04 22:00:00

These are reserved construction variable names...

issues@scons said at 2001-11-04 22:00:00

Converted from SourceForge task item 41627

Rebuild in response to changed build command

This issue was originally created at: 2001-10-28 22:00:00.
This issue was reported by: stevenknight.
stevenknight said at 2001-10-28 22:00:00

Should ignore insignificant differences in white space.

issues@scons said at 2001-10-28 22:00:00

Converted from SourceForge task item 41191

stevenknight said at 2006-05-20 20:56:05

No white space in keyword.

Make subdirectory SConscripts look up files relative to subdir

This issue was originally created at: 2001-10-24 22:00:00.
This issue was reported by: stevenknight.
stevenknight said at 2001-10-24 22:00:00

test/Depends.py has some things that test this.

issues@scons said at 2001-10-24 22:00:00

Converted from SourceForge task item 41023

stevenknight said at 2006-05-20 20:55:41

No white space in keyword.

Add --warn-undefined-variables support

This issue was originally created at: 2001-09-23 22:00:00.
This issue was reported by: stevenknight.
stevenknight said at 2001-09-23 22:00:00

A GNU Make option. Python will throw exceptions for us if an undefined Python variable is used in the script portion itself, but our construction variable expansion should support a way to do this as well.

issues@scons said at 2001-09-23 22:00:00

Converted from SourceForge task item 39032

Add LinkedModule() support.

This issue was originally created at: 2001-09-24 22:00:00.
This issue was reported by: stevenknight.
stevenknight said at 2001-09-24 22:00:00

Need to add this to the doc and add a test for it. We probably won't hold up initial release for this one, but if it makes it in time, great.

issues@scons said at 2001-09-24 22:00:00

Converted from SourceForge task item 39115

install fails

This issue was originally created at: 2001-12-17 06:28:54.
This issue was reported by: issues@scons.
issues@scons said at 2001-12-17 06:28:54

When trying to install scons 0.01 on NT 4.0 with
Python 2.1.1, I get:

C:\tmp\x>python setup.py
Traceback (most recent call last):
File "setup.py", line 78, in ?
if sys.argv[1] == "bdist_wininst":
IndexError: list index out of range

Hm. Do I do something wrong?
How can I specify the install directory?

stevenknight said at 2001-12-17 07:37:47

No, you followed instructions correctly, but the
instructions were wrong.

setup.py requires that you specify an argument. To install
it on your system, you actually need to type:

# python setup.py install

Sorry for the misinformation. A fix is being checked in
immediately.

stevenknight said at 2001-12-17 07:38:08

No, you followed instructions correctly, but the
instructions were wrong.

setup.py requires that you specify an argument. To install
it on your system, you actually need to type:

# python setup.py install

Sorry for the misinformation. A fix is being checked in
immediately.

stevenknight said at 2001-12-17 08:28:14

Fix checked in for 0.02, both to the documentation (to
mention "setup.py install") and to setup.py itself (to catch
the IndexError exception).

issues@scons said at 2001-12-17 08:28:14

Converted from SourceForge tracker item 494202

Don't create .sconsign for files outside the build tree

This issue was originally created at: 2001-10-24 22:00:00.
This issue was reported by: stevenknight.
stevenknight said at 2001-10-24 22:00:00

In the future, we may want some flexibility on this so you can do something like ../other_src/file.o and have it do .sconsign tracking in that dir. But don't worry about it for now.

issues@scons said at 2001-10-24 22:00:00

Converted from SourceForge task item 41072

stevenknight said at 2006-05-20 20:55:29

No white space in keyword.

Add -e support

This issue was originally created at: 2001-09-23 22:00:00.
This issue was reported by: stevenknight.
stevenknight said at 2001-09-23 22:00:00

Use environment variables, not construction variables, for command expansion.

issues@scons said at 2001-09-23 22:00:00

Converted from SourceForge task item 39019

silent command not found failure

This issue was originally created at: 2001-12-14 15:57:23.
This issue was reported by: stevenknight.
stevenknight said at 2001-12-14 15:57:23

From Stephen Kennedy:

I ran into a few gotchas when trying it on some of our
projects:
(is the sourceforge bug tracker being used? there were
zero bugs entered)

  • if a command failed because it could not be located,
    there was no error reported.

stevenknight said at 2001-12-21 09:46:09

Fixed in 0.02.

issues@scons said at 2001-12-21 09:46:09

Converted from SourceForge tracker item 493513

Add -u support

This issue was originally created at: 2001-09-23 22:00:00.
This issue was reported by: stevenknight.
stevenknight said at 2001-09-23 22:00:00

Traverse up the directory tree looking for the SConstruct file. Rewrite targets as appropriate to build only in (and under) the local directory.

issues@scons said at 2001-09-23 22:00:00

Converted from SourceForge task item 39028

-j support on Win32

This issue was originally created at: 2001-11-28 22:00:00.
This issue was reported by: stevenknight.
stevenknight said at 2001-11-28 22:00:00

test/option-j.py doesn't pass on Win32; it executes the two tasks sequentially, not in parallel.

issues@scons said at 2001-11-28 22:00:00

Converted from SourceForge task item 42985

stevenknight said at 2006-05-20 20:56:34

No white space in keyword.

Refactor Taskmaster to support node status

This issue was originally created at: 2001-10-09 22:00:00.
This issue was reported by: stevenknight.
stevenknight said at 2001-10-09 22:00:00

Per email discussions 9 Oct 2001.

issues@scons said at 2001-10-09 22:00:00

Converted from SourceForge task item 40129

stevenknight said at 2006-05-20 20:55:17

No white space in keyword.

Performance improvements

This issue was originally created at: 2001-11-27 22:00:00.
This issue was reported by: stevenknight.
stevenknight said at 2001-11-27 22:00:00

Bring performance up to acceptable levels, first by eliminating redundant implicit dependency scans.

issues@scons said at 2001-11-27 22:00:00

Converted from SourceForge task item 42925

stevenknight said at 2006-05-20 20:56:20

No white space in keyword.

Add --list-{actions,derived,where} support

This issue was originally created at: 2001-09-23 22:00:00.
This issue was reported by: stevenknight.
stevenknight said at 2001-09-23 22:00:00

These correspond to the Cons class -pa, -p, and -pw options. If the functionality's available elsewhere, we may not need all of these.

issues@scons said at 2001-09-23 22:00:00

Converted from SourceForge task item 39021

Add --random support

This issue was originally created at: 2001-09-23 22:00:00.
This issue was reported by: stevenknight.
stevenknight said at 2001-09-23 22:00:00

Build targets/dependencies in random order.

issues@scons said at 2001-09-23 22:00:00

Converted from SourceForge task item 39027

Bug with -C?

This issue was originally created at: 2001-12-14 15:53:02.
This issue was reported by: stevenknight.
stevenknight said at 2001-12-14 15:53:02

From Steve Leblanc:

I think I've found a bug when you want to use the -C
option (at least that's
how I spotted it.) Create files like this:

   SConstruct
   inc1.h
   bar/
       SConscript
       inc2.h
       foo.c

SConstruct looks like this:
env = Environment(CPPPATH=['#'], LINK='cc')
SConscript('dir/SConscript')

SConscript looks like this:
env.Program('foo', 'foo.c')

foo.c looks like this:
#include "inc1.h"
#include "inc2.h"
int main(void) { return 0; }

Now go to the top directory and type 'scons .' and
everything works fine.
Go to directory 'bar' and type 'scons -C .. .' and
you'll get an error
saying that scons couldn't read inc2.h. I followed
this a bit with the
debugger and what's happening is that the build is
taking place in the
top-level directory (as it should) but the path for
the inc2.h node is
'inc2.h' and not 'bar/inc2.h'.

Am I doing something stupid or is there a bug
somewhere?

issues@scons said at 2001-12-17 10:44:36

[Charles C. 12/17/2001] This bug arises from the fact that
the file system cache, SCons.Node.FS.default_fs, is created
when the FS module is imported. This is before the -C
option has been processed, hence the default_fs object is
always rooted at the directory from which scons is run.

I am working on a fix that delays the resolution of the top-
level directory of an FS object until it is either
explicitly set, or someone actually tries to look up a
node, whichever comes first.

issues@scons said at 2001-12-17 10:44:36

Converted from SourceForge tracker item 493512

build pruning

This issue was originally created at: 2001-09-23 22:00:00.
This issue was reported by: stevenknight.
stevenknight said at 2001-09-23 22:00:00

Support the ability to cut down the targets being built. The Cons method is a little quirky, so we should revisit whether or not it's the best way.

issues@scons said at 2001-09-23 22:00:00

Converted from SourceForge task item 39014

Debuggable signature checks

This issue was originally created at: 2001-09-23 22:00:00.
This issue was reported by: stevenknight.
stevenknight said at 2001-09-23 22:00:00

Add something that lets the user print out signatures, with varying degrees of verboseness. We need this for development as much as users need this to know why SCons does what it does.

issues@scons said at 2001-09-23 22:00:00

Converted from SourceForge task item 39013

Support CCFLAGS

This issue was originally created at: 2001-09-23 22:00:00.
This issue was reported by: stevenknight.
stevenknight said at 2001-09-23 22:00:00

Allow compilation with different values of CCFLAGS. A prototype test already exists in test/CCFLAGS.py.

issues@scons said at 2001-09-23 22:00:00

Converted from SourceForge task item 38992

stevenknight said at 2006-05-20 20:53:12

No white space in keyword.

Detect and report command execution errors.

This issue was originally created at: 2001-09-30 22:00:00.
This issue was reported by: stevenknight.
stevenknight said at 2001-09-30 22:00:00

This is a prelude to supporting the -i and -k options.

issues@scons said at 2001-09-30 22:00:00

Converted from SourceForge task item 39577

stevenknight said at 2006-05-20 20:54:27

No white space in keyword.

temporary overrides

This issue was originally created at: 2001-09-23 22:00:00.
This issue was reported by: stevenknight.
stevenknight said at 2001-09-23 22:00:00

This could be like the Cons classic -o option, but that mechanism is a little clunky, so see if we can't come up with something better. Maybe the -e flag reduces the need for much of this.

issues@scons said at 2001-09-23 22:00:00

Converted from SourceForge task item 39015

Detect dependency loops

This issue was originally created at: 2001-10-24 22:00:00.
This issue was reported by: stevenknight.
stevenknight said at 2001-10-24 22:00:00

If Make does this, we should use the same error message. If not, make up something suitably user-friendly.

issues@scons said at 2001-10-24 22:00:00

Converted from SourceForge task item 41071

stevenknight said at 2006-05-20 20:55:54

No white space in keyword.

Add -l support

This issue was originally created at: 2001-09-23 22:00:00.
This issue was reported by: stevenknight.
stevenknight said at 2001-09-23 22:00:00

Only fork jobs when under a specific load average. This could be tricky, because I don't think there's a standard Python library to fetch load average.

issues@scons said at 2001-09-23 22:00:00

Converted from SourceForge task item 39020

Create SConscript subsection on the scons(1) man page

This issue was originally created at: 2001-10-05 22:00:00.
This issue was reported by: stevenknight.
stevenknight said at 2001-10-05 22:00:00

We'll use this instead of a separate user guide for initial release.

issues@scons said at 2001-10-05 22:00:00

Converted from SourceForge task item 39899

stevenknight said at 2006-05-20 20:55:04

No white space in keyword.

Add Module() support.

This issue was originally created at: 2001-09-24 22:00:00.
This issue was reported by: stevenknight.
stevenknight said at 2001-09-24 22:00:00

Haven't really defined this yet or added a test. We probably won't hold up initial release for this, but if it makes it in time, great.

issues@scons said at 2001-09-24 22:00:00

Converted from SourceForge task item 39114

Add -q support.

This issue was originally created at: 2001-09-23 22:00:00.
This issue was reported by: stevenknight.
stevenknight said at 2001-09-23 22:00:00

Query mode, where we don't build, but just let the exit status tell the user if the build is already up-to-date.

issues@scons said at 2001-09-23 22:00:00

Converted from SourceForge task item 39025

Add -w support

This issue was originally created at: 2001-09-23 22:00:00.
This issue was reported by: stevenknight.
stevenknight said at 2001-09-23 22:00:00

We may not need this, since we don't chdir() around the tree the way recursive Make does. If we do need this, then we also need the --no-print-directory option.

issues@scons said at 2001-09-23 22:00:00

Converted from SourceForge task item 39029

Support CPPPATH

This issue was originally created at: 2001-09-23 22:00:00.
This issue was reported by: stevenknight.
stevenknight said at 2001-09-23 22:00:00

Actually search for #include dependencies using CPPPATH.

issues@scons said at 2001-09-23 22:00:00

Converted from SourceForge task item 38993

stevenknight said at 2006-05-20 20:52:31

No white space in keyword.

SIGNATURE configurability

This issue was originally created at: 2001-09-23 22:00:00.
This issue was reported by: stevenknight.
stevenknight said at 2001-09-23 22:00:00

Modeled after the feature recently added to Cons classic.

issues@scons said at 2001-09-23 22:00:00

Converted from SourceForge task item 39011

Don't build a target if a dependency couldn't be built.

This issue was originally created at: 2001-09-24 22:00:00.
This issue was reported by: stevenknight.
stevenknight said at 2001-09-24 22:00:00

This will probably mean implementing the real Taskmaster to communicate between the engine and the script.

issues@scons said at 2001-09-24 22:00:00

Converted from SourceForge task item 39202

stevenknight said at 2006-05-20 20:54:15

No white space in keyword.

Add Command() method

This issue was originally created at: 2001-09-23 22:00:00.
This issue was reported by: stevenknight.
stevenknight said at 2001-09-23 22:00:00

A prototype test already exists (short-circuited) in test/Command.py.

issues@scons said at 2001-09-23 22:00:00

Converted from SourceForge task item 38979

stevenknight said at 2006-05-20 20:53:38

No white space in keyword.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.