summaryrefslogtreecommitdiffstats
path: root/build2/scope.hxx
Commit message (Collapse)AuthorAgeFilesLines
* Move bunch of root scope-only data members to root_extraBoris Kolpackov2019-03-071-19/+40
|
* Add support for alternative build file/directory naming schemeBoris Kolpackov2019-03-071-0/+25
| | | | | | | | Now the build/*.build, buildfile, and .buildignore filesystem entries in a project can alternatively (but consistently) be called build2/*.build2, build2file, and .build2ignore. See a note at the beginning of the Project Structure section in the manual for details (motivation, restrictions, etc).
* Update copyright yearKaren Arutyunov2019-01-161-1/+1
|
* Diagnose target names with multiple trailing slashes as invalidBoris Kolpackov2019-01-141-5/+5
|
* Minor terminology tweaks (model -> build state)Boris Kolpackov2018-11-131-1/+1
|
* Add support for relative to base scope command line variable overridesBoris Kolpackov2018-11-091-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, if we say: $ b dir/ ./foo=bar The scope the foo=bar is set on is relative to CWD, not dir/. While this may seem wrong at first, this is the least surprising behavior when we take into account that there can be multiple dir/'s. Sometimes, however, we do want the override directory to be treated relative to (every) target's base scope that we are building. To support this we are extending the '.' and '..' special directory names (which are still resolved relative to CWD) with '...', which means "relative to the base scope of every target in the buildspec". For example: $ b dir/ .../foo=bar Is equivalent to: $ b dir/ dir/foo=bar And: $ b liba/ libb/ .../tests/foo=bar Is equivalent to: $ b liba/ libb/ liba/tests/foo=bar libb/tests/foo=bar
* Fix bug in override logic for command line variable with project visibilityBoris Kolpackov2018-11-081-0/+6
|
* Add support for rule-specific variables, use to fix cc.type data raceBoris Kolpackov2018-11-011-1/+2
|
* Add support for default extension specification, trailing dot escapingBoris Kolpackov2018-08-071-4/+4
| | | | | | | | | | | | | For example: cxx{*}: extension = cxx cxx{foo} # foo.cxx cxx{foo.test} # foo.test (probably what we want...) cxx{foo.test...} # foo.test.cxx (... is this) cxx{foo..} # foo. cxx{foo....} # foo.. cxx{foo.....} # error (must come in escape pair)
* Update copyright yearKaren Arutyunov2018-05-191-1/+1
|
* Fix uncaught invalid_path exceptionKaren Arutyunov2018-05-161-1/+1
|
* Implement forwarded configurations and backlinkingBoris Kolpackov2018-04-261-5/+1
|
* Allow typification of variables and values across load generationsBoris Kolpackov2017-12-031-1/+1
| | | | | | | | | | The original semantics turned out to be too restrictive. For example, the user may have specified the config.c variable on the command line that is only used by an imported project that is loaded in a subsequent generation. We are also relaxing it for values since conceptually the two feel the same. For a value the (hypothetical) example is a "common" variable set in a project root that is only queried in a subdirectory in a subsequent generation.
* Implement support for scope operation callbacksBoris Kolpackov2017-11-301-1/+32
| | | | | | An entity (module, core) can register a function that will be called when an action is executed on the dir{} target that corresponds to the scope. The pre callback is called just before the recipe and the post -- immediately after.
* Adapt to modularization of libbutlKaren Arutyunov2017-10-031-1/+1
|
* Minor changesBoris Kolpackov2017-08-051-0/+5
|
* Add hxx extension for headersKaren Arutyunov2017-05-011-0/+375