본문 바로가기

[Clet]주노's Clet강좌-2.4. 개발 환경 설정 (LGT 1.6 SDK)

[펌] http://juno.springnote.com/pages/1049756


아마 강좌를 번호 순서대로 읽고 있어서 이 글에 도착하셨다면, 갑자기 왜 SKT SDK 로 잘 나가다가 LGT SDK 인가 하실껍니다.

사실 이 글은 [Clet] 8. API 맛보기 - Network (1) 편 에서 발생한 TCP 데이터 전달 불가 문제 때문에 어찌보면 일단 테스트를 하고자 하는 분들을 위한 임시 방편 제공용(~.~) 글입니다. 따라서 순서대로 읽어 오신 분들이라면 일단 이 부분은 건너 뛰시고 나중에 필요하시면 그때 읽어 주시기 바랍니다.


현재 이통 3사(SKT,KTF,LGT)에서 Clet 은 모두 상용 어플 제작이 가능하고, 당연히 SDK 들도 제공이 되고 있습니다. 다만, 아직은 애매하게 폐쇄적인 여러가지 정책들 때문에 SDK는 대개 개발에 관계된 회사에게만 공개하는 것이 일반적이었습니다. 그러나 작년(2007)쯤에 wipigem 이라는 사이트가 생기면서(사실 SKT Clet 개발 관련 전문 사이트를 만들고 싶었던듯하지만--;) SKT 의 규격을 따르는 Clet 용 SDK 가 개인에게도 공개되었습니다. 현 강좌에서 사용하는 것이 공개된 마지막 버전이죠.(그나마 어느정도 동작은 잘 하는 버전이죠.) 그러나 위에서 이야기한데로 강좌를 진행중 전혀 예상치 못한 버그를 만나 고전해버리고 /* 순전히 CP용 SDK만을 사용하는 제 판단 미스입니다. 구조도 좀 달라서 어찌 강제로 고치기도 뭐하더군요--; */ 그래서 결국 다룰까 말까를 어느정도 고민하고 있던 또하나의 개인이 다운 가능한 Clet SDK인 LGT WIPI SDK 에 대해서 간단하게 컴파일에서 에뮬에서 동작 시켜볼 수 있는 정도까지만 소개하려고 합니다.


LGT WIPI 에서 Clet 만을 보면 크게 1.6 과 2.0 으로 버전이 나뉘게 됩니다. /* 위피 표준은 1.2 이후 버전은 2.0 입니다만...뭐 왜 1.6 인가에 대해서는 순전히 그냥 LGT WIPI 개발사가 정한게 아닐까 싶기도 합니다만, 뭐 그건 논외로 하죠^^ */ 두 버전간에는 꽤 차이가 있습니다.  일단 2.0 은 2.0 API 를 지원한다고 명시를 하는 것 같고(실제 그런지에 대해서는 전 테스트는 안해봤습니다.^^) 다만 2.0 SDK는 에뮬레이터에서 넷을 처리할때 신경 써야하는 부분이 좀 있고(1.6 이라고 없는 건 아닙니다만) 더불어 2.0 SDK 는 사실상 cygwin (이게 뭔지는 검색해보시기 바랍니다.^^) 환경을 사용해야 하기 때문에(물론 노력과 근성(모 애니 영향!)으로 안 쓰고도 개발환경 만들 수 있습니다만 ^^) 살짝 기본편이라고 정의한 이 강좌의 범위는 오버할 느낌이 들더군요. 그래서 결국 1.6 으로 결정한거죠. 조금 불편할 수 있는 환경입니다만...뭐 단순하게 생각해보면 어짜피 이 SDK 를 쓸 일은 사실 TCP 관련 넷 테스트를 위한 용도가 크니깐요. 조금의 불편은 제가 나름 방법을 제시할 생각이니 일단 돌려보자(^^)를 목표로 이번 내용을 봐주시면 좋겠습니다. /* 사실 LGT SDK...현업에서 써보신 분들은 아마 3사 SDK중 가장 환경 설정에 에로에로(--;)가 꽃피는 멋진 SDK라고 외치십니다만, 뭐 어짜피 해당 이통사용으로 개발 테스트하려면 대안이 없잖아요^^ 최대한 자기에게 맡게 고쳐 쓰는 수 밖에 없는거죠. 따라서 여기서는 최소한 이렇게도 해볼 수 있다 정도는 제시할 것 같습니다. 결국 각자 편한데로 환경을 만드는게 좋겠죠^^ */


설치~

일단 해당 웹 사이트에 가서 SDK를 받아와야겠죠.

[LGT WIPI 플랫폼 기술지원사이트] http://technet.veloxsoft.com/

해당 페이지에 가서 일단 개인회원으로 가입합니다. /* 이미 CP레벨 회원으로 가입된 회사 ID가 있다면 그걸로 받으셔도 됩니다.*/ 혹시 주변에 이미 SDK를 받아둔 분이 있다면 그걸 써도 됩니다. 이 SDK는 특별히 ID/PW 인증을 하지 않으니깐요^^


아래에 표시한 메뉴 방향으로 이동해서 해당 SDK를 받습니다. 이 글을 쓰는 시점(2008/04/14) 기준으로 2번째 페이지 첫번째에 존재하네요.

clet2_4-1.png

살짝 덩치가 큰고로 뭐 따로 여기에 제가 파일을 올려두기는 뭐하니깐, 직접 가서 받으시면 되겠습니다.^^


LGT_WIPI1[1].65_ALL_SDK_Release_2007_0627.zip 파일이 다운 받아 질텐데, 아무데나 일단 압축을 푸시고 setup.exe를 살포시 실행해줍니다. 뭐 특별히 설정한건 없고, 다만 SKT SDK 의 환경 설정 내용들과 마찬가지로 설치되는 위치, 즉 SDK의 경로는 잘 기억해두시기 바랍니다. 이 강좌에서는 C:\LGTWIPI 를 SDK 경로로 사용하겠습니다.

clet2_4-2.png


설치는 이걸로 끝(^^)입니다. 간단하죠.

너무 빨리 설치되었다고요? 자 남는 시간(^^) 같이 설치된 문서에서 'WIPI C 개발자 가이드' (시작 메뉴에서부터 접근하시면 잘 보일껍니다.) 도 한번 읽어 보시기 바랍니다. 뭔가 참 심플(^^)하죠......솔직히 좀 너무한 문서죠--; 아무튼 뭐 대략 이런 식으로 하라는 거구나 정도 인식해주시고 바로 실전! /* 프로그램은 익혀가는 방법중 가장 무식하지만 어느정도 감이 잡힌 상태에서는 효과 좋은 방법은 무작정 해보는 거라고 생각합니다. 아 물론 완전 맨땅에 헤딩하는건 비추입니다. 어느정도의 감을 익히기 위해 항상 기초 스터디~는 필수인거죠^^ */


컴파일을 해봅시다~

일단 문서에 나온데로 한번 시도해 보겠습니다.

