I am looking for a way to tell NAnt not to execute a specified target. I've not found anything online so I'm not hopeful but perhaps the good people of SO can help.
The situation is: we have targets A, B, C, D, as well as an overall target T that calls all the others. A is independent of the others so is not really necessary; consider it a sort of an expensive sanity check.
I want to be able to run T and but exclude A - so it would only run B, C, D.
Is this possible, or do I have to declare a new target to specifically run those jobs?
I am thinking in very simple way. You situation might be different.
I would have made T depend on B, C and D only.
When A is also needed I can call it in form of:
NAnt buildfile:Blah.build A T
#NotAgain's answer is useful if the target to be excluded is at the beginning or the end of the chain, but it does involve setting up a new target, or at least editing the existing one.
The best solution I've found so far is to use the conditional logic expressions.
Example:
<property name="runThis" value="true" />
<target name="runIfPropTrue" if="${runThis}">
<exec program="test.bat" />
</target>
This way you can set up any targets you may wish to exclude and switch them on and off by editing the property or by passing it in as a parameter instead.
I assume you can use the unless expression just as easily but I haven't tested it.
Related
Background
I'm trying to remove resize-observer-polyfill from an nx workspace that I'm working on because it's natively supported in the browsers that we are targeting. Once I removed the polyfill, I needed to add #types/resize-observer-browser because the workspace currently uses typescript#4.0.5 and my understanding is that TypeScript does not have a "native" type for ResizeObserver until v4.2 which I'd love to update to, but can't atm.
Problem
In order to make TypeScript happy, it seems like I have to go in and manually add "resize-observer-browser" to individual tsconfig compilerOptions.types entries. This didn't seem that bad to me at first. I just updated the tsconfig.lib.json file of the libraries that happened to utilize ResizeObserver. However, I soon realized I needed to also add it to the tsconfig.spec.json of the libraries so that the unit tests could run, and then I also needed to add it to the tsconfig.app.json of any applications that happened to import those libraries.
Question
Is there an easier way in an nx workspace to handle this sort of problem?
I think that I could remove the default types overrides in each of the tsconfig files, since that would let TypeScript just utilize everything that exists under node_modules/#types when compiling. I didn't want to take that path since I assume there is a good reason for the default nx library/app generators to add the types override (I assume it's to force you to be explicit and not accidentally get away with accidental imports of test code from business logic).
The docs seem to recommend against this for #types packages, but /// <reference types="..." /> (e.g. /// <reference types="resize-observer-browser" />) can be also be used to include types, and might be easier to manage if the type is only used in a few places.
Docs: https://www.typescriptlang.org/docs/handbook/triple-slash-directives.html#-reference-types-
In the Snakemake documentation, the includes directive can incorporate all of the rules of another workflow into the main workflow and apparently can show up in snakemake --dag -n | dot -Tsvg > dag.svg. Sub-workflows, on the other hand, can be executed prior to the main workflow should you develop rules which depend on their output.
My question is: how are these two really different? Right now, I am working on a workflow, and it seems like I can get by on just using includes and putting the name of the output in rule all of the main workflow. I could probably even place the output in the input of a main-workflow rule, making the includes workflow execute prior to that rule. Additionally, I can't visualize a DAG which includes the sub-workflow, for whatever reason. What do sub-workflows offer that the includes directive can't do?
The include doesn't "incorporate another workflow". It just adds the rules from another file, like if you add them with copy/paste (with a minor difference that include doesn't affect your target rule). The subworkflow has an isolated set of rules that work together to produce the final target file of this subworkflow. So it is well structured and isolated from both main workflow and other subworkflows.
Anyway, my personal experience shows that there are some bugs in Snakemake that make using subworkflows quite difficult. Including the file is pretty straightforward and easy.
I've never used subworkflows, but here's a case where it may be more convenient to use them rather than the include directives. (In theory, I think you don't need include and subworkflow as you could write everything in a massive Snakefile, the point is more about convenience.)
Imagine you are writing a workflow that depends on result files from a published work (or from a previous project of yours). The authors did not make public the files you need but they provide a snakemake workflow to produce them. Their snakemake workflow may be quite complex and the files you need may be just intermediate steps. So instead of making sense of the all workflow and parsing it into your own include directives, you use subworkflow to generate the required file(s). E.g.:
subworkflow jones_etal:
workdir:
"./jones_etal"
snakefile:
"./jones_etal/Snakefile"
rule all:
input:
'my_results.txt',
rule one:
input:
jones_etal('from_jones.txt'),
output:
'my_results.txt',
...
My NUnit tests fail unless the nunit runner is launched with /noshadow parameter.
But in CC.net, it seems to be impossible to supply this parameter in the <nunit> block.
I know I always can fall back to generic <exec> block, but is there really no way to configure the <nunit> block?
I would surmise that if this switch/flag isn't documented, then it isn't available in the that you mention.
The thing to keep in mind with these custom tasks, is that usually they are just friendly-wrappers for what eventually becomes a command-line call.
The task-author is just making things simpler for you. They take on the onus of creating the correct commandline, and pass that to the original .exe.
Now, it looks like somebody did address the command line of your interest here:
https://github.com/loresoft/msbuildtasks/blob/master/Source/MSBuild.Community.Tasks/NUnit.cs
Note the code:
if (DisableShadowCopy)
{
builder.AppendSwitch(c+"noshadow");
}
So I would see if you can get this task working.
In fact, I barely use any of the built in CC.NET tasks, except for source-code download and starting up msbuild.exe...and then the publishing. I leave the hard stuff to msbuild.
Aka, I pull source-code, which includes a MyBuild.proj file.
Then I have cc.net execute "msbuild.exe MyBuild.proj"
Then I have cc.net do some of the publishing.
Why?
If most of my logic is in a msbuild .proj file, then if I ever switch to another CI tool, the transition is much less traumatic. In fact, I recently learned that an old job of mine went to TFS, and because I wrote most of the build logic in msbuild (and not a lot of cc.net tasks)....the transition to TFS was fairly painless. If I had used cc.net tasks instead......every single one of those would have had to been translated to a corresponding tfs task.... :<
Anyways. Back to your question. Keep in mind...that somebody is basically (via a task) is usually just writing up a nice way to wire up things, and doing the command line arguments/syntax sugar for you. So they sometimes miss a flag, or a flag gets added later, but the original task is not updated.
So you'll either need to modify the source code yourself........ :< Or pick a library that keeps more up to date.
Good luck.
For better or worse, I've built my own msbuild task. I've given it the name 'msbuild' and it's colliding with one from NAntContrib.
Assuming, I can't remove the one from NAntContrib, is there a way to override the contrib version while keeping the same task name?
Or perhaps another task could be written that can alias an already loaded task to be named something else?
Or I can probably change my task name.
Any info would be appreciated.
I have not seen a way you can overload task names. It sounds like the easiest thing to do would be to change the name of your tasks to something that is not msbuild.
A bit of a hack I found that seem to work is basically giving your task a namespace prefix.
[TaskName("zz:msbuild")]
public class MsbuildTask : ExternalProgramBase
{
}
Then in your nant build file:
<project default="Build" name="TestBuild"
xmlns="http://nant.sf.net/schemas/nant-0.85.win32.net-1.0.xsd"
xmlns:zz="http://nant.sf.net/schemas/nant-0.85.win32.net-1.0.xsd">
<target name="Build">
<zz:msbuild target="Build" project="TestBuild.sln"
verbosity="${msbuild.verbosity}">
<property name="Configuration" value="${build.configuration}" />
</zz:msbuild>
</target>
</project>
The only thing I don't like is the fact that I have to embed the prefix in the TaskNameAttribute. This is necessary because internally NAnt uses the string "zz:msbuild" to hash the task and looks up based on XmlNode.Name property.
Also notice that the prefix is pointing to the default namespace. This is because NAnt discards nodes with namespaces other than the default NAnt namespace. I can kind of understand why they did that but I don't know that it's absolutely necessary.
Looking at the NAnt source, it seems very much feasible to make the adjustments so that I don't have to embed the prefix and to give the task a different namespace.
The alternative to this approach, the one that I've been using previously, was to use task name like "zz.msbuild". But that didn't really seem correct. I remember reading somewhere having a period in element names is not recommended. But more than that, it didn't look good :P
Java compiler provides incremental build, so javac ant task as well. But most other processes don't.
Considering build processes, they transform some set of files (source) into another set of files (target).
I can distinct two cases here:
Transformator cannot take a subset of source files, only the whole set. Here we can only make lazy build - if no files from source was modified - we skip processing.
Transformator can take a subset of sources files and produce a partial result - incremental build.
What are ant internal, third-party extensions or other tools to implement lazy and incremental build?
Can you provide some widespread buildfile examples?
I am interested this to work with GWT compiler in particular.
The uptodate task is Ant's generic solution to this problem. It's flexible enough to work in most situations where lazy or incremental compilation is desirable.
I had the same problem as you: I have a GWT module as part of my code, and I don't want to pay the (hefty!) cost of recompiling it when I don't need to. The solution in my case looked something like this:
<uptodate property="gwtCompile.mymodule.notRequired"
targetfile="www/com.example.MyGwtModule/com.example.MyGwtModule.nocache.js">
<srcfiles dir="src" includes="**"/>
</uptodate>
<target name="compile-mymodule-gwt" unless="gwtCompile.mymodule.notRequired">
<compile-gwt-module module="com.example.MyGwtModule"/>
</target>
Related to GWT, it's not possible to do incremental builds because the GWT compiler looks at all the source code at once and optimizes and inlines code. This means code that wasn't changed could be evaluated differently, for example if you start using a method from a class that wasn't changed, the method was in the previous compilation step left out, but now needs to be compiled in.