is it possible to compile two versions when building?
I would like to have a build/ which is the production release for end users and a buildDev/ with less restrictive dart2js flags. Something like that.
The idea is to be able to access a page with some security token that forces the page use the dart2js debug version.
This is not possible to do in a single build command. webdev build --no-release will use the dev_options instead of release_options, so to get both flavors of build you'll need to run two commands, webdev build; webdev build --no-release -o buildDev.
Related
At the end of a cargo build, I would like to call wasm-opt with specific optimization options on the generated WASM file.
Unfortunately, it seems that the Cargo.toml does not support support asyncify options.
A good solution would prevent cargo from rebuilding the project after running wasm-opt on the WASM file.
If I used a cargo-build script, it is unclear to me how I could specify a dependency on the wasm-opt build step to avoid unnecessary re-builds even though the Rust source files haven't changed. Any pointers ?
I am trying to follow the instructions for contributors here:
https://bazel.build/contributing.html
I have a successful build off of master (i.e. bazel build //src:bazel), but the doc suggests also "you might want to build the various tools Bazel uses." I am trying to do that, for example:
cd src/java_tools/singlejar
bazel build //...
but it fails with:
ERROR: /Users/.../bazel/third_party/protobuf/3.2.0/BUILD:621:1: no such target '//external:gtest': target 'gtest' not declared in package 'external' defined by /Users/plaird/scone/public/bazel/WORKSPACE and referenced by '//third_party/protobuf/3.2.0:test_plugin'.
Do I need to build gtest locally, and then add it to the WORKSPACE file?
bazel build //..., no matter where you invoke it, will build everything in the project. It looks like what you probably want is bazel build //src/java_tools/singlejar/..., which will build all targets under that directory.
In general, though, you probably don't need to compile singlejar separately. I've been working on Bazel for several years and 99% of the time you don't have to build the tools separately.
In terms of the error you're getting, it would be nice if we could get //... building, but it hasn't been a huge priority. The protobuf code build is weird and I don't recommend trying to debug it, just jump into whatever you want to actually work on.
For my release process I need several different "modes." However, if I use the --mode option for pub build and set it to any value other than release, it forces un-minified javascript.
I know I can configure the dart2js transformer in my pubspec.yaml, but if I set minify: true under the $dart2js heading in my pubspec.yaml I am then forcing them to be minified, and then cannot produce un-minified debug builds.
What I'm really looking for is a way to configure arbitrary dart2js options (minified, checked, etc.) in pub build via the CLI (so that I don't have to hardcode in pubspec.yaml), or, failing that, to be able to specify additional arbitrary flags from the pub build CLI so that I can reserve --mode for debug and release. The asPlugin() transformer constructor takes a BarbackSettings object, but I can't see how to see arbitrary params in that via the command line.
I have never seen anything like that mentioned (for example in any of the bug reports) and I'm pretty sure this is not supported. I suggest to just create a feature request at http://dartbug.com.
One way I can think of is to create a script which manipulates the pubspec.yaml file before executing pub build. This should be easy using the https://pub.dartlang.org/packages/yaml package.
We are looking for ways to stop a build if it is being built for release and contains strings that reference "localhost" or containing "10.0" or other rules. does xCode have a way of enforcing these rules?
You can add a custom shell script build phase to your project.. you can run whatever shell script you want in there. You can also inspect the plethora of build environment variables, including one which should tell you if you are building for release or debug.
I am writing a script to automate my iOS building. It will be run outside of Xcode, either via Terminal or from build automating software. Is there any way to have access to Xcode environment variables in my script, so I don't have to try and derive them myself?
For example, can I get access to PROJECT_DIR instead of assuming I'm in the current directory and running pwd?
I am currently hardcoding the product names for my different build configurations. (I'm also hard coding the build configs, but I could parse them them from xcodebuild -list.) Is there a way to get the app if you know the build config name?
(I saw this related question but it doesn't have an answer for me.)
The Xcode environment variables are only defined for child processes of the xcodebuildcommand-line tool.
One solution I used is to have a very simple script as part of my build process (Project->New Build Phase->Add Run Script Build Phase). All this script does is export the necessary variables and call a script in my path somewhere.
That script could be generated by your build script before calling xcodebuild and voilà! you have an external script that has access to Xcode build variables.