Disabling unit-test compilation in Boost.Build - bjam

Boost.Build documentation is quite laconic when it comes to testing.
All tests in my project are defined using unit-test rule.
The only property mentioned, by the documentation, is testing.launcher, but that can only disable tests' execution when set to testing.launcher=true.
How to completely disable compilation of unit-test rules? I would like to do that temporarily, for example, by setting a property from commandline. I could not find any information how to do that or any reference documentation for other testing.* properties.

If you mean disabling them by default? You can do it by adding "explicit ;" for each unit test. If you have many such targets you can save some typing and declare a rule that does it for you, plus declaring the unit test like:
rule explicit-unit-test ( target : source : properties * )
{
unit-test $(target) : $(source) : $(properties) ;
explicit $(target) ;
}
If you want something else.. I guess you need to better explain your question because I can't think of what else you could want.

As I read most of the Boost.Build documentation and the relevant part of its code I found no way to temporary disable building specific rule or the set of targets (for example by matching tests' targets with a regular expression).
It is, also, worth noting, that unit-test was deprecated in favor of the new testing rules: run, run-fail, compile, compile-fail, link, link-fail.
Now, probably, I'm going to create my own rule, as in #GrafikRobot's answer, but instead of making the target explicit I will make the rule empty in the presence of a certain feature.

I use explicit test suites for this purpose as in
explicit X ;
test-suite X
:
[ run test1.cpp ]
[ run test2.cpp ]
[ run test3.cpp ]
[ run test4.cpp ]
;
You will need to request explicitly the execution of the tests in the test-suite X using
bjam X

Related

how to contribute configurations from within a nuxt module

I'm writing a nuxt module following this guide.
Now I would like my module to add a proxy rule to the host application. Its a lot of guesswork and nothing has done the trick so far. I tried
nuxt.options.proxy.options.push(
{
target: 'https://target-url.com',
changeOrigin: true,
pathFilter: ['path/to/match']
}
)
}
but my IDE complains that proxy is not a known property of NuxtOptions. I did shorten the above code for the sake of this post. In my code I also made sure the respective objects exist before assigning something to them.
next best guess (based on the example for adding a css library) was to do the same thing, but on the runtimeConfig like so:
nuxt.options.runtimeConfig.proxy.options.push(...)
no complaints by the IDE anymore (duh, the runtimeConfig object is of type any) but no sign of the proxy actually working.

RobolectricGradleTestRunner vs RobolectricTestRunner.class

In roboelectric when you write your test class you have declare the #RunWith annotation of which there is RobolectricGradleTestRunner and RobolectricTestRunner.class. What is the difference and which one should we use ? Why is there 2 in the first place. If I use RobolectricTestRunner then it does not work for me it says some weird error like :
"java.lang.IllegalStateException: You need to use a Theme.AppCompat theme (or descendant) with this activity."
However this seems to go away if I use RobolectricGradleTestRunner.
RobolectricTestRunner was first and is for maven based projects.
RobolectricGradleTestRunner was for gradle based projects because some paths have changed.
Since robolectric 3.1.1 this is not more necessary and is now deprecated.
For more details see also http://robolectric.org/getting-started/

Setting value of setting on command line when no default value defined in build?

I am writing a plugin that requires a specific setting: configUrl
If I specify that setting in my build.conf it would look like this:
MyPlugin.configUrl := "http://..../..."
I can then use the command line to do this:
sbt 'set MyPlugin.configUrl := "http://..../..."' performAction
Is there a better way that allows me to not have that setting in build?
If I start sbt without that setting I get the following error:
[error] Reference to undefined setting:
[error]
[error] *:config-url from *:application-configuration
I searched google but could not find a way to provide the setting on the command line, something like this:
sbt config-url="http://..../..."
If the setting has a default value, that default should be set in the plugin. If it does not, the type should probably be Option[...] with a default of None. Typically, a build should not require a parameter to be passed from the command line just to be loaded.
Finally, if it is primarily the set syntax you dislike, you can use system properties and read the system property from your setting. However, this is restricted to Strings and so you lose type safety.
System properties can be set by -Dkey=value on the command line (either directly or in your startup script):
sbt -Dconfig.url=http://...
(quoting as needed by your shell). To pull this value into the setting:
MyPlugin.configUrl :=
url(System.getProperty("config.url", "<default>"))
where "<default>" is the value to use if the system property is not set. If you take the Option approach,
MyPlugin.configUrl :=
for(u <- Option(System.getProperty("config.url"))) yield
url(u)

symfony2 console arguments

