윈도머신을 ssh 로 관리하기

http://www.oreillynet.com/onlamp/blog/2008/06/ssh_in_to_microsoft_windows.html?CMP=OTC-6YE827253101&ATT=ssh+in+to+Microsoft+Windows

지금 쓰고있는 윈도머신이 없어서 테스트는 안해봤다. 저글에 소개된 freeSSHd 는 전에 한번 써본것 같은데 기억이 안나네. 다운만 받고 설치를 안했었나?

어쨌거나 이런게 있으니 기억해두자. 위키에 적기 애매한 링크라 여기 적어둔다.
뭐 사실 적어는 두지만 내가 이걸 쓸것 같지는 않다. rdp 가 쓸만하니까..

실행파일 안에 파일 집어넣기

http://www.linuxjournal.com/content/embedding-file-executable-aka-hello-world-version-5967

흠 재미나는 방법이구나. 아래 댓들에도 나왔지만 나라면 재미없게 덤프떠서 변수 하나에 바이너리 때려박는 .c 파일을 만들었을텐데 위에서 소개된 방법은 정말 묘하다.

boost test 프레임웍 최소한의 사용법

아 씨바 좃스팟이 로그인이 안되길래 일단 여기 적어둔다.
사무실에서 테스트해본거라 리눅스 환경.

Makefile 소스 보기

CC  = gcc
CXX = g++
LDFLAGS += -lboost_unit_test_framework

all: a.out b.out

a.out: a.o
    $(CXX) $^ $(LDFLAGS) -o $@
b.out: b.o
    $(CXX) $^ $(LDFLAGS) -o $@

%.o: %.cpp
    $(CXX)  -c $(CXXFLAGS) -o $@ $< -MMD
%.o: %.c
    $(CC)  -c $(CFLAGS) -o $@ $< -MMD

clean:
    -rm -f *.o *.d
    -rm -f core
    -rm -f a.out b.out

-include $(wildcard *.d)

a.cpp 는 워낙 간단하니 적지 않는다.

b.cpp 소스 보기

#define BOOST_TEST_DYN_LINK                         // 소스를 보니 boost_unit_test_framework 를 동적으로 링크하려면 이걸 디파인을 해줘야 하는듯.
                                                    // 실사용시라면 이자리 보다 Makefile 등에서 해주는게 맞겠지.
#define BOOST_TEST_MODULE test module name blahblah // 테스트 모듈의 이름을 define 으로 지정해 주는 모냥이군.
#include <boost/test/unit_test.hpp>                 // included 버전의 헤더를 쓴다면 링크를 피할수 있어서 편해지지만 빌드가 느려질거다

// 함수하나를 만들어서 자동으로 register 까지.
// 앵간한 경우라면 요 방법 하나만 알고 써먹어도 충분할듯.
// BOOST_AUTO_TEST_CASE 매크로를 이용해서 test case 를 추가.
BOOST_AUTO_TEST_CASE(test_sucks)
{
    BOOST_CHECK(1);                          // assert 와 같은놈 참이면 pass 거짓이면 fail
    BOOST_CHECK_EQUAL(1,1);                  // 두 인자 동등비교. 이게 굳이 필요한가? BOOST_CHECK 하나로 충분한거 아닌가
                                             // 어쨌건 요런놈들을 test tools 라고 하는데 boost/test/test_tools.hpp 를 읽어보자.

    int i = 0;
    BOOST_TEST_CHECKPOINT("before divzero"); // 신기하구나. 시그널이나 트랩등이 걸린 경우는 가장 마지막 CHECKPOINT 를 찍어준다. 의심나는 구간 앞에 박아두면 된다.
    i = 100 / i;

    BOOST_TEST_MESSAGE("you sucks");         // 찍혀야 하는거 아닌가 안찍히네
                                             // 아.. 이놈을 빌드해서 나온 파일을 실행할때 --log_level=all 이란 옵션을 주면 된다.
                                             // 또는 환경변수에 BOOST_TEST_LOG_LEVEL=all 를 줘도 같은 효과.
                                             // boost test 의 문서중 parameters 라는 부분을 찾아 읽어보자.
}




// 테스트 스위트를 만드려면 BOOST_AUTO_TEST_CASE() 와 BOOST_AUTO_TEST_SUITE_END() 매크로 를 쓴다.
// 스위트까지 만들어서 테스트를 할일이 있을까? 흠 fixture 를 써야 할 경우라면 필요하겠군.
BOOST_AUTO_TEST_SUITE(suite)

