아 여기 제목...

헐 이건 제목을 어떻게 입력하지?? Live Writer

Post Blog Entry 프로그램 사용

한글이 안깨지려나..

Perl로 만들었다는 중력센서 제어

distcc를 이용한 분산컴파일 시도 요즘 안드로이드때문에 빌드시간을 단축시키기 위해 분산컴파일 환경에 관심이 많다.
안드로이드는 자바로 되어있지만 native 연결 즉 JNI 를 이용하기 위해서는 NDK 빌드를 해야하는데,
이게 시간이 제법 걸린다. 윈도우에서는 Cygwin( http://www.cygwin.com/ )을 이용하여 빌드를 해야한다.

distcc( http://code.google.com/p/distcc/ )는 gcc를 대신하여 소스파일을 전처리하고 include 종속성이 해결된 c코드를 분산PC에 보내서 컴파일하고,
결과파일을 다시 로컬 위치에 갖다놔서 make 가 진행되도록 한다.

컴퓨터 3대로 테스트를 해봤다. (집에 3대가 있다능~)
모두 Cygwin을 깔고, Devel과 Utility는 전체설치를 한다.
distcc 는 gcc의 버전이 모두 맞아야 잘 작동한다고 한다.(다르게해보진 않아서 모르겠다.)
Cygwin의 devel 항목에 distcc가 있긴하지만, 최신버전의 distcc와는 제대로 호환이 되지 않는다.
그래서 distcc 홈페이지에서 tar볼을 다운받아서 빌드한다.

$ wget http://distcc.googlecode.com/files/distcc-3.1.tar.bz2
$ tar xjf distcc-3.1.tar.bz2
$ cd distcc-3.1
$ ./configure ; make ; make install;

이제 각 컴퓨터 마다 distccd 를 띄워야한다.
/usr/local/share/doc/distcc/example 안에 있는 샘플 스크립트들을 이용해서
init.d나 xinet.d 등을 이용해서 스탠드 얼론이나 net서비스로 띄울수 있는데,
일단 수동으로 띄워보자.

distccd --daemon --allow="192.168.0.0/24"

하면 192.168.0.* 에서 오는 것은 모두 허용하게 된다. XP이사에서는 방화벽 차단해제확인이 뜨는데 해제해줘야 한다.
컴파일작업을 넘겨받을 좀비(?) 컴퓨터들에 모두 distccd를 띄웠다면,

이제 아까 distcc의 설치를 위해 했던 distcc의 소스컴파일 작업을 분산빌드로 시작시켜보자.

cd distcc-3.1
make clean
export DISTCC_HOSTS="192.168.0.3,lzo,cpp 192.168.0.16,lzo,cpp localhost,lzo,cpp"
./configure
pump make -j8 CC=distcc

하면
__________Using distcc-pump from /usr/local/bin
__________Using 3 distcc servers in pump mode
이라는 메세지와 함께 죽죽 빌드를 하게 된다.
이때 다른 Cygwin콘솔을 띄워서 distccmon-text 2 라고 실행을 시키면 2초에 한번씩
preprocessing , distributing, receiving 등의 진행 상태를  볼수 있다.

테스트 결과.
1대
real    2m28.380s
user    0m17.426s
sys     2m2.571s

2대
real    2m8.611s
user    0m7.852s
sys     2m2.504s

3대
real    2m8.329s
user    0m8.376s
sys     2m8.292s

흠...20초 정도 줄었다. 왜 별로 안줄어들까?
그러나 잘 보면 user 의 사용량이 확실히 줄어든 것을 볼수 있다.
이를 볼때, 컴파일때 CPU사용량이 많을수록 그 시간이 줄어들것이라 예상할수 있다.
소스가 작은 편이라 3대까지는 활용하는데 오히려 문제가 생기는거 같다.

ccache라든지 distcc 홈페이지에서 권장하는 향상툴을 같이 사용하면 더 좋아질지도 모르겠다.
아직은 뭔지 잘 모르지만.. ㅎㅎ

perl 로 GUI 프로그래밍을 해서 exe로 배포하고 싶다면? perl만으로 GUI프로그래밍을 하면서, exe로도 배포할 수 있다면??
과거 비주얼베이직만큼 만들기가 용이하면서도, 더 강력하고, 심지어는 크로스플램폼도 지원한다면?
내가 CTO라면 당장 회사의 표준언어로 perl을 채택할것이다.ㅋㅋ

Wx 프로그램을 perl로 만들고자 한다면, 딸기펄(Strawberry-perl) 을 추천한다.
MingW 가 내장되어있어 속시원하게 cpan모듈들을 즉석에서 무료로!! 컴파일 하여 쓸수 있게 해준다.

Wx 모듈을 딸기펄의 cpan으로 설치하면, 특히나 속시원하게 죽죽 빌드하고, 테스트창까지 띄우는 SHOW를 즐길수 있을 것이다. 와우!! 매우 뿌듯함이 몰려오는 그 시간...ㅋㅋ
혹시나 해서 설치방법.. 아래 작업만 하면 Wx는 모두 준비된다.

c:\> cpan
cpan> install Wx

그리고 PAR과 나머지 필수 모듈을 설치한다.

cpan> install PAR
cpan> install PAR::Packer
cpan> install Wx::Perl::Packer

이제 도스창에서는 pp 를 치면 perl코드를 exe로 만들어주는 명령이 실행된다.

C:\> pp
C:\strawberry\perl\bin/pp: No input files specified

오...바로 해보자. 아래 내용을 wxtest.pl 로 저장하고 perl wxtest.pl 로 실행해보자.

use Wx;
package MyApp;
use base 'Wx::App';
sub OnInit {
    my $frame = Wx::Frame->new( undef,
                                -1,   
                                'wxPerl rules',
                                [-1, -1],      
                                [250, 150],     
                               );
    $frame->Show( 1 );
}
package main;
my $app = MyApp->new;
$app->MainLoop;

후진창이 하나 뜰것이다. 후져보여도 크로스플랫폼이어서 당당할수 있다.

이제 exe로 만들자.

pp -out a.exe a.pl

디렉토리를 보면 a.exe가 만들어졌다!! 4메가 약간 넘는 것이..그러나 크로스플랫폼 지원을 생각하면 아무것도 아니다!!
그러나 실행해보면 에러가 날것이다!!  wxbase뭐시기 길기도 긴 dll 파일이 없다고 한다. 헉 이게 뭔지 알고 또 어디에 둬야하나? Wx 만 아니면 거의 다 잘되는데 아흐 답답해지기 시작한다.

걱정마시라 그래서 아까 설치한 Wx::Perl::Packager에 포함된 wxpar 이 있다.

wxpar --gui -o a.exe a.pl

제대로 알기만 한다면 pp 명령에도 추가해줄 파일들을 명시하면 되는 일이지만,
wxpar 을 사용하면  Wx 의존파일들을 알아서 추가해준다.
덤으로 gdiplus 디렉토리를 만들어서 gdiplus.dll 파일도 필요할 경우 넣을 곳을 마련해준다.

이제 실행하면 된다!! Enjoy Perl!!

스크립트언어의 반격? GUI 구현과 exe 배포 전격 비교 perl은 오랫동안 인터프리트언어로써의 자존심을 지켜왔고,
스크립트언어란 이래야한다는 모범을 보여왔다.
그러나 늘 '실무'와 만나게 되면, 배포의 문제를 피할수가 없다.
아무리 잘 만들어도 결과물은 실행바이너리가 아니면, 요구사항을 만족시킬수가 없는 것이다.
나는 늘 이런 사실이 안타까웠고 나 스스로가 해법을 찾고자 python, ruby는 어떤지 짧은 여행(?)을 떠나보기도 했다.
스크립트 언어로 MFC, C# 등을 대신해보자!!

3대 스크립트 언어의 벤치마킹
우선 눈여겨서 비교한 것은 GUI 관련 라이브러리의 지원이다.
스크립트언어는 특성상 크로스플랫폼을 만족하는데, GUI 관련된 것도 당연히 크로스플랫폼이어야 한다.
그래서 본 것이 WxWidget, Tk, Qt 이렇게 세가지 가장 유명한 GUI 라이브러리의 지원여부이다.
그중에서도 가장 기능이 충실하고, 의존라이브러리의 크기가 작고 빠른 WxWidget으로 선택했다.
perl > python > ruby 순으로 API의 구현 완성도가 높았다.

그리고 exe로 만들기.
python은 py2exe, ruby는 rubyscript2exe.rb , perl은 PAR::Packer 모듈이 있다.
기본적인 아이디어는 같다.
압축을 풀고 실행환경을 임시로 만들어서 스크립트를 실행해주는 바이너리가 파일의 앞에.
실행에 필요한 스크립트와 모듈들, 모듈이 의존하는 공유라이브러리 요소들, 리소스 파일들을 압축한 것이 그 뒤에.

python
python은 py2exe 가 비교적 완성도가 높았고 Wx 로 프로그래밍한 것을 exe로 만들때도 별로 문제가 생기지 않았다. Wx랑 win32 쪽 지원이 전반적으로 좋은 언어이다. perl이랑 차별화를 위해 따로 신경쓴 듯 하다.

ruby
ruby의 rubyscript2exe.rb는 빼먹는 dll 파일도 간혹 발생해서 ruby 이상으로 알지 않으면 exe로 만들기 어려운 상황이 발생한다. Wx의 지원이 아직 모자라다. 후발주자로써 Python 수준을 따라잡지 않으면 곤란할텐데..

perl
perl은 여러가지 방법이 있다. 언어가 오래되다보니까 나같은 필요를 느끼는 사람도 엄청 맣았겠지..
perl2exe는 신뢰도가 떨어져서 보지 않았다.
ActiveState사의 PDK를 사용하면 GUI 환경에서 exe를 만들수 있고 ActiveX, sysTray, 심지어는 .NET바이너리로 만들수도 있게 되어있다.그러나 정말 Windows 전용이다.(무서운 사람들이다 진짜)
PAR 모듈은 perl이 있는 상태에서 의존성을 해결하기 위한 모듈이면서, 부트스트래퍼만 앞에 붙이면 바로 단독 exe파일이 되게끔 해주는 PAR::Packer 모듈까지 있다. 한 바이너리안에 여러시스템에 맞는 의존파일을 선택적으로 넣을수도 있고, 런타임에 웹에서 PAR파일을 내려받아 의존성을 해결하게끔 할수도 았다.-ㅁ-;; 그리고 의존라이브러리는 캐싱을 하기때문에 최초 실행시에만 좀 느리고 그다음부턴 매우 빠르다. 독보적이다.

결론
극단적으로 상용화를 준비한다고 생각했을때,
멀티플랫폼을 지원하면서, 작업속도도 빠르고, C등과 별반 다름없는 결과물을 원한다면,
WxWidget and ( perl or python ) 가 내가 추천하는 조합이다.