tequilaOS/platform_build_blueprint
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
platform_build_blueprint/build.ninja.in

322 lines
17 KiB
Text
Raw Normal View History

Initial Blueprint commit. Blueprint is a build system component that reads Blueprints files defining modules to be built, and generates a Ninja build manifest that can be used to perform all the build actions. It does not dictate or implement much build policy itself, but rather provides a framework to ease the process of defining build logic in Go. The "blueprint" and "blueprint/parser" Go packages contain the functionality for reading Blueprint files and invoking build logic functions defined in other Go packages. The "blueprint/bootstrap" Go package contains just enough build logic to build a binary that includes Blueprint and any pure-Go (i.e. no cgo) build logic defined in external Go packages. This can be used to create a minimal Ninja file that's capable of bootstrapping a Blueprint-based build system from source. The "blueprint/bootstrap/minibp" Go package contains code for a minimal binary that includes the build logic defined in the "blueprint/bootstrap" package. This binary can then create the Ninja file for the bootstrapping process. Change-Id: I8d8390042372a72d225785cda738525001b009f1
2014-05-28 01:34:41 +02:00
# ******************************************************************************
# *** This file is generated and should not be edited ***
# ******************************************************************************
#
# This file contains variables, rules, and pools with name prefixes indicating
# they were generated by the following Go packages:
#
Update import paths to include github
2015-03-21 03:39:29 +01:00
# bootstrap [from Go package github.com/google/blueprint/bootstrap]
Initial Blueprint commit. Blueprint is a build system component that reads Blueprints files defining modules to be built, and generates a Ninja build manifest that can be used to perform all the build actions. It does not dictate or implement much build policy itself, but rather provides a framework to ease the process of defining build logic in Go. The "blueprint" and "blueprint/parser" Go packages contain the functionality for reading Blueprint files and invoking build logic functions defined in other Go packages. The "blueprint/bootstrap" Go package contains just enough build logic to build a binary that includes Blueprint and any pure-Go (i.e. no cgo) build logic defined in external Go packages. This can be used to create a minimal Ninja file that's capable of bootstrapping a Blueprint-based build system from source. The "blueprint/bootstrap/minibp" Go package contains code for a minimal binary that includes the build logic defined in the "blueprint/bootstrap" package. This binary can then create the Ninja file for the bootstrapping process. Change-Id: I8d8390042372a72d225785cda738525001b009f1
2014-05-28 01:34:41 +02:00
#
Support implicit outputs Added in Ninja 1.7, for outputs that will not show up in $out.
2016-10-26 06:26:12 +02:00
ninja_required_version = 1.7.0
Initial Blueprint commit. Blueprint is a build system component that reads Blueprints files defining modules to be built, and generates a Ninja build manifest that can be used to perform all the build actions. It does not dictate or implement much build policy itself, but rather provides a framework to ease the process of defining build logic in Go. The "blueprint" and "blueprint/parser" Go packages contain the functionality for reading Blueprint files and invoking build logic functions defined in other Go packages. The "blueprint/bootstrap" Go package contains just enough build logic to build a binary that includes Blueprint and any pure-Go (i.e. no cgo) build logic defined in external Go packages. This can be used to create a minimal Ninja file that's capable of bootstrapping a Blueprint-based build system from source. The "blueprint/bootstrap/minibp" Go package contains code for a minimal binary that includes the build logic defined in the "blueprint/bootstrap" package. This binary can then create the Ninja file for the bootstrapping process. Change-Id: I8d8390042372a72d225785cda738525001b009f1
2014-05-28 01:34:41 +02:00
Support a separate build directory To provide a consistent __FILE__ behavior with cpp, we want to be able to run with SRCDIR="." and the outputs be saved elsewhere. Other tools within android also expect to be run from $TOP. Change-Id: I572bce5c9086b0c3310b42065ae98cbf5a1c6399
2015-07-14 03:11:49 +02:00
g.bootstrap.buildDir = @@BuildDir@@
g.bootstrap.BinDir = ${g.bootstrap.buildDir}/.bootstrap/bin
Switch bootstrap.BinDir to a StaticVariable API Change -- will require changes to any code using bootstrap.BinDir This way we can put references to other variables in BinDir, and still be used properly by other packages. Change-Id: I497424cb254b3a170401ac9420fa0adbf8d11d1e
2015-07-14 08:28:37 +02:00
bootstrap: Don't export the script-substituted Ninja vars Change-Id: I8999f9489415cc53661e079401df519f9d83258e
2014-11-09 20:52:56 +01:00
g.bootstrap.bootstrapCmd = @@Bootstrap@@
Initial Blueprint commit. Blueprint is a build system component that reads Blueprints files defining modules to be built, and generates a Ninja build manifest that can be used to perform all the build actions. It does not dictate or implement much build policy itself, but rather provides a framework to ease the process of defining build logic in Go. The "blueprint" and "blueprint/parser" Go packages contain the functionality for reading Blueprint files and invoking build logic functions defined in other Go packages. The "blueprint/bootstrap" Go package contains just enough build logic to build a binary that includes Blueprint and any pure-Go (i.e. no cgo) build logic defined in external Go packages. This can be used to create a minimal Ninja file that's capable of bootstrapping a Blueprint-based build system from source. The "blueprint/bootstrap/minibp" Go package contains code for a minimal binary that includes the build logic defined in the "blueprint/bootstrap" package. This binary can then create the Ninja file for the bootstrapping process. Change-Id: I8d8390042372a72d225785cda738525001b009f1
2014-05-28 01:34:41 +02:00
Support go 1.5 The go compiler and linker changed in v1.5 -- to 'go tool compile' and 'go tool link' instead of 6g and 6l. Move the selection logic to bootstrap.bash, and have it use compile/link if 6g/6l are missing. This way the build.ninja.in will continue working with either go 1.4 or 1.5. Travis and the test suite will fail under 1.5, since the build.ninja.in is still generated with 1.4, and the function names in the comments differ between 1.4 and 1.5.
2015-08-02 00:07:27 +02:00
g.bootstrap.compileCmd = @@GoCompile@@
Initial Blueprint commit. Blueprint is a build system component that reads Blueprints files defining modules to be built, and generates a Ninja build manifest that can be used to perform all the build actions. It does not dictate or implement much build policy itself, but rather provides a framework to ease the process of defining build logic in Go. The "blueprint" and "blueprint/parser" Go packages contain the functionality for reading Blueprint files and invoking build logic functions defined in other Go packages. The "blueprint/bootstrap" Go package contains just enough build logic to build a binary that includes Blueprint and any pure-Go (i.e. no cgo) build logic defined in external Go packages. This can be used to create a minimal Ninja file that's capable of bootstrapping a Blueprint-based build system from source. The "blueprint/bootstrap/minibp" Go package contains code for a minimal binary that includes the build logic defined in the "blueprint/bootstrap" package. This binary can then create the Ninja file for the bootstrapping process. Change-Id: I8d8390042372a72d225785cda738525001b009f1
2014-05-28 01:34:41 +02:00
Support go 1.5 The go compiler and linker changed in v1.5 -- to 'go tool compile' and 'go tool link' instead of 6g and 6l. Move the selection logic to bootstrap.bash, and have it use compile/link if 6g/6l are missing. This way the build.ninja.in will continue working with either go 1.4 or 1.5. Travis and the test suite will fail under 1.5, since the build.ninja.in is still generated with 1.4, and the function names in the comments differ between 1.4 and 1.5.
2015-08-02 00:07:27 +02:00
g.bootstrap.goRoot = @@GoRoot@@
Initial Blueprint commit. Blueprint is a build system component that reads Blueprints files defining modules to be built, and generates a Ninja build manifest that can be used to perform all the build actions. It does not dictate or implement much build policy itself, but rather provides a framework to ease the process of defining build logic in Go. The "blueprint" and "blueprint/parser" Go packages contain the functionality for reading Blueprint files and invoking build logic functions defined in other Go packages. The "blueprint/bootstrap" Go package contains just enough build logic to build a binary that includes Blueprint and any pure-Go (i.e. no cgo) build logic defined in external Go packages. This can be used to create a minimal Ninja file that's capable of bootstrapping a Blueprint-based build system from source. The "blueprint/bootstrap/minibp" Go package contains code for a minimal binary that includes the build logic defined in the "blueprint/bootstrap" package. This binary can then create the Ninja file for the bootstrapping process. Change-Id: I8d8390042372a72d225785cda738525001b009f1
2014-05-28 01:34:41 +02:00
Support go 1.5 The go compiler and linker changed in v1.5 -- to 'go tool compile' and 'go tool link' instead of 6g and 6l. Move the selection logic to bootstrap.bash, and have it use compile/link if 6g/6l are missing. This way the build.ninja.in will continue working with either go 1.4 or 1.5. Travis and the test suite will fail under 1.5, since the build.ninja.in is still generated with 1.4, and the function names in the comments differ between 1.4 and 1.5.
2015-08-02 00:07:27 +02:00
g.bootstrap.linkCmd = @@GoLink@@
Initial Blueprint commit. Blueprint is a build system component that reads Blueprints files defining modules to be built, and generates a Ninja build manifest that can be used to perform all the build actions. It does not dictate or implement much build policy itself, but rather provides a framework to ease the process of defining build logic in Go. The "blueprint" and "blueprint/parser" Go packages contain the functionality for reading Blueprint files and invoking build logic functions defined in other Go packages. The "blueprint/bootstrap" Go package contains just enough build logic to build a binary that includes Blueprint and any pure-Go (i.e. no cgo) build logic defined in external Go packages. This can be used to create a minimal Ninja file that's capable of bootstrapping a Blueprint-based build system from source. The "blueprint/bootstrap/minibp" Go package contains code for a minimal binary that includes the build logic defined in the "blueprint/bootstrap" package. This binary can then create the Ninja file for the bootstrapping process. Change-Id: I8d8390042372a72d225785cda738525001b009f1
2014-05-28 01:34:41 +02:00
bootstrap: Don't export the script-substituted Ninja vars Change-Id: I8999f9489415cc53661e079401df519f9d83258e
2014-11-09 20:52:56 +01:00
g.bootstrap.srcDir = @@SrcDir@@
Initial Blueprint commit. Blueprint is a build system component that reads Blueprints files defining modules to be built, and generates a Ninja build manifest that can be used to perform all the build actions. It does not dictate or implement much build policy itself, but rather provides a framework to ease the process of defining build logic in Go. The "blueprint" and "blueprint/parser" Go packages contain the functionality for reading Blueprint files and invoking build logic functions defined in other Go packages. The "blueprint/bootstrap" Go package contains just enough build logic to build a binary that includes Blueprint and any pure-Go (i.e. no cgo) build logic defined in external Go packages. This can be used to create a minimal Ninja file that's capable of bootstrapping a Blueprint-based build system from source. The "blueprint/bootstrap/minibp" Go package contains code for a minimal binary that includes the build logic defined in the "blueprint/bootstrap" package. This binary can then create the Ninja file for the bootstrapping process. Change-Id: I8d8390042372a72d225785cda738525001b009f1
2014-05-28 01:34:41 +02:00
Support a separate build directory To provide a consistent __FILE__ behavior with cpp, we want to be able to run with SRCDIR="." and the outputs be saved elsewhere. Other tools within android also expect to be run from $TOP. Change-Id: I572bce5c9086b0c3310b42065ae98cbf5a1c6399
2015-07-14 03:11:49 +02:00
builddir = ${g.bootstrap.buildDir}/.minibootstrap
Initial Blueprint commit. Blueprint is a build system component that reads Blueprints files defining modules to be built, and generates a Ninja build manifest that can be used to perform all the build actions. It does not dictate or implement much build policy itself, but rather provides a framework to ease the process of defining build logic in Go. The "blueprint" and "blueprint/parser" Go packages contain the functionality for reading Blueprint files and invoking build logic functions defined in other Go packages. The "blueprint/bootstrap" Go package contains just enough build logic to build a binary that includes Blueprint and any pure-Go (i.e. no cgo) build logic defined in external Go packages. This can be used to create a minimal Ninja file that's capable of bootstrapping a Blueprint-based build system from source. The "blueprint/bootstrap/minibp" Go package contains code for a minimal binary that includes the build logic defined in the "blueprint/bootstrap" package. This binary can then create the Ninja file for the bootstrapping process. Change-Id: I8d8390042372a72d225785cda738525001b009f1
2014-05-28 01:34:41 +02:00
Sort various things for deterministic output. Change-Id: If6457713ad442ae3e4179e594820fa1e02e9b240
2014-09-25 05:26:52 +02:00
rule g.bootstrap.bootstrap
Stop using bootstrap.bash -b for separate builddir It's difficult for wrapping scripts to handle -b properly. Just pass BUILDDIR instead, which is easier to handle. This still accepts -b, so that incremental builds work across this change.
2015-09-18 07:48:04 +02:00
command = BUILDDIR=${g.bootstrap.buildDir} ${g.bootstrap.bootstrapCmd} -i ${in}
Sort various things for deterministic output. Change-Id: If6457713ad442ae3e4179e594820fa1e02e9b240
2014-09-25 05:26:52 +02:00
description = bootstrap ${in}
generator = true
Allow build.ninja regeneration (fix Soong globs) Soong (and soon, Blueprint) embeds the results of filesystem globs into the build.ninja, and uses a helper tool to detect when the glob changes and we need to rebuild the build.ninja file. This is more flexible than listing the affected directories in the depfiles, since it can check to see if a file we actually cared about was added, instead of re-running anytime any file was added/removed (which happens on atomic file modifications as well). My recent bootstrap simplification broke this, since the helper rules are in the main build.ninja, but I removed the ability to regenerate that file from itself. So keep the current model, but add a rule into the primary and main stages that allow themselves to re-run their generator and write out a new build.ninja file if necessary. The actual build rules of the generator aren't necessary, since we already built them in the previous stage. Change-Id: Ib51245920b2ec3ee5306c0c269361a5a8733caa8
2016-11-02 01:12:28 +01:00
rule g.bootstrap.build.ninja
command = ${builder} ${extra} -b ${g.bootstrap.buildDir} -d ${out}.d -o ${out} ${in}
depfile = ${out}.d
description = ${builder} ${out}
restat = true
Support go 1.5 The go compiler and linker changed in v1.5 -- to 'go tool compile' and 'go tool link' instead of 6g and 6l. Move the selection logic to bootstrap.bash, and have it use compile/link if 6g/6l are missing. This way the build.ninja.in will continue working with either go 1.4 or 1.5. Travis and the test suite will fail under 1.5, since the build.ninja.in is still generated with 1.4, and the function names in the comments differ between 1.4 and 1.5.
2015-08-02 00:07:27 +02:00
rule g.bootstrap.compile
command = GOROOT='${g.bootstrap.goRoot}' ${g.bootstrap.compileCmd} -o ${out} -p ${pkgPath} -complete ${incFlags} -pack ${in}
description = compile ${out}
Sort various things for deterministic output. Change-Id: If6457713ad442ae3e4179e594820fa1e02e9b240
2014-09-25 05:26:52 +02:00
rule g.bootstrap.cp
command = cp ${in} ${out}
description = cp ${out}
Initial Blueprint commit. Blueprint is a build system component that reads Blueprints files defining modules to be built, and generates a Ninja build manifest that can be used to perform all the build actions. It does not dictate or implement much build policy itself, but rather provides a framework to ease the process of defining build logic in Go. The "blueprint" and "blueprint/parser" Go packages contain the functionality for reading Blueprint files and invoking build logic functions defined in other Go packages. The "blueprint/bootstrap" Go package contains just enough build logic to build a binary that includes Blueprint and any pure-Go (i.e. no cgo) build logic defined in external Go packages. This can be used to create a minimal Ninja file that's capable of bootstrapping a Blueprint-based build system from source. The "blueprint/bootstrap/minibp" Go package contains code for a minimal binary that includes the build logic defined in the "blueprint/bootstrap" package. This binary can then create the Ninja file for the bootstrapping process. Change-Id: I8d8390042372a72d225785cda738525001b009f1
2014-05-28 01:34:41 +02:00
rule g.bootstrap.link
bootstrap: Don't export the script-substituted Ninja vars Change-Id: I8999f9489415cc53661e079401df519f9d83258e
2014-11-09 20:52:56 +01:00
command = GOROOT='${g.bootstrap.goRoot}' ${g.bootstrap.linkCmd} -o ${out} ${libDirFlags} ${in}
Support go 1.5 The go compiler and linker changed in v1.5 -- to 'go tool compile' and 'go tool link' instead of 6g and 6l. Move the selection logic to bootstrap.bash, and have it use compile/link if 6g/6l are missing. This way the build.ninja.in will continue working with either go 1.4 or 1.5. Travis and the test suite will fail under 1.5, since the build.ninja.in is still generated with 1.4, and the function names in the comments differ between 1.4 and 1.5.
2015-08-02 00:07:27 +02:00
description = link ${out}
Initial Blueprint commit. Blueprint is a build system component that reads Blueprints files defining modules to be built, and generates a Ninja build manifest that can be used to perform all the build actions. It does not dictate or implement much build policy itself, but rather provides a framework to ease the process of defining build logic in Go. The "blueprint" and "blueprint/parser" Go packages contain the functionality for reading Blueprint files and invoking build logic functions defined in other Go packages. The "blueprint/bootstrap" Go package contains just enough build logic to build a binary that includes Blueprint and any pure-Go (i.e. no cgo) build logic defined in external Go packages. This can be used to create a minimal Ninja file that's capable of bootstrapping a Blueprint-based build system from source. The "blueprint/bootstrap/minibp" Go package contains code for a minimal binary that includes the build logic defined in the "blueprint/bootstrap" package. This binary can then create the Ninja file for the bootstrapping process. Change-Id: I8d8390042372a72d225785cda738525001b009f1
2014-05-28 01:34:41 +02:00
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# Module: blueprint
Update import paths to include github
2015-03-21 03:39:29 +01:00
# Variant:
Initial Blueprint commit. Blueprint is a build system component that reads Blueprints files defining modules to be built, and generates a Ninja build manifest that can be used to perform all the build actions. It does not dictate or implement much build policy itself, but rather provides a framework to ease the process of defining build logic in Go. The "blueprint" and "blueprint/parser" Go packages contain the functionality for reading Blueprint files and invoking build logic functions defined in other Go packages. The "blueprint/bootstrap" Go package contains just enough build logic to build a binary that includes Blueprint and any pure-Go (i.e. no cgo) build logic defined in external Go packages. This can be used to create a minimal Ninja file that's capable of bootstrapping a Blueprint-based build system from source. The "blueprint/bootstrap/minibp" Go package contains code for a minimal binary that includes the build logic defined in the "blueprint/bootstrap" package. This binary can then create the Ninja file for the bootstrapping process. Change-Id: I8d8390042372a72d225785cda738525001b009f1
2014-05-28 01:34:41 +02:00
# Type: bootstrap_go_package
Add blank line after build rules, for human readability.
2015-11-09 20:37:39 +01:00
# Factory: github.com/google/blueprint/bootstrap.newGoPackageModuleFactory.func1
Make build.ninja.in independent of the build dir. This change makes the module definition location that's included in the build manifest comments use paths relative to the top-level source directory. This should make the bootstrap build manifest not get regenerated when using a new build directory. Change-Id: I350562ad10aa52688c8841c96c6325502b0faa59
2014-06-05 00:33:08 +02:00
# Defined: Blueprints:1:1
Initial Blueprint commit. Blueprint is a build system component that reads Blueprints files defining modules to be built, and generates a Ninja build manifest that can be used to perform all the build actions. It does not dictate or implement much build policy itself, but rather provides a framework to ease the process of defining build logic in Go. The "blueprint" and "blueprint/parser" Go packages contain the functionality for reading Blueprint files and invoking build logic functions defined in other Go packages. The "blueprint/bootstrap" Go package contains just enough build logic to build a binary that includes Blueprint and any pure-Go (i.e. no cgo) build logic defined in external Go packages. This can be used to create a minimal Ninja file that's capable of bootstrapping a Blueprint-based build system from source. The "blueprint/bootstrap/minibp" Go package contains code for a minimal binary that includes the build logic defined in the "blueprint/bootstrap" package. This binary can then create the Ninja file for the bootstrapping process. Change-Id: I8d8390042372a72d225785cda738525001b009f1
2014-05-28 01:34:41 +02:00
Support a separate build directory To provide a consistent __FILE__ behavior with cpp, we want to be able to run with SRCDIR="." and the outputs be saved elsewhere. Other tools within android also expect to be run from $TOP. Change-Id: I572bce5c9086b0c3310b42065ae98cbf5a1c6399
2015-07-14 03:11:49 +02:00
build $
${g.bootstrap.buildDir}/.bootstrap/blueprint/pkg/github.com/google/blueprint.a $
Support go 1.5 The go compiler and linker changed in v1.5 -- to 'go tool compile' and 'go tool link' instead of 6g and 6l. Move the selection logic to bootstrap.bash, and have it use compile/link if 6g/6l are missing. This way the build.ninja.in will continue working with either go 1.4 or 1.5. Travis and the test suite will fail under 1.5, since the build.ninja.in is still generated with 1.4, and the function names in the comments differ between 1.4 and 1.5.
2015-08-02 00:07:27 +02:00
: g.bootstrap.compile ${g.bootstrap.srcDir}/context.go $
Import globbing from Soong Add globbing with dependency checking to blueprint. Calling ModuleContext.GlobWithDeps or SingletonContext.GlobWithDeps will return a list of files that match the globs, while also adding efficient dependencies to rerun the primary builder if a file that matches the glob is added or removed. Also use the globbing support for optional_subdirs=, subdirs= and build= lines in blueprints files. The globbing slightly changes the behavior of subname= lines, it no longer falls back to looking for a file called "Blueprints". Blueprint files that need to include a subdirectory with a different name can use build= instead of subdir= to directly include them. The Blueprints file is updated to reset subname="Blueprints" in case we want to include subdirectories inside blueprint and the primary builder has changed the subname. Also adds a new test directory that contains a simple primary builder tree to test regeneration for globbing, and runs the tests in travis. Change-Id: I83ce525fd11e11579cc58ba5308d01ca8eea7bc6
2016-11-01 19:10:51 +01:00
${g.bootstrap.srcDir}/fs.go ${g.bootstrap.srcDir}/glob.go $
${g.bootstrap.srcDir}/live_tracker.go ${g.bootstrap.srcDir}/mangle.go $
${g.bootstrap.srcDir}/module_ctx.go $
Move blueprint/* up a directory Make integrating with go tools easier by putting the blueprint package files in the top level directory of the git project instead of in a subdirectory called blueprint. Change-Id: I35c144c5fe7ddf34e478d0c47c50b2f6c92c2a03
2015-01-23 22:38:48 +01:00
${g.bootstrap.srcDir}/ninja_defs.go $
${g.bootstrap.srcDir}/ninja_strings.go $
${g.bootstrap.srcDir}/ninja_writer.go $
${g.bootstrap.srcDir}/package_ctx.go ${g.bootstrap.srcDir}/scope.go $
${g.bootstrap.srcDir}/singleton_ctx.go ${g.bootstrap.srcDir}/unpack.go $
Support go 1.5 The go compiler and linker changed in v1.5 -- to 'go tool compile' and 'go tool link' instead of 6g and 6l. Move the selection logic to bootstrap.bash, and have it use compile/link if 6g/6l are missing. This way the build.ninja.in will continue working with either go 1.4 or 1.5. Travis and the test suite will fail under 1.5, since the build.ninja.in is still generated with 1.4, and the function names in the comments differ between 1.4 and 1.5.
2015-08-02 00:07:27 +02:00
| ${g.bootstrap.compileCmd} $
Support a separate build directory To provide a consistent __FILE__ behavior with cpp, we want to be able to run with SRCDIR="." and the outputs be saved elsewhere. Other tools within android also expect to be run from $TOP. Change-Id: I572bce5c9086b0c3310b42065ae98cbf5a1c6399
2015-07-14 03:11:49 +02:00
${g.bootstrap.buildDir}/.bootstrap/blueprint-parser/pkg/github.com/google/blueprint/parser.a $
Import globbing from Soong Add globbing with dependency checking to blueprint. Calling ModuleContext.GlobWithDeps or SingletonContext.GlobWithDeps will return a list of files that match the globs, while also adding efficient dependencies to rerun the primary builder if a file that matches the glob is added or removed. Also use the globbing support for optional_subdirs=, subdirs= and build= lines in blueprints files. The globbing slightly changes the behavior of subname= lines, it no longer falls back to looking for a file called "Blueprints". Blueprint files that need to include a subdirectory with a different name can use build= instead of subdir= to directly include them. The Blueprints file is updated to reset subname="Blueprints" in case we want to include subdirectories inside blueprint and the primary builder has changed the subname. Also adds a new test directory that contains a simple primary builder tree to test regeneration for globbing, and runs the tests in travis. Change-Id: I83ce525fd11e11579cc58ba5308d01ca8eea7bc6
2016-11-01 19:10:51 +01:00
${g.bootstrap.buildDir}/.bootstrap/blueprint-deptools/pkg/github.com/google/blueprint/deptools.a $
Support a separate build directory To provide a consistent __FILE__ behavior with cpp, we want to be able to run with SRCDIR="." and the outputs be saved elsewhere. Other tools within android also expect to be run from $TOP. Change-Id: I572bce5c9086b0c3310b42065ae98cbf5a1c6399
2015-07-14 03:11:49 +02:00
${g.bootstrap.buildDir}/.bootstrap/blueprint-pathtools/pkg/github.com/google/blueprint/pathtools.a $
${g.bootstrap.buildDir}/.bootstrap/blueprint-proptools/pkg/github.com/google/blueprint/proptools.a
Import globbing from Soong Add globbing with dependency checking to blueprint. Calling ModuleContext.GlobWithDeps or SingletonContext.GlobWithDeps will return a list of files that match the globs, while also adding efficient dependencies to rerun the primary builder if a file that matches the glob is added or removed. Also use the globbing support for optional_subdirs=, subdirs= and build= lines in blueprints files. The globbing slightly changes the behavior of subname= lines, it no longer falls back to looking for a file called "Blueprints". Blueprint files that need to include a subdirectory with a different name can use build= instead of subdir= to directly include them. The Blueprints file is updated to reset subname="Blueprints" in case we want to include subdirectories inside blueprint and the primary builder has changed the subname. Also adds a new test directory that contains a simple primary builder tree to test regeneration for globbing, and runs the tests in travis. Change-Id: I83ce525fd11e11579cc58ba5308d01ca8eea7bc6
2016-11-01 19:10:51 +01:00
incFlags = -I ${g.bootstrap.buildDir}/.bootstrap/blueprint-parser/pkg -I ${g.bootstrap.buildDir}/.bootstrap/blueprint-deptools/pkg -I ${g.bootstrap.buildDir}/.bootstrap/blueprint-pathtools/pkg -I ${g.bootstrap.buildDir}/.bootstrap/blueprint-proptools/pkg
Update import paths to include github
2015-03-21 03:39:29 +01:00
pkgPath = github.com/google/blueprint
Support a separate build directory To provide a consistent __FILE__ behavior with cpp, we want to be able to run with SRCDIR="." and the outputs be saved elsewhere. Other tools within android also expect to be run from $TOP. Change-Id: I572bce5c9086b0c3310b42065ae98cbf5a1c6399
2015-07-14 03:11:49 +02:00
default $
${g.bootstrap.buildDir}/.bootstrap/blueprint/pkg/github.com/google/blueprint.a
Initial Blueprint commit. Blueprint is a build system component that reads Blueprints files defining modules to be built, and generates a Ninja build manifest that can be used to perform all the build actions. It does not dictate or implement much build policy itself, but rather provides a framework to ease the process of defining build logic in Go. The "blueprint" and "blueprint/parser" Go packages contain the functionality for reading Blueprint files and invoking build logic functions defined in other Go packages. The "blueprint/bootstrap" Go package contains just enough build logic to build a binary that includes Blueprint and any pure-Go (i.e. no cgo) build logic defined in external Go packages. This can be used to create a minimal Ninja file that's capable of bootstrapping a Blueprint-based build system from source. The "blueprint/bootstrap/minibp" Go package contains code for a minimal binary that includes the build logic defined in the "blueprint/bootstrap" package. This binary can then create the Ninja file for the bootstrapping process. Change-Id: I8d8390042372a72d225785cda738525001b009f1
2014-05-28 01:34:41 +02:00
Sort modules and singletons for output. This change causes the module and singleton content in generated Ninja files to be sorted by name. Change-Id: I6e1fe6d4211111c7dfa25ebe0fc721701a6d0256
2014-06-12 01:27:16 +02:00
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# Module: blueprint-bootstrap
Update import paths to include github
2015-03-21 03:39:29 +01:00
# Variant:
Sort modules and singletons for output. This change causes the module and singleton content in generated Ninja files to be sorted by name. Change-Id: I6e1fe6d4211111c7dfa25ebe0fc721701a6d0256
2014-06-12 01:27:16 +02:00
# Type: bootstrap_go_package
Add blank line after build rules, for human readability.
2015-11-09 20:37:39 +01:00
# Factory: github.com/google/blueprint/bootstrap.newGoPackageModuleFactory.func1
Import globbing from Soong Add globbing with dependency checking to blueprint. Calling ModuleContext.GlobWithDeps or SingletonContext.GlobWithDeps will return a list of files that match the globs, while also adding efficient dependencies to rerun the primary builder if a file that matches the glob is added or removed. Also use the globbing support for optional_subdirs=, subdirs= and build= lines in blueprints files. The globbing slightly changes the behavior of subname= lines, it no longer falls back to looking for a file called "Blueprints". Blueprint files that need to include a subdirectory with a different name can use build= instead of subdir= to directly include them. The Blueprints file is updated to reset subname="Blueprints" in case we want to include subdirectories inside blueprint and the primary builder has changed the subname. Also adds a new test directory that contains a simple primary builder tree to test regeneration for globbing, and runs the tests in travis. Change-Id: I83ce525fd11e11579cc58ba5308d01ca8eea7bc6
2016-11-01 19:10:51 +01:00
# Defined: Blueprints:89:1
Sort modules and singletons for output. This change causes the module and singleton content in generated Ninja files to be sorted by name. Change-Id: I6e1fe6d4211111c7dfa25ebe0fc721701a6d0256
2014-06-12 01:27:16 +02:00
Update import paths to include github
2015-03-21 03:39:29 +01:00
build $
Support a separate build directory To provide a consistent __FILE__ behavior with cpp, we want to be able to run with SRCDIR="." and the outputs be saved elsewhere. Other tools within android also expect to be run from $TOP. Change-Id: I572bce5c9086b0c3310b42065ae98cbf5a1c6399
2015-07-14 03:11:49 +02:00
${g.bootstrap.buildDir}/.bootstrap/blueprint-bootstrap/pkg/github.com/google/blueprint/bootstrap.a $
Support go 1.5 The go compiler and linker changed in v1.5 -- to 'go tool compile' and 'go tool link' instead of 6g and 6l. Move the selection logic to bootstrap.bash, and have it use compile/link if 6g/6l are missing. This way the build.ninja.in will continue working with either go 1.4 or 1.5. Travis and the test suite will fail under 1.5, since the build.ninja.in is still generated with 1.4, and the function names in the comments differ between 1.4 and 1.5.
2015-08-02 00:07:27 +02:00
: g.bootstrap.compile ${g.bootstrap.srcDir}/bootstrap/bootstrap.go $
Move blueprint/* up a directory Make integrating with go tools easier by putting the blueprint package files in the top level directory of the git project instead of in a subdirectory called blueprint. Change-Id: I35c144c5fe7ddf34e478d0c47c50b2f6c92c2a03
2015-01-23 22:38:48 +01:00
${g.bootstrap.srcDir}/bootstrap/cleanup.go $
${g.bootstrap.srcDir}/bootstrap/command.go $
${g.bootstrap.srcDir}/bootstrap/config.go $
Add self-documenting support The primary builder will now generate a rule to call itself with --docs=.bootstrap/docs/<name>.html to produce an automatically generated documentation file. The documentation generation process is: - Call each factory once to get empty property structs associated with the module type - Use reflection to determine the names of the type of each property struct - Use the bootstrap_go_package modules from reading the Blueprints files to find the source files for each Go package used to build the primary builder - Use the go/parser module to find the type declaration for each property struct - Extract comments for the property struct and each property declaration - Format all the comments into HTML Change-Id: Icae9307cc10549a30bfc14d6922824099de5a9b0
2015-05-13 23:36:24 +02:00
${g.bootstrap.srcDir}/bootstrap/doc.go $
Import globbing from Soong Add globbing with dependency checking to blueprint. Calling ModuleContext.GlobWithDeps or SingletonContext.GlobWithDeps will return a list of files that match the globs, while also adding efficient dependencies to rerun the primary builder if a file that matches the glob is added or removed. Also use the globbing support for optional_subdirs=, subdirs= and build= lines in blueprints files. The globbing slightly changes the behavior of subname= lines, it no longer falls back to looking for a file called "Blueprints". Blueprint files that need to include a subdirectory with a different name can use build= instead of subdir= to directly include them. The Blueprints file is updated to reset subname="Blueprints" in case we want to include subdirectories inside blueprint and the primary builder has changed the subname. Also adds a new test directory that contains a simple primary builder tree to test regeneration for globbing, and runs the tests in travis. Change-Id: I83ce525fd11e11579cc58ba5308d01ca8eea7bc6
2016-11-01 19:10:51 +01:00
${g.bootstrap.srcDir}/bootstrap/glob.go $
Support go 1.5 The go compiler and linker changed in v1.5 -- to 'go tool compile' and 'go tool link' instead of 6g and 6l. Move the selection logic to bootstrap.bash, and have it use compile/link if 6g/6l are missing. This way the build.ninja.in will continue working with either go 1.4 or 1.5. Travis and the test suite will fail under 1.5, since the build.ninja.in is still generated with 1.4, and the function names in the comments differ between 1.4 and 1.5.
2015-08-02 00:07:27 +02:00
${g.bootstrap.srcDir}/bootstrap/writedocs.go | $
${g.bootstrap.compileCmd} $
Support a separate build directory To provide a consistent __FILE__ behavior with cpp, we want to be able to run with SRCDIR="." and the outputs be saved elsewhere. Other tools within android also expect to be run from $TOP. Change-Id: I572bce5c9086b0c3310b42065ae98cbf5a1c6399
2015-07-14 03:11:49 +02:00
${g.bootstrap.buildDir}/.bootstrap/blueprint-parser/pkg/github.com/google/blueprint/parser.a $
Import globbing from Soong Add globbing with dependency checking to blueprint. Calling ModuleContext.GlobWithDeps or SingletonContext.GlobWithDeps will return a list of files that match the globs, while also adding efficient dependencies to rerun the primary builder if a file that matches the glob is added or removed. Also use the globbing support for optional_subdirs=, subdirs= and build= lines in blueprints files. The globbing slightly changes the behavior of subname= lines, it no longer falls back to looking for a file called "Blueprints". Blueprint files that need to include a subdirectory with a different name can use build= instead of subdir= to directly include them. The Blueprints file is updated to reset subname="Blueprints" in case we want to include subdirectories inside blueprint and the primary builder has changed the subname. Also adds a new test directory that contains a simple primary builder tree to test regeneration for globbing, and runs the tests in travis. Change-Id: I83ce525fd11e11579cc58ba5308d01ca8eea7bc6
2016-11-01 19:10:51 +01:00
${g.bootstrap.buildDir}/.bootstrap/blueprint-deptools/pkg/github.com/google/blueprint/deptools.a $
Support a separate build directory To provide a consistent __FILE__ behavior with cpp, we want to be able to run with SRCDIR="." and the outputs be saved elsewhere. Other tools within android also expect to be run from $TOP. Change-Id: I572bce5c9086b0c3310b42065ae98cbf5a1c6399
2015-07-14 03:11:49 +02:00
${g.bootstrap.buildDir}/.bootstrap/blueprint-pathtools/pkg/github.com/google/blueprint/pathtools.a $
${g.bootstrap.buildDir}/.bootstrap/blueprint-proptools/pkg/github.com/google/blueprint/proptools.a $
${g.bootstrap.buildDir}/.bootstrap/blueprint/pkg/github.com/google/blueprint.a $
${g.bootstrap.buildDir}/.bootstrap/blueprint-bootstrap-bpdoc/pkg/github.com/google/blueprint/bootstrap/bpdoc.a
Import globbing from Soong Add globbing with dependency checking to blueprint. Calling ModuleContext.GlobWithDeps or SingletonContext.GlobWithDeps will return a list of files that match the globs, while also adding efficient dependencies to rerun the primary builder if a file that matches the glob is added or removed. Also use the globbing support for optional_subdirs=, subdirs= and build= lines in blueprints files. The globbing slightly changes the behavior of subname= lines, it no longer falls back to looking for a file called "Blueprints". Blueprint files that need to include a subdirectory with a different name can use build= instead of subdir= to directly include them. The Blueprints file is updated to reset subname="Blueprints" in case we want to include subdirectories inside blueprint and the primary builder has changed the subname. Also adds a new test directory that contains a simple primary builder tree to test regeneration for globbing, and runs the tests in travis. Change-Id: I83ce525fd11e11579cc58ba5308d01ca8eea7bc6
2016-11-01 19:10:51 +01:00
incFlags = -I ${g.bootstrap.buildDir}/.bootstrap/blueprint-parser/pkg -I ${g.bootstrap.buildDir}/.bootstrap/blueprint-deptools/pkg -I ${g.bootstrap.buildDir}/.bootstrap/blueprint-pathtools/pkg -I ${g.bootstrap.buildDir}/.bootstrap/blueprint-proptools/pkg -I ${g.bootstrap.buildDir}/.bootstrap/blueprint/pkg -I ${g.bootstrap.buildDir}/.bootstrap/blueprint-bootstrap-bpdoc/pkg
Update import paths to include github
2015-03-21 03:39:29 +01:00
pkgPath = github.com/google/blueprint/bootstrap
default $
Support a separate build directory To provide a consistent __FILE__ behavior with cpp, we want to be able to run with SRCDIR="." and the outputs be saved elsewhere. Other tools within android also expect to be run from $TOP. Change-Id: I572bce5c9086b0c3310b42065ae98cbf5a1c6399
2015-07-14 03:11:49 +02:00
${g.bootstrap.buildDir}/.bootstrap/blueprint-bootstrap/pkg/github.com/google/blueprint/bootstrap.a
Sort modules and singletons for output. This change causes the module and singleton content in generated Ninja files to be sorted by name. Change-Id: I6e1fe6d4211111c7dfa25ebe0fc721701a6d0256
2014-06-12 01:27:16 +02:00
Add self-documenting support The primary builder will now generate a rule to call itself with --docs=.bootstrap/docs/<name>.html to produce an automatically generated documentation file. The documentation generation process is: - Call each factory once to get empty property structs associated with the module type - Use reflection to determine the names of the type of each property struct - Use the bootstrap_go_package modules from reading the Blueprints files to find the source files for each Go package used to build the primary builder - Use the go/parser module to find the type declaration for each property struct - Extract comments for the property struct and each property declaration - Format all the comments into HTML Change-Id: Icae9307cc10549a30bfc14d6922824099de5a9b0
2015-05-13 23:36:24 +02:00
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# Module: blueprint-bootstrap-bpdoc
# Variant:
# Type: bootstrap_go_package
Add blank line after build rules, for human readability.
2015-11-09 20:37:39 +01:00
# Factory: github.com/google/blueprint/bootstrap.newGoPackageModuleFactory.func1
Import globbing from Soong Add globbing with dependency checking to blueprint. Calling ModuleContext.GlobWithDeps or SingletonContext.GlobWithDeps will return a list of files that match the globs, while also adding efficient dependencies to rerun the primary builder if a file that matches the glob is added or removed. Also use the globbing support for optional_subdirs=, subdirs= and build= lines in blueprints files. The globbing slightly changes the behavior of subname= lines, it no longer falls back to looking for a file called "Blueprints". Blueprint files that need to include a subdirectory with a different name can use build= instead of subdir= to directly include them. The Blueprints file is updated to reset subname="Blueprints" in case we want to include subdirectories inside blueprint and the primary builder has changed the subname. Also adds a new test directory that contains a simple primary builder tree to test regeneration for globbing, and runs the tests in travis. Change-Id: I83ce525fd11e11579cc58ba5308d01ca8eea7bc6
2016-11-01 19:10:51 +01:00
# Defined: Blueprints:109:1
Add self-documenting support The primary builder will now generate a rule to call itself with --docs=.bootstrap/docs/<name>.html to produce an automatically generated documentation file. The documentation generation process is: - Call each factory once to get empty property structs associated with the module type - Use reflection to determine the names of the type of each property struct - Use the bootstrap_go_package modules from reading the Blueprints files to find the source files for each Go package used to build the primary builder - Use the go/parser module to find the type declaration for each property struct - Extract comments for the property struct and each property declaration - Format all the comments into HTML Change-Id: Icae9307cc10549a30bfc14d6922824099de5a9b0
2015-05-13 23:36:24 +02:00
build $
Support a separate build directory To provide a consistent __FILE__ behavior with cpp, we want to be able to run with SRCDIR="." and the outputs be saved elsewhere. Other tools within android also expect to be run from $TOP. Change-Id: I572bce5c9086b0c3310b42065ae98cbf5a1c6399
2015-07-14 03:11:49 +02:00
${g.bootstrap.buildDir}/.bootstrap/blueprint-bootstrap-bpdoc/pkg/github.com/google/blueprint/bootstrap/bpdoc.a $
Support go 1.5 The go compiler and linker changed in v1.5 -- to 'go tool compile' and 'go tool link' instead of 6g and 6l. Move the selection logic to bootstrap.bash, and have it use compile/link if 6g/6l are missing. This way the build.ninja.in will continue working with either go 1.4 or 1.5. Travis and the test suite will fail under 1.5, since the build.ninja.in is still generated with 1.4, and the function names in the comments differ between 1.4 and 1.5.
2015-08-02 00:07:27 +02:00
: g.bootstrap.compile ${g.bootstrap.srcDir}/bootstrap/bpdoc/bpdoc.go | $
${g.bootstrap.compileCmd} $
Support a separate build directory To provide a consistent __FILE__ behavior with cpp, we want to be able to run with SRCDIR="." and the outputs be saved elsewhere. Other tools within android also expect to be run from $TOP. Change-Id: I572bce5c9086b0c3310b42065ae98cbf5a1c6399
2015-07-14 03:11:49 +02:00
${g.bootstrap.buildDir}/.bootstrap/blueprint-parser/pkg/github.com/google/blueprint/parser.a $
Import globbing from Soong Add globbing with dependency checking to blueprint. Calling ModuleContext.GlobWithDeps or SingletonContext.GlobWithDeps will return a list of files that match the globs, while also adding efficient dependencies to rerun the primary builder if a file that matches the glob is added or removed. Also use the globbing support for optional_subdirs=, subdirs= and build= lines in blueprints files. The globbing slightly changes the behavior of subname= lines, it no longer falls back to looking for a file called "Blueprints". Blueprint files that need to include a subdirectory with a different name can use build= instead of subdir= to directly include them. The Blueprints file is updated to reset subname="Blueprints" in case we want to include subdirectories inside blueprint and the primary builder has changed the subname. Also adds a new test directory that contains a simple primary builder tree to test regeneration for globbing, and runs the tests in travis. Change-Id: I83ce525fd11e11579cc58ba5308d01ca8eea7bc6
2016-11-01 19:10:51 +01:00
${g.bootstrap.buildDir}/.bootstrap/blueprint-deptools/pkg/github.com/google/blueprint/deptools.a $
Support a separate build directory To provide a consistent __FILE__ behavior with cpp, we want to be able to run with SRCDIR="." and the outputs be saved elsewhere. Other tools within android also expect to be run from $TOP. Change-Id: I572bce5c9086b0c3310b42065ae98cbf5a1c6399
2015-07-14 03:11:49 +02:00
${g.bootstrap.buildDir}/.bootstrap/blueprint-pathtools/pkg/github.com/google/blueprint/pathtools.a $
${g.bootstrap.buildDir}/.bootstrap/blueprint-proptools/pkg/github.com/google/blueprint/proptools.a $
${g.bootstrap.buildDir}/.bootstrap/blueprint/pkg/github.com/google/blueprint.a
Import globbing from Soong Add globbing with dependency checking to blueprint. Calling ModuleContext.GlobWithDeps or SingletonContext.GlobWithDeps will return a list of files that match the globs, while also adding efficient dependencies to rerun the primary builder if a file that matches the glob is added or removed. Also use the globbing support for optional_subdirs=, subdirs= and build= lines in blueprints files. The globbing slightly changes the behavior of subname= lines, it no longer falls back to looking for a file called "Blueprints". Blueprint files that need to include a subdirectory with a different name can use build= instead of subdir= to directly include them. The Blueprints file is updated to reset subname="Blueprints" in case we want to include subdirectories inside blueprint and the primary builder has changed the subname. Also adds a new test directory that contains a simple primary builder tree to test regeneration for globbing, and runs the tests in travis. Change-Id: I83ce525fd11e11579cc58ba5308d01ca8eea7bc6
2016-11-01 19:10:51 +01:00
incFlags = -I ${g.bootstrap.buildDir}/.bootstrap/blueprint-parser/pkg -I ${g.bootstrap.buildDir}/.bootstrap/blueprint-deptools/pkg -I ${g.bootstrap.buildDir}/.bootstrap/blueprint-pathtools/pkg -I ${g.bootstrap.buildDir}/.bootstrap/blueprint-proptools/pkg -I ${g.bootstrap.buildDir}/.bootstrap/blueprint/pkg
Add self-documenting support The primary builder will now generate a rule to call itself with --docs=.bootstrap/docs/<name>.html to produce an automatically generated documentation file. The documentation generation process is: - Call each factory once to get empty property structs associated with the module type - Use reflection to determine the names of the type of each property struct - Use the bootstrap_go_package modules from reading the Blueprints files to find the source files for each Go package used to build the primary builder - Use the go/parser module to find the type declaration for each property struct - Extract comments for the property struct and each property declaration - Format all the comments into HTML Change-Id: Icae9307cc10549a30bfc14d6922824099de5a9b0
2015-05-13 23:36:24 +02:00
pkgPath = github.com/google/blueprint/bootstrap/bpdoc
default $
Support a separate build directory To provide a consistent __FILE__ behavior with cpp, we want to be able to run with SRCDIR="." and the outputs be saved elsewhere. Other tools within android also expect to be run from $TOP. Change-Id: I572bce5c9086b0c3310b42065ae98cbf5a1c6399
2015-07-14 03:11:49 +02:00
${g.bootstrap.buildDir}/.bootstrap/blueprint-bootstrap-bpdoc/pkg/github.com/google/blueprint/bootstrap/bpdoc.a
Add self-documenting support The primary builder will now generate a rule to call itself with --docs=.bootstrap/docs/<name>.html to produce an automatically generated documentation file. The documentation generation process is: - Call each factory once to get empty property structs associated with the module type - Use reflection to determine the names of the type of each property struct - Use the bootstrap_go_package modules from reading the Blueprints files to find the source files for each Go package used to build the primary builder - Use the go/parser module to find the type declaration for each property struct - Extract comments for the property struct and each property declaration - Format all the comments into HTML Change-Id: Icae9307cc10549a30bfc14d6922824099de5a9b0
2015-05-13 23:36:24 +02:00
Add a Glob func that returns dirs searched Change-Id: I35ab9a5f1c7425f42d0e667bac38450afa34c738
2014-10-24 19:42:57 +02:00
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# Module: blueprint-deptools
Update import paths to include github
2015-03-21 03:39:29 +01:00
# Variant:
Add a Glob func that returns dirs searched Change-Id: I35ab9a5f1c7425f42d0e667bac38450afa34c738
2014-10-24 19:42:57 +02:00
# Type: bootstrap_go_package
Add blank line after build rules, for human readability.
2015-11-09 20:37:39 +01:00
# Factory: github.com/google/blueprint/bootstrap.newGoPackageModuleFactory.func1
Import globbing from Soong Add globbing with dependency checking to blueprint. Calling ModuleContext.GlobWithDeps or SingletonContext.GlobWithDeps will return a list of files that match the globs, while also adding efficient dependencies to rerun the primary builder if a file that matches the glob is added or removed. Also use the globbing support for optional_subdirs=, subdirs= and build= lines in blueprints files. The globbing slightly changes the behavior of subname= lines, it no longer falls back to looking for a file called "Blueprints". Blueprint files that need to include a subdirectory with a different name can use build= instead of subdir= to directly include them. The Blueprints file is updated to reset subname="Blueprints" in case we want to include subdirectories inside blueprint and the primary builder has changed the subname. Also adds a new test directory that contains a simple primary builder tree to test regeneration for globbing, and runs the tests in travis. Change-Id: I83ce525fd11e11579cc58ba5308d01ca8eea7bc6
2016-11-01 19:10:51 +01:00
# Defined: Blueprints:50:1
Add a Glob func that returns dirs searched Change-Id: I35ab9a5f1c7425f42d0e667bac38450afa34c738
2014-10-24 19:42:57 +02:00
Support a separate build directory To provide a consistent __FILE__ behavior with cpp, we want to be able to run with SRCDIR="." and the outputs be saved elsewhere. Other tools within android also expect to be run from $TOP. Change-Id: I572bce5c9086b0c3310b42065ae98cbf5a1c6399
2015-07-14 03:11:49 +02:00
build $
${g.bootstrap.buildDir}/.bootstrap/blueprint-deptools/pkg/github.com/google/blueprint/deptools.a $
Support go 1.5 The go compiler and linker changed in v1.5 -- to 'go tool compile' and 'go tool link' instead of 6g and 6l. Move the selection logic to bootstrap.bash, and have it use compile/link if 6g/6l are missing. This way the build.ninja.in will continue working with either go 1.4 or 1.5. Travis and the test suite will fail under 1.5, since the build.ninja.in is still generated with 1.4, and the function names in the comments differ between 1.4 and 1.5.
2015-08-02 00:07:27 +02:00
: g.bootstrap.compile ${g.bootstrap.srcDir}/deptools/depfile.go | $
${g.bootstrap.compileCmd}
Update import paths to include github
2015-03-21 03:39:29 +01:00
pkgPath = github.com/google/blueprint/deptools
default $
Support a separate build directory To provide a consistent __FILE__ behavior with cpp, we want to be able to run with SRCDIR="." and the outputs be saved elsewhere. Other tools within android also expect to be run from $TOP. Change-Id: I572bce5c9086b0c3310b42065ae98cbf5a1c6399
2015-07-14 03:11:49 +02:00
${g.bootstrap.buildDir}/.bootstrap/blueprint-deptools/pkg/github.com/google/blueprint/deptools.a
Add a Glob func that returns dirs searched Change-Id: I35ab9a5f1c7425f42d0e667bac38450afa34c738
2014-10-24 19:42:57 +02:00
Initial Blueprint commit. Blueprint is a build system component that reads Blueprints files defining modules to be built, and generates a Ninja build manifest that can be used to perform all the build actions. It does not dictate or implement much build policy itself, but rather provides a framework to ease the process of defining build logic in Go. The "blueprint" and "blueprint/parser" Go packages contain the functionality for reading Blueprint files and invoking build logic functions defined in other Go packages. The "blueprint/bootstrap" Go package contains just enough build logic to build a binary that includes Blueprint and any pure-Go (i.e. no cgo) build logic defined in external Go packages. This can be used to create a minimal Ninja file that's capable of bootstrapping a Blueprint-based build system from source. The "blueprint/bootstrap/minibp" Go package contains code for a minimal binary that includes the build logic defined in the "blueprint/bootstrap" package. This binary can then create the Ninja file for the bootstrapping process. Change-Id: I8d8390042372a72d225785cda738525001b009f1
2014-05-28 01:34:41 +02:00
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# Module: blueprint-parser
Update import paths to include github
2015-03-21 03:39:29 +01:00
# Variant:
Initial Blueprint commit. Blueprint is a build system component that reads Blueprints files defining modules to be built, and generates a Ninja build manifest that can be used to perform all the build actions. It does not dictate or implement much build policy itself, but rather provides a framework to ease the process of defining build logic in Go. The "blueprint" and "blueprint/parser" Go packages contain the functionality for reading Blueprint files and invoking build logic functions defined in other Go packages. The "blueprint/bootstrap" Go package contains just enough build logic to build a binary that includes Blueprint and any pure-Go (i.e. no cgo) build logic defined in external Go packages. This can be used to create a minimal Ninja file that's capable of bootstrapping a Blueprint-based build system from source. The "blueprint/bootstrap/minibp" Go package contains code for a minimal binary that includes the build logic defined in the "blueprint/bootstrap" package. This binary can then create the Ninja file for the bootstrapping process. Change-Id: I8d8390042372a72d225785cda738525001b009f1
2014-05-28 01:34:41 +02:00
# Type: bootstrap_go_package
Add blank line after build rules, for human readability.
2015-11-09 20:37:39 +01:00
# Factory: github.com/google/blueprint/bootstrap.newGoPackageModuleFactory.func1
Import globbing from Soong Add globbing with dependency checking to blueprint. Calling ModuleContext.GlobWithDeps or SingletonContext.GlobWithDeps will return a list of files that match the globs, while also adding efficient dependencies to rerun the primary builder if a file that matches the glob is added or removed. Also use the globbing support for optional_subdirs=, subdirs= and build= lines in blueprints files. The globbing slightly changes the behavior of subname= lines, it no longer falls back to looking for a file called "Blueprints". Blueprint files that need to include a subdirectory with a different name can use build= instead of subdir= to directly include them. The Blueprints file is updated to reset subname="Blueprints" in case we want to include subdirectories inside blueprint and the primary builder has changed the subname. Also adds a new test directory that contains a simple primary builder tree to test regeneration for globbing, and runs the tests in travis. Change-Id: I83ce525fd11e11579cc58ba5308d01ca8eea7bc6
2016-11-01 19:10:51 +01:00
# Defined: Blueprints:34:1
Initial Blueprint commit. Blueprint is a build system component that reads Blueprints files defining modules to be built, and generates a Ninja build manifest that can be used to perform all the build actions. It does not dictate or implement much build policy itself, but rather provides a framework to ease the process of defining build logic in Go. The "blueprint" and "blueprint/parser" Go packages contain the functionality for reading Blueprint files and invoking build logic functions defined in other Go packages. The "blueprint/bootstrap" Go package contains just enough build logic to build a binary that includes Blueprint and any pure-Go (i.e. no cgo) build logic defined in external Go packages. This can be used to create a minimal Ninja file that's capable of bootstrapping a Blueprint-based build system from source. The "blueprint/bootstrap/minibp" Go package contains code for a minimal binary that includes the build logic defined in the "blueprint/bootstrap" package. This binary can then create the Ninja file for the bootstrapping process. Change-Id: I8d8390042372a72d225785cda738525001b009f1
2014-05-28 01:34:41 +02:00
Support a separate build directory To provide a consistent __FILE__ behavior with cpp, we want to be able to run with SRCDIR="." and the outputs be saved elsewhere. Other tools within android also expect to be run from $TOP. Change-Id: I572bce5c9086b0c3310b42065ae98cbf5a1c6399
2015-07-14 03:11:49 +02:00
build $
${g.bootstrap.buildDir}/.bootstrap/blueprint-parser/pkg/github.com/google/blueprint/parser.a $
Refactor blueprint parser nodes to an interface Refactor the blueprint parser Value object, which contained a Type enum and members to hold every possible type, into an interface (now called Expression). Rename the existing Expression object that represented a binary operator Operator. Also adds and fixes some new printer test cases with mulitline expressions. Change-Id: Icf4a20f92c8c2a27f18df8ca515a9d7f282ff133
2016-06-07 21:28:16 +02:00
: g.bootstrap.compile ${g.bootstrap.srcDir}/parser/ast.go $
${g.bootstrap.srcDir}/parser/modify.go $
Move blueprint/* up a directory Make integrating with go tools easier by putting the blueprint package files in the top level directory of the git project instead of in a subdirectory called blueprint. Change-Id: I35c144c5fe7ddf34e478d0c47c50b2f6c92c2a03
2015-01-23 22:38:48 +01:00
${g.bootstrap.srcDir}/parser/parser.go $
${g.bootstrap.srcDir}/parser/printer.go $
Support go 1.5 The go compiler and linker changed in v1.5 -- to 'go tool compile' and 'go tool link' instead of 6g and 6l. Move the selection logic to bootstrap.bash, and have it use compile/link if 6g/6l are missing. This way the build.ninja.in will continue working with either go 1.4 or 1.5. Travis and the test suite will fail under 1.5, since the build.ninja.in is still generated with 1.4, and the function names in the comments differ between 1.4 and 1.5.
2015-08-02 00:07:27 +02:00
${g.bootstrap.srcDir}/parser/sort.go | ${g.bootstrap.compileCmd}
Update import paths to include github
2015-03-21 03:39:29 +01:00
pkgPath = github.com/google/blueprint/parser
Support a separate build directory To provide a consistent __FILE__ behavior with cpp, we want to be able to run with SRCDIR="." and the outputs be saved elsewhere. Other tools within android also expect to be run from $TOP. Change-Id: I572bce5c9086b0c3310b42065ae98cbf5a1c6399
2015-07-14 03:11:49 +02:00
default $
${g.bootstrap.buildDir}/.bootstrap/blueprint-parser/pkg/github.com/google/blueprint/parser.a
Initial Blueprint commit. Blueprint is a build system component that reads Blueprints files defining modules to be built, and generates a Ninja build manifest that can be used to perform all the build actions. It does not dictate or implement much build policy itself, but rather provides a framework to ease the process of defining build logic in Go. The "blueprint" and "blueprint/parser" Go packages contain the functionality for reading Blueprint files and invoking build logic functions defined in other Go packages. The "blueprint/bootstrap" Go package contains just enough build logic to build a binary that includes Blueprint and any pure-Go (i.e. no cgo) build logic defined in external Go packages. This can be used to create a minimal Ninja file that's capable of bootstrapping a Blueprint-based build system from source. The "blueprint/bootstrap/minibp" Go package contains code for a minimal binary that includes the build logic defined in the "blueprint/bootstrap" package. This binary can then create the Ninja file for the bootstrapping process. Change-Id: I8d8390042372a72d225785cda738525001b009f1
2014-05-28 01:34:41 +02:00
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
Add the blueprint/pathtools package Change-Id: I0706d8b0c0c5cbab1425c4d0b08070fd66a5900b
2014-06-06 23:37:07 +02:00
# Module: blueprint-pathtools
Update import paths to include github
2015-03-21 03:39:29 +01:00
# Variant:
Initial Blueprint commit. Blueprint is a build system component that reads Blueprints files defining modules to be built, and generates a Ninja build manifest that can be used to perform all the build actions. It does not dictate or implement much build policy itself, but rather provides a framework to ease the process of defining build logic in Go. The "blueprint" and "blueprint/parser" Go packages contain the functionality for reading Blueprint files and invoking build logic functions defined in other Go packages. The "blueprint/bootstrap" Go package contains just enough build logic to build a binary that includes Blueprint and any pure-Go (i.e. no cgo) build logic defined in external Go packages. This can be used to create a minimal Ninja file that's capable of bootstrapping a Blueprint-based build system from source. The "blueprint/bootstrap/minibp" Go package contains code for a minimal binary that includes the build logic defined in the "blueprint/bootstrap" package. This binary can then create the Ninja file for the bootstrapping process. Change-Id: I8d8390042372a72d225785cda738525001b009f1
2014-05-28 01:34:41 +02:00
# Type: bootstrap_go_package
Add blank line after build rules, for human readability.
2015-11-09 20:37:39 +01:00
# Factory: github.com/google/blueprint/bootstrap.newGoPackageModuleFactory.func1
Import globbing from Soong Add globbing with dependency checking to blueprint. Calling ModuleContext.GlobWithDeps or SingletonContext.GlobWithDeps will return a list of files that match the globs, while also adding efficient dependencies to rerun the primary builder if a file that matches the glob is added or removed. Also use the globbing support for optional_subdirs=, subdirs= and build= lines in blueprints files. The globbing slightly changes the behavior of subname= lines, it no longer falls back to looking for a file called "Blueprints". Blueprint files that need to include a subdirectory with a different name can use build= instead of subdir= to directly include them. The Blueprints file is updated to reset subname="Blueprints" in case we want to include subdirectories inside blueprint and the primary builder has changed the subname. Also adds a new test directory that contains a simple primary builder tree to test regeneration for globbing, and runs the tests in travis. Change-Id: I83ce525fd11e11579cc58ba5308d01ca8eea7bc6
2016-11-01 19:10:51 +01:00
# Defined: Blueprints:56:1
Initial Blueprint commit. Blueprint is a build system component that reads Blueprints files defining modules to be built, and generates a Ninja build manifest that can be used to perform all the build actions. It does not dictate or implement much build policy itself, but rather provides a framework to ease the process of defining build logic in Go. The "blueprint" and "blueprint/parser" Go packages contain the functionality for reading Blueprint files and invoking build logic functions defined in other Go packages. The "blueprint/bootstrap" Go package contains just enough build logic to build a binary that includes Blueprint and any pure-Go (i.e. no cgo) build logic defined in external Go packages. This can be used to create a minimal Ninja file that's capable of bootstrapping a Blueprint-based build system from source. The "blueprint/bootstrap/minibp" Go package contains code for a minimal binary that includes the build logic defined in the "blueprint/bootstrap" package. This binary can then create the Ninja file for the bootstrapping process. Change-Id: I8d8390042372a72d225785cda738525001b009f1
2014-05-28 01:34:41 +02:00
Update import paths to include github
2015-03-21 03:39:29 +01:00
build $
Support a separate build directory To provide a consistent __FILE__ behavior with cpp, we want to be able to run with SRCDIR="." and the outputs be saved elsewhere. Other tools within android also expect to be run from $TOP. Change-Id: I572bce5c9086b0c3310b42065ae98cbf5a1c6399
2015-07-14 03:11:49 +02:00
${g.bootstrap.buildDir}/.bootstrap/blueprint-pathtools/pkg/github.com/google/blueprint/pathtools.a $
Support go 1.5 The go compiler and linker changed in v1.5 -- to 'go tool compile' and 'go tool link' instead of 6g and 6l. Move the selection logic to bootstrap.bash, and have it use compile/link if 6g/6l are missing. This way the build.ninja.in will continue working with either go 1.4 or 1.5. Travis and the test suite will fail under 1.5, since the build.ninja.in is still generated with 1.4, and the function names in the comments differ between 1.4 and 1.5.
2015-08-02 00:07:27 +02:00
: g.bootstrap.compile ${g.bootstrap.srcDir}/pathtools/lists.go $
Import globbing from Soong Add globbing with dependency checking to blueprint. Calling ModuleContext.GlobWithDeps or SingletonContext.GlobWithDeps will return a list of files that match the globs, while also adding efficient dependencies to rerun the primary builder if a file that matches the glob is added or removed. Also use the globbing support for optional_subdirs=, subdirs= and build= lines in blueprints files. The globbing slightly changes the behavior of subname= lines, it no longer falls back to looking for a file called "Blueprints". Blueprint files that need to include a subdirectory with a different name can use build= instead of subdir= to directly include them. The Blueprints file is updated to reset subname="Blueprints" in case we want to include subdirectories inside blueprint and the primary builder has changed the subname. Also adds a new test directory that contains a simple primary builder tree to test regeneration for globbing, and runs the tests in travis. Change-Id: I83ce525fd11e11579cc58ba5308d01ca8eea7bc6
2016-11-01 19:10:51 +01:00
${g.bootstrap.srcDir}/pathtools/glob.go | ${g.bootstrap.compileCmd} $
${g.bootstrap.buildDir}/.bootstrap/blueprint-deptools/pkg/github.com/google/blueprint/deptools.a
incFlags = -I ${g.bootstrap.buildDir}/.bootstrap/blueprint-deptools/pkg
Update import paths to include github
2015-03-21 03:39:29 +01:00
pkgPath = github.com/google/blueprint/pathtools
default $
Support a separate build directory To provide a consistent __FILE__ behavior with cpp, we want to be able to run with SRCDIR="." and the outputs be saved elsewhere. Other tools within android also expect to be run from $TOP. Change-Id: I572bce5c9086b0c3310b42065ae98cbf5a1c6399
2015-07-14 03:11:49 +02:00
${g.bootstrap.buildDir}/.bootstrap/blueprint-pathtools/pkg/github.com/google/blueprint/pathtools.a
Add the blueprint/pathtools package Change-Id: I0706d8b0c0c5cbab1425c4d0b08070fd66a5900b
2014-06-06 23:37:07 +02:00
Add the blueprint/proptools package. This change adds some utility functions for manipulating properties structs using reflection. Change-Id: I62017ef06bceb68d536421e50b853449a73daed3
2014-10-03 03:36:13 +02:00
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# Module: blueprint-proptools
Update import paths to include github
2015-03-21 03:39:29 +01:00
# Variant:
Add the blueprint/proptools package. This change adds some utility functions for manipulating properties structs using reflection. Change-Id: I62017ef06bceb68d536421e50b853449a73daed3
2014-10-03 03:36:13 +02:00
# Type: bootstrap_go_package
Add blank line after build rules, for human readability.
2015-11-09 20:37:39 +01:00
# Factory: github.com/google/blueprint/bootstrap.newGoPackageModuleFactory.func1
Import globbing from Soong Add globbing with dependency checking to blueprint. Calling ModuleContext.GlobWithDeps or SingletonContext.GlobWithDeps will return a list of files that match the globs, while also adding efficient dependencies to rerun the primary builder if a file that matches the glob is added or removed. Also use the globbing support for optional_subdirs=, subdirs= and build= lines in blueprints files. The globbing slightly changes the behavior of subname= lines, it no longer falls back to looking for a file called "Blueprints". Blueprint files that need to include a subdirectory with a different name can use build= instead of subdir= to directly include them. The Blueprints file is updated to reset subname="Blueprints" in case we want to include subdirectories inside blueprint and the primary builder has changed the subname. Also adds a new test directory that contains a simple primary builder tree to test regeneration for globbing, and runs the tests in travis. Change-Id: I83ce525fd11e11579cc58ba5308d01ca8eea7bc6
2016-11-01 19:10:51 +01:00
# Defined: Blueprints:71:1
Add the blueprint/proptools package. This change adds some utility functions for manipulating properties structs using reflection. Change-Id: I62017ef06bceb68d536421e50b853449a73daed3
2014-10-03 03:36:13 +02:00
Update import paths to include github
2015-03-21 03:39:29 +01:00
build $
Support a separate build directory To provide a consistent __FILE__ behavior with cpp, we want to be able to run with SRCDIR="." and the outputs be saved elsewhere. Other tools within android also expect to be run from $TOP. Change-Id: I572bce5c9086b0c3310b42065ae98cbf5a1c6399
2015-07-14 03:11:49 +02:00
${g.bootstrap.buildDir}/.bootstrap/blueprint-proptools/pkg/github.com/google/blueprint/proptools.a $
Move CloneProperties to clone.go Move CloneProperties, CloneEmptyProperties, and ZeroProperties from proptools/proptools.go to proptools/clone.go.
2015-10-30 21:19:14 +01:00
: g.bootstrap.compile ${g.bootstrap.srcDir}/proptools/clone.go $
Add proptools functions to escape strings Blueprint properties that end up as command line arguments need to be both ninja and shell escaped. Provide helpers that primary builders can use to appropriately escape them. Change-Id: Ifd697d87edb1c6f0a910377835c391bbe8f95b42
2016-09-29 22:19:34 +02:00
${g.bootstrap.srcDir}/proptools/escape.go $
Move CloneProperties to clone.go Move CloneProperties, CloneEmptyProperties, and ZeroProperties from proptools/proptools.go to proptools/clone.go.
2015-10-30 21:19:14 +01:00
${g.bootstrap.srcDir}/proptools/extend.go $
Add proptools.TypeEqual When appending properties, it may be necessary to determine if two property structs are the same "type". A simple Go type comparison is not sufficient, as there may be interface{} values in the property structs that contain different types. Add proptools.TypeEqual that returns true if they have equal types and all embedded pointers to structs and interfaces to pointers to structs have the same nilitude and type.
2015-11-02 23:58:10 +01:00
${g.bootstrap.srcDir}/proptools/proptools.go $
${g.bootstrap.srcDir}/proptools/typeequal.go | $
Support go 1.5 The go compiler and linker changed in v1.5 -- to 'go tool compile' and 'go tool link' instead of 6g and 6l. Move the selection logic to bootstrap.bash, and have it use compile/link if 6g/6l are missing. This way the build.ninja.in will continue working with either go 1.4 or 1.5. Travis and the test suite will fail under 1.5, since the build.ninja.in is still generated with 1.4, and the function names in the comments differ between 1.4 and 1.5.
2015-08-02 00:07:27 +02:00
${g.bootstrap.compileCmd}
Update import paths to include github
2015-03-21 03:39:29 +01:00
pkgPath = github.com/google/blueprint/proptools
default $
Support a separate build directory To provide a consistent __FILE__ behavior with cpp, we want to be able to run with SRCDIR="." and the outputs be saved elsewhere. Other tools within android also expect to be run from $TOP. Change-Id: I572bce5c9086b0c3310b42065ae98cbf5a1c6399
2015-07-14 03:11:49 +02:00
${g.bootstrap.buildDir}/.bootstrap/blueprint-proptools/pkg/github.com/google/blueprint/proptools.a
Add the blueprint/proptools package. This change adds some utility functions for manipulating properties structs using reflection. Change-Id: I62017ef06bceb68d536421e50b853449a73daed3
2014-10-03 03:36:13 +02:00
Import globbing from Soong Add globbing with dependency checking to blueprint. Calling ModuleContext.GlobWithDeps or SingletonContext.GlobWithDeps will return a list of files that match the globs, while also adding efficient dependencies to rerun the primary builder if a file that matches the glob is added or removed. Also use the globbing support for optional_subdirs=, subdirs= and build= lines in blueprints files. The globbing slightly changes the behavior of subname= lines, it no longer falls back to looking for a file called "Blueprints". Blueprint files that need to include a subdirectory with a different name can use build= instead of subdir= to directly include them. The Blueprints file is updated to reset subname="Blueprints" in case we want to include subdirectories inside blueprint and the primary builder has changed the subname. Also adds a new test directory that contains a simple primary builder tree to test regeneration for globbing, and runs the tests in travis. Change-Id: I83ce525fd11e11579cc58ba5308d01ca8eea7bc6
2016-11-01 19:10:51 +01:00
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# Module: bpglob
# Variant:
# Type: bootstrap_core_go_binary
# Factory: github.com/google/blueprint/bootstrap.newGoBinaryModuleFactory.func1
# Defined: Blueprints:130:1
build ${g.bootstrap.buildDir}/.bootstrap/bpglob/obj/bpglob.a: $
g.bootstrap.compile ${g.bootstrap.srcDir}/bootstrap/bpglob/bpglob.go | $
${g.bootstrap.compileCmd} $
${g.bootstrap.buildDir}/.bootstrap/blueprint-deptools/pkg/github.com/google/blueprint/deptools.a $
${g.bootstrap.buildDir}/.bootstrap/blueprint-pathtools/pkg/github.com/google/blueprint/pathtools.a
incFlags = -I ${g.bootstrap.buildDir}/.bootstrap/blueprint-deptools/pkg -I ${g.bootstrap.buildDir}/.bootstrap/blueprint-pathtools/pkg
pkgPath = bpglob
default ${g.bootstrap.buildDir}/.bootstrap/bpglob/obj/bpglob.a
build ${g.bootstrap.buildDir}/.bootstrap/bpglob/obj/a.out: g.bootstrap.link $
${g.bootstrap.buildDir}/.bootstrap/bpglob/obj/bpglob.a | $
${g.bootstrap.linkCmd}
libDirFlags = -L ${g.bootstrap.buildDir}/.bootstrap/blueprint-deptools/pkg -L ${g.bootstrap.buildDir}/.bootstrap/blueprint-pathtools/pkg
default ${g.bootstrap.buildDir}/.bootstrap/bpglob/obj/a.out
build ${g.bootstrap.BinDir}/bpglob: g.bootstrap.cp $
${g.bootstrap.buildDir}/.bootstrap/bpglob/obj/a.out
default ${g.bootstrap.BinDir}/bpglob
Add option to build and run tests during bootstrap Users that want to enable this option can use the '-t' option to bootstrap.bash when passing '-r'. Builders that want to enable this can set the RUN_TESTS environment variable in their bootstrap.bash. The gotestmain tools is needed to write the main functions for the test binaries, since 'go test' doesn't work well in this environment. Change-Id: Iec5c2b5c9c3f5e3ba0ac8677fb88f5e963f9bd3f
2015-06-24 02:21:00 +02:00
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# Module: gotestmain
# Variant:
Use three stage builds This splits the current bootstrap stage into two stages: A bootstrap stage, which like today, a reference is checked into the tree. It just builds the "core" blueprint binaries -- minibp, gotestmain, and choosestage. Just enough to build the next stage's ninja file. A primary builder stage. This builds the primary builder, the main ninja file, and any other bootstrap binaries (bpfmt, etc). The main advantage here is that the checked in file really only contains references to blueprint -- not the primary builder. This will allow us to make the primary builder more dynamic, by loading more module types that may or may not exist in all trees. It's even possible to reuse the build.ninja.in in the blueprint repo directly now. We don't currently do that, since we still want to turn on tests. Change-Id: I18683891ed7348b0d7af93084e3a68a04fbd5dbc
2015-07-23 02:06:06 +02:00
# Type: bootstrap_core_go_binary
Add blank line after build rules, for human readability.
2015-11-09 20:37:39 +01:00
# Factory: github.com/google/blueprint/bootstrap.newGoBinaryModuleFactory.func1
Import globbing from Soong Add globbing with dependency checking to blueprint. Calling ModuleContext.GlobWithDeps or SingletonContext.GlobWithDeps will return a list of files that match the globs, while also adding efficient dependencies to rerun the primary builder if a file that matches the glob is added or removed. Also use the globbing support for optional_subdirs=, subdirs= and build= lines in blueprints files. The globbing slightly changes the behavior of subname= lines, it no longer falls back to looking for a file called "Blueprints". Blueprint files that need to include a subdirectory with a different name can use build= instead of subdir= to directly include them. The Blueprints file is updated to reset subname="Blueprints" in case we want to include subdirectories inside blueprint and the primary builder has changed the subname. Also adds a new test directory that contains a simple primary builder tree to test regeneration for globbing, and runs the tests in travis. Change-Id: I83ce525fd11e11579cc58ba5308d01ca8eea7bc6
2016-11-01 19:10:51 +01:00
# Defined: Blueprints:148:1
Add option to build and run tests during bootstrap Users that want to enable this option can use the '-t' option to bootstrap.bash when passing '-r'. Builders that want to enable this can set the RUN_TESTS environment variable in their bootstrap.bash. The gotestmain tools is needed to write the main functions for the test binaries, since 'go test' doesn't work well in this environment. Change-Id: Iec5c2b5c9c3f5e3ba0ac8677fb88f5e963f9bd3f
2015-06-24 02:21:00 +02:00
Support a separate build directory To provide a consistent __FILE__ behavior with cpp, we want to be able to run with SRCDIR="." and the outputs be saved elsewhere. Other tools within android also expect to be run from $TOP. Change-Id: I572bce5c9086b0c3310b42065ae98cbf5a1c6399
2015-07-14 03:11:49 +02:00
build ${g.bootstrap.buildDir}/.bootstrap/gotestmain/obj/gotestmain.a: $
Support go 1.5 The go compiler and linker changed in v1.5 -- to 'go tool compile' and 'go tool link' instead of 6g and 6l. Move the selection logic to bootstrap.bash, and have it use compile/link if 6g/6l are missing. This way the build.ninja.in will continue working with either go 1.4 or 1.5. Travis and the test suite will fail under 1.5, since the build.ninja.in is still generated with 1.4, and the function names in the comments differ between 1.4 and 1.5.
2015-08-02 00:07:27 +02:00
g.bootstrap.compile ${g.bootstrap.srcDir}/gotestmain/gotestmain.go | $
${g.bootstrap.compileCmd}
Add option to build and run tests during bootstrap Users that want to enable this option can use the '-t' option to bootstrap.bash when passing '-r'. Builders that want to enable this can set the RUN_TESTS environment variable in their bootstrap.bash. The gotestmain tools is needed to write the main functions for the test binaries, since 'go test' doesn't work well in this environment. Change-Id: Iec5c2b5c9c3f5e3ba0ac8677fb88f5e963f9bd3f
2015-06-24 02:21:00 +02:00
pkgPath = gotestmain
Support a separate build directory To provide a consistent __FILE__ behavior with cpp, we want to be able to run with SRCDIR="." and the outputs be saved elsewhere. Other tools within android also expect to be run from $TOP. Change-Id: I572bce5c9086b0c3310b42065ae98cbf5a1c6399
2015-07-14 03:11:49 +02:00
default ${g.bootstrap.buildDir}/.bootstrap/gotestmain/obj/gotestmain.a
Add option to build and run tests during bootstrap Users that want to enable this option can use the '-t' option to bootstrap.bash when passing '-r'. Builders that want to enable this can set the RUN_TESTS environment variable in their bootstrap.bash. The gotestmain tools is needed to write the main functions for the test binaries, since 'go test' doesn't work well in this environment. Change-Id: Iec5c2b5c9c3f5e3ba0ac8677fb88f5e963f9bd3f
2015-06-24 02:21:00 +02:00
Support a separate build directory To provide a consistent __FILE__ behavior with cpp, we want to be able to run with SRCDIR="." and the outputs be saved elsewhere. Other tools within android also expect to be run from $TOP. Change-Id: I572bce5c9086b0c3310b42065ae98cbf5a1c6399
2015-07-14 03:11:49 +02:00
build ${g.bootstrap.buildDir}/.bootstrap/gotestmain/obj/a.out: $
g.bootstrap.link $
${g.bootstrap.buildDir}/.bootstrap/gotestmain/obj/gotestmain.a | $
${g.bootstrap.linkCmd}
default ${g.bootstrap.buildDir}/.bootstrap/gotestmain/obj/a.out
Add blank line after build rules, for human readability.
2015-11-09 20:37:39 +01:00
Switch bootstrap.BinDir to a StaticVariable API Change -- will require changes to any code using bootstrap.BinDir This way we can put references to other variables in BinDir, and still be used properly by other packages. Change-Id: I497424cb254b3a170401ac9420fa0adbf8d11d1e
2015-07-14 08:28:37 +02:00
build ${g.bootstrap.BinDir}/gotestmain: g.bootstrap.cp $
Support a separate build directory To provide a consistent __FILE__ behavior with cpp, we want to be able to run with SRCDIR="." and the outputs be saved elsewhere. Other tools within android also expect to be run from $TOP. Change-Id: I572bce5c9086b0c3310b42065ae98cbf5a1c6399
2015-07-14 03:11:49 +02:00
${g.bootstrap.buildDir}/.bootstrap/gotestmain/obj/a.out
Switch bootstrap.BinDir to a StaticVariable API Change -- will require changes to any code using bootstrap.BinDir This way we can put references to other variables in BinDir, and still be used properly by other packages. Change-Id: I497424cb254b3a170401ac9420fa0adbf8d11d1e
2015-07-14 08:28:37 +02:00
default ${g.bootstrap.BinDir}/gotestmain
Add option to build and run tests during bootstrap Users that want to enable this option can use the '-t' option to bootstrap.bash when passing '-r'. Builders that want to enable this can set the RUN_TESTS environment variable in their bootstrap.bash. The gotestmain tools is needed to write the main functions for the test binaries, since 'go test' doesn't work well in this environment. Change-Id: Iec5c2b5c9c3f5e3ba0ac8677fb88f5e963f9bd3f
2015-06-24 02:21:00 +02:00
Add a test runner This removes the need to use $OLDPWD when running tests, which means that the builddir may be an absolute or relative directory. It also filters out the "PASS" message on successful test runs to clean up our output. Change-Id: I4ab937c7a87b74fe997a47cc0311e2f357f9f7e9
2015-09-18 05:59:51 +02:00
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# Module: gotestrunner
# Variant:
# Type: bootstrap_core_go_binary
Add blank line after build rules, for human readability.
2015-11-09 20:37:39 +01:00
# Factory: github.com/google/blueprint/bootstrap.newGoBinaryModuleFactory.func1
Import globbing from Soong Add globbing with dependency checking to blueprint. Calling ModuleContext.GlobWithDeps or SingletonContext.GlobWithDeps will return a list of files that match the globs, while also adding efficient dependencies to rerun the primary builder if a file that matches the glob is added or removed. Also use the globbing support for optional_subdirs=, subdirs= and build= lines in blueprints files. The globbing slightly changes the behavior of subname= lines, it no longer falls back to looking for a file called "Blueprints". Blueprint files that need to include a subdirectory with a different name can use build= instead of subdir= to directly include them. The Blueprints file is updated to reset subname="Blueprints" in case we want to include subdirectories inside blueprint and the primary builder has changed the subname. Also adds a new test directory that contains a simple primary builder tree to test regeneration for globbing, and runs the tests in travis. Change-Id: I83ce525fd11e11579cc58ba5308d01ca8eea7bc6
2016-11-01 19:10:51 +01:00
# Defined: Blueprints:153:1
Add a test runner This removes the need to use $OLDPWD when running tests, which means that the builddir may be an absolute or relative directory. It also filters out the "PASS" message on successful test runs to clean up our output. Change-Id: I4ab937c7a87b74fe997a47cc0311e2f357f9f7e9
2015-09-18 05:59:51 +02:00
build ${g.bootstrap.buildDir}/.bootstrap/gotestrunner/obj/gotestrunner.a: $
g.bootstrap.compile ${g.bootstrap.srcDir}/gotestrunner/gotestrunner.go $
| ${g.bootstrap.compileCmd}
pkgPath = gotestrunner
default ${g.bootstrap.buildDir}/.bootstrap/gotestrunner/obj/gotestrunner.a
build ${g.bootstrap.buildDir}/.bootstrap/gotestrunner/obj/a.out: $
g.bootstrap.link $
${g.bootstrap.buildDir}/.bootstrap/gotestrunner/obj/gotestrunner.a | $
${g.bootstrap.linkCmd}
default ${g.bootstrap.buildDir}/.bootstrap/gotestrunner/obj/a.out
Add blank line after build rules, for human readability.
2015-11-09 20:37:39 +01:00
Add a test runner This removes the need to use $OLDPWD when running tests, which means that the builddir may be an absolute or relative directory. It also filters out the "PASS" message on successful test runs to clean up our output. Change-Id: I4ab937c7a87b74fe997a47cc0311e2f357f9f7e9
2015-09-18 05:59:51 +02:00
build ${g.bootstrap.BinDir}/gotestrunner: g.bootstrap.cp $
${g.bootstrap.buildDir}/.bootstrap/gotestrunner/obj/a.out
default ${g.bootstrap.BinDir}/gotestrunner
Initial Blueprint commit. Blueprint is a build system component that reads Blueprints files defining modules to be built, and generates a Ninja build manifest that can be used to perform all the build actions. It does not dictate or implement much build policy itself, but rather provides a framework to ease the process of defining build logic in Go. The "blueprint" and "blueprint/parser" Go packages contain the functionality for reading Blueprint files and invoking build logic functions defined in other Go packages. The "blueprint/bootstrap" Go package contains just enough build logic to build a binary that includes Blueprint and any pure-Go (i.e. no cgo) build logic defined in external Go packages. This can be used to create a minimal Ninja file that's capable of bootstrapping a Blueprint-based build system from source. The "blueprint/bootstrap/minibp" Go package contains code for a minimal binary that includes the build logic defined in the "blueprint/bootstrap" package. This binary can then create the Ninja file for the bootstrapping process. Change-Id: I8d8390042372a72d225785cda738525001b009f1
2014-05-28 01:34:41 +02:00
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# Module: minibp
Update import paths to include github
2015-03-21 03:39:29 +01:00
# Variant:
Use three stage builds This splits the current bootstrap stage into two stages: A bootstrap stage, which like today, a reference is checked into the tree. It just builds the "core" blueprint binaries -- minibp, gotestmain, and choosestage. Just enough to build the next stage's ninja file. A primary builder stage. This builds the primary builder, the main ninja file, and any other bootstrap binaries (bpfmt, etc). The main advantage here is that the checked in file really only contains references to blueprint -- not the primary builder. This will allow us to make the primary builder more dynamic, by loading more module types that may or may not exist in all trees. It's even possible to reuse the build.ninja.in in the blueprint repo directly now. We don't currently do that, since we still want to turn on tests. Change-Id: I18683891ed7348b0d7af93084e3a68a04fbd5dbc
2015-07-23 02:06:06 +02:00
# Type: bootstrap_core_go_binary
Add blank line after build rules, for human readability.
2015-11-09 20:37:39 +01:00
# Factory: github.com/google/blueprint/bootstrap.newGoBinaryModuleFactory.func1
Import globbing from Soong Add globbing with dependency checking to blueprint. Calling ModuleContext.GlobWithDeps or SingletonContext.GlobWithDeps will return a list of files that match the globs, while also adding efficient dependencies to rerun the primary builder if a file that matches the glob is added or removed. Also use the globbing support for optional_subdirs=, subdirs= and build= lines in blueprints files. The globbing slightly changes the behavior of subname= lines, it no longer falls back to looking for a file called "Blueprints". Blueprint files that need to include a subdirectory with a different name can use build= instead of subdir= to directly include them. The Blueprints file is updated to reset subname="Blueprints" in case we want to include subdirectories inside blueprint and the primary builder has changed the subname. Also adds a new test directory that contains a simple primary builder tree to test regeneration for globbing, and runs the tests in travis. Change-Id: I83ce525fd11e11579cc58ba5308d01ca8eea7bc6
2016-11-01 19:10:51 +01:00
# Defined: Blueprints:121:1
Initial Blueprint commit. Blueprint is a build system component that reads Blueprints files defining modules to be built, and generates a Ninja build manifest that can be used to perform all the build actions. It does not dictate or implement much build policy itself, but rather provides a framework to ease the process of defining build logic in Go. The "blueprint" and "blueprint/parser" Go packages contain the functionality for reading Blueprint files and invoking build logic functions defined in other Go packages. The "blueprint/bootstrap" Go package contains just enough build logic to build a binary that includes Blueprint and any pure-Go (i.e. no cgo) build logic defined in external Go packages. This can be used to create a minimal Ninja file that's capable of bootstrapping a Blueprint-based build system from source. The "blueprint/bootstrap/minibp" Go package contains code for a minimal binary that includes the build logic defined in the "blueprint/bootstrap" package. This binary can then create the Ninja file for the bootstrapping process. Change-Id: I8d8390042372a72d225785cda738525001b009f1
2014-05-28 01:34:41 +02:00
Support go 1.5 The go compiler and linker changed in v1.5 -- to 'go tool compile' and 'go tool link' instead of 6g and 6l. Move the selection logic to bootstrap.bash, and have it use compile/link if 6g/6l are missing. This way the build.ninja.in will continue working with either go 1.4 or 1.5. Travis and the test suite will fail under 1.5, since the build.ninja.in is still generated with 1.4, and the function names in the comments differ between 1.4 and 1.5.
2015-08-02 00:07:27 +02:00
build ${g.bootstrap.buildDir}/.bootstrap/minibp/obj/minibp.a: $
g.bootstrap.compile ${g.bootstrap.srcDir}/bootstrap/minibp/main.go | $
${g.bootstrap.compileCmd} $
Support a separate build directory To provide a consistent __FILE__ behavior with cpp, we want to be able to run with SRCDIR="." and the outputs be saved elsewhere. Other tools within android also expect to be run from $TOP. Change-Id: I572bce5c9086b0c3310b42065ae98cbf5a1c6399
2015-07-14 03:11:49 +02:00
${g.bootstrap.buildDir}/.bootstrap/blueprint-parser/pkg/github.com/google/blueprint/parser.a $
Import globbing from Soong Add globbing with dependency checking to blueprint. Calling ModuleContext.GlobWithDeps or SingletonContext.GlobWithDeps will return a list of files that match the globs, while also adding efficient dependencies to rerun the primary builder if a file that matches the glob is added or removed. Also use the globbing support for optional_subdirs=, subdirs= and build= lines in blueprints files. The globbing slightly changes the behavior of subname= lines, it no longer falls back to looking for a file called "Blueprints". Blueprint files that need to include a subdirectory with a different name can use build= instead of subdir= to directly include them. The Blueprints file is updated to reset subname="Blueprints" in case we want to include subdirectories inside blueprint and the primary builder has changed the subname. Also adds a new test directory that contains a simple primary builder tree to test regeneration for globbing, and runs the tests in travis. Change-Id: I83ce525fd11e11579cc58ba5308d01ca8eea7bc6
2016-11-01 19:10:51 +01:00
${g.bootstrap.buildDir}/.bootstrap/blueprint-deptools/pkg/github.com/google/blueprint/deptools.a $
Support a separate build directory To provide a consistent __FILE__ behavior with cpp, we want to be able to run with SRCDIR="." and the outputs be saved elsewhere. Other tools within android also expect to be run from $TOP. Change-Id: I572bce5c9086b0c3310b42065ae98cbf5a1c6399
2015-07-14 03:11:49 +02:00
${g.bootstrap.buildDir}/.bootstrap/blueprint-pathtools/pkg/github.com/google/blueprint/pathtools.a $
${g.bootstrap.buildDir}/.bootstrap/blueprint-proptools/pkg/github.com/google/blueprint/proptools.a $
${g.bootstrap.buildDir}/.bootstrap/blueprint/pkg/github.com/google/blueprint.a $
${g.bootstrap.buildDir}/.bootstrap/blueprint-bootstrap-bpdoc/pkg/github.com/google/blueprint/bootstrap/bpdoc.a $
${g.bootstrap.buildDir}/.bootstrap/blueprint-bootstrap/pkg/github.com/google/blueprint/bootstrap.a
Import globbing from Soong Add globbing with dependency checking to blueprint. Calling ModuleContext.GlobWithDeps or SingletonContext.GlobWithDeps will return a list of files that match the globs, while also adding efficient dependencies to rerun the primary builder if a file that matches the glob is added or removed. Also use the globbing support for optional_subdirs=, subdirs= and build= lines in blueprints files. The globbing slightly changes the behavior of subname= lines, it no longer falls back to looking for a file called "Blueprints". Blueprint files that need to include a subdirectory with a different name can use build= instead of subdir= to directly include them. The Blueprints file is updated to reset subname="Blueprints" in case we want to include subdirectories inside blueprint and the primary builder has changed the subname. Also adds a new test directory that contains a simple primary builder tree to test regeneration for globbing, and runs the tests in travis. Change-Id: I83ce525fd11e11579cc58ba5308d01ca8eea7bc6
2016-11-01 19:10:51 +01:00
incFlags = -I ${g.bootstrap.buildDir}/.bootstrap/blueprint-parser/pkg -I ${g.bootstrap.buildDir}/.bootstrap/blueprint-deptools/pkg -I ${g.bootstrap.buildDir}/.bootstrap/blueprint-pathtools/pkg -I ${g.bootstrap.buildDir}/.bootstrap/blueprint-proptools/pkg -I ${g.bootstrap.buildDir}/.bootstrap/blueprint/pkg -I ${g.bootstrap.buildDir}/.bootstrap/blueprint-bootstrap-bpdoc/pkg -I ${g.bootstrap.buildDir}/.bootstrap/blueprint-bootstrap/pkg
Initial Blueprint commit. Blueprint is a build system component that reads Blueprints files defining modules to be built, and generates a Ninja build manifest that can be used to perform all the build actions. It does not dictate or implement much build policy itself, but rather provides a framework to ease the process of defining build logic in Go. The "blueprint" and "blueprint/parser" Go packages contain the functionality for reading Blueprint files and invoking build logic functions defined in other Go packages. The "blueprint/bootstrap" Go package contains just enough build logic to build a binary that includes Blueprint and any pure-Go (i.e. no cgo) build logic defined in external Go packages. This can be used to create a minimal Ninja file that's capable of bootstrapping a Blueprint-based build system from source. The "blueprint/bootstrap/minibp" Go package contains code for a minimal binary that includes the build logic defined in the "blueprint/bootstrap" package. This binary can then create the Ninja file for the bootstrapping process. Change-Id: I8d8390042372a72d225785cda738525001b009f1
2014-05-28 01:34:41 +02:00
pkgPath = minibp
Support a separate build directory To provide a consistent __FILE__ behavior with cpp, we want to be able to run with SRCDIR="." and the outputs be saved elsewhere. Other tools within android also expect to be run from $TOP. Change-Id: I572bce5c9086b0c3310b42065ae98cbf5a1c6399
2015-07-14 03:11:49 +02:00
default ${g.bootstrap.buildDir}/.bootstrap/minibp/obj/minibp.a
Initial Blueprint commit. Blueprint is a build system component that reads Blueprints files defining modules to be built, and generates a Ninja build manifest that can be used to perform all the build actions. It does not dictate or implement much build policy itself, but rather provides a framework to ease the process of defining build logic in Go. The "blueprint" and "blueprint/parser" Go packages contain the functionality for reading Blueprint files and invoking build logic functions defined in other Go packages. The "blueprint/bootstrap" Go package contains just enough build logic to build a binary that includes Blueprint and any pure-Go (i.e. no cgo) build logic defined in external Go packages. This can be used to create a minimal Ninja file that's capable of bootstrapping a Blueprint-based build system from source. The "blueprint/bootstrap/minibp" Go package contains code for a minimal binary that includes the build logic defined in the "blueprint/bootstrap" package. This binary can then create the Ninja file for the bootstrapping process. Change-Id: I8d8390042372a72d225785cda738525001b009f1
2014-05-28 01:34:41 +02:00
Support a separate build directory To provide a consistent __FILE__ behavior with cpp, we want to be able to run with SRCDIR="." and the outputs be saved elsewhere. Other tools within android also expect to be run from $TOP. Change-Id: I572bce5c9086b0c3310b42065ae98cbf5a1c6399
2015-07-14 03:11:49 +02:00
build ${g.bootstrap.buildDir}/.bootstrap/minibp/obj/a.out: g.bootstrap.link $
${g.bootstrap.buildDir}/.bootstrap/minibp/obj/minibp.a | $
${g.bootstrap.linkCmd}
Import globbing from Soong Add globbing with dependency checking to blueprint. Calling ModuleContext.GlobWithDeps or SingletonContext.GlobWithDeps will return a list of files that match the globs, while also adding efficient dependencies to rerun the primary builder if a file that matches the glob is added or removed. Also use the globbing support for optional_subdirs=, subdirs= and build= lines in blueprints files. The globbing slightly changes the behavior of subname= lines, it no longer falls back to looking for a file called "Blueprints". Blueprint files that need to include a subdirectory with a different name can use build= instead of subdir= to directly include them. The Blueprints file is updated to reset subname="Blueprints" in case we want to include subdirectories inside blueprint and the primary builder has changed the subname. Also adds a new test directory that contains a simple primary builder tree to test regeneration for globbing, and runs the tests in travis. Change-Id: I83ce525fd11e11579cc58ba5308d01ca8eea7bc6
2016-11-01 19:10:51 +01:00
libDirFlags = -L ${g.bootstrap.buildDir}/.bootstrap/blueprint-parser/pkg -L ${g.bootstrap.buildDir}/.bootstrap/blueprint-deptools/pkg -L ${g.bootstrap.buildDir}/.bootstrap/blueprint-pathtools/pkg -L ${g.bootstrap.buildDir}/.bootstrap/blueprint-proptools/pkg -L ${g.bootstrap.buildDir}/.bootstrap/blueprint/pkg -L ${g.bootstrap.buildDir}/.bootstrap/blueprint-bootstrap-bpdoc/pkg -L ${g.bootstrap.buildDir}/.bootstrap/blueprint-bootstrap/pkg
Support a separate build directory To provide a consistent __FILE__ behavior with cpp, we want to be able to run with SRCDIR="." and the outputs be saved elsewhere. Other tools within android also expect to be run from $TOP. Change-Id: I572bce5c9086b0c3310b42065ae98cbf5a1c6399
2015-07-14 03:11:49 +02:00
default ${g.bootstrap.buildDir}/.bootstrap/minibp/obj/a.out
Initial Blueprint commit. Blueprint is a build system component that reads Blueprints files defining modules to be built, and generates a Ninja build manifest that can be used to perform all the build actions. It does not dictate or implement much build policy itself, but rather provides a framework to ease the process of defining build logic in Go. The "blueprint" and "blueprint/parser" Go packages contain the functionality for reading Blueprint files and invoking build logic functions defined in other Go packages. The "blueprint/bootstrap" Go package contains just enough build logic to build a binary that includes Blueprint and any pure-Go (i.e. no cgo) build logic defined in external Go packages. This can be used to create a minimal Ninja file that's capable of bootstrapping a Blueprint-based build system from source. The "blueprint/bootstrap/minibp" Go package contains code for a minimal binary that includes the build logic defined in the "blueprint/bootstrap" package. This binary can then create the Ninja file for the bootstrapping process. Change-Id: I8d8390042372a72d225785cda738525001b009f1
2014-05-28 01:34:41 +02:00
Support a separate build directory To provide a consistent __FILE__ behavior with cpp, we want to be able to run with SRCDIR="." and the outputs be saved elsewhere. Other tools within android also expect to be run from $TOP. Change-Id: I572bce5c9086b0c3310b42065ae98cbf5a1c6399
2015-07-14 03:11:49 +02:00
build ${g.bootstrap.BinDir}/minibp: g.bootstrap.cp $
${g.bootstrap.buildDir}/.bootstrap/minibp/obj/a.out
Switch bootstrap.BinDir to a StaticVariable API Change -- will require changes to any code using bootstrap.BinDir This way we can put references to other variables in BinDir, and still be used properly by other packages. Change-Id: I497424cb254b3a170401ac9420fa0adbf8d11d1e
2015-07-14 08:28:37 +02:00
default ${g.bootstrap.BinDir}/minibp
Initial Blueprint commit. Blueprint is a build system component that reads Blueprints files defining modules to be built, and generates a Ninja build manifest that can be used to perform all the build actions. It does not dictate or implement much build policy itself, but rather provides a framework to ease the process of defining build logic in Go. The "blueprint" and "blueprint/parser" Go packages contain the functionality for reading Blueprint files and invoking build logic functions defined in other Go packages. The "blueprint/bootstrap" Go package contains just enough build logic to build a binary that includes Blueprint and any pure-Go (i.e. no cgo) build logic defined in external Go packages. This can be used to create a minimal Ninja file that's capable of bootstrapping a Blueprint-based build system from source. The "blueprint/bootstrap/minibp" Go package contains code for a minimal binary that includes the build logic defined in the "blueprint/bootstrap" package. This binary can then create the Ninja file for the bootstrapping process. Change-Id: I8d8390042372a72d225785cda738525001b009f1
2014-05-28 01:34:41 +02:00
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# Singleton: bootstrap
Add blank line after build rules, for human readability.
2015-11-09 20:37:39 +01:00
# Factory: github.com/google/blueprint/bootstrap.newSingletonFactory.func1
Use three stage builds This splits the current bootstrap stage into two stages: A bootstrap stage, which like today, a reference is checked into the tree. It just builds the "core" blueprint binaries -- minibp, gotestmain, and choosestage. Just enough to build the next stage's ninja file. A primary builder stage. This builds the primary builder, the main ninja file, and any other bootstrap binaries (bpfmt, etc). The main advantage here is that the checked in file really only contains references to blueprint -- not the primary builder. This will allow us to make the primary builder more dynamic, by loading more module types that may or may not exist in all trees. It's even possible to reuse the build.ninja.in in the blueprint repo directly now. We don't currently do that, since we still want to turn on tests. Change-Id: I18683891ed7348b0d7af93084e3a68a04fbd5dbc
2015-07-23 02:06:06 +02:00
Allow build.ninja regeneration (fix Soong globs) Soong (and soon, Blueprint) embeds the results of filesystem globs into the build.ninja, and uses a helper tool to detect when the glob changes and we need to rebuild the build.ninja file. This is more flexible than listing the affected directories in the depfiles, since it can check to see if a file we actually cared about was added, instead of re-running anytime any file was added/removed (which happens on atomic file modifications as well). My recent bootstrap simplification broke this, since the helper rules are in the main build.ninja, but I removed the ability to regenerate that file from itself. So keep the current model, but add a rule into the primary and main stages that allow themselves to re-run their generator and write out a new build.ninja file if necessary. The actual build rules of the generator aren't necessary, since we already built them in the previous stage. Change-Id: Ib51245920b2ec3ee5306c0c269361a5a8733caa8
2016-11-02 01:12:28 +01:00
build ${g.bootstrap.buildDir}/.bootstrap/build.ninja: g.bootstrap.build.ninja $
Clean up unnecessary dependencies Other than cleaning up the code, the only change in behavior is to run the docs build in parallel with the primary builder, saving about a second on a Soong bootstrap (10s -> 9s). Change-Id: Iaff51d6d1a37af842f294f12db11d5774d48d440
2016-11-02 06:44:25 +01:00
${g.bootstrap.srcDir}/Blueprints | ${builder}
Allow build.ninja regeneration (fix Soong globs) Soong (and soon, Blueprint) embeds the results of filesystem globs into the build.ninja, and uses a helper tool to detect when the glob changes and we need to rebuild the build.ninja file. This is more flexible than listing the affected directories in the depfiles, since it can check to see if a file we actually cared about was added, instead of re-running anytime any file was added/removed (which happens on atomic file modifications as well). My recent bootstrap simplification broke this, since the helper rules are in the main build.ninja, but I removed the ability to regenerate that file from itself. So keep the current model, but add a rule into the primary and main stages that allow themselves to re-run their generator and write out a new build.ninja file if necessary. The actual build rules of the generator aren't necessary, since we already built them in the previous stage. Change-Id: Ib51245920b2ec3ee5306c0c269361a5a8733caa8
2016-11-02 01:12:28 +01:00
builder = ${g.bootstrap.BinDir}/minibp
extra = --build-primary
Simplify bootstrap tl;dr: Read if you don't use the wrapper or use SKIP_NINJA Previously, we were relying on the ninja behavior of restarting the build when the build.ninja file was updated to switch between different bootstrap stages. But that means that every step that could produce a build.ninja must pass in order to switch to a different stage. That wasn't a big problem when we had a two stage build -- there was very little that could fail in the second stage before we chose to go back to the first stage. But when we had a three stage build, it was possible to get into a state (usually during development) where you were in the second stage, but the build was failing because the first stage needed to be run. This was fixed in d79f1af7423e0ef7a13573efdae5100a57fabc82 by adding a wrapper that always started building at the first stage. But this kept all of the complexity of using ninja restarts without any of the benefits, so this change removes that complexity and just runs each stage sequentially in the wrapper. So the wrapper is now required. Since we're no longer going through choosestage, we can also skip the template parsing for the later stages that don't need to be templated -- this can save a couple of seconds for large files. In addition to all of the above, this also lets Soong reduce the number of times the main ninja file is loaded. We had been running the wrapper once (3 stages), then running ninja again after combining the Soong-generated build.ninja with the Kati-generated build.ninja. This change lets us removing the intermediate parsing of Soong's build.ninja, so that we only execute ninja 3 times per build. It also lets us have dependencies on pools or rules from Kati in the primary builder, since we're never executing the main build.ninja without the Kati build.ninja. The wrapper has a new option, NINJA to provide the path to ninja. This used to be hardcoded to `ninja`, and will still default to that. But we'll be running the first two bootstrap stages with $NINJA even if SKIP_NINJA is set. The wrapper passes "-w dupbuild=err" to ninja now -- this really should always be turned on if you care about reliable builds. Change-Id: I6f656b74eb3d064b8b9e69d1d6dac1129d72b747
2016-08-13 21:42:11 +02:00
default ${g.bootstrap.buildDir}/.bootstrap/build.ninja
Support a separate build directory To provide a consistent __FILE__ behavior with cpp, we want to be able to run with SRCDIR="." and the outputs be saved elsewhere. Other tools within android also expect to be run from $TOP. Change-Id: I572bce5c9086b0c3310b42065ae98cbf5a1c6399
2015-07-14 03:11:49 +02:00
Simplify bootstrap tl;dr: Read if you don't use the wrapper or use SKIP_NINJA Previously, we were relying on the ninja behavior of restarting the build when the build.ninja file was updated to switch between different bootstrap stages. But that means that every step that could produce a build.ninja must pass in order to switch to a different stage. That wasn't a big problem when we had a two stage build -- there was very little that could fail in the second stage before we chose to go back to the first stage. But when we had a three stage build, it was possible to get into a state (usually during development) where you were in the second stage, but the build was failing because the first stage needed to be run. This was fixed in d79f1af7423e0ef7a13573efdae5100a57fabc82 by adding a wrapper that always started building at the first stage. But this kept all of the complexity of using ninja restarts without any of the benefits, so this change removes that complexity and just runs each stage sequentially in the wrapper. So the wrapper is now required. Since we're no longer going through choosestage, we can also skip the template parsing for the later stages that don't need to be templated -- this can save a couple of seconds for large files. In addition to all of the above, this also lets Soong reduce the number of times the main ninja file is loaded. We had been running the wrapper once (3 stages), then running ninja again after combining the Soong-generated build.ninja with the Kati-generated build.ninja. This change lets us removing the intermediate parsing of Soong's build.ninja, so that we only execute ninja 3 times per build. It also lets us have dependencies on pools or rules from Kati in the primary builder, since we're never executing the main build.ninja without the Kati build.ninja. The wrapper has a new option, NINJA to provide the path to ninja. This used to be hardcoded to `ninja`, and will still default to that. But we'll be running the first two bootstrap stages with $NINJA even if SKIP_NINJA is set. The wrapper passes "-w dupbuild=err" to ninja now -- this really should always be turned on if you care about reliable builds. Change-Id: I6f656b74eb3d064b8b9e69d1d6dac1129d72b747
2016-08-13 21:42:11 +02:00
build ${g.bootstrap.buildDir}/.minibootstrap/build.ninja.in: $
Allow build.ninja regeneration (fix Soong globs) Soong (and soon, Blueprint) embeds the results of filesystem globs into the build.ninja, and uses a helper tool to detect when the glob changes and we need to rebuild the build.ninja file. This is more flexible than listing the affected directories in the depfiles, since it can check to see if a file we actually cared about was added, instead of re-running anytime any file was added/removed (which happens on atomic file modifications as well). My recent bootstrap simplification broke this, since the helper rules are in the main build.ninja, but I removed the ability to regenerate that file from itself. So keep the current model, but add a rule into the primary and main stages that allow themselves to re-run their generator and write out a new build.ninja file if necessary. The actual build rules of the generator aren't necessary, since we already built them in the previous stage. Change-Id: Ib51245920b2ec3ee5306c0c269361a5a8733caa8
2016-11-02 01:12:28 +01:00
g.bootstrap.build.ninja ${g.bootstrap.srcDir}/Blueprints | ${builder}
builder = ${g.bootstrap.BinDir}/minibp
extra =
Simplify bootstrap tl;dr: Read if you don't use the wrapper or use SKIP_NINJA Previously, we were relying on the ninja behavior of restarting the build when the build.ninja file was updated to switch between different bootstrap stages. But that means that every step that could produce a build.ninja must pass in order to switch to a different stage. That wasn't a big problem when we had a two stage build -- there was very little that could fail in the second stage before we chose to go back to the first stage. But when we had a three stage build, it was possible to get into a state (usually during development) where you were in the second stage, but the build was failing because the first stage needed to be run. This was fixed in d79f1af7423e0ef7a13573efdae5100a57fabc82 by adding a wrapper that always started building at the first stage. But this kept all of the complexity of using ninja restarts without any of the benefits, so this change removes that complexity and just runs each stage sequentially in the wrapper. So the wrapper is now required. Since we're no longer going through choosestage, we can also skip the template parsing for the later stages that don't need to be templated -- this can save a couple of seconds for large files. In addition to all of the above, this also lets Soong reduce the number of times the main ninja file is loaded. We had been running the wrapper once (3 stages), then running ninja again after combining the Soong-generated build.ninja with the Kati-generated build.ninja. This change lets us removing the intermediate parsing of Soong's build.ninja, so that we only execute ninja 3 times per build. It also lets us have dependencies on pools or rules from Kati in the primary builder, since we're never executing the main build.ninja without the Kati build.ninja. The wrapper has a new option, NINJA to provide the path to ninja. This used to be hardcoded to `ninja`, and will still default to that. But we'll be running the first two bootstrap stages with $NINJA even if SKIP_NINJA is set. The wrapper passes "-w dupbuild=err" to ninja now -- this really should always be turned on if you care about reliable builds. Change-Id: I6f656b74eb3d064b8b9e69d1d6dac1129d72b747
2016-08-13 21:42:11 +02:00
default ${g.bootstrap.buildDir}/.minibootstrap/build.ninja.in
build ${g.bootstrap.buildDir}/.minibootstrap/build.ninja: $
g.bootstrap.bootstrap $
${g.bootstrap.buildDir}/.minibootstrap/build.ninja.in | $
Enhance bootstrap stage selection This simplifies the bootstrap process while making it more flexible by moving the stage selection into a go binary(choosestage). It will now be possible to have more than two build stages. Now each stage has a ninja template(main.ninja.in) and a timestamp file(main.ninja.in.timestamp). The timestamp file may be updated by any build stage that wishes to regenerate the ninja template. If the choosestage binaries sees that the timestamp is newer than the template, it will choose the prior stage. The main stage no longer writes to the source tree to update the build.ninja.in file. This was a problem for read-only source trees. Instead, the choosestage binary first checks to see if that file is newer than the last bootstrap.ninja.in, copies it in place, and starts the boostrap stage. The bootstrap stage regenerates it's own ninja template, but that required a loop through the main stage to actually run it. The choosestage binary now detects if the template has changed for the current stage, and will restart the stage. One change is that if dependencies do get messed up, instead of silently failing, there's a higher chance that the bootstrap step will just continue looping, doing nothing. This can happen if the main stage has a dependency that triggers the bootstrap stage, but the bootstrap stage doesn't see anything required to rebuild the main ninja file. A side effect of this requirement is that changes to test code will now rebuild the main ninja file. Change-Id: I9965cfba79dc0dbbd3af05f5944f7653054455a2
2015-07-23 02:05:59 +02:00
${g.bootstrap.bootstrapCmd}
Simplify bootstrap tl;dr: Read if you don't use the wrapper or use SKIP_NINJA Previously, we were relying on the ninja behavior of restarting the build when the build.ninja file was updated to switch between different bootstrap stages. But that means that every step that could produce a build.ninja must pass in order to switch to a different stage. That wasn't a big problem when we had a two stage build -- there was very little that could fail in the second stage before we chose to go back to the first stage. But when we had a three stage build, it was possible to get into a state (usually during development) where you were in the second stage, but the build was failing because the first stage needed to be run. This was fixed in d79f1af7423e0ef7a13573efdae5100a57fabc82 by adding a wrapper that always started building at the first stage. But this kept all of the complexity of using ninja restarts without any of the benefits, so this change removes that complexity and just runs each stage sequentially in the wrapper. So the wrapper is now required. Since we're no longer going through choosestage, we can also skip the template parsing for the later stages that don't need to be templated -- this can save a couple of seconds for large files. In addition to all of the above, this also lets Soong reduce the number of times the main ninja file is loaded. We had been running the wrapper once (3 stages), then running ninja again after combining the Soong-generated build.ninja with the Kati-generated build.ninja. This change lets us removing the intermediate parsing of Soong's build.ninja, so that we only execute ninja 3 times per build. It also lets us have dependencies on pools or rules from Kati in the primary builder, since we're never executing the main build.ninja without the Kati build.ninja. The wrapper has a new option, NINJA to provide the path to ninja. This used to be hardcoded to `ninja`, and will still default to that. But we'll be running the first two bootstrap stages with $NINJA even if SKIP_NINJA is set. The wrapper passes "-w dupbuild=err" to ninja now -- this really should always be turned on if you care about reliable builds. Change-Id: I6f656b74eb3d064b8b9e69d1d6dac1129d72b747
2016-08-13 21:42:11 +02:00
default ${g.bootstrap.buildDir}/.minibootstrap/build.ninja
Initial Blueprint commit. Blueprint is a build system component that reads Blueprints files defining modules to be built, and generates a Ninja build manifest that can be used to perform all the build actions. It does not dictate or implement much build policy itself, but rather provides a framework to ease the process of defining build logic in Go. The "blueprint" and "blueprint/parser" Go packages contain the functionality for reading Blueprint files and invoking build logic functions defined in other Go packages. The "blueprint/bootstrap" Go package contains just enough build logic to build a binary that includes Blueprint and any pure-Go (i.e. no cgo) build logic defined in external Go packages. This can be used to create a minimal Ninja file that's capable of bootstrapping a Blueprint-based build system from source. The "blueprint/bootstrap/minibp" Go package contains code for a minimal binary that includes the build logic defined in the "blueprint/bootstrap" package. This binary can then create the Ninja file for the bootstrapping process. Change-Id: I8d8390042372a72d225785cda738525001b009f1
2014-05-28 01:34:41 +02:00
Reference in a new issue Copy permalink