실행에서 cmd를 실행하시던가 편하신 방법으로 커맨드 창으로 나가서 SDK가 설치된 경로로 갑니다.

일단 문서에서는 makeclet 을 이용해서 컴파일 한다네요. 한번 무작정 실행해 보죠.

clet2_4-3.png

흠 역시나 간단한 파라메터 설명이 나오는군요. 직관적이려나...아무튼 자 이제 그 아래 줄에 적은 것 같이해서 컴파일을 해보려고 합니다. 그전에 어떤 준비를 해야하는데.....^^ 그쵸 아직 컴파일할 소스조차 전혀 준비 안했는걸요.

이 강좌는 8강에서 TCP 넷 테스트를 에뮬레이터에서 제대로 못한 것에 대한 보충 파트(^^)이기도 하니깐, hello clet 보다는 아예 바로 8강 TCP 소스를 가져다 쓰도록 하겠습니다. /* 슬슬 이제 막나가는 강좌가 되어가는 느낌이^^ */

clet2_4-4.png

위와 같이 SDK 경로 바로 하위 폴더로 TCPTest 라는 폴더를 생성후 미리 준비(^^)한 소스 파일 하나를 던져두었습니다.

자 이러면 위의 커맨드창에서 엔터를 살포시 쳐주면 잘 될까요? 백문이 불여일타(?)....해보는겁니다.

clet2_4-5.png

흠....일단 뭔가...엉망~ 이군요...

대충 처음 보이는 에러(A)는 아예 뭐가 실행을 하려고 하는데 파일이 없다는군요. 쉽게 이런 에러는 시스템 환경 변수인 PATH 에 해당 실행 파일이 있는 경로가 지정되어 있지 않아서 발생하죠. 뭐 정말 파일이 없을 수도 있는거구요^^. (아마 평상시 개발툴을 잘 설치해서 쓰지 않은 분들이라면 아마 아래 부분의 jar 파일 생성도 에러날 확율이 있겠죠. jar.exe 자체를 못 찾을 수도 있으니깐요.)

그 다음 에러(B)를 보니 우리 소스를 컴파일 하려고 했는데(tcptest.c) 바로 1라인부터 헤더 파일에러가 나왔네요. 흠...뭐 이런 경우는 include 파일을 찾을 경로 설정이 문제이거나 이 SDK는 아예 다른 헤더 파일 이름을 쓰는건지도 모르죠.

일단 소스 컴파일에도 에러가 있으니 당연히 중간쯤에 보이는 Link 파트는 무조건 에러가 나겠죠. 이런 경우 일단 넘어가야죠. 소스부터 컴파일에 성공해야 그 다음이 전진 가능할테니깐요.

그런데 마지막 줄을 보니 Complete! ....--; 그리고 build.log 를 읽으라네요....위에서 만든 폴더에 가보면 정말 build.log 가 생겨 있습니다...........그러나 내용은 꽝....사이즈가 0KB....장난하냐!!!! 라는 말이 나오죠... /* 제가 처음 이 SDK를 회사에서 설치하고 컴파일 시도했을때...딱 위와 같은 상황이었습니다....정말 뭐하자는 플레이냐~ 싶더군요...ㅎㅎ */


사실 위의 문제들을 해결하기 위해 접근할 수 있는 방법은 꽤 여러가지가 있을 것 같습니다. 제 경우는 그냥 바로 스크립트 파일(위와 같으면 makeclet.bat 겠군요.)을 읽어서 흐름부터 파악하고 필요한 것만 들어내는 걸 선호합니다만, 뭐 사람마다 이건 다 접근법이 다를 것 같습니다.

더우기나 솔직히 이 컴파일 흐름을 보다보면 왜 이렇게 해야 하나 싶게 특이한 몇가지가 있는데, 솔직히 뭐 개발한 분의 의도를 모르겠으므로 최대한 존중(--)해서 잘 돌아가는 상태만 만들어 주기로 맘먹고 이제 최소한의 노력으로 해결하기 위한 방안을 살펴보겠습니다. 뭐 살펴본다기 보다는 사실 그냥 이렇게 고치세요 의 느낌이겠지만....솔직히 만약 이 강좌가 제대로 LGT 개발 환경을 만들자 였으면 아마 저 글 안 썼을 껍니다. ㅎㅎ


뭐가 문제일까요?

일단 위의 버그 말고도 사실 위 과정을 유심히 보셨다면(^^) 뭔가 이상하지 않나 싶은 부분도 있는데요. 한번 제가 생각한 문제들을 나열해보겠습니다. 이 부분은 각자 다 틀릴 수 있습니다만, 일단 해결 방안을 찾기위한 과정중 하나의 예시라고 생각하고 봐주세요.

  • [스크립트] major.exe : 뭐하는 녀석인지 모르겠지만, 배치 파일을 무작정 열어서 에디터등에서 보니
  1. echo Compiling...
    %MAJOR% %COMPILER_OPT% %DEFINES% -Tc ..\bin\wipic.bin -Fomodule_clet.obj
    %COMPILER% %COMPILER_OPT% %DEFINES% *.c 2> %LOG_FILE%

흠... 그냥 컴파일 옵션도 그대로 쓰고 (바로 아래줄의 컴파일러 호출 부분과 같은 옵션에 파일만 다른 구조죠) 아무래도 저 이상한 소스로 추정되는 wipic.bin을 입력 받아서 module_clet.obj 파일로 컴파일 시키는 것 같네요. 일단 이정도만 생각해두죠.

  • [스크립트] 위 내용중 맨 아래줄에 컴파일의 결과등을 LOG_FILE 에 기록하게 한 것 같은데 이상하죠 왜 로그 파일은 0KB 였을까요. '2>' 의 의미는 간단히 stderr 출력을 redirection 한다는 의미인데요. 자세한건 커맨드상의 redirection 등을 찾아 보시면 도움이 될 것 같습니다. 일단..위 문장으로만 봐서는 컴파일러의 에러 출력은 stderr 출력이 아닌가 봅니다.
  • [소스] 위에서 헤더 파일 에러가 나왔죠. 경로상의 문제이거나 실제 저런 이름의 헤더 파일이 없거나...겠죠..이 부분에 대한 접근은 그래도 그렇게 어렵지는 않을 것 같네요.
  • [프로젝트폴더] 사실 가장 이해 안가는 부분인데...어째서 각 개발 프로젝트마다의 폴더를 바로 SDK 경로내에 만들도록 했을까요? 뭔가 애매하지 않습니까....이런 상태로 계속 어플 개발 수가 늘면 늘수록 잘 정리해두지 않으면 저 SDK 루트 밑에는 폴더 수가 자꾸 증식만 하겠네요...실제 개발을 계속 하다보면 이런 구조적인 관리 부분도 무시할 수 없다는걸 자꾸 느끼기 때문에 정말 이해 안가는 구조구만이라는 생각뿐이 안 들더군요. 뭐 쉽게 피할 방법을 생각해보라면 빌드할때마다 제 프로젝트 폴더에서 카피하고 컴파일하고 결과물을 복사한다~ 정도로 정리가 되려나요...ㅎㅎ 그것도 좀 그렇네요.^^
  • [디버깅?] 뭐 SDK 문서에는 VC++ 환경을 그냥 단순 디버깅을 위한 에뮬 실행용도로 사용하네요...그 아래 이어지는 말에서 넘어가는 줄 알았는데요...