I want to create a single named argument/option for symfony command. And want symfony to distinguish those 3 options:
my:command, which means something like my:command --arg=null
my:command --arg, which means my:command --arg=defalutValue
my:command --arg=someValue, which is fully explicit.
I.e. I want two working modes for code under that command: default one and non-default with additional argument, and that arg should have default value.
I understand, that I could create 2 args, but I'm looking for one-arg-to-rule-them-all solution.
Is it possible to accomplish that with built-in classes or should I create custom ones? If solution is only available with custom classes, please tell me, where to start (i.e. "create subclass of ..." or "install a bundle named ..."), cause I'm not familiar with Symfony2's architecture.
It is possible:
->addOption('arg', 'a', InputOption::VALUE_NONE)
my:command => $input->getOption('arg') //false
my:command --arg => $input->getOption('arg') //true
my:command --arg=5 => $input->getOption('arg') //5
Answer by corvax is incorrect and doesn't work. As of today, you just cannot achieve this.
It is even stated in the Console documentation: Using Command Options.
See also these issues on GitHub:
#8135 [Console] Input options with InputOption::VALUE_OPTIONAL and InputOption::VALUE_NONE not working as expected
#11883 [Console] Added three state long option
#12769 [Console] Ability to use option default only if the option was passed
#12773 [Console] Add method to know parsed option
Symfony2 have console component which can be used separately. You can see documentation here. For more example you can check implementations of SensioGeneratorBundle.

Conditional compilation "else"

In AS3 you can pass a constant to the compiler
-define+=CONFIG::DEBUG,true
And use it for conditional compilation like so:
CONFIG::DEBUG {
trace("This only gets compiled when debug is true.");
}
I'm looking for something like #ifndef so I can negate the value of debug and use it to conditionally add release code. The only solution I've found so far was in the conditional compilation documentation at adobe and since my debug and release configurations are mutually exclusive I don't like the idea of having both DEBUG and RELEASE constants.
Also, this format works, but I'm assuming that it's running the check at runtime which is not what I want:
if (CONFIG::DEBUG) {
//debug stuff
}
else {
//release stuff
}
I also considered doing something like this but it's still not the elegant solution I was hoping for:
-define+=CONFIG::DEBUG,true -define+=CONFIG::RELEASE,!CONFIG::DEBUG
Thanks in advance :)
This works fine and will strip out code that won't run:
if (CONFIG::DEBUG) {
//debug stuff
}
else {
//release stuff
}
BUT this will be evaluated at runtime:
if (!CONFIG::DEBUG) {
//release stuff
}
else {
//debug stuff
}
mxmlc apparently can only evaluate a literal Boolean, and not any kind of expression, including a simple not.
Use the if / else construct : the dead code will be removed by the compiler and it will not be tested at runtime. You will have only one version of your code in your swf.
If you are not sure use a decompiler or a dump tool to see what really happens.
http://apparat.googlecode.com/files/dump.zip
http://www.swftools.org/
...
While Patrick's answer fulfills the question's criteria, it does not cover all use cases. If you are in an area of code that allows you to use an if/else statement then this is a good answer. But if you are in a place where you cannot then you will need a better solution. For example, you may want to do something like this to declare a constant in a class:
private var server:String = "http://localhost/mystagingenvironment";
or for a live release:
private var server:String = "http://productionserver.com";
(this is an example and I'm not advocating this as production code).
I use xml configs and use the loadConfig+="myconfig.xml" to do my configuration instead of passing large numbers of command line params. So in the <compiler> section of your xml config:
<define>
<name>CONFIG::debug</name>
<value>false</value>
</define>
<define>
<name>CONFIG::release</name>
<value>!CONFIG::debug</value>
</define>
This works well for all use cases:
CONFIG::debug
{
private var server:String = "http://localhost/mystagingenvironment";
}
CONFIG::release
{
private var server:String = "http://productionserver.com";
}
This has the additional benefit of working consistently across applications. It also does not rely on the 'optimize' flag being true, like Patrick's answer (although I think we can assume that 99.999999% of all swfs have optimize=true, I only set it to false when the optimizer breaks my AS3).
It does have the drawback that it doesn't compile all code paths, just the ones that are included. So if you're not using a build server to create release builds and tell you when things break, be prepared for surprise errors when you do your release build ("But it compiled in debug! Crap, I need this to launch now!").
Just my two cents about Chris Hill's answer (which is the solution I also use regularly): it seems that using the loadConfig+="myconfig.xml" option makes the compiler searching for the myconfig.xml file in the Flex SDK directory whereas the -load-config+=myconfig.xml option makes it searching for the myconfig.xml file in the project's directory, which is the behavior I strongly prefer as you can then easily distribute this file with your project sources...

Resources