작업환경을 linux로 migration하신 경험에 대해 듣고싶습니다
안녕하세요, 우선 읽어주셔서 감사합니다.
제목에서부터 벌써 이건 좀 kldp에 어째 위배(?^^; )되는듯한 느낌입니다.
당연히, 지금 주 작업환경이 linux이신 분은 질문에 해당사항이 없으신게 되겠네요.
sourceforge 들어가서 이달의 pjt들을 보다보니, 제법 많은 개발자들이
primary를 windows를 쓰고, secondary로 linux box를 쓰고 계시더군요.
그걸 보고 이런 생각이 들었습니다.
뭐, 당연하게도 작업pc랄지 하는건 이것저것 같이 쓸수 있는걸텐데요,
업무용(일반 사무라고 하는 편이 낫겠네요) pc로서가 아니라 작업(개발업무)용
으로서의 linux box는 어떻게 되는건지 해서요.
보통 웹이랄지 서버랄지, 혹은 완전히 리눅스box based pjt를 하는 경우가
많으실것 같습니다만, 그밖에도 linux를 이용하여 개발(gcc라거나
crossgcc환경을 구축해서 하는 일등, 혹은 target의 os가 linux이고 하다보니
자연스레 host pc가 linux일 경우등)이 있겠죠.
그러니까 사실은 windows based의 상용 compiler를 써서
개발하는것이 보통인데 그걸 linux box로 migration해서 개발하시는 경우가
있으신지 궁금합니다.
제 경우는, crosscompile용의 linux는 써도, project에 사용되는
상용의 compile환경을 alternative성격이 강한 linux로 migrate해서
개발한적은 없거든요.
즉, 쉽게 사용할수 있는 환경을 두고 돌아가듯이 linux를 작업환경으로
선택한적은 없다는 뜻입니다.
아무래도, 구축이 용이하고(머 걍 install하면 끝이니...), 그 환경을 대상으로
나온 코드의 수정이랄지 하는 수고도 필요없고, 뭐 그런 식이로군요.
지금 참여하고 있는 업무는 cdma modem, u-com,
개발툴용 win programming정도가 되는군요.
linux사용 업무과제는 대략 8:2, 7:3정도로 적었던것 같군요.
결과적으로 질문의 범위가 더욱 좁혀질텐데요,
상용툴로 구축된(혹은 구축가능하거나) 그런 작업환경을
과제에 사용하기엔 추가작업이 필요한 대안환경으로서의 linux box로
전환해서 사용하신 경험에 대해 여러분의 의견과 경험을 듣고 싶습니다.
(server side pjt류는 아무래도 host os의 dependency가 높은것 같으니
빼볼까요?^^; 이것저것 다빼고나면 별로 없을것도 같네요^^; )
어쩐지 적고 나니 좀 오해소지가 있을수도 있나 싶기도 합니다.
당연한 이야기입니다만, 여러가지중에 선택할수 있는 개발 환경으로서의
linux box에 대한 얘기가 되겠습니다.
그럼 좋은 하루하루 되십시오.
저는 임베디드 시스템쪽으로만 계속 일을 해 오고 있는데, 예전에 저도 비
저는 임베디드 시스템쪽으로만 계속 일을 해 오고 있는데, 예전에 저도 비슷한 고민을 한적이 있었던 거 같네요. 근데, 문맥상 제가 고민한 거랑 동일한 지는 잘 이해가 되질 않는군요.
저같은 경우는 문서편집이나 모 직접적인 개발업무랑 상관없는 건 윈도우즈에서 하지만, 개발업무는 거의 대부분이 리눅스 박스에서 이루어집니다.(아예 PC를 2대 가져다 놓고 있죠..^^)
하지만, 결론부터 말씀드리자면, 자기 개발 어플리케이션에 의해서 개발환경도 결정되는 거 같네요.
제가 주로 했던 일은 임베디드 RTOS 개발 혹은 어플리케이션쪽이었는데, 처음에는 UNIX에서 컴파일(상용 컴파일러)만 하는 수준으로 작업을 했었어요.
하지만, 단순히 콘솔만 이용하니까 에뮬레이터를 사용하면서 제공되는 각종 UI툴 사용과 병행하면서 불편함을 좀 느꼈죠.
그래서, 결국 PC에 cygwin을 설치해서 gcc cross compiler를 설치해서 모든 작업을 PC(윈도우기반)에서 작업을 했습니다. 한 4년전일거에요.
상용 컴파일러는 될 수 있으면 사용하지 않고 GCC 환경으로 바꾸면서, 몇가지 고민을 하기 시작했어요. 직접 개발한 RTOS라면 상관이 없지만, 대다수 상용 RTOS같은 경우, 권장 cross compiler를 명시해 주고, Makefile도 그 컴파일러에 맞게 제공이 되는 경우가 많아요.
물론, 저도 예외가 아니었기 때문에 결국 GCC환경으로 바꾸는 작업을 해야만 했죠.
근데, 의외로 GCC로 바뀐 환경에서도 큰 무리없이 시스템이 정상적으로 운용되는 것을 보았어요. (GCC 신봉자들한텐 좀 미안한 말이지만, 상용제품에서는 좀 꺼리는 환경이기도 했거든요. ^^ )
그런데, GCC로 바뀐 환경에서 작업을 하면서, 마음이 바뀐것이 또 있었어요.
저 같은 임베디드쟁이들이 주로 고민하는 일이기도 하고 매번 부딪히는 일인데, 일정에 쫒겨 타겟보드가 나오기 전에 유닛테스트만이라두 미리 해두어야 하는 상황이 종종 생기는 부분들을 어떻게 좀 해결할 수 없나....하는 거였죠.
주로 인터페이스만 있는 NULL device루틴을 짜서 해결하기는 하는데, 그나마 개발 타겟과 유사한 타겟보드에다가 올려서 시험하는게 고작이었는데, 것도 사실은 만만치 않은 작업(?? 사실은 좀 귀찮죠..^^)이죠.
디버그 환경과 시뮬레이션 환경을 함께 사용하기에는 이것저것 해보았지만, 제가 윈도우즈 프롬은 잘 못하거든요...^^ 결국은 리눅스 플랫폼을 선택한 거죠.
지금은 아예 코딩을 할때, 리눅스 호스트에서도 동작하고, 타겟에서도 동작하도록 구성을 합니다. 최소한 논리적인 유닛테스트는 호스트에서도 검증할 수 있으니까요(하지만 너무 많은 건 기대를 안하죠...^^)... 결국은 제가 최근에 개발한 타겟보드들은 대부분 임베디드 리눅스를 탑재하게 된 것두 이런 이유들 때문이죠.
이것저것 다 만족하는 환경은 없는거 같네요... 단지 어느쪽에 더 가까이 있느냐가 서로 다른거 같아요....^^
앗, 드디어 답변이^^;
우선, 답변에 감사드립니다.
문맥상 님께서 고민하신 바와 제가 고민하던 바는 상당히 유사한것 같습니다.
^^;
시그너스가 일찌기 그런 작업환경(일단은 compiler환경구축같은 기본
설정이 위주겠지만요^^;)을 gnu gcc를 가지고 상업적으로 시작했다고 하지요?
물론 지금은 역사속으로 사라진 회사가 되지만요.
그 시그너스가 제안했던것이 대안적(alternative) 선택으로서 gnu system
이라고 알고 있습니다.
전해지는 문서상으로 당시 상황을 들어보면, chip vendor가 제공하는
상용(혹은 전용) 컴파일러가 너무 후져서 gcc로 전환했을때의 성능이
전자의 그것들을 압도해버리는 상황이 벌어졌다고 들었습니다.
뭐 아마도, 당시에야 icd나 ice같은 툴은 없었던거겠죠? 있었을래나^^;
그냥 일반적으로 생각할수 있는 개발 환경의 조합이라는 것이,
compiler set, emulator, debugger, in-circuit debugger정도가
되지 않나 싶습니다.
그중 emulator, debugger의 경우, 이기종 machine의 op-code지원이
완벽하지 않달지, peripheral(null device를 쓰신댔죠?^^; )의
문제랄지 하는 식으로 불충분하게 됩니다.
결국, compiler와 여유가 된다면(아마 시간땜에 거의 필수가 되어가지만요)
in-circuit debugger가 기본 구성이라고 볼수 있을텐데요.
말씀하신 바와 같이, 상용 툴이 crossgcc를 구축한달지 하는 식의
수고도 없고, 또 일단은 공신력(?^^; )이 있는 처지인거죠.
더구나 debugging 환경도 제법 안정적이고 나이스하단 말입니다.
이에 비해 cross gcc에 gdb조합은 분명 대안적으로는 존재하지만,
그렇게 잘 쓰이는 조합은 아닌것 같거든요.
(솔직히 딱 두번 봤고, 한번 써봤습니다.ㅡ.ㅡ; )
뭐냐하면, gdb만 해도 jtag의 front-end가 구현되어있다고는 하지만,
상용툴에 제공되는 gdb가 아닌 일반 gdb를 다운받고 patch해서
써본적은 없단 겁니다.
그래서, linux host platform 기반위의 프로그래밍을 하는 것이 아닌
embedded system의 경우도, 상당한 메리트는 있어보이지만,
그다지 다가서기가 쉽지는 않은 것이 현실입니다.(아 정정하겠습니다.
제 현실이라고 하는 편이 맞습니다.)
또한 지적하신 바와 같이 상용 rtos나 dsp blockset의 경우,
환경에 대한 부분이 권장이라기보다는 mandatory에 가깝기도 하죠.
이래저래 아예 제로부터 시작해서 새로이 만드는 시스템이 아닌 이상,
대안으로서의 리눅스환경구축은 참 선택하기 애매한 구석이 있더라
이겁니다.
그래도, 제가 생각하던 바와 유사하게 작업하시는 분이 계시는군요.
제 경우는 cygwin을 그냥 editor와 windows하에서 상용 compiler를
사용하기 위한 shell정도의 개념으로밖에 쓰고 있지 않은데 비해
(기껏해야 makefile수정이나 script fitting정도고, 순전히
vi, ctags, grep, perl을 맘편히 쓰기 위한 용도랍니다.^^; )
그 위에서 cross compiler까지 구축해서 쓰신다는 점이 다르시군요.
여담입니다만, 초기 리눅스나 gnu toolkit들을 보면, 하단부 s/w에 대한
논의가 활발했던것 같습니다만, 이곳 kldp에서는 그런 부분보다는
보다 상위의 s/w, server side위주의 논의가 많은것 같습니다.
아마도, 하단은 이미 견고해진 탓이려나요?^^;
답글 정말 감사합니다. 많은 도움이 되었습니다.
그럼 좋은 하루하루 되십시오.
--------------------------------------------------------------------------------
＼(´∇`)ノ ＼(´∇`)ノ ＼(´∇`)ノ ＼(´∇`)ノ
def ed():neTdiVeR in range(thEeArTh)