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

346 lines
15 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
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
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 = .bootstrap/bin/choosestage
bootstrap: Don't export the script-substituted Ninja vars Change-Id: I8999f9489415cc53661e079401df519f9d83258e
2014-11-09 20:52:56 +01: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
bootstrap: Don't export the script-substituted Ninja vars Change-Id: I8999f9489415cc53661e079401df519f9d83258e
2014-11-09 20:52:56 +01:00
g.bootstrap.goOS = @@GoOS@@
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.goArch = @@GoArch@@
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.goToolDir = ${g.bootstrap.goRoot}/pkg/tool/${g.bootstrap.goOS}_${g.bootstrap.goArch}
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.goChar = @@GoChar@@
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.gcCmd = ${g.bootstrap.goToolDir}/${g.bootstrap.goChar}g
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.linkCmd = ${g.bootstrap.goToolDir}/${g.bootstrap.goChar}l
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
Change the bootstrap dir to .bootstrap Change-Id: I016939015144e29f5981b754b725a6c8e48e3b0d
2014-06-06 23:21:57 +02:00
builddir = .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
Sort various things for deterministic output. Change-Id: If6457713ad442ae3e4179e594820fa1e02e9b240
2014-09-25 05:26:52 +02:00
rule g.bootstrap.bootstrap
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
command = ${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
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.gc
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.gcCmd} -o ${out} -p ${pkgPath} -complete ${incFlags} -pack ${in}
description = ${g.bootstrap.goChar}g ${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}
description = ${g.bootstrap.goChar}l ${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
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
# Factory: github.com/google/blueprint/bootstrap.func·001
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
Update import paths to include github
2015-03-21 03:39:29 +01:00
build .bootstrap/blueprint/pkg/github.com/google/blueprint.a: g.bootstrap.gc $
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}/context.go ${g.bootstrap.srcDir}/live_tracker.go $
${g.bootstrap.srcDir}/mangle.go ${g.bootstrap.srcDir}/module_ctx.go $
${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 $
| ${g.bootstrap.gcCmd} $
Update import paths to include github
2015-03-21 03:39:29 +01:00
.bootstrap/blueprint-parser/pkg/github.com/google/blueprint/parser.a $
Add support for arbitrary globs in subdirs Change-Id: I874535483266622213dbcfe3c84875f41a136b9f
2015-04-01 05:39:02 +02:00
.bootstrap/blueprint-pathtools/pkg/github.com/google/blueprint/pathtools.a $
Update import paths to include github
2015-03-21 03:39:29 +01:00
.bootstrap/blueprint-proptools/pkg/github.com/google/blueprint/proptools.a
Add support for arbitrary globs in subdirs Change-Id: I874535483266622213dbcfe3c84875f41a136b9f
2015-04-01 05:39:02 +02:00
incFlags = -I .bootstrap/blueprint-parser/pkg -I .bootstrap/blueprint-pathtools/pkg -I .bootstrap/blueprint-proptools/pkg
Update import paths to include github
2015-03-21 03:39:29 +01:00
pkgPath = github.com/google/blueprint
default .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
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
# Factory: github.com/google/blueprint/bootstrap.func·001
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
# Defined: Blueprints:70: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 $
.bootstrap/blueprint-bootstrap/pkg/github.com/google/blueprint/bootstrap.a $
: g.bootstrap.gc ${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 $
${g.bootstrap.srcDir}/bootstrap/writedocs.go | ${g.bootstrap.gcCmd} $
Update import paths to include github
2015-03-21 03:39:29 +01:00
.bootstrap/blueprint-parser/pkg/github.com/google/blueprint/parser.a $
Add support for arbitrary globs in subdirs Change-Id: I874535483266622213dbcfe3c84875f41a136b9f
2015-04-01 05:39:02 +02:00
.bootstrap/blueprint-pathtools/pkg/github.com/google/blueprint/pathtools.a $
Update import paths to include github
2015-03-21 03:39:29 +01:00
.bootstrap/blueprint-proptools/pkg/github.com/google/blueprint/proptools.a $
.bootstrap/blueprint/pkg/github.com/google/blueprint.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
.bootstrap/blueprint-deptools/pkg/github.com/google/blueprint/deptools.a $
.bootstrap/blueprint-bootstrap-bpdoc/pkg/github.com/google/blueprint/bootstrap/bpdoc.a
incFlags = -I .bootstrap/blueprint-parser/pkg -I .bootstrap/blueprint-pathtools/pkg -I .bootstrap/blueprint-proptools/pkg -I .bootstrap/blueprint/pkg -I .bootstrap/blueprint-deptools/pkg -I .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 $
.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
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
# Factory: github.com/google/blueprint/bootstrap.func·001
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
# Defined: Blueprints:89:1
build $
.bootstrap/blueprint-bootstrap-bpdoc/pkg/github.com/google/blueprint/bootstrap/bpdoc.a $
: g.bootstrap.gc ${g.bootstrap.srcDir}/bootstrap/bpdoc/bpdoc.go | $
${g.bootstrap.gcCmd} $
.bootstrap/blueprint-parser/pkg/github.com/google/blueprint/parser.a $
.bootstrap/blueprint-pathtools/pkg/github.com/google/blueprint/pathtools.a $
.bootstrap/blueprint-proptools/pkg/github.com/google/blueprint/proptools.a $
.bootstrap/blueprint/pkg/github.com/google/blueprint.a
incFlags = -I .bootstrap/blueprint-parser/pkg -I .bootstrap/blueprint-pathtools/pkg -I .bootstrap/blueprint-proptools/pkg -I .bootstrap/blueprint/pkg
pkgPath = github.com/google/blueprint/bootstrap/bpdoc
default $
.bootstrap/blueprint-bootstrap-bpdoc/pkg/github.com/google/blueprint/bootstrap/bpdoc.a
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
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
# Factory: github.com/google/blueprint/bootstrap.func·001
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
# Defined: Blueprints:46:1
Add a Glob func that returns dirs searched Change-Id: I35ab9a5f1c7425f42d0e667bac38450afa34c738
2014-10-24 19:42:57 +02:00
Update import paths to include github
2015-03-21 03:39:29 +01:00
build .bootstrap/blueprint-deptools/pkg/github.com/google/blueprint/deptools.a $
: g.bootstrap.gc ${g.bootstrap.srcDir}/deptools/depfile.go | $
${g.bootstrap.gcCmd}
pkgPath = github.com/google/blueprint/deptools
default $
.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
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
# Factory: github.com/google/blueprint/bootstrap.func·001
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
# Defined: Blueprints:31: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 .bootstrap/blueprint-parser/pkg/github.com/google/blueprint/parser.a: $
g.bootstrap.gc ${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 $
${g.bootstrap.srcDir}/parser/sort.go | ${g.bootstrap.gcCmd}
Update import paths to include github
2015-03-21 03:39:29 +01:00
pkgPath = github.com/google/blueprint/parser
default .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
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
# Factory: github.com/google/blueprint/bootstrap.func·001
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
# Defined: Blueprints:52: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 $
.bootstrap/blueprint-pathtools/pkg/github.com/google/blueprint/pathtools.a $
: g.bootstrap.gc ${g.bootstrap.srcDir}/pathtools/lists.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}/pathtools/glob.go | ${g.bootstrap.gcCmd}
Update import paths to include github
2015-03-21 03:39:29 +01:00
pkgPath = github.com/google/blueprint/pathtools
default $
.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
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
# Factory: github.com/google/blueprint/bootstrap.func·001
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
# Defined: Blueprints:64: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 $
.bootstrap/blueprint-proptools/pkg/github.com/google/blueprint/proptools.a $
: g.bootstrap.gc ${g.bootstrap.srcDir}/proptools/proptools.go | $
${g.bootstrap.gcCmd}
pkgPath = github.com/google/blueprint/proptools
default $
.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
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
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# Module: bpfmt
Update import paths to include github
2015-03-21 03:39:29 +01:00
# Variant:
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
# Type: bootstrap_go_binary
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
# Factory: github.com/google/blueprint/bootstrap.func·002
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
# Defined: Blueprints:110:1
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
build .bootstrap/bpfmt/obj/bpfmt.a: g.bootstrap.gc $
${g.bootstrap.srcDir}/bpfmt/bpfmt.go | ${g.bootstrap.gcCmd} $
Update import paths to include github
2015-03-21 03:39:29 +01:00
.bootstrap/blueprint-parser/pkg/github.com/google/blueprint/parser.a
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
incFlags = -I .bootstrap/blueprint-parser/pkg
pkgPath = bpfmt
default .bootstrap/bpfmt/obj/bpfmt.a
build .bootstrap/bpfmt/obj/a.out: g.bootstrap.link $
.bootstrap/bpfmt/obj/bpfmt.a | ${g.bootstrap.linkCmd}
libDirFlags = -L .bootstrap/blueprint-parser/pkg
default .bootstrap/bpfmt/obj/a.out
build .bootstrap/bin/bpfmt: g.bootstrap.cp .bootstrap/bpfmt/obj/a.out
default .bootstrap/bin/bpfmt
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# Module: bpmodify
Update import paths to include github
2015-03-21 03:39:29 +01:00
# Variant:
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
# Type: bootstrap_go_binary
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
# Factory: github.com/google/blueprint/bootstrap.func·002
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
# Defined: Blueprints:116:1
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
build .bootstrap/bpmodify/obj/bpmodify.a: g.bootstrap.gc $
${g.bootstrap.srcDir}/bpmodify/bpmodify.go | ${g.bootstrap.gcCmd} $
Update import paths to include github
2015-03-21 03:39:29 +01:00
.bootstrap/blueprint-parser/pkg/github.com/google/blueprint/parser.a
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
incFlags = -I .bootstrap/blueprint-parser/pkg
pkgPath = bpmodify
default .bootstrap/bpmodify/obj/bpmodify.a
build .bootstrap/bpmodify/obj/a.out: g.bootstrap.link $
.bootstrap/bpmodify/obj/bpmodify.a | ${g.bootstrap.linkCmd}
libDirFlags = -L .bootstrap/blueprint-parser/pkg
default .bootstrap/bpmodify/obj/a.out
build .bootstrap/bin/bpmodify: g.bootstrap.cp .bootstrap/bpmodify/obj/a.out
default .bootstrap/bin/bpmodify
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:
# Type: bootstrap_go_binary
# Factory: github.com/google/blueprint/bootstrap.func·002
# Defined: Blueprints:127:1
build .bootstrap/choosestage/obj/choosestage.a: g.bootstrap.gc $
${g.bootstrap.srcDir}/choosestage/choosestage.go | $
${g.bootstrap.gcCmd}
pkgPath = choosestage
default .bootstrap/choosestage/obj/choosestage.a
build .bootstrap/choosestage/obj/a.out: g.bootstrap.link $
.bootstrap/choosestage/obj/choosestage.a | ${g.bootstrap.linkCmd}
default .bootstrap/choosestage/obj/a.out
build .bootstrap/bin/choosestage: g.bootstrap.cp $
.bootstrap/choosestage/obj/a.out
default .bootstrap/bin/choosestage
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:
# Type: bootstrap_go_binary
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
# Factory: github.com/google/blueprint/bootstrap.func·002
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
# Defined: Blueprints:122: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
build .bootstrap/gotestmain/obj/gotestmain.a: g.bootstrap.gc $
${g.bootstrap.srcDir}/gotestmain/gotestmain.go | ${g.bootstrap.gcCmd}
pkgPath = gotestmain
default .bootstrap/gotestmain/obj/gotestmain.a
build .bootstrap/gotestmain/obj/a.out: g.bootstrap.link $
.bootstrap/gotestmain/obj/gotestmain.a | ${g.bootstrap.linkCmd}
default .bootstrap/gotestmain/obj/a.out
build .bootstrap/bin/gotestmain: g.bootstrap.cp $
.bootstrap/gotestmain/obj/a.out
default .bootstrap/bin/gotestmain
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:
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_binary
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
# Factory: github.com/google/blueprint/bootstrap.func·002
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
# Defined: Blueprints:101: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
Add support for removing abandoned files. This change makes the bootstrapping process remove any files that were previously created by invoking a Ninja rule (i.e. they appear in the .ninja_log file) but are no longer a build output target. Change-Id: I3c78e563393b97f8ca196ac85c7caa2b3866ffa6
2014-10-28 06:34:56 +01:00
build .bootstrap/minibp/obj/minibp.a: g.bootstrap.gc $
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/minibp/main.go | ${g.bootstrap.gcCmd} $
Update import paths to include github
2015-03-21 03:39:29 +01:00
.bootstrap/blueprint-parser/pkg/github.com/google/blueprint/parser.a $
Add support for arbitrary globs in subdirs Change-Id: I874535483266622213dbcfe3c84875f41a136b9f
2015-04-01 05:39:02 +02:00
.bootstrap/blueprint-pathtools/pkg/github.com/google/blueprint/pathtools.a $
Update import paths to include github
2015-03-21 03:39:29 +01:00
.bootstrap/blueprint-proptools/pkg/github.com/google/blueprint/proptools.a $
.bootstrap/blueprint/pkg/github.com/google/blueprint.a $
.bootstrap/blueprint-deptools/pkg/github.com/google/blueprint/deptools.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
.bootstrap/blueprint-bootstrap-bpdoc/pkg/github.com/google/blueprint/bootstrap/bpdoc.a $
Update import paths to include github
2015-03-21 03:39:29 +01:00
.bootstrap/blueprint-bootstrap/pkg/github.com/google/blueprint/bootstrap.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
incFlags = -I .bootstrap/blueprint-parser/pkg -I .bootstrap/blueprint-pathtools/pkg -I .bootstrap/blueprint-proptools/pkg -I .bootstrap/blueprint/pkg -I .bootstrap/blueprint-deptools/pkg -I .bootstrap/blueprint-bootstrap-bpdoc/pkg -I .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
bootstrap: Don't export the script-substituted Ninja vars Change-Id: I8999f9489415cc53661e079401df519f9d83258e
2014-11-09 20:52:56 +01:00
default .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
Change the bootstrap dir to .bootstrap Change-Id: I016939015144e29f5981b754b725a6c8e48e3b0d
2014-06-06 23:21:57 +02:00
build .bootstrap/minibp/obj/a.out: g.bootstrap.link $
Add support for removing abandoned files. This change makes the bootstrapping process remove any files that were previously created by invoking a Ninja rule (i.e. they appear in the .ninja_log file) but are no longer a build output target. Change-Id: I3c78e563393b97f8ca196ac85c7caa2b3866ffa6
2014-10-28 06:34:56 +01:00
.bootstrap/minibp/obj/minibp.a | ${g.bootstrap.linkCmd}
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
libDirFlags = -L .bootstrap/blueprint-parser/pkg -L .bootstrap/blueprint-pathtools/pkg -L .bootstrap/blueprint-proptools/pkg -L .bootstrap/blueprint/pkg -L .bootstrap/blueprint-deptools/pkg -L .bootstrap/blueprint-bootstrap-bpdoc/pkg -L .bootstrap/blueprint-bootstrap/pkg
bootstrap: Don't export the script-substituted Ninja vars Change-Id: I8999f9489415cc53661e079401df519f9d83258e
2014-11-09 20:52:56 +01:00
default .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
Change the bootstrap dir to .bootstrap Change-Id: I016939015144e29f5981b754b725a6c8e48e3b0d
2014-06-06 23:21:57 +02:00
build .bootstrap/bin/minibp: g.bootstrap.cp .bootstrap/minibp/obj/a.out
bootstrap: Don't export the script-substituted Ninja vars Change-Id: I8999f9489415cc53661e079401df519f9d83258e
2014-11-09 20:52:56 +01:00
default .bootstrap/bin/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
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
# Factory: github.com/google/blueprint/bootstrap.func·007
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
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
command = .bootstrap/bin/minibp ${runTests} -m ${g.bootstrap.bootstrapManifest} -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
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 s.bootstrap.bigbp
command = .bootstrap/bin/minibp -p -m ${g.bootstrap.bootstrapManifest} --timestamp ${timestamp} --timestampdep ${timestampdep} -d ${outfile}.d -o ${outfile} ${in}
depfile = ${outfile}.d
description = minibp ${outfile}
rule s.bootstrap.bigbpDocs
command = .bootstrap/bin/minibp -p --docs ${out} ${g.bootstrap.srcDir}/Blueprints
description = minibp docs ${out}
build .bootstrap/bootstrap.ninja.in: s.bootstrap.minibp $
${g.bootstrap.srcDir}/Blueprints | ${g.bootstrap.bootstrapManifest} $
.bootstrap/bin/minibp
default .bootstrap/bootstrap.ninja.in
build .bootstrap/main.ninja.in .bootstrap/main.ninja.in.timestamp: $
s.bootstrap.bigbp ${g.bootstrap.srcDir}/Blueprints | $
.bootstrap/bin/bpfmt .bootstrap/bin/bpmodify $
.bootstrap/bin/choosestage .bootstrap/bin/gotestmain $
.bootstrap/bin/minibp ${g.bootstrap.srcDir}/Blueprints $
.bootstrap/docs/minibp.html
outfile = .bootstrap/main.ninja.in
timestamp = .bootstrap/main.ninja.in.timestamp
timestampdep = .bootstrap/main.ninja.in.timestamp.d
default .bootstrap/main.ninja.in .bootstrap/main.ninja.in.timestamp
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 .bootstrap/docs/minibp.html: s.bootstrap.bigbpDocs | $
.bootstrap/bin/minibp
default .bootstrap/docs/minibp.html
Change the bootstrap dir to .bootstrap Change-Id: I016939015144e29f5981b754b725a6c8e48e3b0d
2014-06-06 23:21:57 +02:00
build .bootstrap/notAFile: phony
bootstrap: Don't export the script-substituted Ninja vars Change-Id: I8999f9489415cc53661e079401df519f9d83258e
2014-11-09 20:52:56 +01:00
default .bootstrap/notAFile
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
build .bootstrap/build.ninja.in: g.bootstrap.chooseStage $
.bootstrap/bootstrap.ninja.in .bootstrap/main.ninja.in | $
${g.bootstrap.chooseStageCmd} ${g.bootstrap.bootstrapManifest} $
.bootstrap/notAFile
current = .bootstrap/bootstrap.ninja.in
default .bootstrap/build.ninja.in
build build.ninja: g.bootstrap.bootstrap .bootstrap/build.ninja.in | $
${g.bootstrap.bootstrapCmd}
bootstrap: Don't export the script-substituted Ninja vars Change-Id: I8999f9489415cc53661e079401df519f9d83258e
2014-11-09 20:52:56 +01:00
default 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