2013-10-10 3 views
2

저는 벤더가 제공 한 라이브러리를 사용하는 C 임베디드 펌웨어 프로젝트를 진행 중입니다. 예를 들어, TCP/IP 스택 라이브러리. 공급 업체는 이러한 라이브러리를 정기적으로 업데이트합니다. 그러나 우리는 특정 응용 프로그램을 위해 라이브러리에 많은 추가 및 사용자 지정을 수행했습니다.공급 업체 라이브러리 업데이트를 용이하게하는 방식으로 공급 업체 내장 라이브러리 수정?

일부 경우 이전 설계자가 라이브러리 원본 파일을 가져 와서 수정 한 다음 이름을 바꾸고 원본의 다른 폴더로 이동했습니다. 이는 파일을 추적하고 공급 업체 라이브러리 업데이트를 적용하기가 더 어려워 지므로 문제가되는 것 같습니다.

이 시나리오의 모범 사례는 무엇입니까? 즉, 원래 라이브러리 소스 파일에서 사용자 화를 분리 할 수 ​​있습니까? 그리고 이것에 대한 성공적인 접근 방법은 무엇입니까?

+0

나는 라이브러리를 라이브러리로 유지하는 경향이 있습니다. 공급 업체의 소스를 별도로 컴파일 한 다음 코드에서 링크하십시오. 이 경우에 라이브러리를 수정해야하는 경우가 아니라면 패치 대기열 또는 이와 유사한 (작업을 훨씬 어렵게 만들기) 코드를 별도의 라이브러리로 유지하는 것이 좋습니다. – nonsensickle

+0

[patch] (http://linux.die.net/man/1/patch)에 대한 아이디어는 RPM과 다른 사람들이 * pristine * 소스와 작은 변경 사항을 처리하는 데 사용됩니다. 패치의 아이디어는 RPM에 내장되어 있습니다. 이는 패치의 범위와 항상 균형을 유지합니다. 또 다른 방법은 패치를 공급 업체에 제공하여 통합 할 수 있도록하는 것입니다. –

답변

1

프로젝트에서 라이브러리 파일을 별도로 사용해야합니다. 나는 업데이트를 관리 버전 관리 (의욕, 힘내 또는 유사)를 사용하는 것이 좋습니다 :

  1. 만들기의 repo 및 (지점 ) 원래 공급 업체 libs와 커밋.
  2. 변경 사항을 가지고 지점 B (B 에서 시작)에 커밋.
  3. 라이브러리를 추가로 수정 한 경우 지점 에서 소스를 편집하고 변경 사항을 적용하십시오.
  4. 공급 업체 업데이트를하게되면, 그들 을 분기하는 커밋 한 다음 B의 머리에 의 머리를 병합합니다.
  5. 준비가되면 지점 의 최신 파일을 기본 프로젝트에 복사하거나 기본 프로젝트에 연결할 수있는 라이브러리로 컴파일하십시오. ,

    • A1
    • A2 업데이트 된 업체 LIB
    • B1이다 원래 공급 업체의 lib 디렉토리 :

      A1 ------- A2 
          \   \ 
          B1 - B2 -- B3 - B4 
      

      :

다음 당신의 역사는 다음과 같이 보일 수 있습니다 B2B4은 내 채널입니다. anges

  • B3은 공급 업체 변경 사항이 변경 사항과 병합되는 곳입니다.