I am trying to define some values in my ccnet.config file.
I am running version 1.4.4.83.
I added xmlns:cb="urn:ccnet.config.builder" to my main cruisecontrol element.like:
<cruisecontrol xmlns:cb="urn:ccnet.config.builder">
next I defined some defines processor constants:
<cb:define prodbuildtag="1.1.25.1207" />
<cb:define testbuildtag="1.1.25.1207">
finally I tried to reference the define values in a tag like so:
<sourcecontrol type="svn">
<trunkUrl>https://someserver/svn/myproject/tags/$(prodbuildtag)</trunkUrl>
<username>johnDoe</username>
<password>JelloW0r1d</password>
<tagOnSuccess>false</tagOnSuccess>
<tagBaseUrl>https://someserver/svn/myproject/tags/</tagBaseUrl>
</sourcecontrol>
When I bulid using the script it treats the define $(prodbuildtag) as an empty string and checkes out the code based on the trunkUrl 'https://someserver/svn/myproject/tags/'. I am having trouble getting the Configuration Preprocessor to work; please help.
I tested the code you posted in 1.5 and it seems to work. If you are including multiple files make sure you have <cruisecontrol xmlns:cb="urn:ccnet.config.builder"> in each file
I think $() syntax resolves environment variables as well.
I know that this works because we do it all the time. Here is an example of what we have in our ccnet.config file:
<cruisecontrol xmlns:cb="urn:ccnet.config.builder">
<cb:define svnPath="C:\Program Files\CollabNet Subversion\svn.exe"/>
<cb:define svnReposRootUrl="http://someserver/svn"/>
<!-- cc.net auto-updating config project -->
<project name="ccnet-config">
<triggers>
<intervalTrigger seconds="30"/>
</triggers>
<sourcecontrol type="svn">
<workingDirectory>C:\Program Files\CruiseControl.NET\server\config</workingDirectory>
<executable>$(svnPath)</executable>
<trunkUrl>$(svnReposRootUrl)/build/trunk/ccnet/config/XMGBUILD01</trunkUrl>
</sourcecontrol>
</project>
</cruisecontrol>
It's not clear from your question where the cb:define tag is in relation to where you are using it. I would try putting it as child of the cruisecontrol element. I don't know if it can be a child of anything else... I've never tried.
Related
I am running a pipeline and was trying to optimize it by declaring the paths in a config file (config.yaml). The config.yaml file contains the path to find the scripts to run inside the pipeline, but when I expand the wildcard of the path, the pipeline does not run the script. The script itself runs fine.
To explain my problem:
rule with_script:
input: someinput
output: someoutput
script: expand("{script_path}/scriptfile", script_path = config[scriptpath])
input, output or rule all do not contain the script's path wildcard, so here is the first time I'm declaring it. The config.yaml line that contains the path looks like this:
scriptpath: /path/to/the/script
is there a way to maintain the wildcard and config file path (to make it easier for others to make changes if needed) and have the script work? Like this snakemake doesn't even enter the script file. Or maybe it is possible to declare global wildcards outside the rule all?
Thank you for your help!
P.S.: I'm sorry if this question has already been answered, but I couldn't find anything to help me with this.
You cannot define a function like expand() in the script section. Snakemake expects a path to your script.
Like the documentation states:
The script path is always relative to the Snakefile containing the directive (in contrast to the input and output file paths, which are relative to the working directory). It is recommended to put all scripts into a subfolder "scripts"
If you need to define different paths to your scripts, you can always do it in python outside of your rules. Don't forget, all python code outside of rules is executed before building the DAG. Thus, you can define all variables you want and use them in your rules.
SCRIPTSPATH = config["scriptpath"]
rule with_script:
input: someinput
output: someoutput
script: "{SCRIPTSPATH}/scriptfile"
Note:
Do not mix wildcards and "variables". In an expand function as
expand("{script_path}/scriptfile", script_path = config[scriptpath])
{script_path} is not a wildcard but just a placeholder for the values given in the second parameter of the function.
I'm having problem understanding how to correctly set the COMPILE_DEFINITIONS target properti in CMake.
my target is add_library(modelutilities STATIC ${modelutilities_SRCS})
I if use
set(modelutilities_COMPILE_DEFINE ${modelutilities_COMPILE_DEFINE} ${Qt5Widgets_COMPILE_DEFINITIONS})
set_target_properties(modelutilities PROPERTIES
VERSION "0.0.1"
SOVERSION 0
EXPORT_NAME "ModelUtilities"
ARCHIVE_OUTPUT_DIRECTORY "${modelutilities_PlatformDir}/lib"
LIBRARY_OUTPUT_DIRECTORY "${modelutilities_PlatformDir}/lib"
RUNTIME_OUTPUT_DIRECTORY "${modelutilities_PlatformDir}/bin"
COMPILE_DEFINITIONS ${modelutilities_COMPILE_DEFINE}
)
everything works fine, but if I add another line between them with set(modelutilities_COMPILE_DEFINE ${modelutilities_COMPILE_DEFINE} MODELUTILITIES_LIB) it stops working complaining that set_target_properties was called with the wrong number of arguments.
Anyone can spot what I'm doing wrong?
P.S.
I already tried using doublequotes: set(modelutilities_COMPILE_DEFINE ${modelutilities_COMPILE_DEFINE} "MODELUTILITIES_LIB"). It did not change anything
P.P.S.
If I message(STATUS ${modelutilities_COMPILE_DEFINE}) QT_WIDGETS_LIB;QT_GUI_LIB;QT_CORE_LIB in the first case and QT_WIDGETS_LIB;QT_GUI_LIB;QT_CORE_LIB;MODELUTILITIES_LIB in the second
With newer version of CMake, what is being preached is the idea of targets. So, for example, instead of include_directories() it's now preferred to use target_include_directories().
That being the case I think you'd be better served using the preferred target_compile_definitions() to set compile definitions for your utilities library.
One advantage you get is that your can scope your compile definitions using the PUBLIC or PRIVATE keywords.
I would like to use Doxygen for documenting my Arduino code. For this I need the *.ino-files in my project to be treated like *.c-files and be parsed with the C code parser in Doxygen. I think there was a setting somwhere for this mapping but I can't find it anymore.
My settings so far:
FILE_PATTERNS = [...] *.ino
Oh, I think I already found the option. It is located under "Project" in doxywizard, "EXTENSION_MAPPING". These are the options that seem to be working for me now:
FILE_PATTERNS = [...] *.ino
EXTENSION_MAPPING = ino=c
And the tag that gets me every time: A #file-tag has to be added to the top of the file, otherwise it is ignored by Doxygen. Like so:
/**#file sketch_1.ino */
I have a Plone add-on with the following setup.py
setup(
...
install_requires=[
...
'zope.i18n',
...
'Zope2',
],
...
)
If I run bin/instance I get the following traceback:
File ".buildout/eggs/zope.configuration-3.7.4-py2.7.egg/zope/configuration/config.py", line 1527, in resolveConflicts
raise ConfigurationConflictError(conflicts)
zope.configuration.config.ConfigurationConflictError: Conflicting configuration actions
For: ('utility', <InterfaceClass zope.i18n.interfaces.INegotiator>, '')
File ".buildout/eggs/zope.i18n-3.7.4-py2.7.egg/zope/i18n/configure.zcml", line 3.2-6.8
<utility
provides="zope.i18n.interfaces.INegotiator"
component="zope.i18n.negotiator.negotiator"
/>
File ".buildout/eggs/Zope2-2.13.22-py2.7.egg/ZPublisher/i18n.zcml", line 5.2-8.8
<utility
provides="zope.i18n.interfaces.INegotiator"
component="zope.i18n.negotiator.negotiator"
/>
If I comment out zope.i18n from setup.py, run buildout again, then the instance starts fine.
Surprisingly enough, both bin/instance files (before and after removing zope.i18n) are exactly the same.
So I'm sort of left clueless about what's wrong on defining something on setup.py that anyway the same version gets picked...
Last note, on the distribution's main configure.zcml I have this line:
<includeDependencies package="." />
Does this matter at all?
That seems odd?? obviously it's not possible to registry twice the same utility, but both packages do? I'm very confused about that. Usually you don't need the <includeDependencies package="." /> parts, since all components should be loaded by the plone entry point of z3c.autoinclude. I assume in a default plone environment, one of the components will not be loaded.
I checked in on a Plone 4.3.6... The Negotiator of zope.i18n is used.
So my best bet is, that your <includeDependencies package="." />, also loads the configure.zcml of Zope2, which should not happen.
Removing the <includeDependencies package="." />, may solve your issue.
We are moving into Scala/SBT from a Java/Gradle stack. Our gradle builds were leveraging a task called processResources and some Ant filter thing named ReplaceTokens to dynamically replace tokens in a checked-in .properties file without actually changing the .properties file (just changing the output). The gradle task looks like:
processResources {
def whoami = System.getProperty( 'user.name' );
def hostname = InetAddress.getLocalHost().getHostName()
def buildTimestamp = new Date().format('yyyy-MM-dd HH:mm:ss z')
filter ReplaceTokens, tokens: [
"buildsig.version" : project.version,
"buildsig.classifier" : project.classifier,
"buildsig.timestamp" : buildTimestamp,
"buildsig.user" : whoami,
"buildsig.system" : hostname,
"buildsig.tag" : buildTag
]
}
This task locates all the template files in the src/main/resources directory, performs the requisite substitutions and outputs the results at build/resources/main. In other words it transforms src/main/resources/buildsig.properties from...
buildsig.version=#buildsig.version#
buildsig.classifier=#buildsig.classifier#
buildsig.timestamp=#buildsig.timestamp#
buildsig.user=#buildsig.user#
buildsig.system=#buildsig.system#
buildsig.tag=#buildsig.tag#
...to build/resources/main/buildsig.properties...
buildsig.version=1.6.5
buildsig.classifier=RELEASE
buildsig.timestamp=2013-05-06 09:46:52 PDT
buildsig.user=jenkins
buildsig.system=bobk-mbp.local
buildsig.tag=dev
Which, ultimately, finds its way into the WAR file at WEB-INF/classes/buildsig.properties. This works like a champ to record build specific information in a Properties file which gets loaded from the classpath at runtime.
What do I do in SBT to get something like this done? I'm new to Scala / SBT so please forgive me if this seems a stupid question. At the end of the day what I need is a means of pulling some information from the environment on which I build and placing that information into a properties file that is classpath loadable at runtime. Any insights you can give to help me get this done are greatly appreciated.
The sbt-buildinfo is a good option. The README shows an example of how to define custom mappings and mappings that should run on each compile. In addition to the straightforward addition of normal settings like version shown there, you want a section like this:
buildInfoKeys ++= Seq[BuildInfoKey](
"hostname" -> java.net.InetAddress.getLocalHost().getHostName(),
"whoami" -> System.getProperty("user.name"),
BuildInfoKey.action("buildTimestamp") {
java.text.DateFormat.getDateTimeInstance.format(new java.util.Date())
}
)
Would the following be what you're looking for:
sbt-editsource: An SBT plugin for editing files
sbt-editsource is a text substitution plugin for SBT 0.11.x and
greater. In a way, it’s a poor man’s sed(1), for SBT. It provides the
ability to apply line-by-line substitutions to a source text file,
producing an edited output file. It supports two kinds of edits:
Variable substitution, where ${var} is replaced by a value. sed-like
regular expression substitution.
This is from Community Plugins.