It's just like pok

Octave(이하 옥타브)는 Matlab에 대응하는 오픈소스 프로그램이다.

최근 학교에서 Matlab을 이용한 수치해석이나 확률과정 개론을 배운다.
그런데 Matlab은 고가의 소프트웨어라서 집에서는 오픈소스 프로그램인 옥타브를 사용한다.

이 글은 3.2 버전에 맞춰 작성되었다.
옥타브 3.0버전에서 고민하던 문제들이 3.2버전에서 단박에 풀려서 3.2버전을 사용하기를 강력히 추천한다.

먼저 옥타브는 커맨드라인 프로그램이다. 그래서 옥타브가 아쉽다기보다는 윈도용 커맨드라인 환경이 아쉬운 경우가 종종있다. 가장 아쉬웠던것은 글꼴이었고, 옥타브 3.0버전에서는 '삐'거리던 스피커음도 불만이었다.

먼저 커맨드라인 글꼴바꾸기
http://smallvoid.com/article/winnt-cmd-add-font.html

내경우에는 HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft \Windows NT \CurrentVersion \Console \TrueTypeFont 에서 나눔코딩고딕을 콘솔 폰트로 설정해서 사용하고 있다.



그리고 커맨드라인에서 PC스피커 (bell service) 끄는 방법.
http://superuser.com/questions/10575/turning-off-the-cmd-window-beep-sound
커맨드라인에서 벨을 끄는 방법은 여러가지 있는데 내가 사용했던 방법은 아래와 같다.

net start beep

그런데 이것은 재부팅때마다 재설정을 해야했고, 다음은 재부팅마다 재설정을 할 필요가 없게 만드는 커맨드다.

sc config beep start= disabled

이 방법 말고도 '장치관리자'를 통해 beep 을 제거하는 방법이 있다. 제어판의 장치관리자를 실행한후에 보기 - 숨김 장치 표시 를 해서 beep 장치를 '사용안함'으로 설정하는 방식이다.


다행히도 옥타브 3.2버전의 less는 '삐'거리는 소리 대신에 윈도 효과음을 사용하고 그것도 똑똑히 사용해서 더이상 저 설정이 필요없게 되었다.

나는 cygwin의 bin 디렉토리에 path가 걸려있어서 자주사용하는 프로그램들은 그곳에 배치스크립트를 작성해 넣어둔다. 옥타브의 경우는 cygwin/bin/octave.bat 파일로 넣어두어사용하며 그 내용은 다음과 같다.

cd C:\Users\pok\Documents\workspace\Octave
"C:\Octave\3.2.2_gcc-4.3.0\bin\octave-3.2.2.exe"
rem start C:\Users\pok\Documents\Utils\Console2\Console.exe -c C:\Users\pok\Documents\Utils\Console2\console_octave.xml

저렇게 하면 내 'workspace'가 pwd(present working directory, current working directory라 하여 cwd라고도 한다)로 설정되어 .m 파일등을 작성할때 편리하다.

아래 주석(rem) 되어 있는것은 cosole2라는 꽤 훌륭한 cmd 대체 프로그램을 이용할때인데, 이놈이 한글입력이 되지 않아 현재는 사용하지 않는다.

3.0버전에서는 사용자 디렉토리 밑에 무조건 'octave'라는 폴더를 만들어버려서 프로그램실행 창에서 'octave'라고 치면 그 디렉토리가 열렸다. 3.2버전에서는 그런만행을 하지 않아 꼭 octave.bat이라고 칠 필요없이 octave라고만 쳐도 되서 편리하다.

다음은 내 local home directory에 있는 .octaverc 파일의 내용.

addpath('C:\Users\pok\Documents\workspace\Octave');
edit("EDITOR", "C:\\Users\\pok\\Documents\\Utils\\Vim\\vim72\\gvim.exe %s -c cd C:\\Users\\pok\\Documents\\workspace\\Octave -c \"30vs .\" -c \"wincmd w\"");
edit("HOME", "C:\\Users\\pok\\Documents\\workspace\\Octave");
edit("LICENSE", "BSD");
#set(0,'defaulttextfontname', 'Malgun Gothic');

