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

341 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
#
Require ninja 1.6.0, remove workaround The workaround no longer works with the new stage selector. We may run bootstrap.ninja.in twice before running the next stage, but we can't encode whether to run another ninja instance in the checked in build.ninja.in. This can likely be solved, but now that there's an official release with support for multiple passes, just push up the required version. Change-Id: I76e321912e323d60e462aabec61bdfcc7118cd5e
2015-07-22 21:58:01 +02:00
ninja_required_version = 1.6.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
bootstrap: Don't export the script-substituted Ninja vars Change-Id: I8999f9489415cc53661e079401df519f9d83258e
2014-11-09 20:52:56 +01:00
g.bootstrap.bootstrapManifest = @@BootstrapManifest@@
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.chooseStageCmd = ${g.bootstrap.buildDir}/.bootstrap/bin/choosestage
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
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
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
rule g.bootstrap.chooseStage
command = ${g.bootstrap.chooseStageCmd} --current ${current} --bootstrap ${g.bootstrap.bootstrapManifest} -o ${out} ${in}
description = choosing next stage
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 $
Allow tests to mock filesystem Tests can call Context.MockFileSystem to pass in a map of filenames to contents. Change-Id: Idd67c68f7cb43bc2117cc78336347db7e2f21991
2016-06-03 00:30:20 +02:00
${g.bootstrap.srcDir}/fs.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 $
${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
incFlags = -I ${g.bootstrap.buildDir}/.bootstrap/blueprint-parser/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
Allow tests to mock filesystem Tests can call Context.MockFileSystem to pass in a map of filenames to contents. Change-Id: Idd67c68f7cb43bc2117cc78336347db7e2f21991
2016-06-03 00:30:20 +02:00
# Defined: Blueprints:83: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 $
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 $
${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-deptools/pkg/github.com/google/blueprint/deptools.a $
${g.bootstrap.buildDir}/.bootstrap/blueprint-bootstrap-bpdoc/pkg/github.com/google/blueprint/bootstrap/bpdoc.a
incFlags = -I ${g.bootstrap.buildDir}/.bootstrap/blueprint-parser/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-deptools/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
Allow tests to mock filesystem Tests can call Context.MockFileSystem to pass in a map of filenames to contents. Change-Id: Idd67c68f7cb43bc2117cc78336347db7e2f21991
2016-06-03 00:30:20 +02:00
# Defined: Blueprints:102: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 $
${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
incFlags = -I ${g.bootstrap.buildDir}/.bootstrap/blueprint-parser/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
Allow tests to mock filesystem Tests can call Context.MockFileSystem to pass in a map of filenames to contents. Change-Id: Idd67c68f7cb43bc2117cc78336347db7e2f21991
2016-06-03 00:30:20 +02:00
# Defined: Blueprints:49: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
Allow tests to mock filesystem Tests can call Context.MockFileSystem to pass in a map of filenames to contents. Change-Id: Idd67c68f7cb43bc2117cc78336347db7e2f21991
2016-06-03 00:30:20 +02:00
# Defined: Blueprints:33: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
Allow tests to mock filesystem Tests can call Context.MockFileSystem to pass in a map of filenames to contents. Change-Id: Idd67c68f7cb43bc2117cc78336347db7e2f21991
2016-06-03 00:30:20 +02:00
# Defined: Blueprints:55: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 $
${g.bootstrap.srcDir}/pathtools/glob.go | ${g.bootstrap.compileCmd}
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
Allow tests to mock filesystem Tests can call Context.MockFileSystem to pass in a map of filenames to contents. Change-Id: Idd67c68f7cb43bc2117cc78336347db7e2f21991
2016-06-03 00:30:20 +02:00
# Defined: Blueprints:67: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 $
${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
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
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# Module: choosestage
# 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
Allow tests to mock filesystem Tests can call Context.MockFileSystem to pass in a map of filenames to contents. Change-Id: Idd67c68f7cb43bc2117cc78336347db7e2f21991
2016-06-03 00:30:20 +02:00
# Defined: Blueprints:145:1
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
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/choosestage/obj/choosestage.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}/choosestage/choosestage.go | $
${g.bootstrap.compileCmd}
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
pkgPath = choosestage
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/choosestage/obj/choosestage.a
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
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/choosestage/obj/a.out: $
g.bootstrap.link $
${g.bootstrap.buildDir}/.bootstrap/choosestage/obj/choosestage.a | $
${g.bootstrap.linkCmd}
default ${g.bootstrap.buildDir}/.bootstrap/choosestage/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}/choosestage: 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/choosestage/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}/choosestage
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
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
Allow tests to mock filesystem Tests can call Context.MockFileSystem to pass in a map of filenames to contents. Change-Id: Idd67c68f7cb43bc2117cc78336347db7e2f21991
2016-06-03 00:30:20 +02:00
# Defined: Blueprints:135: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
Allow tests to mock filesystem Tests can call Context.MockFileSystem to pass in a map of filenames to contents. Change-Id: Idd67c68f7cb43bc2117cc78336347db7e2f21991
2016-06-03 00:30:20 +02:00
# Defined: Blueprints:140: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
Allow tests to mock filesystem Tests can call Context.MockFileSystem to pass in a map of filenames to contents. Change-Id: Idd67c68f7cb43bc2117cc78336347db7e2f21991
2016-06-03 00:30:20 +02:00
# Defined: Blueprints:114: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 $
${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-deptools/pkg/github.com/google/blueprint/deptools.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
incFlags = -I ${g.bootstrap.buildDir}/.bootstrap/blueprint-parser/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-deptools/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}
libDirFlags = -L ${g.bootstrap.buildDir}/.bootstrap/blueprint-parser/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-deptools/pkg -L ${g.bootstrap.buildDir}/.bootstrap/blueprint-bootstrap-bpdoc/pkg -L ${g.bootstrap.buildDir}/.bootstrap/blueprint-bootstrap/pkg
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
rule s.bootstrap.primarybp
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
command = ${g.bootstrap.BinDir}/minibp --build-primary ${runTests} -m ${g.bootstrap.bootstrapManifest} --timestamp ${timestamp} --timestampdep ${timestampdep} -b ${g.bootstrap.buildDir} -d ${outfile}.d -o ${outfile} ${in}
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
depfile = ${outfile}.d
description = minibp ${outfile}
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
Fix a re-bootstrapping issue. This change fixes an issue where the re-bootstrapping process would overwrite a newer bootstrap manifest with one that it generates using its older minibp. It fixes the issue by only generating a new bootstrap manifest right after rebuilding minibp (as part of the bootstrap process). It then uses an additional rebootstrap iteration to replace the old bootstrap manifest with the new one. Change-Id: I16bad2f30f6ad7f10da07d77105e8745adec3650
2014-06-06 05:00:22 +02:00
rule s.bootstrap.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
command = ${g.bootstrap.BinDir}/minibp ${runTests} -m ${g.bootstrap.bootstrapManifest} -b ${g.bootstrap.buildDir} -d ${out}.d -o ${out} ${in}
Fix a re-bootstrapping issue. This change fixes an issue where the re-bootstrapping process would overwrite a newer bootstrap manifest with one that it generates using its older minibp. It fixes the issue by only generating a new bootstrap manifest right after rebuilding minibp (as part of the bootstrap process). It then uses an additional rebootstrap iteration to replace the old bootstrap manifest with the new one. Change-Id: I16bad2f30f6ad7f10da07d77105e8745adec3650
2014-06-06 05:00:22 +02:00
depfile = ${out}.d
description = minibp ${out}
generator = true
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/primary.ninja.in $
${g.bootstrap.buildDir}/.bootstrap/primary.ninja.in.timestamp: $
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
s.bootstrap.primarybp ${g.bootstrap.srcDir}/Blueprints | $
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
${g.bootstrap.BinDir}/choosestage ${g.bootstrap.BinDir}/gotestmain $
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
${g.bootstrap.BinDir}/gotestrunner ${g.bootstrap.BinDir}/minibp $
${g.bootstrap.srcDir}/Blueprints
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
outfile = ${g.bootstrap.buildDir}/.bootstrap/primary.ninja.in
timestamp = ${g.bootstrap.buildDir}/.bootstrap/primary.ninja.in.timestamp
timestampdep = ${g.bootstrap.buildDir}/.bootstrap/primary.ninja.in.timestamp.d
default ${g.bootstrap.buildDir}/.bootstrap/primary.ninja.in $
${g.bootstrap.buildDir}/.bootstrap/primary.ninja.in.timestamp
build ${g.bootstrap.buildDir}/.bootstrap/bootstrap.ninja.in: $
s.bootstrap.minibp ${g.bootstrap.srcDir}/Blueprints | $
${g.bootstrap.bootstrapManifest} ${g.bootstrap.BinDir}/minibp
default ${g.bootstrap.buildDir}/.bootstrap/bootstrap.ninja.in
Add blank line after build rules, for human readability.
2015-11-09 20:37:39 +01: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/notAFile: phony
default ${g.bootstrap.buildDir}/.bootstrap/notAFile
Add blank line after build rules, for human readability.
2015-11-09 20:37:39 +01: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/build.ninja.in: $
g.bootstrap.chooseStage $
${g.bootstrap.buildDir}/.bootstrap/bootstrap.ninja.in $
${g.bootstrap.buildDir}/.bootstrap/primary.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.chooseStageCmd} ${g.bootstrap.bootstrapManifest} $
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/notAFile
current = ${g.bootstrap.buildDir}/.bootstrap/bootstrap.ninja.in
default ${g.bootstrap.buildDir}/.bootstrap/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
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}/build.ninja: g.bootstrap.bootstrap $
${g.bootstrap.buildDir}/.bootstrap/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}
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}/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