2012-04-28 4 views
2

gummi (http : //dev.midnightcoding)와 autogen.sh (http://buildconf.brlcad.org/)를 사용하려고합니다. .org/projects/gummi), 예를 들어 configure.ac를 변경할 때, 나의 패치는 설정 변경을 포함 할 필요가 없다. 나는 젤리 소스의 최신 버전을 다운로드 한 경우, PO/Makefile.in.in를 제거 autogen.sh에 드롭하고 실행, autogen.sh는autogen.sh는 po/Makefile.in.in을 생성하지 않습니다.

Preparing the Gummi build system...please wait 

Found GNU Autoconf version 2.68 
Found GNU Automake version 1.11.1 
Found GNU Libtool version 2.4 

Automatically preparing build ... done 

The Gummi build system is now prepared. To build here, run: 
    ./configure 
    make 

성공적으로 완료되지만 포/Makefile을 생성하지 않습니다 .in.in. 그러나 intltoolize를 실행하면 po/Makefile.in.in이 생성됩니다. autogen.sh의 출처를 살펴보면 때때로 intltoolize를 실행하는 것으로 나타납니다. 이것은 autogen.sh의 버그입니까? 어떤 방법으로 configure.ac (또는 다른 파일)에서 autogen에 intltoolize를 실행하도록 지시해야합니까? intltoolize로 생성 된 파일이 모든 배포판에 포함되어 있습니까?

+0

일반적으로 구성과 같이 생성 된 파일의 변경 사항을 포함하는 패치를 피하는 가장 좋은 방법은 버전 제어를 유지하지 않는 것입니다. –

답변

4

예, autogen.sh는 패키지가 intltool을 사용하는 경우 intltoolize를 실행해야합니다. 그렇지 않으면 버그입니다.

그런데, 당신이 사용하고있는 스크립트가 "autogen.sh"라고 부르지 만 실제로 autogen.sh는 유일하지 않습니다. 이것은 부트 스트랩 스크립트의 일반적인 이름입니다. 필자는 각 프로젝트마다 고유 한 것을 쓰는 것을 선호합니다. 그것은이처럼 간단 할 수있다 :

#!/bin/bash 
autoreconf --force --install || exit 1 
intltoolize --force || exit 1 

그러나 intltoolize 실행 여부를 감지 멋진 autogen.sh이 있다면, 그것은 아마 configure.ac에서 IT_PROG_INTLTOOL의 호출이 있는지 여부를 감지합니다. 나는 이것이 일어난 것을 보았다. 그러나 나는 너의 생각을하지 않는다. 나는 Sourceforge here에 관한 최신 개정판을보고 있는데, 그 곳 어디에서나 "intltool"문자열을 찾을 수 없다. autogen.sh가 intltool과 호환되지 않는다고 말하고 싶습니다. 한마디로

:

  • 각 프로젝트는 자신의 autogen.sh을 포함해야한다. (빌드 시스템을 준비하는 데 필요한 유일한 명령이 autoreconf가 아니라면.) Gummi는 버그가 아니기 때문에 버그입니다.
  • 보편적 인 autogen.sh와 같은 것이 없습니다. 기존 패키지를 가져 와서 복사하거나 적용 할 수 있지만 소스 패키지에 따라 어떤 단계를 수행해야하는지에 달려 있습니다.