백 만년 만에 글이네요. 그 동안 예비군도 다녀오고 회사 업무로 바쁜 탓도 있었지만, 블로깅은 안 쓰기 시작하면 또 한정 없이 안 쓰게 되는 특성을 가지고 있는 것 같아요.

회사에서 지금 만들고 있는 제품(모질라 기반인 만큼 곧 오픈소스로 나오겠죠? ^^)과 관련해서 그간 모질라 프로젝트를 쭉 살펴보고 있었습니다. 모질라가 개발 플랫폼으로 밀면서 칭찬을 아끼지 않는 XULRunner를 가져와서 작업하고 있습니다. XULRunner는 2분기에 출시될 예정인 Firefox3와 맞물려서 XULRunner 1.9의 마무리 작업인 한참 진행 중인 상태죠.

모질라 홈페이지를 방문해보면 상당히 많은 양의 문서를 발견할 수 있습니다. 과거 코드만 달랑 공개하고 문서가 전무했던 다른 프로젝트에 비하면 상황이 상당히 좋은 편이죠.

하지만 모질라라는 몬스터급 괴물을 씨름하는 데 있어서는 이 정도 문서도 빈약하다는 생각이 드네요. 더군다나 막대한 덩치 때문인지 문서를 만드는 사람들도 제각각 일관성이 없는 데다가, 오래된 문서들이 갱신이 안 되고 있어서 실컨 읽다가 보면 이거 너무 옛날 얘기잖아 하면서 실망한 적이 많이 있었습니다. webshell이 docshell이 되고, 임베딩에 쓰는 런타임도 MRE였다가 GRE이 였다가 지금은 XRE라고 하는데, 뭔가 정리 안 된 느낌 때문에 혼란스럽네요.

결국은 모질라 메일링 리스트에 가입해서 관련 글도 훑어보고 문서나 코드만으로 이해 안 되는 질문들을 하나 둘씩 올려보고 있습니다. 적극적인 참여 없는 오픈소스란 결국 전임자가 만들다가 던져놓고 간 소스코드와 문서를 보면서 좌절하는 느낌과 묘하게 비슷하더군요.

저는 개발할 때 윈도를 쓰지만, POSIX compliant한 Cygwin 환경에서 대부분의 작업을 합니다. 주로 하는 일이라는 게 ./configure 스크립트를 돌리고 make를 치고 소스 코드를 vim으로 보는 것이기 때문입니다.

최근에는 조금 복잡한 소스 코드를 가져다가 Visual C++(커맨드 라인의 cl.exe와 link.exe)와 Cygwin을 섞어서 컴파일할 일이 있는데, 이렇게 되니깐 상당히 헷갈리는군요. 윈도 쪽에서 set으로 환경 변수준 것도 있고 Cygwin에서 export한 것도 있고, 특히나 파일 패스명이 다르다 보니 어디에서는 /cygdrive/c/ 와 같이 시작하고 어디에서는 C:\로 시작하니 정신이 없습니다. 특히 Subversion, Python, Ruby 등은 윈도 버전도 깔려 있고 Cygwin 버전도 깔려 있어서 내가 지금 어느 윈도용을 쓰는건지 Cygwin용을 쓰는 건지도 헷갈리게 되네요.

그래서 제가 다시 부활시킨 게 MinGW입니다. MinGW는 Win32를 위한 미니멀한 툴 체인을 주는 것을 목표로 하고 있는데, 원래는 Cygwin에서 fork된 프로젝트입니다. 다만 철학이 달라서 Cygwin이 POSIX를 거의 다 에뮬레이션해서 대부분의 프로그램을 컴파일하는 데 비해서, MinGW는 미니멀한 툴 체인만 주고, 보다 Win32에 특화된 네이티브한 어플리케이션을 작성할 수 있게 합니다.

여러분은 어떤 환경에서 작업하세요?


추가: MinSYS의 경우 rxvt 터미널에서 pty emulation 관련 문제로 네이티브 윈도 프로그램들이 제대로 동작 안 하네요. python.exe이나 irb.bat 등을 실행시키면 멈춰 버립니다 ㅠ.ㅠ

추가: 이 문제로 메일링 리스트에 포스팅을 했더니, MinSYS에 rxvt를 디폴트 터미널로 해야할지 말아야 할지로 꽤 많은 의견이 오가고 있군요. rxvt가 일으키는 문제의 원인은 다음과 같았습니다.

Keith MARSHALL <keith.marshall@total.com>

RXVT owns the `stdin', `stdout' and `stderr' file descriptors bound to your console, and uses pipes to connect these to your shell, and to any process you invoke from that shell. A pipe is not a tty, so `isatty()' returns `false', for these `stdio' streams in the application; thus, the standard runtime init routines enable block buffering for these streams, rather than the expected line buffered or unbuffered modes. This causes at least two serious problems for interactive console applications, run within an RXVT:

1) Expected output is delayed in the block buffer, instead of appearing on the screen; users are left waiting for prompts that never appear on the screen, yet the application has moved on, and is waiting for their input, (unless the application has been sprinkled with `flush()' calls, to explicitly work around this abnormal behaviour).

2) Special characters, such as ^D or ^Z, which users expect to be able to use to signal EOF on input are swallowed by RXVT; applications which loop until EOF on `stdin' are locked into a perpetual interminable state.

The above is a consequence of Win32's lack of *nix's `pty' feature; trying to emulate it with pipes just isn't at all satisfactory. I do know that Earnie has put considerable effort into seeking a solution to this `pty' emulation problem, with frustrating lack of success.

FORTRAN 언어 설계자이자 BNF를 만든 John Backus 씨(1977년 튜링 어워드 수상자)가 별세하였습니다. 삼가 조의를 표합니다.