2009-09-15 3 views
2

내 개발을위한 런타임 환경을 정의해야합니다. 물론 첫 번째 아이디어는 바퀴를 재발 명하지 않는 것입니다. easyport를 사용하여 macports를 다운로드하고 fink를 시도했습니다. 나는 항상 문제가 있었다. 예를 들어 MacPorts 설치 프로그램이 gcc43을 다운로드하고 설치하려고하기 때문에 scipy를 컴파일 할 수 없지만 Snow Leopard에서는 컴파일되지 않습니다. 이 문제점에 대한 버그가 공개되어 있지만 기본적으로 런타임에 사용할 수 있도록 묶여 있습니다.런타임 환경 정의

내가 얼마 전에 배운 기술은 명확하게 지정된 버전의 라이브러리와 유틸리티를 사용하여 런타임/libs를 다운로드하고 빌드하는 makefile을 작성하는 것이 었습니다. 이것은 MacPorts/fink/apt 접근법에 비해 훨씬 앞서지 만 모든 것을 수동으로해야 할지라도 훨씬 더 많은 것을 제어 할 수 있습니다. 물론 이것은 런타임이 커지면 악몽이 될 수 있지만 문제가 발견되면 patch을 사용하여 다운로드 한 패키지의 문제를 해결 한 다음 빌드하십시오.

내가 여러 질문이 :

  • 개발을 위해 잘 정의 된 런타임/라이브러리 모음을 준비하는 당신의 방법은 무엇입니까?
  • MacPorts/fink/무엇이 잘못되어도 다시 해킹 할 수있는 유연성이 있습니까?
  • 내 makefile 솔루션을 고려할 때 내 소프트웨어가 마침내 다운로드 될 때 내 개발 환경과 사용자 컴퓨터의 실제 플랫폼 사이에 발생할 수있는 문제를 해결하기위한 제안은 무엇입니까?

편집 : 다른 프로젝트에서 나에게 힌트를주지 않는다는 것이 분명합니다. 예를 들어 방금 scipy를 다운로드했습니다. scipy는 많은 의존성이있는 복잡한 라이브러리입니다. 개발자는 작업하기 전에 모든 deps 설정을해야합니다. 그럼에도 불구하고 svn에는이 환경을 만드는 것이 없습니다.

편집 : 질문에 현상금을 추가했습니다. 나는 이것이 중요한 이슈라고 생각하며 더 많은 답변을 얻을 가치가있다. 나는 발생 된 문제와 해결책에 특히주의를 기울여 실제 사례를 통해 이러한 답을 가장 잘 고려할 것입니다. 바운티에 대한 영감을

추가 질문 :

  • 사용자 환경에서 테스트를 수행 마십시오 (예를 들어, 통합 시스템에 적절한 설치를 확인하기 위해)?
  • 출하시 환경을 어떻게 포함합니까? C 언어의 경우 정적으로 링크하거나 동적 라이브러리를 제공하고 실행 파일을 실행하기 전에 LD_LIBRARY_PATH를 수정해야합니까? 파이썬, 펄, 기타 같은 문제는 어떻습니까?
  • 런타임을 준수합니까, 아니면 시간이 지남에 따라 업데이트합니까? 의존성 라이브러리 또는 고정 버전의 "트렁크"패키지를 다운로드합니까?
  • 다음과 같은 상황을 어떻게 처리해야합니까? 라이브러리 foo는 파이썬 2.5가 필요하지만 파이썬 2.5에서는 라이브러리 막대가 작동하지 않으므로 파이썬 2.4에서 개발해야합니까?
+1

다음은 "런타임"을 사용하여 "링크 가능한 라이브러리 및 OS 서비스 집합"을 얼마나 싫어 하는지를 표현할 수 없습니다. 이 가증 한 것은 언제부터 온거야? 누가 * * 비난 할 수 있습니까? – dmckee

+0

일부 답변은 여기에서 찾을 수 있습니다. http://en.wikipedia.org/wiki/Run-time_system –

+0

나는 그것을 보았지만 첫 사용 날짜도 아니고 내 vitriol의 목표도 제공하지 않습니다. 이 문맥에서는 도움이되지 않습니다. – dmckee

답변

1

우리는 모든 종속성을 다운로드 (주로 SVN을 통해)/구성/빌드하는 Makefile을 생성하는 CMake 스크립트를 사용합니다. 왜 CMake? 멀티 플랫폼. 이것은 꽤 잘 작동하며 우리는 scons/autopain/cmake의 호출을 지원합니다. 우리가 여러 플랫폼 (Windows, MacOSX, 많은 리눅스 변종들)을 기반으로 할 때 우리는 또한 운영 체제에 따라 다른 컴파일 플래그 등을 지원합니다.일반적으로 라이브러리에는 기본 구성이 있으며 특별한 구성이 필요한 시스템이 있으면 구성이 특수 구성으로 바뀝니다. 이것은 꽤 잘 작동합니다. 우리는 우리의 목적에 맞는 준비된 솔루션을 찾지 못했습니다.

즉, 여러 운영 체제를 지원해야하는 경우 많은 노브가 필요합니다. 종속성이 상당히 고정되어있어 라이브러리가 정기적으로 업그레이드되지만 유지 보수가 악몽이 될 것이라고는 생각하지 않습니다. 그러나 새 라이브러리는 거의 도입하지 않습니다.

+0

기본적으로 개인화 된 다운로드/빌드 스크립트 방식을 사용합니다. –

+1

Yupp =) 그러나 Makefile을 직접 사용하는 대신 Makefile 또는 NMake Makfile을 생성하는 CMake를 사용합니다. 우리는 이것이 Makefiles를 직접 사용하는 것보다 더 많은 유연성과 두통을 덜어 주었다고 생각합니다. – larsmoa

+0

소프트웨어 산업에 널리 퍼져있는 문제에 대해 간소화 된 것은 이상하지 않은 것처럼 보입니다. –

1

virtualenv은 좋지만 마술을 할 수는 없습니다. Python 2.4 이 있어야하는 라이브러리를 사용하고 싶다면, 대신 2.5가 필요합니다. 또한 새로운 릴리스의 OS가 있고 반 도구 인 & c가 아직 지원하지 않으면 Virtualenv (또는 다른 도구)도 도움이됩니다. Snow Leopard에 언급했듯이 몇 가지 문제는 해결할 수 없습니다 (두 개의 라이브러리 동일한 빌드 내에서 절대적으로 충돌하는 요구 사항이있는) 다른 사용자는 인내심을 필요로합니다 (필요한 모든 도구가 새 OS 릴리스로 이식 될 때까지 이전 OS 릴리스 만 유지하면됩니다).