하지만, 현재 항상 모듈이 실행된 이후에야 잡을 수 있기 때문에, startClet() 같은 함수는 잡기 힘들다. 그래서 한번 실행 후, 모듈창의 모듈 위에서 마우스 오른쪽 클릭을 해서 “Kill Process”를 선택하거나, 종료 버튼을 눌러서 모듈을 종료시킨다..(생략)...“STOP”상태에서 “File”/”Open”을 사용해, 디버깅할 C 소스를 열고, breakpoint를 잡는다.

..................................--;;;;;;;

솔직히 뭐 여기서는 안 다루지만 LGT 2.0 SDK 에서는 이런 문제를 해결(OTL)하려고 한건지는 모르겠지만, 참 맘에 안드는 VS의 addin 을 붙여 버리죠..그래놓고 결국 컴파일 실행은 역시나 bat파일->bash스크립트 콤보죠...아...뭔가 노력과 근성중 노력의 부족이라고 밖에 할 말이 없어요! /* 솔직히 이번글은 거의 이런 푸념을 늘어놓는 글이 될 것 같군요 ...OTL... */

어찌되었건....차라리 이런 구조가 될꺼라면 그냥 복잡해도 VC 프로젝트 속성 설정법을 늘어 놓던가 탬플릿으로 주던가...정말이지 골탕먹이려는 거로 밖에는 안 보이더군요....--;


뭐 일단 간단히 최대한 자제해서(--;) 나열한게 요만큼(^^) 입니다만, 일단 위에서 이야기한 부분들에 대한 해결책의 제시와 쉽게 활용해볼만한 배치 파일로 기존 배치파일을 좀 수정해보도록 하겠습니다. 뭐 어디까지나 TCPTest 라는 소스를 컴파일해서 에뮬에서 돌리자가 목표입니다...웃쌰!


이렇게 수정하세요~ 그리고 컴파일~

일단 기존의 소스부터 수정하겠습니다. 어짜피 이건 LGT Clet 에 맞춰야 하는 부분이 좀 있는 부분입니다만, 8강에서 사용했던 tcp 소스에서는 다행히 2군데 정도 수정하면 될듯하네요. /* 사실 다른 기능들을 더 사용했다면 더 고쳐야 할 부분이 나올껍니다. 솔직히 같은 WIPI Clet 이라지만, 3사 모두 독특한 특성과 방식이 존재해서 모두 대응하려면 각 특성들을 알아야 하죠. */

  1. 맨 첫 라인에 있던 헤더를
  2. #include "WIPIHeader.h"
  3. 에서 아래와 같이 수정합니다.
  4. #include "exp_wipic.h"

헤더 말고 사실 문제가 되는 부분이 하나 더 있는데, 사실 약간의 넷쪽 노하우에 속하는 부분입니다만, 뭐 이 LGT 에뮬에서는 바로 보게될 문제이니 일단 소스 수정부터 하겠습니다.

  1. 소스상의 Clet_netConnectCB 함수 부분 맨 아래쪽의
  2. retVal = MC_netSocketConnect(socketFD,addr,port,Clet_netSockConnectCB,NULL);
  3. if (retVal < 0)
    {
        MC_knlPrintk("* MC_netSocketConnect : Err[%d]\n",retVal);
        Clet_NetDisconnect();
        return;
    }
  4. 부분을 아래와 같이 수정합니다.(에러 처리 부분을 없애야 합니다.)
  5. retVal = MC_netSocketConnect(socketFD,addr,port,Clet_netSockConnectCB,NULL);
  6. MC_knlPrintk("* MC_netSocketConnect : ret[%d]\n",retVal);

실제 좀 있다 에뮬에서 실행을 해보시면, MC_netSocketConnect 의 반환값이 성공을 하던말던 -7 이 나온다는걸 보실 수 있으실텐데요. (-7 은 M_E_INPROGRESS 을 의미) 사실 해석하기 나름이지만, 콜백 함수 호출이 진행중이라는 건지..아직 연결된건지 아닌건지 모르는 상태라는 건지 알 방법은 없으나...어쨌거나 위의 원소스때와 같이 - 값이 들어온다고 바로 끊어버리면 절대 연결 못하게 됩니다. 보너스로 이건 KTF 폰에서도 간혹 볼 수 있는 증상이니깐, TCP 소스 작성시 감안하시는게 좋을 것 같네요. /* 뭐 저런 에러 코드를 출력하는지에 대해서는 생각하다보면 뭐 그럴 수도 있겠네~ 싶지만..문제는 어디까지나 음수값은 에러라는 거죠..차라리 그냥 통보 값이라고 따로 정의를 하던가...좀 애매한 부분입니다. 뭐 이런건 최대한 돌아서 피해가는게 최고려나요--; */


소스 수정은 위와 같이 하면 끝나고, 이제 makeclet.bat 을 수정할텐데, 사실 모든 과정을 다 설명하려고 하니 아무래도 내용이 엄청 길어질 듯하고...사실 이 강좌는 어디까지나 Clet 강좌니깐(뭐 관련이 없지는 않겠지만요^^)....그냥 바로 제가 어느정도 현 강좌 정도에서는 바로 사용할 수 있게 수정한 것을 사용하도록 하겠습니다.


일단 파일을 보기전에 꼭 해야할 작업이 있습니다. 바로 major 녀석(^^)과 관계된 일인데요. 일단 이유가 어찌되었던 SDK 설치 경로 \ BIN 폴더에 위치하는 major.exe 와 batou.dll 파일을 VS가 설치된 곳의 cl.exe 파일이 있는 곳으로 옮깁니다.

대략 아래와 같은 위치입니다.(아래 그림은 VS.NET 2003 기본 설치시의 장소입니다.)

clet2_4-6.png

각 Visual Studio 버전마다 폴더 위치의 차이는 있겠지만, 찾기 어려우면 VS 폴더에서 바로 검색으로 cl.exe를 찾으면 됩니다.

