Flutter는 커다란 한 수

최근 Dart와 Typescript 중에 하나를 선택하려고 깊은 고심을 하다가 결국 TS를 골랐습니다. 일단 저는 상당히 친 구글 성향인데, 그럼에도 불구하고 한 가지 프레임웍이 없었다면 고민 자체를 하지 않고 TS를 선택했을 겁니다. 그 프레임웍이 Flutter죠.

Flutter는 다트로 한 번 프로그래밍해서 Android와 iOS용 앱을 모두 빌드할 수 있는 프레임웍입니다. 웹앱과 두 가지 모바일 앱을 언어 하나로 모두 개발할 수 있다는 점이 큰 장점으로 다가왔지만, 결국 당장 필요한 웹앱개발의 여건에 TS가 너무나 압도적이라는 판단을 내렸습니다.

Flutter는 리눅스 환경에서는 데스크탑 앱으로도 빌드할 수 있으며 Fuchsia도 Flutter로 UX 작업을 한다고 하니, 구글이 바라보는 Dart는 모든 환경의 클라이언트를 작성하는 언어일 수도 있겠다 싶습니다. 그 목적이 이미 달성되었다면 Dart도 꽤나 매력적인 언어였을 수 있겠다 싶습니다.

문제는 아직 그 때가 아니라는 점이죠 :-/

GCC와 Clang의 RAII

GLib 코딩을 하다가 g_autoptr() 이라는 매크로가 보이길래, C로 또 무슨 흑마술을 부렸나 살펴봤더니 RAII (Resource acquisition is initialization) 기법을 가능하게 하는 확장이 생겼습니다. cleanup 이라는 이름의 확장입니다. 다음과 같은 형태로 쓸 수 있습니다.

void clean_up(int *final_value)
{
  printf("Cleaning up\n");
  printf("Final value: %d\n",*final_value);

}

int main(int argc, char **argv)
{
  /* declare cleanup attribute along with initiliazation
     Without the cleanup attribute, this is equivalent 
     to:
     int avar = 1;
  */
  
  int avar __attribute__ ((__cleanup__(clean_up))) = 1;
  avar = 5;

  return 0;
}

다음에는 간단한 ref count 시스템을 만들어봐야겠군요 :-)

리눅스상 C/C++ 빌드툴 정리.

"빌드툴이 무엇이다" 라는 것까지는 알고 있는 사람들을 대상으로 리눅스 환경에서 고려될만한 빌드툴들을 가벼운 마음으로 경험상 비교한 것.

크게 보면 다음 세 가지 카테고리로 먼저 분류를 하게 된다.

1. 직접 cc 명령어로 컴파일하고 링크함. 예제파일 이상의 수준에서 쓸 일 없음.
2. Makefile을 작성하고 make 명령어로 1을 수행함.
3. Makefile을 만들어주는 프로그램(예-autotools)을 이용해서 2→1을 수행함.

여기서 1은 대체할 툴이 어쩌고 할 여지가 없고,
2에서 make 대안으로 언급될만한 것은 ninja,
3에서 autotools의 대안으로 언급될만한 것은 cmake, 그리고 내 경우에는 gyp, gn 등


ninja와 make를 비교하면 가장 중요한 차이는 make는 스스로 빌드툴 역할을 하는 상황을 상정하지만 ninja는 하지 않는다는 것이다. make의 경우에 make 자체가 빌드 시스템의 프론트엔드인 경우, 다시 말해서 Makefile을 인간이 직접 작성하는 것을 전제하고 만들어져서 소스가 되는 파일을 눈으로 읽어가면서 작업하는 것이 그래도 할만하고 조건부 빌드같은 기능도 필요한 것으로 간주되어 있다.

반면에 ninja의 경우에는 정말로 빌드를 위한 의존관계 정리만으로 할 일을 최소화하고 있다. 다시 말해서 autotools나 cmake의 백앤드로 작동하기 위한 것이지 스스로 빌드툴 역할을 할 생각은 없다는 것이다. 컨디셔널 빌드? 각종 프로그램적 커스텀? 그건 다 cmake같은 툴에서 ninja 파일을 생성하는 시점에 할 일이다. ninja는 그저 기계적으로 빠르게 의존관계를 처리해서 빌드만 하면 된다. 그리하여 ninja의 리소스파일은 유닉스 텍스트 파일이지만 사람 눈으로 읽기에 친절하게 하려는 목표를 가지고 있지 않다. 그리고 실제로 make와 속도의 차이가 난다고 한다.


그 뒷 단계의 autotools/cmake 등을 비교하면..

autotools는 첫번째 난관은 진정 제대로 쓰려면 m4라는 언어 하나를 더 배워야 한다는 점이다. 개인적으로 "순수하게 declarative한 언어의 예시"로 언급하는 이상으로는 이 언어를 활용하지 못하고 있다.

두번째로는 autoconf-autoreconf와 automake의 이원화된 시스템이라는 점.

세 번째는 첫번째와 두번째의 시너지가 일으키는 복잡성.

마지막으로는 빌드 관리툴이라기보다는 GNU 시스템의 타볼 패키지를 생성하는 도구에 가깝다는 점이다. 다시 말해서 autotools를 기반으로 한 소스코드 디렉토리는 다양한 환경을 지원하는 프로젝트의 소스코드라기보다는 GNU운영체제의 배포용 패키지에 가깝다. GNU 운영체제가 나름 다양한 타겟 아키텍쳐를 지원하지만 근본적으로 GNU 밖에서 쓰기에 적절하지 않다. 윈도우 환경에서 빌드하는 데 악명이 높다.

cmake는 그냥 무난하고 대세스러운 느낌. 특별히 설명할 말을 모르겠다. 특히 지금처럼 잘 알지도 못하는 상황에서는.


지금 무슨 프로젝트를 시작하게 된다면 cmake/ninja가 내 선택이 될 것 같다.


가벼운 인상비평들.