cmake, 서브프로젝트간 의존성 추적이 좀 부족해보인다.

예를들어 최상위 CMakeLists.txt 는 아래 세개의 서브프로젝트를 가진다.
[code]
add_subdirectory(foo)
add_subdirectory(bar)
add_subdirectory(main)
[/code]

foo, bar 는 라이브러리를, main 은 실행파일을 만드는데 main 에는 bar 를 링크해야 하고 bar 에는 foo 를 링크해야 한다. 뭐 사실상 라이브러리간 링크가 아니고 main 에 foo, bar 모두 링크해야 하지만 main 쪽에서 봤을때는 bar 만 보이고 foo 는 bar 뒤에 딸려오는 놈이라고 볼수있다. 즉 의미상 foo -> bar, bar -> main 의 관계가 생긴다.

foo 의 CmakeLists.txt 는 간단.

[code]
project(foo)
add_library(foo foo.c)
[/code]

bar 를 빌드할때는 foo 가 필요하다.
[code]
project(bar)
add_library(bar bar.c)

include_directories(${foo_SOURCE_DIR})
link_directories(${foo_BINARY_DIR})
target_link_libraries(bar foo)
[/code]

main 을 빌드할때는 bar 만 명시해주면 foo 는 cmake 가 알아서 붙여준다.
[code]
project(main)
add_executable(main main.c)

include_directories(${bar_SOURCE_DIR})
link_directories(${bar_BINARY_DIR})
target_link_libraries(main bar)          // bar 가 필요하면 bar 에 필요한 foo 도 딸려온다.
[/code]

우왕굿.
그럴듯 해보인다.
main 은 직접적인 의존성이 걸린 bar  만 신경쓰면 되고 foo 는 존재조차 알 필요 없다.

하지만 저런식의 구성이 될경우 bar 는 foo 의 헤더를 인클루드 해서 main 에 까지 노출하는 경우가 태반이다. 즉 main 쪽에서 foo 쪽의 헤더를 찾아야 하고 cmake  는 링크 의존성은 줄줄이 해결해 주지만 인클루드 의존성은 해결해주지 않는다..

결국 main 의 CMakeLists.txt 에서 bar 뒤에 숨은 foo 에 접근을 해야할 필요가 생긴다
[code]
project(main)
add_executable(main main.c)

include_directories(${foo_SOURCE_DIR})      # 갓댐!

include_directories(${bar_SOURCE_DIR})
link_directories(${bar_BINARY_DIR})
target_link_libraries(main bar)
[/code]


흠. 뭔가 맘에 안드는 모양새다. bjam 은 include 의존성도 잘 풀어줬던걸로 기억나는데.. 뭐 cmake 가 계속 조금씩 나아지고 있으니 언젠가 방법이 나오겠지. 아니면 link_libraries 가 버려지고 target_link_libraries 가 나온것처럼 다른 명령어가 이미 추가됐을지도.. 는 아직(2.8 버전) 아닌거 같다.



추가.
흠 위에서 link_directories 를 매번 해줬는데 안해줘도 된다. target_link_libraries 가 알아서 경로까지 가져온다. boost 던가가 msvc 에서는 link_directories 를 해줘야 돌아서 버릇삼아 적은건데.. 후에 수정하자.