BOOST_AUTO_TEST_CASE(hello_suite)
{
}

// 중첩도 가능
BOOST_AUTO_TEST_SUITE(suite)

BOOST_AUTO_TEST_CASE(hello_inner_suite)
{
}

BOOST_AUTO_TEST_SUITE_END()

BOOST_AUTO_TEST_SUITE_END()




// 좀 복잡한 테스트 스위트
BOOST_AUTO_TEST_SUITE(suite2)
struct adder {
    adder()  { BOOST_TEST_MESSAGE("setup fixture"); }
    ~adder() { BOOST_TEST_MESSAGE("teardown fixture"); }
    int add(int x, int y) { return x+y; }
};

BOOST_FIXTURE_TEST_CASE(test_adder_1, adder)
{
    // adder 의 non-private 멤버에 바로 접근이 가능
    BOOST_CHECK_EQUAL(add(1,1),1);
}


BOOST_AUTO_TEST_SUITE_END()

몇가지 포인트만 적어보면

• header 파일을 인클루드 할때 included 아래의 헤더를 가져오면 이놈이 main 을 가지고 있어서 boost_unit_test_framework 를 링크할 필요가 없다. 단 이런짓을 하면 안그래도 느린 빌드속도가 더 느려질테니 불편해도 링크를 해서 쓰자. 이내용은 boost test 문서중에 FAQ 에 들어있다.
• 리눅스 환경에서 처음 빌드했을때 링크에러가 자꾸 났었다. 적당히 소스를 뒤져보니 BOOST_TEST_DYN_LINK 를 디파인해주지 않아서 생긴 문제. 물론 so 버전 말고 .a 를 링크해줘도 해결됐었겠지. 어쨌거나 이부분은 좀 거슬리는데.. 윈도환경에서도 테스트를 해보고 그럴듯하게 빌드시스템(Make, Cmake) 로 뽑아내는 방법을 찾아야겠다.
• 위에서 적은 경우는 BOOST_AUTO_TEST_CASE 를 이용해서 함수를 정의하면서 register 까지 해버린 경우인데 사실 코딩하다 보면 함수 정의와 register 를 따로 해야 하는 경우도 생기겠지... 난 이런식으로 테스트 코드와 릴리즈 코드가 섞이는것을 좋아 하지 않으니 그런 경우는 아예 적지도 않았다. 릴리즈 빌드에 테스트코드 넣는것은 아직 거부감이 든다.
• BOOST_CHECK_BLAHBLAH 류의 매크로가 여러가지 준비되어있다. 이놈들을 test tools 라고 하는데 위 주석에도 적었지만 boost/test/test_tools.hpp 를 참고하자.
• 테스트 스위트 는 BOOST_AUTO_TEST_SUITE 와 BOOST_AUTO_TEST_SUITE_END 매크로로 정의되며 중첩도 가능하다.
• 테스트 스위트를 쓴다면 결국 픽스쳐를 쓴다는 소리. boost test 의 샘플을 가져다가 잘 도는것을 테스트해봤는데 프리프로세서 풀어보고 소스를 읽어보려고 하니 좀 복잡하네.
  
• 위 예제에서는 스위트 안에 adder 란 클래스와 test_adder_1 이란 픽스쳐를 만들었는데 만약 test_adder_2 라는 픽스쳐를 만들어서 테스트를 하게 되면 adder 가 두번 생성 ( 정확히는 boost test 시스템이 만든 adder 의 서브클래스겠지 ), 이 되서 각각의 fixture 마다 다른 인스턴스를 보게된다. fixture 마다 완전히 독립되었다는것 명심하자. 하나의 인스턴스를 순서대로 이어받는식으로 작성이 가능한지는 모르겠다.
• 위에 적은 내용을 확인하려면 BOOST_TEST_MESSAGE 등의 매크로를 쓰면 된다. 기본값으로는 이걸로 메시지를 뿌려도 안찍히니 boost test 에 parameter 란걸 조정해줘야 하는데 실행파일을 실행할때 --log_level=all 라는 인자를 주거나 BOOST_TEST_LOG_LEVEL=all  란 환경변수를 주거나 하는등의 방법이 있다. 이내용은 boost test 문서중 parameter 를 참고.