위 과정은 무조건 해주셔야 하는 과정입니다. 사실 경로 설정만 잘 되면 되겠지 했지만, 제 개발 환경의 문제인지는 모르겠지만, 사실 major 파일이 cl.exe를 후킹(hooking)해서 컴파일을 시도하는 구조인데 그 후킹 라이브러리로 batou.dll 을 사용하는 구조더군요. /* 후킹 동네에 관심이 있는 분들을 위해 아까 major에 파라메터중 입력되는 소스에 해당하는 wipic.bin 은 C 소스를 인코딩 알고리즘을 써서 소스를 못 알아보게 해둔 파일입니다. 그걸 major 가 cl 을 후킹하고 cl 이 wipic.bin을 읽으려고 하는 부분에서 파일 내용을 디코딩해서 cl 에게 컴파일하라고 주는 구조인거죠. 왜 이렇게 해야하는 건지가 아주많이(솔직히 짜증이 나서--;) 궁금해서 역으로 까보려고 좀 궁리 좀 하다가 문득 컴파일러의 잼난 구조를 이용해서 그냥 쉽게(=허무하게) 소스를 봤습니다...쩝...인간들...정리하기가 싫었던 거예요...에휴..아무튼 방법을 그냥 공개적인 문서에 적는건 정도는 아닌듯하니 일단 제가 접근했던 과정만 살짝 알려드렸습니다. 사실 뭐 방법을 어찌하던(역후킹을 하셔도 되고요^^) 현업에서는 솔직히 저런 중간 과정 하나하나가 개발할때 짜증도를 올려주니...더우기 잘 정리해둔 개발 환경을 자꾸 무너뜨리니...~.~ 살짝 궁리해보셔서 major 부분을 날려버리는 감격을 느껴보셨으면 좋겠네요. */


위의 과정이 끝났다면, 적당한 곳에 프로젝트 폴더를 하나 만드시고 위에서 수정한 소스 파일과 아래 배치 파일을 받으셔서 넣어두세요. 아래 그림 같이요.

수정된 배치 파일 : makeclet.bat

덤으로 소스 파일 : test.c

clet2_4-7.png

자 그럼 다시 커맨드 창을 열어서 해당 폴더로 접근하죠. 이제 컴파일 해보도록 하겠습니다.

clet2_4-8.png

/* 현재 받으시는 bat파일은 위 화면의 출력 메세지와 약간 다른 메세지를 출력합니다. 아주 조금 수정했다는^^ */

makeclet tcptest 12345 라고 입력하고 엔터를 딱 치니...오호 뭔가 메세지 하나 없이 깔끔하게.....끝~ 이네요. 과연 결과가 나온걸까요~ 라고 보니....

오~ jar 파일이 생겼네요. 더불어 build.log 도 사이즈가 좀 되는군요.

/* 만약 jar 가 생성이 안되었거나 뭔가 이상하다 하는 분들은 잠깐 찾아 주세요. 아무래도 개발 환경들이 기본적으로 다르니 최소한의 수정이 필요하거든요.*/

일단 제대로 된건지 build.log 부터 보도록 하겠습니다.

  1. Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.6030 for 80x86
    Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.

    wipic.bin
    c:\LGTWIPI\bin\system.bin(108291) : warning C4049: 컴파일러 한계 : 줄 번호 내보내기를 종료하고 있습니다.
            줄 번호에 대한 컴파일러 한계는 65535입니다.

    make_clet_def.c
    test.c
    test.c(30) : warning C4022: 'MC_knlSetTimer' : 실제 매개 변수 3의 포인터가 일치하지 않습니다.
    test.c(63) : warning C4022: 'MC_knlSetTimer' : 실제 매개 변수 3의 포인터가 일치하지 않습니다.
    코드 생성 중...
    LINK : warning LNK4224: /PDB:NONE은(는) 더 이상 지원되지 않습니다. 무시됩니다.
    C:\LGTWIPI\lib\common.def(1) : warning LNK4017: 대상 플랫폼에는 DESCRIPTION 문이 지원되지 않습니다. 무시됩니다.
       binary.lib 라이브러리 및 binary.exp 개체를 생성하고 있습니다.
    adding: META-INF/ (in=0) (out=0) (stored 0%)
    adding: META-INF/MANIFEST.MF (in=56) (out=56) (stored 0%)
    adding: binary.mod (in=188824) (out=61569) (deflated 67%)
    adding: binary.mie (in=232) (out=35) (deflated 84%)
    Total:
    ------
    (in = 189100) (out = 62072) (deflated 67%)

오호...특별히 에러는 없고 제대로 된거네요. 특별히 major 가 처리하는 컴파일 파트에서 재미있는(--;) 경고가 뜨길래 색을 좀 다르게 해놨습니다.

이야...얼마나 길면 라인수가 길어서 경고를 내보낼까요...그런데 사실 이 경고 그냥 무시하면...안되는 문제가 있습니다. 원래 cl의 저 경고문은 16비트 호환을 위해서 설정된 경고 입니다만(16bit 를 수로 표현하면 65535 까지 가능하죠.) 사실 컴파일러 입장에서는 그 라인 수를 넘어가도 특별히 문제되는 건 없습니다. 다만 만약 원래 배치파일내의 컴파일 옵션을 그대로 써서 어찌어찌 성공하셨다면 간혹 에뮬에서 실행하려는데 뻗어버리는 현상을 보실 수 있게 될 껍니다. 그래서 특별히 저런게 색까지 다르게 해서 표시해두는 겁니다. 원인은 머리 아프지 않을 한도내에서 한번 생각해보시고, 결과적으로 저는 bat파일 내부에서 저는 컴파일 옵션을 이렇게 구별했습니다.

  1. set COMPILER_OPT=-nologo -c -Od -MTd -Zp1 -Z7
    set MAJOR_OPT=-nologo -c -Od -MTd -Zp1

/* 딱 봐도 -Z7 이 사라진 것뿐이 없네~ 하고 바로 아실껍니다. 그럼 저걸 왜 빼는게 안전한지에 대해서...는...그냥 영원한 숙제로^^....힌트라면...우리가 쉽게 사용하는 VC++의 디버깅 시스템은 과연 어떤 구조로 동작하는 걸까~ 와 연관이 있습니다. 그냥 머리 아프지 않을때 간간히 찾아보세요~ */


자 그럼 이제는 파일 다 드렸는데도~ 저 컴파일이 안되요~ jar가 안나와요 하는 분들을 위한 서비스라기 보다는 각자 환경에 맞게 당연히 고쳐야 하는 부분에 대해서 알려드리겠습니다. 사용하기 편한 에디터에서 makeclet.bat 을 여세요. 고쳐야 할 부분은 제가 위쪽으로 몰아두었습니다.

  1. @echo off

    set SDKPATH=C:\LGTWIPI      (만약 SDK 설치 경로가 다르다면 여길 고치세요. 폴더명 마지막에 \ 넣지 마세요!)
    set JARPATH=c:\cygwin\bin\jar      (jar.exe가 있는 경로+프로그램이름까지 넣어주세요. 전 cygwin에 있는 jar를 사용)
    set INCLUDE=%SDKPATH%\include;C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include
                                     (만약 VS.NET 2003 의 설치 경로가 다르거나 다른 VS 시리즈를 사용할 경우 적당히 바꿔주세요.)
  2. set LIB=C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\lib
  3.                                  (만약 VS.NET 2003 의 설치 경로가 다르거나 다른 VS 시리즈를 사용할 경우 적당히 바꿔주세요.)
    set RAPTOR=%SDKPATH%\bin\raptor.exe
    set MAJOR=major.exe
    set COMPILER=cl.exe
    set LINKER=link.exe
    set LIBS=%SDKPATH%\lib\stub_system.lib %SDKPATH%\lib\stub_jar.lib %SDKPATH%\lib\stub_lcdui.lib %SDKPATH%\lib\stub_wipic.lib
    set MAKEDEF=%SDKPATH%\bin\makecletdef.exe

