I have an action defined that generates coverage files, it takes some options.
actions coverage {
echo coverage $(OPTIONS) >> $(<)
}
I need a rule to set the $(OPTIONS) variable:
rule coverage ( targets * : sources * : properties * ) {
OPTIONS on $(targets) = ... # Get from environment variables
}
Once I have done that, I can use the rule to generate coverage files:
make cov.xml : : #coverage ;
What I want is a second rule (that computes the $(OPTIONS) variable in a different way), that uses the same actions. Is that possible without duplicating the action itself? In other words, is it possible to associate two rules with the same action?
What I want is something like this:
actions coverage-from-features {
# AVOID HAVING TO REPEAT THIS
echo coverage $(OPTIONS) >> $(<)
}
rule coverage-from-features ( targets * : sources * : properties * ) {
OPTIONS on $(targets) = ... # Get from feature values
}
make cov2.xml : : #coverage-from-features ;
Obviously without repeating the action commands itself (DRY and all that).
The key aspect you need is that: You don't need to use actions that mirror the rule invoked. A rule can call any, and multiple actions, to do the work. In your case you can do something like:
actions coverage-action {
echo coverage $(OPTIONS) >> $(<)
}
rule coverage ( targets * : sources * : properties * ) {
OPTIONS on $(targets) = ... ; # Get from environment variables
coverage-action $(target) : $(sources) ;
}
rule coverage-from-features ( targets * : sources * : properties * ) {
OPTIONS on $(targets) = ... ; # Get from feature values
coverage-action $(target) : $(sources) ;
}
make cov.xml : : #coverage ;
make cov2.xml : : #coverage-from-features ;
Related
So, let's say, I call bjam debug, or bjam release, or bjam clean, possibly with other target names, and I'd like to have the build action or type (debug, release, clean) available in a script.
Here https://android.googlesource.com/platform/external/boost/+/ac861f8c0f33538060790a8e50701464ca9982d3/Jamroot I found an example, that I modified like this:
import modules ;
tbuildcmd = "" ;
if clean in [ modules.peek : ARGV ]
{
tbuildcmd = clean ;
}
else if release in [ modules.peek : ARGV ]
{
tbuildcmd = release ;
}
else if debug in [ modules.peek : ARGV ]
{
tbuildcmd = debug ;
}
echo "tbuildcmd $(tbuildcmd)" ;
And this works fine, it seems - but I was wondering, is there a better method to get the build command/type as a variable? For instance, they say in https://www.boost.org/doc/libs/1_35_0/doc/html/bbv2/tutorial.html :
The release and debug that we've seen in bjam invocations are just a shorthand way to specify values of the variant feature. For example, the command above could also have been written this way:
bjam variant=release inlining=off debug-symbols=on
So, there is apparently a "variant" "feature" - but how can I use / echo it? I tried echo $(<variant>) and that failed.
I am currently using this action:
actions re2c {
re2c --tags -o `basename $(<)` $(>)
}
But I'd like to use the path.basename rule instead. Something along the lines:
rule re2c ( targets * : sources * : properties * )
{
import path ;
targets = [ path.basename $(targets) ] ;
}
This approach is not working for me.
In VMD I want to load every new file with the drawing method CPK. This doesn't seem not to be an option in the .vmdrc file for some technical reasons.
How can I do this from the VMD command line (so that I can make a script)?
Or is there some other solution/workaround/hack to make this work?
There are several ways to achieve what you want:
(1) put the following line in the correct location of your .vmdrc
mol default style CPK
(2) use the VMD Preferences Panel (last item in the Extensions menu of the main window) to generate a .vmdrc file that meets your expectations(s). The setting you're looking for is in the Representations tab.
(3) for more advanced settings (i.e. default settings applied to molecules already loaded when vmd read the startup .vmdrc file), you can use the following (works for me on VMD 1.9.2):
proc reset_viz {molid} {
# operate only on existing molecules
if {[lsearch [molinfo list] $molid] >= 0} {
# delete all representations
set numrep [molinfo $molid get numreps]
for {set i 0} {$i < $numrep} {incr i} {
mol delrep $i $molid
}
# add new representations
mol representation CPK
# add other representation stuff you want here
mol addrep $molid
}
}
proc reset_viz_proxy {args} {
foreach {fname molid rw} $args {}
eval "after idle {reset_viz $molid}"
}
## put a trace on vmd_initialize_structure
trace variable vmd_initialize_structure w reset_viz_proxy
after idle {
if { 1 } {
foreach molid [molinfo list] {
reset_viz $molid
}
}
}
This piece of code is adapted from this Axel Kohlmeyer website.
HTH,
I found a convenient solution.
In .bashrc add:
vmda () {
echo -e "
mol default style CPK
user add key Control-w quit
" > /tmp/vmdstartup
echo "mol new $1" > /tmp/vmdcommand
vmd -e /tmp/vmdcommand -startup /tmp/vmdstartup
}
Look at a structure with
vmda file.pdb
and close the window (quit the application) with Ctrl+w, like other windows.
I need to skip specifications and individual tests while running my test suite.
Here's an example such test:
package models
import org.specs2.mutable._
import org.specs2.runner._
class SlowTaggedSpecification extends Specification{
"SLOW_SPEC" should {
"BAD!! Not Skipped" in {
"axbcd" must find( "bc".r )
}
} section( "SLOW_SPEC" )
}
class SlowFastTaggedSpecification extends Specification{
"SLOW_FAST_SPEC" should {
"run fast test" in {
"axbcd" must find( "bc".r )
} section( "FAST_TEST" )
"SLOW_TEST should be skipped (BAD!! NOT Skipped)" in {
"axbcd" must find( "bc".r )
} section( "SLOW_TEST" )
} section( "SLOW_FAST_SPEC" )
}
I need to skip SLOW_SPEC (entire spec) and SLOW_TEST (indvidual test only).
My build.sbt is:
scalaVersion := "2.11.1"
libraryDependencies += "org.specs2" %% "specs2" % "2.3.12" % "test"
When I run the following command line:
sbt '~testOnly models.* -- -l SLOW_SPEC'
sbt '~testOnly models.* -- -l SLOW_TEST'
none of the tests gets skipped. May I know how do I exclude a specification and an individual test using tags? Also, what would be the sbt syntax if I weren't using testOnly , but test?
sbt '~test -- -l SLOW_SPEC'
causes sbt to complain. My sbt version is 0.13.5
Any pointers would be appreciated.
The command line argument to exclude tags is
sbt> ~testOnly models.* -- exclude SLOW_SPEC
If you want to exclude tags when using the test command you need to use Test.Arguments in your build.sbt file:
testOptions in Test += Tests.Argument(TestFrameworks.Specs2, "exclude", "SLOW_SPEC")
If you want to specifically run a SLOW_SPEC test, then use the following:
sbt 'set testOptions in Test := Seq()' '~testOnly models.SlowTaggedSpecification'
I need to edit a .jam file used by boost-build for a specific kind of projects. The official manual on BJAM language says:
One of the toolsets that cares about DEF files is msvc. The following line should be added to it. flags msvc.link DEF_FILE
;
Since the DEF_FILE variable is not used by the msvc.link action, we need to modify it to be: actions link bind DEF_FILE { $(.LD) ....
/DEF:$(DEF_FILE) .... } Note the bind DEF_FILE part. It tells bjam to
translate the internal target name in DEF_FILE to a corresponding
filename in the link
So apparently just printing DEF_FILE with ECHO wouldn't work. How can it be expanded to a string variable or something that can actually be checked?
What I need to do is to print an error message and abort the build in case the flag is not set. I tried:
if ! $(DEF_FILE)
{
errors.user-error "file not found" ;
EXIT ;
}
but this "if" is always true
I also tried putting "if ! $_DEF_FILE {...}" inside the "actions" contained but apparently it is ignored.
I am not sure I understand the global task you have. However, if you wanted to add checking for non-empty DEF_FILE -- expanding on the documentation bit you quote, you need to add the check in msvc.link function.
If you have a command line pattern (specified with 'actions') its content is what is passed to OS for execution. But, you can also have a function with the same name, that will be called before generating the actions. For example, here's what current codebase have:
rule link.dll ( targets + : sources * : properties * )
{
DEPENDS $(<) : [ on $(<) return $(DEF_FILE) ] ;
if <embed-manifest>on in $(properties)
{
msvc.manifest.dll $(targets) : $(sources) : $(properties) ;
}
}
You can modify this code to additionally:
if ! [ on $(<) return $(DEF_FILE) ] {
ECHO "error" ;
}