path에 내가 '.m'파일들을 모아놓고 있는 C:\Users\pok\Documents\workspace\Octave 를 추가했고
"EDITOR"에는 주로 사용하는 에디터인 vim 을 .m 파일들을 나열하여 열리게 설정하였다. "LICENSE"는 새로 만드는 .m 함수의 라이센스를 어떤걸로 할건지 여부를 정하는것은 기본은 GPL이고 나는 BSD로 라이센스를 변경했다.

3.0 버전에 plot의 기본글꼴 설정이 구리구리하여 set을 이용하여 기본글꼴을 설정했는데, 3.2버전에서는 wgnuplot에서 설정하고 저장할수 있게 바뀌었다.

멀티플랫폼/실행환경 Octave, 수학

코딩컨벤션 삽질기 2탄은 vim의 modeline 삽질기다.

제일 삽질했던것이 // vim 과 /* vim */ 의 설정 포멧이 다르다는것을 모르고 안된다고 이것저것해봤던것.
그것에 대한 차이점을 자세히 설명해놓은곳이 이곳이다.

두번째 삽질은, // vim 위치의 문제. 이 mode line 주석이 있을곳은 소스의 맨 처음이거나 맨 마지막이어야한다!
이걸 몰라서 우엉삽질을 했다.

참고로, modeline을 사용하려면 set modeline(혹은 set ml)이 설정되어 있어야한다. 일반적인 배포판에서 이것이 설정되어있는지는 모르겠으나, win32 gvim은 기본으로 설정되어 있더라.

결론적으로, 나는 소스의 맨 마지막줄에

// vim: ts=4:sw=4:nowrap

같은 modeline을 설정한다.

멀티플랫폼/개발환경 vim

svn에는 property라는것이 있다. 그중에서 set:keyword property가 있는데 이것을 이용하면 커밋에 대한 정보를 소스파일에 심을 수 있다. 이에 대한 정보들은 상당히 많다.

• http://dreamstorm.cafe24.com/cgi-bin/moin.cgi/Subversion
• http://my.oops.org/128
• TortoiseSVN에서 set:keyword property 설정
  
• TortoiseSVN에서 auto property 설정
• 치환 키워드인 $Id$, $Rev$에 대해 자세한 설명이 나와있는 사이트

간단하게 Id keyword만 설정해놓고 $Id$라고 치면, 왠만한 정보는 다 실리는데... 문제는 여기에 나오는 날짜가 Z(Zulu Time - UTC zero time을 기준, 위키페디아참조)라서... 영 못읽어 먹겠더라.

그런데 특이하게도 $LastChangedDate$는 또 local zone을 기준으로 시간을 기록해준다. 여기에 대한 분분한 의견들이 있는데, 어쨌든, $Id$ 시간과 $LastChagnedDate$가 다른 시간을 기록해준다는것은 사실이다.

그래서 그냥 $Id$ 안쓰고 다음과 같이 쪼개 쓰기로 했다.

// $LastChangedBy$
// $LastChangedDate$
// $Rev$

이것때문에 svn 커밋을 10번가까이 반복했다는...-_-

멀티플랫폼/개발환경 svn, UTC

vim의 환경변수중에 자주사용하는 환경변수로 $VIMRUNTIME과 $HOME 이 있다. 만일 $HOME이 정해지면 재미있는것들을 많이 할 수 있는데, 예를들면 ctags 파일이나 session 파일들을 한곳에 몰아둘 수 있다.

