파이썬에 ctypes 통합

대중적인 언어들이라면 요즘 누구나 FFI (Foreign Function Interface)를 갖고 있는 편입니다. C#(CLI)의 P/Invoke나 Haskell의 ffi같이, C언어 중심으로 이루어진 세상에 적응을 하려면
아무래도 꼭 필요하다고 볼 수 있겠지요~
그런 역할을 하고 있던게, 파이썬에서는 바로
ctypes인데,
그동안 많은 사용자들이 ctypes로 가려운 부분을 긁어가며
잘 쓰고 있었지만, 파이썬 소스코드만 짜서는 절대로 세그폴트가
나서는 안 된다는 귀도의 철학때문에 표준 파이썬에는 들어오지
못하고 있었습니다.

그러던 와중, ctypes개발자인 토머스가 다시 메일링 리스트에
용기를 내어 제안을 했고, 귀도가 이제 많이 성격이 온화해져서
마음이 완전히 편하지는 않지만, 그런대로 찬성이라는 의견을
올리면서, 드디어 2.5에서는 ctypes가 들어올 확률이 매우 높아졌습니다. 🙂

그런데, ctypes 안에 포함되어 있는 크로스플랫폼 ffi 라이브러리인
libffi가
gcc 안에서 automake를 쓰는 바람에, libffi 자체는 X11 라이선스임에도 불구하고, 빌드 스크립트들이 일부 GPL이 포함되어 있는 바람에 파이썬에 들어오게 되면 다른 파이썬 코드들이 GPL 영향을 받게 된다는 우려들이 나오면서 다들 라이선스 해석하느라 공황 상태에 들어갔습니다.

가장 큰 이슈는 automake가 생성해주는 aclocal.m4에 GPL 코드가 와장창 들어있어서, 그 부분을 어떻게든 제거를 하는 것이었습니다. 다들 automake는 결과 코드에 대해서는 라이선스 제한이 없다 있다고 싸우고 있었는데, 마틴이 그냥 빌드 도구를 우리가 따로 만들어서 쓰면 되지 않겠느냐고 해서, 그냥 설날기념으로 한번 automake를 제거하고 distutils에서 직접 빌드를 하도록 ctypes 패치를 해 봤습니다. 🙂

libffi가 생각보다 굉장히 간단한 라이브러리라 빌드과정이 복잡한 것은 전혀 없었고, configure 스크립트에서 보내주는 변수를 쓰기 위해서 fficonfig.py.in 이라는 템플릿을 autoconf에서 처리해주도록 해서 그걸 distutils쪽 스크립트에서 execfile해서 처리를 했습니다. 해놓고 나니 소스도 거의 1MB 줄고 좋네요~ 곧 ctypes가 들어갈 수 있기를 기원해 봅니다. -O-