I have the following snippet, to copy a file as-is to the build dir:
for m in std_mibs:
print("Copying", m)
bld(name = 'cpstdmib',
rule = 'cp -f ${SRC} ${TGT}',
#source = m + '.mib',
source = bld.path.make_node(m + '.mib'), # <-- section 5.3.3 of the waf book
target = bld.path.get_bld().make_node(m + '.mib')
)
I see that this rule, though hit (from the print), the copy doesnt seem to be happening!
I also changed the source to use the make_node as shown, in an example in the section 5.3.3 of the waf book, still no luck! Am I missing something obvious here!?
Also, I have some rules after this, which rely on the copied files, and I tried adding
an intervening
bld.add_group()
I hope that the sequencing will work, if this copy succeeds
If you run the rule once, it will not be run again until source is updated. This is true even if the target is deleted, for instance (which is probably how you were testing.)
If you want to recopy if the target is deleted, you will need always=True, or you'll need to check for existence and set target.sig = None.
Two alternatives:
features="subst" with is_copy=True:
bld(features='subst', source='wscript', target='wscript', is_copy=True)
waflib.extras.buildcopy like this:
from waflib.extras import buildcopy
#...
def build(bld):
bld(features='buildcopy',buildcopy_source=['file'])
cp is not platform independent.
A task_gen object is created, which later will become a Task, that will be executed before process_sources. Don't expect an immediate effect.
Have a look into your out dir, there will be out/${TGT} (not exactly, but ${TGT} path relative to your top directory)
This is totally to be expected behaviour, since you do not want to modify your source tree when building.
Related
the rule is
"//Reference[matches(#literal, \"^\$[^!]+\") and ./preceding-sibling::Text and ./following-sibling::Text]"
for your convenient I will provide the project and you can mvn-test it.
the whole project is at https://github.com/XenoAmess/p3c/tree/1605f4d1b9c6a505074be5328953af26f578e190/p3c-pmd
the Rule class is com.alibaba.p3c.pmd.lang.vm.rule.other.UseQuietReferenceNotationRule
I tried to look through your update log, and found nothing related.
Thanks for help.
That's a side-effect of fixing https://github.com/pmd/pmd/issues/1923. It has been fixed by using real/full name in the rule context (see https://github.com/pmd/pmd/pull/1982). In unit tests, the file name used is "n/a", which is now interpreted as the file "a" in directory "n". RuleContext::getSourceCodeFilename returns just the filename and not the full path. To retrieve the full path RuleContext::getSourceCodeFile can be used.
Your rule UseQuietReferenceNotationRule checks the filename (UseQuietReferenceNotationRule.java:65) which is now not "n/a" anymore in the unit tests but "a". You can "fix" the unit test by simply changing UT_FILE_NAME to "a" (see UseQuietReferenceNotationRule.java:45).
Alternatively you can change the rule to use ctx.getSourceCodeFile().toString() to recover the full pathname in UseQuietReferenceNotationRule.java:62. Although the file doesn't exist, it still points to "n/a".
An alternative for checking the path names in the rule itself might be File exclusion/inclusion patterns.
Also, contributions on https://github.com/pmd/pmd are welcome if you think the rules make sense for a wider audience.
I'm using the visual client for perforce and I want to exclude a directory from the workspace. Before streams, I would just navigate to my workspace, find the folder in the tree, and exclude it (and I've found this solution in a number of other related questions I've found). However, now that I am using a stream, it won't let me do this, i have to edit the stream mapping apparently.
So I tried to add this line to the remapped box when editing the stream:
-//NumberPlus/current/Library/... //nplus-mainline/current/Library/
However I just get an error:
Error in stream specification.
Error detected at line 24
Null directory (//) not allowed in '-//NumberPlus/current/Library/...'.
EDIT: I'm in Windows 8.1, for clarification.
If the folder you want to exclude is specific to your machine, setting P4IGNORE locally is the easiest way to exclude it from being added to the depot.
http://www.perforce.com/blog/120214/new-20121-p4ignore
You'd set P4IGNORE to some name like "p4ignore.txt", create a file with that name, and add "Libraries" to it -- subsequent "p4 add" commands will skip over paths found in the P4IGNORE file, so those files will never get added to the depot.
If this is something that's going to be common to all workspaces of this stream (e.g. it's a build artifact that everyone is going to generate and nobody is supposed to check in), what you want to do is add an "exclude" to the stream's Paths (this will exclude it from both branch views and client views generated by that stream). E.g.:
Paths:
share ...
exclude Libraries/...
The "exclude Libraries/..." is basically the same thing as the exclusion line you would add to the client view, except you specify it as a relative path, you don't need to specify both sides of the mapping, and the "-" is implied by the "exclude" type. The "remap" type is if you want to keep those files but in a different depot location, which doesn't sound applicable here.
More information on defining stream views:
http://www.perforce.com/perforce/doc.current/manuals/p4v/streams_views.html
You can't just edit the mappings for your client workspace if it is switched to a particular stream. The whole point of streams is that your workspace mapping is directly generated from the stream definition. So that's a feature.
It's not totally clear whether
you don't want the directory in the stream at all, or
it's valid to have the directory in the stream, but you don't want to sync it to your workstation, or
you want the directory sync'd to your workstation, but you want the directory to have different contents (say, from some other stream which has a different version of the library.
However, for all of these situations, I suspect the best path forward is to define a new child stream of your current stream.
You will want to define the path mappings using the "share", "exclude", "isolate", and "import" mapping types.
For example, if you just didn't want the Library/... directory at all, you'd "exclude" it from your parent.
Then that stream simply won't have that directory, and it (of course) won't be on your workstation when you sync to the stream, either.
If you wanted to have a different copy of the code in the Library/... directory, so that it became a point of intentional divergence from the parent, you'd "isolate" it from your parent to submit your own custom version, or "import" it from another stream to use that stream's Library/... directory instead.
In either case, the directory would be part of the stream, and would be sync'd to your workstation, but the contents of that directory would differ from the contents that are used in the parent stream (the exact way in which they'd differ is under your control, as you define the stream accordingly).
Documentation and some examples are here: http://www.perforce.com/perforce/doc.current/manuals/p4v/streams_views.html
and here:
http://www.perforce.com/sites/default/files/pdf/Streams-ebook.pdf
I believe I have solved this. To be clear, I wanted the folder to be completely ignored by version control. I'm using p4connect with Unity and it keeps wanting to include unnecessary stuff in my depot.
All I had to do was add this line to my parent stream in the Paths box:
exclude current/Library/...
I'm trying to set up a build involving an external tool which produces a directory as output (doxyindexer for the curious). So far, I've essentially got these commands:
target = "doxysearch.db/iamchert"
doxygen.Doxyindexer(target,["project1.xml","project2.xml","project3.xml"])
Default([target])
Default(Install(ARGUMENTS["cgibin"],"doxysearch.db"))
The problem that I'm having is that I think I'd like target to be the directory itself, not some random file inside the directory. There's nothing I can glob because the target doesn't exist until I build it and I don't want to presume anything that Dimitri might change! When I use the directory as the target, I get this error:
TypeError: Tried to lookup Dir 'doxysearch.db' as a File.:
which is why I picked iamchert to be the target. Those lines all seem to work as expected, even if my approach is a hack. However, I can't get that last line to work. I need to copy the directory doxysearch.db into the cgi-bin directory, which is specified on the command line by the user. Maybe someone can explain how to do this step properly? I'm a newb when it comes to scons!
I'm having trouble googling the answer because all the search words involved are too common to find me specific help!
SCons does in fact treat all the files in a dir as dependencies of that dir. There are some dark corners that need work, but it should work in a simple case like this.
What you need is the undocumented target_factory builder flag. When you define Doxyindexer do it like this:
doxyindexer = Builder(..., target_factory=env.fs.Dir)
and have your builder return the dir itself. That should avoid the TypeError you were getting.
Im not sure how well SCons will work with the target being a directory. The issue is: How should SCons determine if the directory has changed or not to know if it should be built? The obvious answer would be that a directory is considered to be changed if it has more or less files therein, but I dont think SCons currently does this check and you might have to make your own builder to get it.
I did the following example to test this, and it never builds:
env = Environment()
env.Command(target = 'targetDir',
source = 'srcTextFile',
action = Copy("$TARGET", "$SOURCE"))
When I execute SCons, I always get the same result:
scons: '.' is up to date
Regarding your SCons code, I think it would work better as follows:
targetDir = "doxysearch.db/iamchert"
srcFiles = ["project1.xml","project2.xml","project3.xml"]
doxygenTarget = doxygen.Doxyindexer(targetDir, srcFiles)
# This may need to be called via the Command() builder like this:
# cmd = "doxygen.Doxyindexer("$TARGET", "$SOURCE")
# doxygenTarget = env.Command(target=targetDir, source=srcFiles, action=cmd)
# This call to Default isnt really necessary
Default(doxygenTarget)
Install(ARGUMENTS["cgibin"], doxygenTarget)
I'm having some trouble cherrypicking some folders out of a repo using SharpSvn (from C#). I did this:
client.CheckOut( uri, dir, new SvnCheckOutArgs() { Depth = SvnDepth.Empty } );
foreach( var folder in folders )
{
client.Update( folder );
}
But my second call to Update didn't work. It reports that the action was SvnNotifyAction.Skip and nothing gets written to the working copy.
uri is essentially something like: svn://myserver/myrepo/mysdk and dir is something like C:\Test\mysdk. (I've changed exact names for the purposes of this question, but structurally it's identical.)
Then the 1st folder is C:\Test\mysdk\include (this works)
Then the 2nd folder is C:\Test\mysdk\bin\v100\x86 (this one doesn't update)
Why would the first one work but when I get the 2nd folder (nested subfolders) it doesn't Update? It reports that it is skipped? But I don't know how to figure out why.
It turns out that updating the nested subdirectory doesn't work because the parent directories don't exist yet and so the nested subdirectory update is skipped. To fix this, I needed to add an argument to Update to indicate that it should create the parent directories.
(The equivalent svn command line option would be --parents).
client.Update( folder, new SvnUpdateArgs() { UpdateParents = true } );
I discovered this by trying to do it manually from the svn command line (and encountered the same problem.) svn help co offered this tiny clue: --parents : make intermediate directories I'm assuming that UpdateParents and --parents are equivalent. So far so good.
For example, instead of writing the following:
element * .../my_branch_01/LATEST
element * .../base_branch/LATEST -mkbranch my_branch_01
I would want to write something like this:
MY_BRANCH=my_branch_01
element * .../%MY_BRANCH%/LATEST
element * .../base_branch/LATEST -mkbranch %MY_BRANCH%
Is this even possible? What is the correct syntax?
The only native way to do this in ClearCase is to use attribute within a config-spec.
According to the version selector rules, you can make a "selection by query" rule, based for instance on an attribute:
element * ...{MY_ATTRIBUTE_NAME=="aValue"}
would select the LATEST version on any branch with an attribute 'MY_ATTRIBUTE_NAME' with 'aValue' in it.
That mean you need to change the attribute value on the old branch, put it on the new branch, 'cleartool setcs' your view again, and you should have a new content based on a new version selection.
Not very straight forward, but it could work, except for the mkbranch part (which needs a fixed name).
Regarding GeekCyclist's answer, a few comments:
The solution to include a common config spec can work for Base ClearCase solution, but:
need to be in a share available by all concerned developer
the setcs is indeed necessary to Ccuses the view_server to flush its caches and reevaluate the current config spec, which is stored in file config_spec in the view storage directory. This includes:
Evaluating time rules with nonabsolute specifications (for example, now, Tuesday)
Reevaluating –config rules, possibly selecting different derived objects than previously
Re-reading files named in include rules
all the other developers need to be notified when the common included config spec file changes (there is no native notification included in ClearCase)
If you need to have one "environment" (i.e. one "view" or workspace) with a variable content (depending on a different branch), you need to define a symbolic link (or a windows subst) pointing to different views (each with their own config spec)
That way, you only have to change the link (or the path subst'ed) in order to change the config spec associated with a given fixed path.
It's been a while since I worked in ClearCase (we switched to Subversion), but if I recall correctly there is no way to do this native to ClearCase.
You could use or write a script generator that would create your spec file and then include that in the actual spec:
element * CHECKEDOUT
include scripted_file_output
Then run
cleartool setcs -current
The problem with this approach is that I believe the include spec would need to be regenerated and the cleartool setcs run whenever you change the value of MY_BRANCH.