cygwin 터미널용 vim과 gvim win32 버전을 동시에 사용하고, vimrc파일을 공유할경우 - 내 경우는 win32 vimrc를 ~/.vimrc 파일로 심볼릭링크를 걸어서 공유한다 - $HOME 변수를 설정하는것이 조금 곤란하다. 왜냐하면 시그윈과 윈도우즈가 디렉토리를 다루는 방식이 상이하기 때문이다. 내 경우는 그래서 꼼수로 $VIMRUNTIME 변수를 이용해서 아예 그곳에 set_home.vim 파일을 따로 두어 각각읽어들이게 했다. 그래서 시그인용 vim은 /usr/share/vim/vim72/set_home.vim 을 읽고 (그곳에서 let $HOME="/cygdrive/c/Users/pok/Documents") gvim win32는 다른 set_home.vim을 읽어들인다.

(Language : perl)

source $VIMRUNTIME/set_home.vim
function MakeTags()
    let current_dir = getcwd()
    let filename = substitute( substitute(current_dir, "[*:*|*' '*]", "_", "g"), "[*\/*|*\\*]", "_", "g" )
    let filename = $HOME . '/workspace/ctags_cscope/' . filename . '.ctags'
    execute '!ctags -R -f ' . filename . ' "' . current_dir . '"'
    execute 'set tags+=' . filename
endfunction
function AddTags()
    let ctags_files = substitute(glob($HOME . '/workspace/ctags_cscope/*ctags'), "\n", ",", "g")
    execute 'set tags+=' . ctags_files
endfunction
call AddTags()
au VimEnter * :cd $HOME
let g:alternateSearchPath = 'sfr:../source,sfr:../src,sfr:../include,sfr:../inc,sfr:../,sfr:./include'

MakeTags라는 함수는 현재 작업하는 곳의 ctags 파일을 작업디렉토리에서 공백이나 :, /, \ 등의 문자를 _로 바꾸어 $HOME/workspace/ctags_cscope 디렉토리에 만들어저장하는 역할을 한다. AddTags라는 파일은, 처음에 vim을 로딩할때 만들어둔 ctags 파일들을 읽는 역할을 한다. 소스를 분석할 디렉토리에서 :call MakeTags()만 호출하면, ctrl+]등을 자유롭게 이용할수 있다.

소스분석에서 매우 자주사용하는 플러그인이 a.vim이라는 플러그인인데, ./include/a.h , ./a.cpp 이렇게 파일들이있다면 :A 커맨드가 원하는데로 되지 않는다. cpp와 h 파일이 a.vim이 기본으로 지원하는 SearchPath에 없어서 생긴 문제인데, g:alternateSearchPath를 변경하면 원하는 SearchPath를 추가할수 있다. 마지막에 있는 sfr:../,sfr:./include 가 위의 문제를 해결하기위해 기본 SearchPath에서 추가한 설정이다.

마지막으로, 현재 vim의 view나 설정들(열어놓은 파일들이나 버퍼의 현재 커서 줄)을 저장하는 방법이 있는데, session을 저장하는 방법이다. :mks 원하는이름.vim 이라고 하면 세션이 저장되고 부르려면 :source 원하는이름.vim, 덮어저장하련 :mks! 원하는이름.vim 이라고 하면 된다. 내경우에는 $HOME 디렉토리에 세션들을 모두 저장해놓고 있으며, vim을 시작하면 자동으로 cwd를 $HOME으로 변경시켜놓아서( au VimEnter * :cd $HOME ) :source 이름.vim을 하면 바로 저장해놓은 세션들을 읽어들인다.

멀티플랫폼/개발환경 vim

메일링 리스트를 자주사용하는 사람에게는 '쓰레드로 글 읽기'라는 썬더버드 기능이 참 편리하다. ThreadVis는 이러한 쓰레드관리기능을 강화해주는 썬더버드 익스텐션이다.