아 그리고 생각해보니 혹시 VS 환경은 설치 되어 있는데 환경 변수중 PATH가 컴파일러(cl.exe)등이 있는 경로가 잡혀있지 않아서 커맨드 창에서 cl 이라고 입력했을때 파일을 못 찾는다고 나온다면 PATH에 꼭 VS 의 필수 실행파일 경로를 넣어주세요. /* PATH 설정에 대해서는 제가 설명하는 것보다 네버~ 지식人등에서 훨씬 잘 설명한 분들이 있을테니 이 기회에 설정하는 법을 알아두세요. 혹 자신의 환경 변수 값들이 궁금하다면, 커맨드 창에서 set 이라고 입력해보세요. 아마 주르륵~ 나올껍니다.^^ */


혹 jar.exe 가 없는 분들을 위한 나름 보너스....(으아..너무 챙기는 것 같아요..)

cygwin용 jar : jar_cygwin.zip  (위와 마찬가지로 PATH 경로나 뭐 그것도 귀찮으면 그냥 프로젝트 폴더에(--) 넣고 위의 배치 파일 경로를 잡아주세요. 관련 dll도 함께 같은 폴더에 있어야 합니다. 압축 파일안에 같이 들어 있어요.)


만약 JDK 를 설치해두셨다면 해당 JDK의 bin 폴더에 jar 가 있습니다. 마찬가지로 배치 파일 경로에 그 폴더 경로를 넣어주세요.

혹시나 JDK가 필요한 분들을 위해...흔히 모바일 개발 환경에서 좀 쓰이는 듯한 1.4 버전의 링크를 남겨둡니다.

[JDK 1.4.2_16 다운로드 Link] http://java.sun.com/products/archive/j2se/1.4.2_16/index.html

최신 버전은 아니지만, 그래도 왠지 이 업계에서는 가장 많이 쓰이는 1.4 대의 마지막 버전이고 잘 동작하니(테스트 완료^^) 뭐...필요한 분도 있을지 모르니 링크 남겨둡니다.(혹 나중에 sun 사의 변덕으로 링크가 바뀌면....누군가 링크 깨졌어요~라고 알려주시면 수정하겠습니다.^^)


자 그럼 이제 다들 jar 파일까지 제대로 만들어졌겠죠? 여기까지 했는데도 잘 안된다~ 하시는 분들은 과감하게 메일등을 날려주세요. 제가 수정한 배치파일이니 반응은 느릴지 모르지만, A/S 는 하겠습니다.(물론 문제가 발견되면 본문도 고쳐놓겠습니다.)


jar 파일을 살짝 열어보면(압축 파일 어플등에서) binary.mod 와 binary.mie 가 보인다면 제대로 된겁니다. 이제 에뮬레이터를 실행해보죠.


clet2_4-9.png

SDK가 정상적으로 설치되었다면 위와 같은 경로에서 에뮬레이터를 실행할 수 있습니다. SDK 설치 경로 bin 폴더내의 dywin.exe 파일을 실행해도 됩니다.


clet2_4-10.png

에뮬이 정상적으로 시작되었다면, 여러개의 창이 뜨는데, 그중 폰 화면이 보이는 창에서 위와 같은 메뉴를 찾아서 선택합니다.


clet2_4-11.png

아까 컴파일한 해당 경로로 가서 jar 파일을 선택해줍니다. (jar 이외에 다른 건 하지 마세요^^)


clet2_4-12.png

제대로 컴파일되어서 결과물을 에뮬레이터가 인식할 수 있게 되면, 위와 같은 창에 맨 아래, 배치 파일의 파라메터로 입력한 이름과 번호가 나오는 걸 볼 수 있습니다.

그리고 옆에 상태를 보니 INIT 상태네요. 이 상태는 현재 어플의 동작 상태를 알려주는데, INIT 은 아직 시작은 안되었고 준비만 되어있는 상태라고 생각하면 되겠습니다.


clet2_4-13.png

이제 우리가 만든 어플(여기서는 모듈이라고 하는군요)을 실행해보죠. 해당 모듈을 선택하고 마우스 우클릭을 해서 나오는 팝업 메뉴에서 첫번째 Exec Module 을 선택하면 바로 어플이 실행됩니다. 뭐 tcp test용 어플은 LCD 화면은 쓰지 않으므로 '왜 화면에 아무것도 안 나와~' 라고 외치시면 안됩니다.^^

더불어 어플의 종료는 위 메뉴에서 Kill Process 입니다.(강제 종료죠..), 그리고 만약 소스를 좀 수정해서 다시 컴파일 후에 에뮬에서 다시 테스트하려면 에뮬 실행후 꼭 기존의 어플을 위 메뉴에서 Uninstall Module 을 선택해서 제거후에 다시 모듈을 로드하셔야 합니다. 꽤나 귀찮죠^^ 별수없...는 것 같습니다...ㅠㅠ


clet2_4-14.png

그냥 실행하고 가만히 두니 타이머가 돌기는 하는데...흠..뭔가 저 시간 간격을 보니 이상하네요...전 소스에 타이머 값으로 1000ms 를 줬으니 1초마다 떠야하는 거 아닙니까!!!!....에잇...뭐 돌아가니깐...거기에 의미를 두고 일단 무시하겠습니다. /* 왜 이런지에 대해서는 나중에 시간 여유가 좀 더 생기면 그때 확인해보도록 하겠습니다.~.~*/


자 그럼 8강에서의 스샷으로만 봤던 테스트를 해보시길 바랍니다. 그전에...소스에 IP 주소를 서버 어플을 돌릴 곳의 IP 주소등으로 바꿔주시고 포트 번호등도 기억하시고 그래야 겠죠^^. 그마저도 귀찮으시다면....그냥 아래 스샷으로 패스하셔도 뭐..^^

clet2_4-15.png

디버그 로그 와 보기 좋게 초간단 서버(^^)의 로그를 함께 놓았습니다.

MC_netSocketConnect : ret[-7] 인데 연결후 동작은 잘 되네요.

여기까지 해서 어떻게든 TCP 소스 테스트를 할 수 있는 환경을 만들어 보자는 목표는 달성했다고 생각합니다만^^....

흠....확실히 지금까지 써오던 환경과 새로운 환경....어느 쪽이 더 맘에 드시나요...뭐 선택은 취향에 따라~ 인거죠......


More...?

