I have a very complex scons project. One of the targets include running a unittest application that is generated as part of the build.
I would like to be able to say:
scons <target> <some magic: arguments>
where some magic is something that will tell scons for which execution step the arguments are and the arguments are completely arbitrary arguments that the unittest application knows how to interpret.
the question is, is there already mechanism to do this, or I need to add code in my scons to achieve this - in both cases a pointers how to do it will be great.
Please check the User Guide at http://scons.org/doc/production/HTML/scons-user.html . You'll be interested in chapter 10 "Controlling a Build From the Command Line", which describes ways how to propagate values from the command-line to your SConscripts.
Reserve an Environment Variable, e.g. "UNITTST_ARGS", and use it to transport your arguments through to your SConscript, where you actually call your external unittest application.
Related
There are many ways to produce a verbose make command with cmake.
This has been described in many places. (basically cmake; make VERBOSE=1 or set the CMAKE_VERBOSE_MAKEFILE variable).
Verbose here refers to showing the invoked commands and other information on the steps taken by make.
This seems to be an all or nothing setting.
Either you see all the commands or none of the commands,
regardless of the whether the command succeed or not.
A related tool, ctest (for testing) has a very useful options --output-on-failure for which verbosity depends on the particular test being successful;
only showing the screen out for failing tests.
The question is whether cmake has a similar feature regarding giving details only on failure.
That is, for the most part I don't want to see make compilation commands, but when it fails I would like to see what is the exact command that failed with all the options on display.
That is, the question is if there is some setting or command-line option for make or cmake that, in the build step, will print the full issued command (and output) only for commands that failed.
The reason of course is that it gives the opportunity to see the actual compilation flags for the failing step and allows to reproduce the exact command interactively sometimes.
(I use C++, but the question is general I think)
This is not exactly an answer because you only mentioned make, but what you ask is the default behavior of Ninja. It only outputs the command that failed.
Sometimes, when I am too desperate and I cannot understand the error messages I do this:
make -j 10 -k || make VERBOSE=1
So it will compile fast, and if it fails it runs again serially in verbose mode. It is very likely that the first compilation is the one failing.
I'm using PVS-Studio in docker image based on ubuntu:18.04 for cross-compiling a couple of files with arm-none-eabi-gcc. After doing pvs-studio-analyzer trace -- .test/compile_with_gcc.sh strace_out file is successfully created, it's not empty and contains calls to arm-none-eabi-gcc.
However pvs-studio-analyzer analyze complains that "No compilation units were found". I tried using --compiler arm-none-eabi-gcc key with no success.
Any ideas?
The problem was in my approach to compilation. Instead of using a proper build system, I used a wacky shell script (surely, I thought, using a build system for 3 files is an overkill, shell script won't hurt anybody). And in that script I used grep to redefine one constant in the source - kinda like that: grep -v -i "#define[[:blank:]]\+${define_name}[[:blank:]]" ${project}/src/main/main.c | ~/opt/gcc-arm-none-eabi-8-2018-q4-major/bin/arm-none-eabi-gcc -o main.o -xc
So compiler didn't actually compiled a proper file, it compiled output of grep. So naturally, PVS-Studio wasn't able to analyze it.
TL;DR: Don't use shell scripts as build system.
We have reviewed the stace_out file. It can be handled correctly by the analyzer, if the source files and compilers are located by the absolute path in the stace_out file. We have a suggestion what might help you. You can "wrap" the build command in a call to pvs-studio-analyzer -- trace and pvs-studio-analyzer analyze and place them inside your script (compile_with_gcc.sh). Thus, the script should start with the command:
pvs-studio-analyzer trace --
and end with the command:
pvs-studio-analyzer analyze
This way we will make sure that the build and analysis were started at the same container run. If the proposed method does not help, please describe in more detail, by commands, the process of building the project and running the analyzer. Also tell us whether the container reruns between the build and the formation of strace_out, and the analysis itself.
It would also help us a lot if you ran the pvs-studio-analyzer command with the optional --dump-log flag and provided it to us. An example of a command that can be used to do this:
pvs-studio-analyzer analyze --dump-log ex.log
Also, it seems that it is not possible to quickly solve the problem and it is probably more convenient to continue the conversation via the feedback form on the product website.
I can use envireonment-variables such as $(TargetFileName) in my pre- and post-build-events. What I want to do is apply those variables to the command-line args of an external program (in my case nunit). So whenever my app starts I want to start another one with the file-name of the first as arg.
Is this possible?
When debugging my project the nunit-windows appears but shows an error-message that the given assembly $(OutDir)$(TargetFileName)$(TargetExt) could not be found. I suppose that the variables are only available during build but not during run so it seems I have to hardcode the parameters to the command-line args. Is this true?
I'd like to simplify the workflow so that rather than issuing these commands
$ make program_unittest
... output of $MAKE ...
$ ./program_unittest args
I could have my program automatically attempt to compile itself (if the source has been updated) when it is run, so that I do not have to go back and run make myself.
Here's what I'm thinking: My unit test build should first check if there is a makefile in the directory it's in, and if so, fork and exec make with the target corresponding to itself. If make determines "nothing to be done", it will continue on its way (running the unit-tests). However, if make actually performs a compilation, one of two things may happen. gcc (invoked by make) might be able to overwrite the build (an older version of which is already running) during compilation, in which case I can then perhaps exec it. If my system does not permit gcc to overwrite the program which is in use, then I have to quit the program before running make.
So this has become quite involved already. Are there perhaps more elegant solutions? Maybe I could use a bash script? How do I ascertain if make issued compilation commands or not?
Why not have make run the unit tests?
In Xcode, I know that you can get variables such as PROJECT_DIR to use in some situations, such as a run script build phase. I am wondering if it's possible to get the build type (i.e., Release or Debug). Any ideas?
The best source is probably Apple's official documentation. The specific variable you are looking for is CONFIGURATION.
Here's a list of the environment variables. I think you might want CURRENT_VARIANT. See also BUILD_VARIANTS.
They're not all documented. For example, you won't find ARCHIVE_PATH, MARKETING_VERSION (the version string set in Xcode) in Naaff's or smorgan's answer. These 2 are very common pieces of information someone would need! Here's a list of all of them I got: https://gist.github.com/ben-xD/c063b0ca2c33684de1eb379bb9d6405d
How I got them
I found the best way was to print them using set, I just wrote this including a method to list all the environment variables available.
Add this to your run script (either Archive post run script, or your build phases run script, etc.):
#!/bin/sh
exec > ${PROJECT_DIR}/environment_variables.log 2>&1
set
Look in environment_variables.log and you'll see them all.