find.exe conflicts on Windows emacs

emacs를 사용할때 내부적으로 unix 툴인 find.exe를 사용하는데 이것은 Windows에 기본으로 내장되어 있는 find.exe프로그램과 이름이 같다. 따라서 emacs에서 unix의 find.exe를 call하고 싶어도 할 방법이 없다.

이것에 대한 해결책은 다음과 같다. 간단한 솔루션이지만 정말 많은 시간을 소비했다. --;;

Copy grep.exe and find.exe to Emacs’ own bin directory

Quickbuild script examples

Quickbuild를 잘~ 사용하려면 built-in script(OGNL)를 많이 사용해야 한다. script reference가 있음에도 친절한 수준은 아니라서 reference만 보고 하기에는 시간 낭비가 만만치 않다. 그래서 내가 사용했던 script snippet을 공유하면 도움이 되지 않을까 하는 생각에서 정리해 본다.

to use Quickbuild effectively, you should know how to use built-in script(OGNL). Though there is complete script reference, it's not easy to use it at first time. so It would be helpful for Quickbuild newbie to share these script snippet.


based on Quickbuild V3.x
+ Getting workspace directory of 'root/dev' on specific node.

${system.getConfigurationManager().get("root/dev").getWorkspaceDir()}
or
${system.getConfiguration("root/dev").getWorkspaceDir()}

+ Getting revision of last successful build of 'root/dev'

${system.getConfiguration("root/dev").getLatestSuccessfulBuild().getRepository("repo").getRevision()}

+ If TXT variable is equal to node's attribute value of 'CAP_GCC' returns true. otherwise returns false. This can be used at 'node match condition'.

node.getAttribute("CAP_GCC").equals("${vars.get("TXT")}")

+ check if this node is Windows OS

grid.getNode(params.get("nodes")).getAttribute("WRAPPER_OS").equals("windows")

+ return true if all specified step is successful

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":""}

link again with another link option in cmake build tree

cmake를 사용하다 보면 다른 link option으로 같은 바이너리를 여러벌 만들어야 할 경우가 생길 수 있다. 손쉽게는 debug 혹은 release와 같이 configuration을 나눠서 여러번 빌드해서 원하는 것을 이룰 수 있다. 하지만 rebuild 없이 현재까지 빌드된 object파일들을 가지고 할 수 있는 방법이 있다면 더 효율적일 것이다.

그래서 고민한 끝에 얻은 결론은 link.txt를 이용하는 것이었다.  전체 적인 sequence는 :

• "${CMAKE_CURRENT_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/${this_target}.dir/link.txt" 에 link command가 들어가 있다. 역시나 link할때 cmake -E로 이 파일을 이용해서 링크를 하고 있다.


• 따라서 FILE(READ ...)로 link.txt을 read한 다음 내 입맛에 맞게 link option을 수정한다. STRING(REPLACE ...) 혹은 STRING계열 함수를 이용하면 쉽게 요리가 가능하다


• 새로운 link command를 link2.txt로 저장한다.


• 그 후 cmake -E로 해당 link command를 불러주면 된다.

나의 경우 한번은 --no_deubg 옵션이 들어가게 링크하고 또 다른 한번은 이 옵션 없이 link를 해야  할 필요가 있었다. 이것을 cmake macro로 단순화 하면 다음과 같다.

새삼 느끼는 거지만 cmake 참 좋다. ㅎ

[sourcecode]
MACRO(LINK_WITH_ANOTHER_OPTION _target)
FILE(READ "${CMAKE_CURRENT_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/${_target}.dir/link.txt" _link)
STRING(REPLACE "--no_debug" "" _link2 ${_link})
FILE(WRITE "${CMAKE_CURRENT_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/${_target}.dir/link2.txt" ${_link2})
# message(status ${_link})
# message(status ${_link2})
ADD_CUSTOM_COMMAND(TARGET ${_target}
POST_BUILD
COMMAND ${CMAKE_COMMAND} -E cmake_link_script "${CMAKE_CURRENT_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/${this_target}.dir/link2.txt" --verbose=$(VERBOSE)
COMMENT "link with different option ${_target}"
)
ENDMACRO(LINK_WITH_ANOTHER_OPTION)
[/sourcecode]

SidebySide(WinSxS) problem

Windows 계열에서 Dll hell문제를 해결하기 위한 하나의 방법으로 고안한것이 Side-by-Side tech 이다. dll 생성시 manifest파일을 만들고 그곳에 사용하는 버전의 crt버전을 적고 런타임시에 그 crt를 사용하는 기술이다.

최근에 겪었던 문제가 좀 복잡한 케이스 인데 상황을 설명하면 이렇다. Win7환경에서 Egg.dll을 빌드하자 아래와 같은 manifest.xml이 생성되었다.

[sourcecode language="xml"]
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC80.DebugCRT" version="8.0.50727.4053" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC80.DebugCRT" version="8.0.50727.762" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
</dependentAssembly>
</dependency>
</assembly>
[/sourcecode]

우선 위 manifest에서 이상한 것이 debugCRT가 2개라는 것이다.

1. 8.0.50727.4053


2. 8.0.50727.762

더구나 1번의 8.0.50727.4053버전은 내컴에 존재하지도 않는다. 내 컴에서 빌드를 했음에도 4053이 있다!  그래서 실행하면 side by side error를 낸다.

이것은 무엇을 의미하느냐 Egg.dll이 link하는 3rt party lib중의 하나가 분명 4053버전으로 컴파일이 되었단 이야기다.  그래서 결과적으로 4053과 762버전 둘다 manifest에 들어가게 된것이고. 빌드는 이렇게 되었으나 runtime시에 해당 dll을 찾을 수 없다고 에러가 뜬다. 더구나 4053버전은 Win7을 support하지 않는다.

여기까지 왜 이런 문제가 생겼는지 까지는 이해가 되었다. 그럼 해결하는 방법은 msdn forum에 언급되었다. 발췌하면 아래와 같다.

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/

이와 별개로 manifest를 생성하지 않는것도 한 방법이다. 다소 risky 하긴 하지만..