일단 컴파일은 어찌어찌해서 편하게(?) 되었습니다만, 이런 환경으로 사실 디버그 하세요~ 하면 왠간히 VS 환경에 익숙한 사람이 아니고서는 참 난감할껍니다. /* 뭐 SDK 내에 있는 문서에 적힌 내용대로 하면 뭐 못할 것은 없겠습니다만^^ */


여기서는 좀 더 생각해보자는 측면에서, 과연 위에서 bat를 이용해서 진행한 컴파일 과정이 VC++에서도 가능하지 않을까라는 방향으로 간단히 접근해보도록 하겠습니다. 물론, 이런 방법은 어디까지나 각자의 취향(^^)에 맞춰서 다르게 진행할 수 있는 부분이기에 저는 여기서는 이렇게 하세요~ 보다는 "왜 이 SDK에서는 이리 불편하게(^^) 하도록 했을까~ 정말 그냥 VC++에서는 안되는건가? 분석~"이라는 생각의 흐름을 나열해보는 식으로 방향만 제시해보도록 하겠습니다.


일단 위에 제가 맘대로 고쳐버린 bat파일(^^)을 아무 에디터에서나 열어서 같이 보면서 가보도록 하죠.


  • 제가 윗 내용에서 각자 환경에 맞춰서 폴더 경로등을 고쳐주세요 했던 그 부분 바로 아래 부분을 보도록 하겠습니다.
  1. set RAPTOR=%SDKPATH%\bin\raptor.exe
    set MAJOR=major.exe
    set COMPILER=cl.exeset LINKER=link.exe
    set LIBS=%SDKPATH%\lib\stub_system.lib %SDKPATH%\lib\stub_jar.lib %SDKPATH%\lib\stub_lcdui.lib %SDKPATH%\lib\stub_wipic.lib
    set MAKEDEF=%SDKPATH%\bin\makecletdef.exe

일단 배치파일 내에서 사용되는 실행 파일들을 보니 위의 표시해둔 부분은 확실히 VC++ 시리즈의 컴파일러(cl.exe)와 링커(link.exe)임을 확인할 수 있습니다.

그렇다면 일단 VC++에서 가능하다는 이야기가 되겠죠. 뭐 선후 작업이야 어떻게든 낑겨 넣을 수 있는거니깐요.(^^)


  • 그럼 이제 실제 이 배치파일은 어떤 과정을 거치는지 확인해보도록 하겠습니다.
    이 부분은 설명 편의를 위해 제가 그냥 배치파일내의 실행 명령을 전부 출력하도록 고쳐서 옮겨보았습니다.(뭐 직접 해보실 분들은 그냥 잘 찾아서 echo 를 붙여주시는걸로 끝^^)

  1. [PRE] C:\LGT_WIPI16\bin\makecletdef.exe -o . -name make_clet_def.c

    [PRE] C:\LGT_WIPI16\bin\module.def 생성

    [MAIN] major.exe -nologo -c -Od -MTd -Zp1 -DWIN32 -D_WINDOWS -DWIN32_EMUL -DDEBUG -D_DEBUG -DSYMBOLIC_LINK -DCOMPACTION_GC -DUSE_HANDLE -DUSE_GC_MALLOC_FOR_IMAGE_DECODING -DFIXED_STATIC_FIELD_BUG -Tc C:\LGT_WIPI16\bin\wipic.bin -Fomodule_clet.obj

    [MAIN] cl.exe -nologo -c -Od -MTd -Zp1 -Z7 -DWIN32 -D_WINDOWS -DWIN32_EMUL -DDEBUG -D_DEBUG -DSYMBOLIC_LINK -DCOMPACTION_GC -DUSE_HANDLE -DUSE_GC_MALLOC_FOR_IMAGE_DECODING -DFIXED_STATIC_FIELD_BUG *.c

    [MAIN] link.exe -pdb:none -debug -nologo -dll  -def:C:\LGT_WIPI16\lib\common.def -out:binary.dll C:\LGT_WIPI16\lib\stub_system.lib C:\LGT_WIPI16\lib\stub_jar.lib C:\LGT_WIPI16\lib\stub_lcdui.lib C:\LGT_WIPI16\lib\stub_wipic.lib *.obj

    [POST] .a.txt 생성

    [POST] C:\LGT_WIPI16\bin\raptor.exe -i binary.dll .a.txt

    [POST] C:\LGT_WIPI16\bin\raptor.exe -p binary.dll null binary.mod

    [POST] C:\jdk1.4\bin\jar cvf .\test.jar binary.mod binary.mie

생각보다 별로 과정이 없죠?(^^) 더욱 구분하기 쉽게 하기 위해 각 과정을 [PRE] , [MAIN] , [POST] 라고 구분했는데요. 왜 이렇게 구분했는지 바로~ 감이 오시는 분은 VC++과 좀 놀아보신(^^) 분이실 듯하네요. 무슨 말인지 모르시겠다고요? VC++의 프로젝트 속성을 한번 보도록 하죠. /* 물론 어떤 프로젝트 타입을 선택해서 생성했냐에 따라 조금 다르겠지만, 일단 대개 에뮬은 dll을 생성해서 동적 로딩하는 방식이므로 DLL 프로젝트라고 여기면 되겠죠. 굳이 왜 DLL 프로젝트냐! 라고 하신다면 위 실행문들 중에서 link.exe 부분에 자주빛(?)으로 표시해둔 -dll 로 인해서 알았다고 하면 되겠습니다. 뭐 이렇게 아는건 link 의 옵션들이 어떤 역활들을 하는지 좀 더 알아야 하는거라 일단은 그냥 그 아래 결과물을 변형(?)하는 부분에 binary.dll 을 쓰는걸 보고 간단히 아~ dll 을 만드는구나 라고 하셔도 일단은 OK 일듯합니다.^^ 점점 공부해나가다 보면 나중에는 옵션들에 대해서도 어떤 차이가 있는지 알게 되겠죠^^ */
clet2_4-16.png

/* VS.NET 2003 기준 화면입니다. 버전마다 좀 다른 화면을 보시겠지만, 내용은 별로 차이 없습니다. 2강/2.1강/2.2강 에서 각각 다른 버전을 다루지만, 솔직히 별 차이 없지 않던가요^^ */

위는 제가 실제로 저런 과정을 어찌어찌 거쳐서(조금 다른 구조이기는 합니다만) 실제 LGT Clet 1.6 프로젝트로 생성해서 쓰는 프로젝트의 속성 화면입니다.

일단 왼쪽의 트리를 보면 C/C++링커 라는 항목을 보실 수 있습니다.(위의 화면은 C/C++ 이 선택되어 그 세부 항목이 열린 것이죠.)

실제로 DLL 프로젝트를 생성해서 그 프로젝트 속성을 보면 일단 '구성 속성' 이라는 항목 아래로 위와 같은 항목들이 나오고 거기에 필요한 설정을 사용하는게 일반적인 개발 방법이죠.