보낸사람있는 패널 오른쪽으로 보이는, 회색네모와 파란네모 그리고 그 네모들을 연결하는 선이 ThreadVis의 인터페이스다. 파란네모가 지금 내가 보고 있는 메일이고 연결선들은 어떤 쓰레드로 연결되어 있는지를 알수 있게 해준다. 저 네모들은 클릭이 가능하여 읽고 있는 쓰레드의 부모로 바로 가는것이 가능하다.

'별표'상태는 썬더버드에 오래전부터 있던 기능인데 이렇게 별표를 찍어두고 '검색폴더'기능으로 '별표'라는 폴더를 만들어두면, 내가 이 계정에서 별표해놓은 메일을 바로 검색할수 있어서 편리하다.



네모들중에 속이 비어있는 네모가 있는데 그것은 내가 작성한 메일을 의미한다. 역시 클릭이 가능하며 쓰레드간의 이동이 편리하다. '검색폴더'를 만드는 가장쉽고 또 가장 강력한 방법은 오른쪽 상단에 있는(돋보기에 '제목'이라고 써있는) 검색필터를 통해서 만드는 방법이다. 원하는 필터종류로 필터링을 한후에 바로 검색폴더로 만들수 있다. 글로 적자니 조금 장황한데, 써보면 직관적이라서 바로 알수 있을것이다.

다른 검색폴더 만들기 방법도 있지만 이 방법을 추천하는 이유는, 다른 방법으로 만들어진 검색폴더에서는 쓰레드 - 번역이 적절하게 '글타래'로 되어있다 - 보기가 안되고 이 방법으로 만들어진 폴더에서만 글타래보기가 가능하기 때문이다. 썬더버드 버그인지 아니면 내가 잘 모르는것인지 모르겠지만, 하여튼 저방법으로 검색폴더를 만들면 메시지리스트 창에서 글타래로 정렬해 볼 수 있다.

멀티플랫폼/실행환경 메일링리스트, 썬더버드

비교하고 싶은 두 파일이 있을때 vim을 이용하면 편리하다.

간단히 두 파일을 하나의 vim으로 열면 vim 하나에 두개의 버퍼가 있을것이다. 현재 vim에 어떤파일들이 열려있어서 어떤 버퍼들이 있는지를 보려면

:buffers

라는 명령을 치면 된다.

그러면 불친절한(?) 리스트가 뜨는데, 리스트에 나타난 기호와 알파벳의 정체는 이렇다.

• % current window
• # alternate buffer (switch using :e# or :b#)
• a active (loaded and visible)
• + modified

그 리스트 중에서 현재 편집중인 것과 diff하려는 버퍼를 split 하여 열면 된다.

:sb N

여기서 N은 리스트에 나타난 버퍼번호이다. 나는 diff를 할때 비교하려는 파일을 수직으로 나누어 보는것을 좋아하므로 버퍼를 항상 수직으로 연다.

:vert sb N

ctrl+W, W를 누르면 분할된 창끼리 넘나드는데 넘나들면서 각각의 버퍼에 diffthis명령을 준다.

:diffthis

그러면 두개의 창이 diff 모드가 된다. 만일 diff모드를 해제하고 싶다면 diffoff( 7.0이상이던가.. 그렇다)를 준다.

:diffoff

reference link
   - :buffers 명령시에 나타난 불친절한 메시지를 친절히 설명해 놓은 사이트
   - vimdiff의 더 많은 활용 from kldp

멀티플랫폼/개발환경 Development, vim

얼마전 회사동료분께서 notepad++ 의 'Current dir path to Clipboard' 기능이 파일 편집에 있어서 매우 유용하다라 요지의 말을 했었었다(-_- 한 1년전쯤?) 그리고 친구녀석이 vim에서 같은 기능을 찾았었던것 같다. 요새 Portable Apps 로 컴퓨터 사용환경을 바꾸면서 vim을 꾸미다가 생각이나서 관련자료들을 찾아보았다.

우선 vim에서 현재 편집중인 파일 - 버퍼 - 는 expand("%")라는 표현식을 통해서 문자열로 얻을수 있다. 예를들면, vim으로 문서를 열고

