In my project, I want to use some commands which are installed via homebrew on Mac. Unfortunately, bazel doesn't include my modified classpath when I run commands via it. How can I enable such PATH with minimum amount of command line parameters and configurations?
There's an --action_env flag which allows to specify environment variables. See more here: https://bazel.build/designs/2016/06/21/environment.html
Related
How is it possible to access which features the package is being built with, inside the build.rs script? There is an incredibly expensive step in the script which is only needed for a particular cargo feature, but I can't see any way to access config features inside the build script.
Is there any way to read whether or not a given feature is enabled in the build.rs script?
I haven't been able to find documentation here, but was able to figure out one solution by guessing.
Cargo features are available as build features not just in the main source files, but inside the build.rs script as well. So you can use any of the standard ways to check configuration, like the cfg! and #[cfg(feature = "...")] macros, as mentioned in https://doc.rust-lang.org/reference/conditional-compilation.html and How do I use conditional compilation with `cfg` and Cargo?
Cargo sets a number of environment variables when the build scripts are run:
https://doc.rust-lang.org/cargo/reference/environment-variables.html#environment-variables-cargo-sets-for-build-scripts
Including an environment variable for each feature:
CARGO_FEATURE_<name> — For each activated feature of the package being built, this environment variable will be present where <name> is the name of the feature uppercased and having - translated to _.
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.
What does specifying tools under "Tool Locations" in Jenkins Node configuration, exactly do?
I wanted to run a mvn command in free style project. I specified the Maven tool and its home under "Tool Locations" and that didn't help. The job failed for not being able to find mvn. I followed this solution and modified the PATH variable to include maven path. That did the trick.
So how exactly does specifying Tool Locations help? Is it just to help users see the tool paths when they visit Jenkins node configuration site?
In Global Configuration, you can configure different tools, such as Maven, JDK, Ant, etc. When you do that, you also provide an installation method (usually an automatic online installer).
Now, on the Job Configuration, when you configure a buildstep using one of the tools, for example Invoke Ant, you will see a drop down. The first option is Default, the next is whatever tool installations that you've configured in Global Configuration.
If you choose Default it will use whatever is already installed on the system by simply executing a command like java, ant, or mvn. Obviously, if those commands are not in the path, it will fail.
If you choose one of the configured options, Jenkins will install it to the system (if not already done), and use that particular version (as opposed to the one you have under path).
This installation will happen on both the master and the slave nodes. If you do not want to use this automatic installation on a particular node, you can manually specify the location of the particular tool in the screenshot you provided.
The above is only useful if in your Job Configuration, you are selecting a specific version of the tool, other than Default, because as already explained: Default will use whatever is already installed on the system (not by Jenkins).
To answer your queries:
So how exactly does specifying Tool Locations help?
Well, not really i would say. It's meant to specify your custom installation directory path for any program that's already setup in your global config page in a different location. If you have configured mvn 2.0 in global settings but wish to use mvn 3.0 on this specific node, then you can use Tool Locations. However, it will work only if the path to the executable is already present in the PATH env variable of the user with which the slave process is running.
Is it just to help users see the tool paths when they visit Jenkins
node configuration site?
Well, yes, you can say that. I am saying so because whenever you specify a custom path, it generally isn't in the PATH of the user with which the process is running. That's true in most of the cases because such binaries don't run independently. They need other dependent modules to work properly otherwise simply dropping a binary in one of the directories that's already present in the PATH would have sufficed. So, it's safe to say that you explicitly have to add the path to executable in PATH to make it work.
If you have noticed the Help (?) section in the Tool Locations, even that doesn't sound very excited about using this feature :P It says:
You can specify the location of certain tools on this node, overriding the global configuration. (You may prefer to use automatic tool installers instead, removing the need to configure each node separately.)
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.
I'm doing java work on a class server where I don't have root. Whenever I try to compile using ant, it points to the wrong directory (/usr/tomcat instead of /usr/tomcat/jre ).
One of the things we were told to do when setting up our user accounts was to add export JAVA_HOME=/usr/tomcat/jre to the .bashrc file. I don't know if that was supposed to take care of the problem but it doesn't seem to.
So, how can I change the JAVA_HOME property for ant but only for when I run ant?
EDIT:
echo $JAVA_HOME points to /usr/tomcat/jre
echo $JAVA_HOME\bin points to /usr/tomcat/jrebin
The problem is when I normally run ant I get this error:
Unable to locate tools.jar. Expected to find it in /usr/tomcat/lib/tools.jar
Buildfile: build.xml
compile:
[javac] Compiling 1 source file to /home/ejm244/build/classes
BUILD FAILED
/home/ejm244/build.xml:9: Unable to find a javac compiler;
com.sun.tools.javac.Main is not on the classpath.
Perhaps JAVA_HOME does not point to the JDK
Total time: 0 seconds
You could create your own script for running ant, e.g. named ant.sh like:
#!/bin/sh
JAVA_HOME=</path/to/jdk>; export JAVA_HOME
ant $#
and then run your script.
$ chmod 755 ant.sh
$./ant.sh clean compile
or whatever ant target you wish to run
JAVA_HOME should point at where the JDK is installed not not a JRE.
So, if you type ls $JAVA_HOME what do you see?
if you do ls $JAVA_HOME/bin/ do you see javac?
If the first doesn't work then you don't have JAVA_HOME pointing at the right directory.
If the second doesn't work then you need to point JAVA_HOME at a JDK instead of a JRE.
Looking at the shell script for invoking ant, it is possible that the value for $JAVA_HOME set for your shell in .bashrc can be overridden in the files /etc/ant.conf, $HOME/.ant/ant.conf, and $HOME/.antrc. If you execute bash -x <path to ant script> it will emit debugging information which should help you track down where $JAVA_HOME is being overridden.
On my Windows 7 machine setting:
JAVA_HOME="C:\Program Files\Java\jdk1.6.0_18"
didn't work. But setting:
JAVA_HOME=C:\Program Files\Java\jdk1.6.0_18
worked.
There are 2 ways of changing the compiler:
export JAVA_HOME=/path/to/jdk before you start Ant.
Set <javac exectuable="/path/to/javac">
Another option would be to add a respective tools.jar to the classpath, but this is usually used if Ant is started from another tools like Maven.
For more details on these (or other) options of changing Java Compiler in Ant, see this article for example.
Set the env var:
JAVACMD - full path of the Java executable. Use this to invoke a different JVM than JAVA_HOME/bin/java(.exe).
Reference: http://ant.apache.org/manual/running.html
Though the environment variable JAVA_HOME set correctly, the ant may use the configured JRE within the each build.xml or any build files.
To check what version of the JRE the ant is using, right click on the build file -> select the build ant which displays the details about the tasks to choose etc, select the JRE which you want to use.
Its advisable to use the project level settings or just at the workspace level.
JAVA_HOME needs to point to a JDK home if you're trying to compile code. Check to see if '/usr/tomcat/jre/bin/javac' exists. I doubt it does.
If you don't have a JDK, then you can work around it by getting the ECJ (eclipse compiler) library, dropping it into '~/.ant/lib' and adding a system property to the command-line to use that compiler - check the Ant manual for details.
http://ant.apache.org/
Set the JRE in the project (project properties -> Java Build Path-> Libraries, typically last entry), or global default in preferences (Java->Installed JREs) to a JDK, not a JRE.
When using Bash just try this:
$ export JAVA_HOME=/usr/tomcat/jre
When running ant from the shell, you don't need to export JAVA_HOME first, which would set that variable for your current shell and all future commands, instead use
user#host:~# JAVA_HOME=/path/to/jdk ant targets
You will need to change JAVA_HOME path to the Java SDK directory instead of the Java RE directory. In Windows you can do this using the set command in a command prompt.
e.g.
set JAVA_HOME="C:\Program Files\Java\jdk1.6.0_14"
try with this:
/usr/sbin/update-alternatives --config java
java_home always points to the jdk, the compiler that gave you the classes,
and the jre is thw way that your browser or whatever will the compiled classes so it must have matching between jdk and jre in the version.