이때 C/C++ 항목에서 정의해주는 속성값들이 실제 cl.exe 의 파라메터로 전달되는 값이고 링커 항목에서 정의해주는 속성 값들이 link.exe 의 파라메터로 전달되는 값이 됩니다.

결국 이 부분이 위 배치 파일을 VC++로 옮기는게 있어서의 핵심이 되겠죠. 그럼 파라메터의 속성은 어떻게 찾아서(^^) 설정해야 하는걸까요?

위에서 배치파일이 만든 cl.exe 부분을 보면 아래와 같은 파라메터가 존재했습니다.

cl.exe -nologo -c -Od -MTd -Zp1 -Z7 -DWIN32 -D_WINDOWS -DWIN32_EMUL -DDEBUG -D_DEBUG -DSYMBOLIC_LINK -DCOMPACTION_GC -DUSE_HANDLE -DUSE_GC_MALLOC_FOR_IMAGE_DECODING -DFIXED_STATIC_FIELD_BUG *.c

사실 컴파일러의 파라메터는 상당히 많고 그 조합법도 독특해서(서로 같이 사용 못하는 파라메터도 꽤 되죠.) 기억하고 있기도 어렵고, 더불어 이러한 파라메터는 또 컴파일러마다 다 차이가 나버리니(대표적으로 많이 쓰이는 gcc 의 경우 훨씬더 엄청난 파라메터들이 존재합니다.) 그때그때 중요한 것들만 기억하고(이런게 가능한게 있다~ 를 기억하는게 좋겠죠. 굳이 외우려고 한다기 보다는 이런 설정도 되었었지~를 기억하는게^^) 나머지는 레퍼런스 문서등을 찾아보면 되겠죠.

즉, 위 cl.exe의 파라메터의 의미등은 MSDN 에서 찾아보면 되겠습니다. /* MS 제품군에 대한 모든 문서는 MSDN 에서 왠간한건 다 찾을 수 있죠. */

뭐 여기서는 세세하게 이렇게 하세요의 접근이 아니라고 위에서도 이야기 했으니 옵션 설정은 각자 찾아 보시는걸로 하고 대략 C/C++ 항목을 잘 설정해서 위와 유사하게 고칠 수 있다는 정도를 보여드리도록 하겠습니다. /* VS.NET 으로 넘어오면서 속성값들에 파라메터도 같이 보여주도록 되서 훨씬 더 이런 접근이 편해졌습니다. 예를 들어 위 화면에서 C7 호환(/Z7) 과 같은 표시가 그것이죠. 맘에 드는 부분입니다.^^ */


/I "C:\LGT_WIPI16\include" /I "C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include" /D "WIN32" /D "_WINDOWS" /D "WIN32_EMUL" /D "DEBUG" /D "_DEBUG" /D "SYMBOLIC_LINK" /D "COMPACTION_GC" /D "USE_HANDLE" /D "USE_GC_MALLOC_FOR_IMAGE_DECODING" /D "FIXED_STATIC_FIELD_BUG" /MTd /Zp1  /nologo /c /Z7 /W3

제 프로젝트의 실제 설정값입니다. /* 물론 제가 개인적으로 쓰는 파라메터는 빼버렸습니다. 취향의 영역이라 ㅎㅎ */

C/C++ 항목에서 설정한 모든 속성값의 실제 파라메터형을 보시려면 C/C++ >> 명령줄 항목을 참고하시면 됩니다.

일단 파란색으로 칠한 영역은 위에서 배치파일이 만들어낸 cl.exe의 파라메터와 동일한 영역입니다. MS 어플류의 특징이지만, 파라메터 기호를 받을때 - 나 / 는 같은 의미라고 보시면 되겠고요, "" 을 하는건 이제 이야기할 경로명 등에서 공백(space)가 존재할 수 있기 때문에 그걸 감싸서 하나의 값이라는 의미로 쓰기 위함입니다.

일단 칠해진 영역이외의 부분중 앞 부분을 보면 /I 로 경로명을 2개 입력한 걸 볼 수 있습니다. 이건 어디서 온 값일까요?

위 배치 파일에서 윗 부분에 있던 내용중 아래 내용에 해당하는 부분입니다.

  1. set INCLUDE=%SDKPATH%\include;C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include
    set LIB=C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\lib

사실 dos 환경에서 set 명령어는 시스템 환경 변수를 설정하는 명령어 인데, 이때 INCLUDE 는 cl.exe 에서 /I 로 입력하는 포함 경로와 같게 인식이 되는 환경 변수 입니다.

덤으로(^^), 유사하게 LIB 의 경우 link.exe 에서 사용되는 라이브러리 포함 경로명으로 사용되는 환경 변수입니다. (이 부분은 직접 찾아보세요^^)

맨 마지막의 추가되어 있는 '/W3' 은 경고(warning) 출력 단계를 지정하는 옵션인데, 사실 위의 배치 파일 cl 파라메터에는 이 부분이 없지만, 컴파일러 기본 값으로 '/W2' 가 내부적으로 사용되며, 위에서는 이렇게 추가적인 파라메터를 줄 수 있다는 걸 보여드리기 위해 경고 단계를 별도로 넣어 보았습니다.(사실 VC++ 프로젝트 속성 설정 특성상 /W 동네는 무조건 들어가버립니다.^^)

대략 이러한 방법으로 작업하시면 위 내용중 [MAIN]파트에 해당하는 cl.exe 와 link.exe 부분은 처리 가능하실껍니다. link 부분은 직접 해보세요^^.


  • 그럼 남은 [MAIN] 부분중 major.exe 는 어찌 해야할까요? 제가 제시할 수 있는 일반적인(^^) 대안은 2가지 일듯합니다. /* 물론 위에서도 이야기했지만, 공개적으로 이야기하기는 좀 그런 방법도 있기는 합니다.^^ */

1) 그냥 맘편히 [PRE] 영역으로 보내버리는 겁니다. 아래 내용에서 이야기 하겠지만, [PRE]와 [POST] 영역은 맘편히 그냥 bat 파일로 재구성 하셔도 되는 영역입니다.

왜 그런지는 해당 내용에서 확인해주세요.

