grep.exe and find.exe to Emacs’ own bin directory${system.getConfigurationManager().get("root/dev").getWorkspaceDir()}
or
${system.getConfiguration("root/dev").getWorkspaceDir()}
${system.getConfiguration("root/dev").getLatestSuccessfulBuild().getRepository("repo").getRevision()}
node.getAttribute("CAP_GCC").equals("${vars.get("TXT")}")
grid.getNode(params.get("nodes")).getAttribute("WRAPPER_OS").equals("windows")
steps.get("master>sync").isSuccessful()&&steps.get("master>sdk").isSuccessful()&&steps.get("master>publish").isSuccessful()+ select a build agent which doesn't have any job. this can be used at 'node match condition'
node.isBuildAgent() && (node.getJobCount()==0)+ previous step is successful and check specific variable
current.getPreviousSibling().isSuccessful()&&vars.get("isPrevent").value=="no"+ add -c option when clean option checked
${vars.getValue("clean")=="yes"?"-c":""}
The fact that both 762 and 4053 are listed in the same manifest is a big red flag. This should never happen. The only way it could possibly happen is that you are still linking to static libraries that have not been rebuilt to refer to 762 instead of 4053. You should rebuild those static libraries.
If it's not possible to rebuild those static libraries i.e. they are third party libraries that you don't have access to, I suggest you follow instructions in the link below (a blog entry that I wrote over a year ago) to make your manifests show 762 only, not 4053. Don't worry, this won't make your app less secure, if the appropriate 4053 DLLs have been installed on the user's machine, they'll still be loaded, through the power of policy redirection). see:
http://tedwvc.wordpress.com/2009/08/10/avoiding-problems-with-vc2005-sp1-security-update-kb971090/
projectA: projectB, base
projectB: base
...
Save the following script as Extract-VS2005Dependency.ps1
[sourcecode language="powershell"]
# usage
# powershell .Extract-VS2005Dependency -slnFile c:my.sln
param(
[string] $slnFile = $(throw 'need slnFile path')
)
$projects = @{}
switch -regex -file $slnFile
{
"^Project.*= ""(w+)"",.*vcproj"", ""(.*)""" {
#$_ ;
$projects[$Matches[2]] = $Matches[1]
}
}
#$projects
#$projects.count
switch -regex -file $slnFile
{
"^Project.*= ""(w+)"",.*vcproj"", ""(.*)""" {
#$_ ;
$curProject = $Matches[1]
""
write-host "$($curProject):" -nonewline
}
"({[A-Fa-f0-9-]+}) = 1" {
# $_
# $Matches[1]
write-host $projects[$Matches[1]]"," -nonewline
}
}
[/sourcecode]
powershell .vcproj2cmake.ps1 c:xxx.vcproj -conf 'Debug'
예전 글과 같은 논의/설득의 과정을 통해서 팀에 위키 도입하는 것에 성공했다. 하지만 내가 원한 상용 위키 도입은 미뤄졌다. 우선 무료 위키로 시작하고 본 궤도에 올라가면 상용을 써 보도록 하자고 결론이 났다.
우선 무료 위키 소프트웨어를 리스트 업해서 우리에게 맞는 위키를 하나 선택해야 했다. 후보는 DokuWiki, Media wiki, MoinMoin 등으로 압축되었다. 이중 WISWIG방식이 가장 쓸만한 MoinMoin으로 선택했다. 이유는 위키를 처음 접하는 사람들이 많았기 때문에 최대한 learning curve가 없어야 한다는 이유에서이다. 만약 그런 고려를 하지 않았다면 Media wiki를 사용했을것이다.
