In sbt, I can pass arguments to ScalaTest using testOptions in Test += Tests.Arguments("...") as described here.
Is there a way to pass these options through scct to ScalaTest when calling scct:test? I tried testOptions in Scct += ... but it seemed to have no effect.
scct looks like it has two configurations: ScctTest and Scct. From the source, you probably want testOptions in ScctTest
Related
There's the command sbt flywayMigrate from flywaydb.org. The command requires use to set flywayUrl, flywayUser, and flywayPassword beforehand. It was good so far.
Now I want to be able to use sbt flywayMigrate for two different environment; Their variables should be different.
I tried to make two new commands: sbt flywayMigrateDev and sbt flywayMigrateProd. I couldn't figure out how to connect the new commands to flywayMigrate.
I tried creating a new scope. But I couldn't figure out how to wire the variables and tasks properly.
I wonder if anyone can give me an example on how to do this. I'd like to see a code example.
We can simplify the problem to:
There's the command sbt flywayMigrate that depends on flywayUrl. How do we allow the command to use different flywayUrls by calling sbt commands (or any other way is good, too)?
Thank you!
You should use config for this.
Example .sbt file contents:
// Set up your configs.
lazy val prodConfig = config("prod")
lazy val devConfig = config("dev")
// Set up any configuration that's common between dev and prod.
val commonFlyway = Seq(
// For the sake of example, a couple of shared settings.
flywayUser := "pg_admin",
flywayLocations := Seq("filesystem:migrations")
)
// Set up prod and dev.
inConfig(prodConfig)(flywayBaseSettings(prodConfig) ++ commonFlyway)
flywayUrl.in(prodConfig) := "jdbc:etc:proddb.somecompany.com"
// Or however you want to load your production password.
flywayPassword.in(prodConfig) := sys.env.getOrElse("PROD_PASSWD", "(unset)")
inConfig(devConfig)(flywayBaseSettings(prodConfig) ++ commonFlyway)
flywayUrl.in(devConfig) := "jdbc:etc:devdb.somecompany.com"
flywayPassword.in(devConfig) := "development_passwd"
Now you can run prod:flywayMigrate and dev:flywayMigrate to migrate production and development, respectively.
See the Flyway docs page for other examples.
Let's consider the following Makefile:
.PHONY : all
OPTS += -DBLA
OPTS += -DBLUBB
STUFF = default
all :
./do_something $(OPTS) $(STUFF)
One can pass variables on the command line. So with the following call
confus#confusion:/tmp/$ make STUFF=foo
make will run ./do_something -DBLA -DBLUBB foo.
Contrary to what I thought one can't append to variables:
confus#confusion:/tmp/$ make STUFF+=foo OPTS+=-DMOREOPT
will simply run ./do_something -DMOREOPT foo (as if I had left out the plus signs), when I'd expect it to ./do_something -DBLA -DBLUBB -DMOREOPT default foo.
Is there a way to append to a make variable with a command line option?
If this is GNU make, you have to use the override directive in your makefile to specify that you want the values set in the makefile to take precedence over the command line values:
override OPTS += -DBLA
override OPTS += -DBLUBB
override STUFF += default
If it matters, note that this will put the settings provided on the command line first, and the settings in the makefile last.
This topic has been discussed a few times, but the answers only seem to cover GNU make. For this particular Makefile, I'd like it to be a single cross-platform file assuming GNU make for Mac and Linux, and dmake for Windows.
I'm trying to figure out how to assign macros/variables for only a specified target using dmake.
In this case, I'm going to use it for preprocessor definitions.
I'd like to add
CPPFLAGS += -DINITIAL
to an 'initial' target and
CPPFLAGS += -DUPDATE
to an 'update' target.
Using GNU make, we can achieve this by the following:
initial: CPPFLAGS += -DINITIAL
initial:
...
update: CPPFLAGS += -DUPDATE
update:
...
but unfortunately, it breaks the build using dmake.
Using dmake, the syntax needs to be slightly changed to
initial ?= CPPFLAGS += -DINITIAL
Resource: http://www.openoffice.org/tools/dmake/dmake_4.3.html#lbAS
Wrapping the different syntaxes in OS checks allows for a cohesive Makefile .
Is there a way to conditionally disable forking if the project is run in debug mode:
sbt -jvm-debug 9999
Then in my build:
fork in Test := {
//find a key that lets me know if debugging in set up
!isDebugging.value
}
Specifying flywayUrl through system property in SBT should be of some help.
Add the following to build.sbt:
lazy val isDebugging = settingKey[Boolean]("true when xdebug is true; false otherwise")
isDebugging := System.getProperty("xdebug") == "true"
fork in Test := !isDebugging.value
When you execute sbt -Dxdebug=true it gives you what you want.
BTW I see no references to jvm-debug in the SBT sources, but it is indeed in the shell script I'm using to fire it up. It could be that you'd have to change sbt-launch-lib.bash to accommodate the change to add xdebug when -Xdebug is set.
Jacek's suggestion is pointing to the right direction, but couldn't work for me (or even at all?). System.getProperty cannot retrieve -Xdebug flag set by an sbt's Bash script basically - when calling System.getProperties, -Xdebug is not listed there, likewise any other non-standard JVM property (like -Xmx for example).
What's worked for me is this:
lazy val isDebug = settingKey[Boolean]("true when -Xdebug is set, false otherwise")
isDebug := ManagementFactory.getRuntimeMXBean.getInputArguments.contains("-Xdebug")
fork in Test := !isDebug.value
Cheers!
how to define a config in pro file ?
by default, we have two config, debug and release. I want to add 2 other config but not in pro.user ! in pro file.
Your question is a bit unclear. It sounds like maybe you're currently building with "debug" and "release", from the command line, and you want to add your own build variants similar to that.
If that's the case... the mechanism for this is addExclusiveBuilds. Here is an example. I wouldn't recommend to mess around with it if you aren't comfortable reading qmake code.
TEMPLATE = app
SOURCES = main.cpp
# Adds two build variants.
# One of them builds the app with optimal compiler flags,
# the other one builds the app with support for collecting coverage data.
# For the first one, CONFIG will contain `optimized' and a Makefile.Optimized will be generated.
# For the second, CONFIG will contain `coverage' and a Makefile.Coverage will be generated.
# There will also be a top-level Makefile which invokes both the sub-makefiles.
addExclusiveBuilds(optimized, Optimized, coverage, Coverage)
CONFIG(optimized, coverage|optimized) {
message(I am in the optimized build variant)
QMAKE_CXXFLAGS += -O3
TARGET = myapp-optimized
}
else:CONFIG(coverage, coverage|optimized) {
message(I am in the coverage build variant)
QMAKE_CXXFLAGS += --coverage
QMAKE_LFLAGS += --coverage
TARGET = myapp-coverage
}
else {
message(I am in the glue project which contains the build variants)
# This will cause a `make' to build both optimized and coverage
# variants by default.
CONFIG += build_all
}
If I understand what you are saying, you add what you want to the CONFIG variable:
CONFIG += user_setting
...
user_setting: message( "compiling with user_setting" )
See the qmake manual where it talks about the CONFIG variable, especially near the end of the section.