I know that the compiler can run directly on arm-linux-androideabi, but the Android emulator (I mean emulation of ARM on x86/amd64) is slow,
so I don't want to use cargo and rustc on the emulator, I only want to run tests on it.
I want to cross-compile tests on my PC (cargo test --target=arm-linux-androideabi --no-run?), and then upload and run them on emulator,
hoping to catch bugs like this.
How can I run cargo test without running cargo test? Is it as simple as running all binaries that were built with cargo test --no-run?
There are two kinds of tests supported by cargo test, one is the normal tests (#[test] fns and files inside tests/), the other is the doc tests.
The normal tests are as simple as running all binaries. The test is considered successful if it exits with error code 0.
Doc tests cannot be cross-tested. Doc tests are compiled and executed directly by rustdoc using the compiler libraries, so the compiler must be installed on the ARM machine to run the doc tests. In fact, running cargo test --doc when HOST ≠ TARGET will do nothing.
So, the answer to your last question is yes as long as you don't rely on doc-tests for coverage.
Starting from Rust 1.19, cargo supports target specific runners, which allows you to specify a script to upload and execute the test program on the ARM machine.
#!/bin/sh
set -e
adb push "$1" "/sdcard/somewhere/$1"
adb shell "chmod 755 /sdcard/somewhere/$1 && /sdcard/somewhere/$1"
# ^ note: may need to change this line, see https://stackoverflow.com/q/9379400
Put this to your .cargo/config:
[target.arm-linux-androideabi]
runner = ["/path/to/your/run/script.sh"]
then cargo test --target=arm-linux-androideabi should Just Work™.
If your project is hosted on GitHub and uses Travis CI, you may also want to check out trust. It provides a pre-packaged solution for testing on many architectures including ARMv7 Linux on the CI (no Android unfortunately).
My recommendation for testing on Android would be to use dinghy which provides nice wrapper commands for building and testing on Android/iOS devices/emulator/simulators.
For whoever might still be interested in this:
run cargo -v test with -v
Then look for this output
Finished release [optimized] target(s) in 21.31s
Running `/my-dir/target/release/deps/my-binary-29b03924d05690f1`
Then just copy the test binary /my-dir/target/release/deps/my-binary-29b03924d05690f1 to the machine without rustc
Related
The question: Is there a way in autotools to build my code and unit tests without running the unit tests?
I have a code base that uses autotools and running make check compiles the code and runs unit tests. I have a portable singularity container that I want to build and test the code on a slurm cluster. I am able to do something like
./configure MPI_LAUNCHER="srun --mpi=pmi2"
singularity exec -B ${PWD} container.sif envscript.sh "make check"
Which will run an environment set up script (envscript.sh) and build the code. When it gets to the unit tests, it hangs. I think this is because it's trying to run the srun --mpi=pmi2 in the container and not on the host. Is there a way to get this to work with this set up? Can I build the library and then just build the unit tests without running them? Then in a second step, run the tests. I imagine something like this:
./configure MPI_LAUNCHER="srun --mpi=pmi2 singularity exec -B ${PWD} container.sif envscript.sh"
singularity exec -B ${PWD} container.sif envscript.sh "make buildtests"
make check
I don't even this this would work though because our tests are set up with the -n for the number of cores for each test like this
mpirun -n test_cores ./test.sh
So subbing in the srun singularity command would put the -n after singularity. If anyone has any idea, please let me know.
The question: Is there a way in autotools to build my code and unit tests without running the unit tests?
None of the standard makefile targets provided by Automake provide for this.
In fact, the behavior of not building certain targets until make check is specifically requested by the Makefile.am author. Designating those targets in a check_PROGRAMS, check_LIBRARIES, etc variable (and not anywhere else) has that effect. If you modify each check_FOO to noinst_FOO then all the targets named by those variables should be built by make / make all. Of course, if the build system already uses noinst_ variables for other purposes then you'll need to perform some merging.
BUT YOU PROBABLY DON'T WANT TO DO THAT.
Targets designated (only) in check_FOO or noinst_FOO variables are not installed to the system by make install, and often they depend on data and layout provided by the build environment. If you're not going to run them in the build environment, then you should plan not to run them at all.
Additionally, if you're performing your build inside the container because the container is the target execution environment then it is a huge red flag that the tests are not running successfully inside the container. There is every reason to think that the misbehavior of the tests will also manifest when you try to run the installed software for your intended purposes. That's pretty much the point of automated testing.
On the other hand, if you're building inside the container for some kind of build environment isolation purpose, then successful testing outside the container combined with incorrect behavior of the tests inside would indicate at minimum that the container does not provide an environment adequately matched to the target execution environment. That should undercut your confidence in the test results obtained outside. Validation tests intended to run against the installed software are a thing, to be sure, but they are a different thing than build-time tests.
I am trying to cross compile the atlas library for an armv7 cortex-a9 processor.
When I try to make build it takes more than five hours to build the library from source. I think the problem is it runs all sanity tests. Is there a way to skip this?
Host system: ubuntu 16.4 in a virtual box with 4gb ram allocated , and 2 cores.
Target system: cortex a9, small endian armv7 architecture
Build process:
export PATH =$PATH:PATH TO ARM TOOL CHAIN FROM BUILDROOT
export CC=arm-linux-gcc
export ARCH=arm
export RANLIB=arm-linux-ranlib
export STRIP=arm-linux-strip
export LD=arm-linux-ld
export CPP=arm-linux-cpp
export AR=arm-linux-ar
export AS=arm-linux-as
export FC=arm-linux-gfortran
downloaded the atlas library
tar -xf atlas.3.10.3.tat.gz
cd ATLAS
mkdir test
cd test
../configure -Si archdef 0
make build
It would be helpful to know if I am missing some steps in between or any build commands to be included while make so that the sanity tests don't happen and I
get the output any sooner?
Though it doesn't answer your question, just FYI - modern approach is to use docker for building, CI tests and so on. VM (such as VirtualBox) will eat more resources.
For ARM cross-compilation you may consider https://github.com/dockcross/dockcross it has image for Cortex-A9 as well.
If you makefile runs long tests, then there may be an option to skip them indeed. Check the makefile if the author implemented something for that purpose.
I recently installed rustup on my Windows machine and incorporated it into Atom as my editor. Everything works fine, but as soon as I do a cargo run on my project, the first thing that Cargo says is:
Blocking waiting for file lock on build directory
This blocks the whole process for about a minute before the actual compile and run starts. As far as I remember this did not happen before (I use Cargo under OS X but without rustup).
Is there any way to disable this or at least reduce the timeout?
The tokamak Atom plugin runs cargo commands. Since you cannot run cargo twice at the same time, you get this notice.
I don't think there is something you can do, unless waiting for the compiler to speed up.
Perhaps playing with the options like save_buffers_before_run in tokamak.toml could make a difference.
Today I facing the same problem, and this command works for me:
rm -rf ~/.cargo/.package-cache
Once you run the code, just run cargo build
I built GNU Radio and followed this Guide: https://gnuradio.org/redmine/projects/gnuradio/wiki/UbuntuInstall#Installing-GNU-Radio.
Make runs fine.
But when I start
make test
qa_ofdm_txrx failes.
Whenn i run
ctest -V -R ofdm_tx
there is a unresolved Name:
packet_nu_tag_key
Can some one tell me which library is missing?
I didn't get any matches by Google when i search for packet_nu_tag_key.
Edit:
What i forgot to mention is it is Ubuntu 14.10.3
packet_nu_tag_key is actually a typo (hence a bug). I'll have a pull request up in a minute; I'd expect this to be solved rather quickly.
However, if it's only that unit test that fails for this reason, congratulations, you have a successfully built GNU Radio. Continuing to (sudo) make install will set it up correctly.
If you want to try my bugfix:
git pull https://github.com/marcusmueller/gnuradio.git digital_fix_typo_nu_num
in your gnuradio repository.
I am currently trying to run Coverity Prevent and I believe I have everything set up appropriately on my windows 7 build machine. I have run it with AnthillPro and when my code finishes and gets to Coverity it says that everything was built fine and the only error I get is:
Warning: Cygwin pathname conversion ignored; no applicable
'bash'/'mount', 'cygpath', or registry keys found.
I have even tried to install Cygwin to see if this could rectify the problem and I still end up with the same error.
I am currently using AnthillPro 3.7 and Coverity 5.5.3. The build log says that I have warnings but no errors and that it hasn't emitted anything. I have tried to run a script directly from the machine (not server) itself and I have the same error as I do using the Coverity Prevent in Anthill
This is the only information I get at the bottom of the build log.
Run from AnthillPro:
Build time (cov-build overall): 00:00:17.753597
[WARNING] No files were emitted. This may be due to a problem with your configuration
or because no files were actually compiled by your build command.
Please make sure you have configured the compilers actually used in the compilation.
For more details, please look at:
d:\Coverity\Intermediate\AllToolsProjects.sln_pc_vs2010\build-log.txt
Run from Script:
The cov-build FAILED.
This may be because less than 90 percent of units were successfully compiled
Check for errors here:
D:\\Coverity\Scripts\build_AllToolsProjects.sln_pc_vs2010.bat
D:\\Coverity\Intermediate\AllToolsProjects.sln_pc_vs2010\build-log.txt
D:\\Coverity\Configuration\pc_vs2010
It sounds like you haven't configured the compiler - that's when you tell your Coverity Analysis installation which compiler you are using. devenv is not a compiler, cl.exe is.
Run the following command:
coverity-analysis-dir/bin/cov-configure --msvc
This will say that you are using the cl.exe compiler and it's of type msvc no matter where it's installed.
Then rerun your Coverity build and see if it captures more of your compilations.