2) 이건 좀 더 이 SDK 의 에뮬의 단순함(^^)과 major.exe의 실제 하는 일을 분석해야지 판단할 수 있는 부분입니다만, 아무튼 결과적으로(^^) 보면 major 부분에서 생성되는 결과물인 module_clet.obj 는 사실 거의 변함이 없는 파일입니다. 실제 컴파일중에 그 위에서 생성하는 %SDKPATH%\bin\module.def 을 참조해서 코드를 만들어 컴파일하기 때문에 만약 안테나 유무차이만 없다면 그냥 한번 컴파일된 해당 파일을 그냥 링커에 던져버리면 그만입니다. 즉 단순히 생각해보면 컴파일 환경을 바꾸지 않는 이상 안테나 있는 경우와 없는 경우로 나눠서 2개의 obj 파일을 만들어 두고 그냥 필요할때 선택해서 링크하도록 하면 실상 끝인거죠. 흠..바로 이해가 안되시는 분들은 나중에 좀 더 컴파일 과정에 대해서 이해를 하신 후에 다시 보시면 이해가 되실꺼라 생각합니다.
/*

실제 module.def 에는 사실 LCD사이즈와 안테나 유무의 값만 정의되어서 컴파일시에 헤더파일처럼 사용되는 파일입니다. 실제 내용을 봐도

#define LCD_176x220
#define USE_ANNUN

이렇게 두줄이 전부입니다. 그나마도 안테나 사용을 안하는 경우 첫번째 줄만 남겨집니다. 그럼 이걸 이용해서 컴파일된 어플은 240*320 화면에서는 안 나오는걸까요?

신기한 결과지만, 실행에는 아무런 영향이 없습니다. 고로 사이즈는 그냥 저대로 놔두고 안테나 유무로만 각각 obj 를 만들어 두면 그다음은 뭐... 선택의 문제일뿐이죠^^

덤으로...이렇게 해서 안테나를 넣고 컴파일 해서 에뮬에서 실행을 시작했는데 갑자기 죽는다거나, VC++의 디버그 모드였다면, 죽는 메세지로 divide by zero 와 같은 에러 나오면서 죽는다면, 살며시 일단 최종 결과물인 jar 파일이 위치한 곳에 있는 dywin.ini 파일을 지워버리시고, SDK의 bin 폴더내에 있는 dywin.ini 파일을 복사해서 넣으시기 바랍니다.

에뮬레이터의 버그입니다.(왜 죽는지 알아내려고 어셈 다 읽고 들어가느라 엄청 고생했습니다...ㅠㅠ 안테나 레벨 MAX값등이 0 이 나오면서 죽는거더군요 ㅠㅠ)

*/


  • 이제 그럼 남은 부분은 [PRE] 와 [POST] 부분이죠.
    먼저 [PRE] 부분을 보죠. 2가지 동작이 있는데...만약 위에서 major 부분 처리 방법을 1) 을 택하셨다면, bat파일로 이 부분만 잘 뜯어다가 프로젝트 속성에 "빌드 전 이벤트"의 명령줄에 넣으시면 됩니다. 아래 화면은 빌드 후 이벤트, 즉 [POST] 처리를 할 배치 파일을 입력하는 부분을 보여주고 있습니다만, 뭐 빌드전이나 후나 입력하는 값은 비슷합니다.

    clet2_4-17.png

    만약 위에서 2) 를 선택하셔서 이미 obj 파일을 안테나 유무별로 만드셨다면, 사실 module.def는 더 이상 필요가 없게 됩니다. 더불어 맨 처음에 만들어지는 make_clet_def.c 파일도 사실 내용이 안 바뀝니다. /* 물론 저희가 하는 작업 특성 때문에 이렇게 단순화 되는 것이기 때문에 Clet App 이 아닌 다른 타입의 개발 작업시에는 분명 방식이 달라집니다. */

    그렇다면 결국 [PRE] 부분도 미리 한번만 작업해두면 되는 부분이라는 거네요.^^


  • 나머지 [POST] 부분은 위 그림에서와 같이 "빌드 후 이벤트"의 명령줄에 별도의 배치 파일을 만들어 주면 되겠습니다.
    .a.txt 라는 뭔가 애매한~ 파일이 하나 생성되는데, 이 안에는 makeclet 의 파라메터로 넘기는 모듈이름(jar파일명), 모듈ID(5자리 숫자)가 들어가게 되는데, 그 위치야 bat 파일만 보셔도 금방 이해하실테니, 딱 한번만 구성해주면, 그다음 부터는 신경 안써도 되겠죠.
    그 이후 raptor 명령 2줄과 jar 압축하는 곳은 bat 에 넣어주셔야하는 부분입니다. dll 을 가지고 에뮬에서 쓰는 방식으로 만들어 jar로 묶는 과정이니 이 부분은 bat파일등으로 매 빌드마다 실행시켜줘야 겠죠.

대략 이런 방법으로 프로젝트 설정과 환경을 잘 구성하면, 나름 편리하게 VC++ 에서 슥슥 에뮬 테스트를 해 볼 수가 있습니다. 1.6 에뮬은 아쉽게도 직접 로딩을 시킬 방법은 명확히 보이지가 않아서(어찌 잘 복사하고 잘 파일만 꾸미면 될 듯도 한데 말이죠^^ 아직은 모르겠네요.) 아쉽습니다만, 뭐 그래도 그정도야 애교로 패스해줄 수 있네요. 어짜피 다른 이통사 에뮬도 있으니^^...


이런 방법으로 접근하면 왠지 더 머리 아파 보이는 LGT 2.0 SDK 의 에뮬용 빌드도 VC++로 옮길 수 있습니다. /* 설치해보신 분들은 아시겠지만, 그 VS에 이상한 addon 까는거..정말 짜증나더군요..KTF도 그러더만...--; 그런거 날리려고 이렇게 삽질(^^)하고 그러죠...~.~ */ 사실 어느 정도 플랫폼별 컴파일의 과정과 각 툴의 특성만 알면 왠만한건 다 자기가 원하는 환경으로 설정하는게 가능하기는 하죠. 이런 부분도 프로그램 개발 공부와 더불어 시간 나실때 이것저것 해보시면서 익혀보시는 것도 괜찮을 것 같습니다.


정리

계속 강좌에서 사용해오던 SDK의 에뮬레이터에서 TCP 오류가 발생하는 것 때문에 결국 다른 Clet SDK 를 선택하고 사용하는 법에 대해 살펴보았습니다. /* 사실 넷 강좌 연속해서 쓰려고 했는데, 요즘 일이 많아져서 연속적인 긴 시간을 내기가 어려워 짧게 끊어서 쓸 수 있는 파트부터 쓰는 것입니다만^^ */


처음에는 문제가 있던건 부분만 해볼 수 있게 빌드 bat파일만 제공하고 간단히 끝낼까 했으나, 역시 이 SDK 때문에 고생했던(--;) 추억(OTL)이 마구 떠올라서 결국 마구마구 적어버렸습니다. 상당히 주관적인(+개인적인) 생각이 엄청 담겨버린 환경 설정 이야기이었습니다만, 엄한 SDK에 괴로워 하시던 분들에게 약간이라도 도움이 된다면 좋겠네요. 더 좋은 방법들도 만들어 주시고요^^


9강부터는 다시 가급적 기존 SDK 환경을 기준으로 계속 진행하도록 하겠습니다. 확실히 작업하기는 이녀석(^^)보다는 그녀석(^^)이 더 편하니깐요.


본 내용은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

분문의 오류나 오타등의 문의는 문의 게시판에 해주시기 바랍니다. 본 내용은 지속적으로 업데이트 될 수 있습니다.^^

Email : juno@evermore.pe.kr