:echo expand("%")

라는 명령을 치면 커맨드라인에 현재 편집중인 버퍼의 이름이 출력된다.

둘째로, vim에는 'yank'등을 위한 register라는 특수한 변수들이 있다. 이러한 변수들은 @를 사용하여 vim script등에 사용할수 있다. 예를들면 제일만만한 이름없는 레지스터 "에 "hi"라는 값을 집어넣어서 p 단축키를 통해 "hi"를 붙여넣으려면

:let @" = "hi"

라고 커맨드 라인에서 입력하고 편집모드에서 p를 누르면 원하는대로 hi가 붙여넣어질 것이다. (좀더 자세한 사항은 :help let-@) 특별히, win32계열의 gvim에서 @* 는 윈도우 전역 클립보드를 의미한다.

마지막으로 substitute라는 vim 내장함수가 있는데, 이것은 정규표현식을 이용하여 vim script의 문자변수를 치환해준다. 예를들면 현재 편집중인 버퍼이름으로부터 디렉토리 패쓰만을 뽑아오려면

substitute( expand("%"), '\(.*\\\)\(\).*', '\1', 'g' )

와 같이 사용하면 된다. (이 정규표현식에 대한 좋은 설명을 http://www.kldp.org/node/91397 에서 볼수 있다.)

이 세가지 팁들을 합쳐서

:let @*= substitute( expand("%"), '\(.*\\\)\(\).*', '\1', 'g' )

를 입력해주면 현재 편집중인 버퍼의 디렉토리 패쓰가 윈도우 클립보드에 저장되며, ctrl+v 등을 이용하여 붙여넣기 할수 있다. 만일 자주사용된다면 키맵을 하거나 메뉴를 편집하여 추가하면 될것이다.

멀티플랫폼/개발환경 Development, vim

NetBeans용 jVi의 감동으로 인해 이클립스내에서 vi키를 쓸수 있는 플러그인들을 sf에서 찾아보았다.

viPlugin은 0.2버전이후에 상용으로 돌아섰는데, 구버전은 쓸만하지 않다.
eclipseviplugin은 오픈소스중에서 그나마 쓸만한 녀석인데, 'v', 'shift+v'가 안된다. 으악.
vimeclipse는... 문제는 이녀석이다.

뭔가 있어보이는 이녀석은 이클립스안에 gvim을 임베이딩 해준다. 그리고 그게 전부다. 이렇게 하면 OutLine이나 뭐나 그런거 안된다. 이클립스 자동 채워주기 요런거 안된다. 그냥 임베이딩만 해준다. 이거 깔라고 잘쓰고 있던 vim 밀고 최신의 cream을 깔았는데 허무했다.

삽질의 하이라이트는 bufexplorer였다.
최신의 cream을 깔면서 플러그인들도 업그레이드 했는데 요 bufexplorer의 '\bs', '\bv'기능이 안되는거다. 물론 일반적으로 \be를 썼지만, 안되니까 신경질이났다.

가장 쉬워보이는, cream에서 다시 예전의 gvim7.1로 다운그래이를 해봐도 안되고 해서 bufexplorer 최신 버전이 아닌가.. 싶어서 스크립트 홈페이지에 가보니까

bufexplorer.zip

7.1.2

2007-11-07

6.0

jeff lanzarotta

This is a MAJOR update. * Added handling of tabs. (Dave Larson) * Removed \bs and \bv commands because these are easier for the user to create horizontal and vertical windows. (Dave Larson) * Fixed jumplist issue spotted by JiangJun. * Went back to using just a plugin file, instead of both an autoload and plugin file. The splitting of the file caused issues with other plugins. So if you have a prior version of bufexplorer that has an autoload file, please remove autoload\bufexplorer and plugin\bufexplorer before installing this new version. * Fixed E493 error spotted by Thomas Arendsen Hein. * Minor cosmetic changes. * Minor help file changes.

음? 이 뭥미? 정말 말그대로 완전 삽질했다.

그나마 삽질하면서 몇가지 건진게 있는데, 일단 글꼴문제.
http://gooom.kr/16
윈도우에 내가 원하는 글꼴셋을 묶는 기능이 없는지 궁금했는데 있더라. 아이좋아.

그리고 인코딩 문제.
http://kldp.org/node/32987
euc-kr 파일과 utf-8 파일을 구분하여 읽기중에 이렇게 간단한 방법이 있었다니!

이 두가지 해결한거에 3시간 삽질을 위로해야겠다

멀티플랫폼/개발환경 Eclipse, NetBeans, vim

이클립스에서 자주쓰는 플러그인들이 있다. 이것들을 한꺼번에 설치하면 참 좋겠다고 생각했는데, 기특하게 그런 프로젝트가 있더라. 이름하여 Callisto Simultaneous Release!

The goal of the Callisto Simultaneous Release was to release ten major Eclipse projects at the same time.

참 기특하다. 덕분에 새로 설정이 필요한 이클립스의 플러그인 설치를 무지 편리하게 할 수 있었다.

현재 One-Shopping(-_-) 할수 있는 플러그인들은 다음과 같다.

Projects Included In The Release
    * Business Intelligence and Reporting Tools (BIRT) Project
    * C/C++ IDE
    * Data Tools Platform
    * Eclipse Modeling Framework
    * Graphical Editor Framework
    * Graphical Modeling Framework
    * Platform
    * Test and Performance Tools Platform
    * Web Tools Platform
    * Visual Editor

Callisto Simultaneous Release 홈페이지

멀티플랫폼/개발환경 Eclipse

make를 무지무지 싫어했다. 알수없는 매크로로 덕지덕지 붙어 있는것도 그렇고 탭들여쓰기도 그렇고.. 그런데 그간 내가 make에 대해 오해하고 있었나보다. 나는 make를 '변경에 관한 관리툴'로 보지 않고 스크립트언어의 일종으로 본것이다.

make는 빌드 관리 시스템이다. 빌드 관리에서 가장중요한것은 변경에한 관리다. 종속성관리라는 요소도 사실은 변경사항을 적용하기위한 하나의 부가적인 측면에 지나지 않는다. 그래서 make는 변경사항 감시와 변경에 대해, 종속적인 순서에 의거 정해진 일을 해주는 시스템툴이라고 요약할수 있겠다.

make의 기본적인 항목들을 살펴보면 다음과 같다.

1. 매크로 정의
매크로는 다음과 같이 정의할 수 있다.

#재귀적 확장 매크로, 뒤에서 $(VALUE)를 통해 재작성하면 그것도 여기에 적용된다.
VALUE = something

#단순확장 매크로, 이후의 $(VALUE)를 단순히 something으로 치환한다.
VALUE := something

#기존의 매크로에 something을 공백을 두고 덧붙있다.
#ex. 기존 VALUE가 anything 이었다면, 이후 anything something 이 된다.
VALUE += something

#앞에 VALUE가 정의 되어 있지 않다면 VALUE를 정의하고 값을 something이 되게 한다.
VALUE ?= someting

#make 함수를 사용하였다면 그 결과로 치환된다.
VALUE = ($shell pwd)

그리고 다음과 같이 사용한다.

all:
#반드시 탭
    @echo $(VALUE)

2. 타겟의 기술
타겟은 아래와 같이 기술된다.

target : dependency1 dependency2
<tab>command

타겟은 종속적인것을 먼저 수행하고 타겟의 커맨드를 수행한다. 만일 이때 타겟과 종속적인것이 오브젝트 파일이나 소스파일이라면, 변경사항을 검사하고 확장자 규칙에 자동적으로 종속작업을 할수 있다.

3. 구문 / 함수
make는 여러함수와 간단한 구문을 포함한다. 조건 구문을 먼저 살피면

#아래의 구문은 명령에 들어가며 매크로의 값을 비교해서 명령을 수행한다.
all :
ifeq( &(CC), gcc )
    @echo "Complier - GCC"
else
    @echo "Complier - Not GCC"
endif

#아래의 구문은 매크로 정의에 따라 타겟을 구성하거나 구성하지 않는다.
ifndef DEF_ONLY_ONE_FILE
#SRCS:.c = .o는 SRCS의 .c 부분을 .o로 바꾸는 make 함수이다
$(TARGET).o : $(SRCS:.c = .o)
# $@은 타켓을 의미하며 $^은 종속성을 의미하는 내부지정 매크로다.
    $(LD) -r $^ -o $@
endif

그리고 make는 매크로(문자변수 정도로 생각하면 편할듯)를 편리하게 다룰수 있는 많은 함수들도 제공한다.

#shell함수, 함수뒤에 오는 쉘 명령을 수행하고 결과를 문자열로 던저준다.
PWD := $(shell pwd)

#wildcard 함수, 지정된 디렉토리에서 패턴과 일치하는 파일리스트를 뽑는다.
#디렉토리를 특별히 지정하지 않으면 .와 같다.
#patsubst, $(매크로명:패턴 = 치환할 문자열
SRCS = $(wildcard *.c) #$(wildcard ./*.c와 같다)
OBJECTS = $(SRCS:.c = .o)

#foreach 함수 : $(foreach 변수명, 대입문자열, 확장문자일)
#아래는 현재 디렉토리에서 시작해서
#dir_sub_1과 dir_sub_2 아래에 있는 모든 .c 파일을 SRCS로 만든다.
#먼저 dir이라는 변수명에 . 이 들어가서 $(wildcard ./*.c)가 수행된다.
#만일 현재에 a.c 가 있고 dir_sub_1에 b.c 가 있고 dir_sub_2에 c.c가 있다면
#SRCS 는 ./a.c dir_sub_1/b.c dir_sub_2/c.c 가 있다.
SRCS := $(foreach dir, . dir_sub_1 dir_sub_2, $(wildcard $(dir)/*.c) )

4. 기타 규칙
make의 다른 규칙들을 살펴보려면 'make -p' 명령을 통해 현재 규칙들을 살펴볼 수 있다. 만일 이 명령을 수행한 디렉토리 내에 makefile이 있다면 그 makefile에 대한 매크로와 규칙들을 화면에 출력해줄 것이다.

5. make의 친구들
사실 make는 변경사항을 종속성에 따라 감시하는것을 제외하고는 스크립트로써 꽝이다. (100줄만 넘어가도 정말 내가 뭘 짜고 있는지 모르겠다.) 그런 사람들이 많았는지 makefile 작성을 도와주는 많은 유틸리티 프로그램이 있다. 그중에서 대표적인것이 autoconf와 automake 인데, autoconf는 configure.ac 와 Makefile.in을 가지고 configure 스크립트파일을 만들어 내고 사용자는 이 configure 스크립트 파일을 이용해서 makefile을 생성해 내도록 하는 도구이다. automake는 Makefile.in을 쉽게 만들수 있도록 도와주는 유틸리티다. 사실 이 도구들은 사용하기 조금 까다로와서 KDE같은 경우에는 cmake를 사용하게 전환했다는 소리를 들었다. 음... 요는 makefile을 만들면 되는것 아닌가? 그렇다면 ruby같은 스크립트를 이용하는것도 괜찮을 것이다. 사실 KDevelop을 사용하면 이런 configure.ac 파일같은것들을 쉽게 작성할수 있도록 도와주기때문에 그럭저럭 괜찮고, 또 configure 스크립트가 거의 표준이기때문에 쉽게 떨쳐 내지는 못하겠지만...

멀티플랫폼/개발환경 Development