다른 여러 libs에 우산 "래퍼"역할을하는 C 라이브러리를 작성할 계획입니다. 일부 라이브러리는 GPL이고 일부 라이브러리는 독점적입니다. 또한 일부 라이브러리는 컴파일 할 때 사용할 수 없으므로 configure 중에 autotools가이를 감지하도록 계획합니다. 나는 또한 이러한 약한 의존성에 대한 지원을 구축해야하는지, 그리고 실행 시간에이를 탐지하는지, 특히 독점적 인 libs에 대해서도 궁금합니다. 이유는 다음과 같습니다.독점적 인 libs에 약한 의존성을 가진 GPL 라이브러리를 디자인하는 것이 가장 좋은 방법입니까?
라이브러리는 구체적으로 설명하지 않고 다양한 장치와 통신하기위한 API를 제공하기위한 것이며 일부는 오픈 소스 드라이버가 없습니다. 현재 사용할 수있는 표준 API를 쉽게 사용할 수 없으므로 이러한 장치를 프로그래밍하기가 어렵습니다. 각 공급 업체는 자체 공급 업체를 제공합니다. 사용할 수있는 몇 가지 다른 API가 있지만 그 크기는 모두 큰 것입니다.
- C++ 전용입니다.
- * nix를 고려한 Windows 환경 용으로 설계되었습니다.
- 올바른 위치에 종속성이 없으면 (즉, 적절한 구성/빌드 시스템이 없다면) 빌드하지 못합니다.
- 가장 중요한 점은, 독점적 인 라이브러리에 직접 링크되는 방식으로 설계되어 데비안에 이러한 API를 제공하는 것이 거의 불가능하다는 것을 거의 100 % 확실하게합니다.
따라서 나의 최종 목표는 사람들이 실제로 간단한 apt-get 이러한 장치에 대한 프로그램을 작성할 수 있도록 배포판으로 만드는 지옥에 기회가 매우 간단하고 직선적 C API를 구축하는 것입니다.
제 질문은 라이브러리가 GPL과 호환되고 데비안과 호환되도록 설계하는 것이 가장 좋습니다. 그러나 필요한 경우 독점적 인 라이브러리를 호출 할 수 있습니까?
이상적으로 나는 사용자가이 라이브러리를 사용하여 프로그램을 얻을 수 있고, 예상되는 위치에 공급 업체의 사용자 수준 드라이버가 설치되어있는 한 모든 것이 즉시 작동해야합니다.
내 관심은 두 가지이다 : 그들은 또는하지 않을 수 있기 때문에, 선택, 독점 libs와에
- 가진 종속성을 동적으로 이러한 libs와 링크를 컴파일 할 수없는 라이브러리의 바이너리 배포판을 의미한다 유효한.
- 사용자는 오픈되어 있거나 독점권이없는 장치에 대한 종속성을 설치해서는 안됩니다.
다른 패키지가 독점적 인 libs에 연결하여 런타임 종속성이 약한이 문제를 어떻게 처리합니까? dlopen은 모든 것을위한 올바른 방법입니까? 내가 dlopen 독점 물건 만해야합니까? 데비안이 그러한 패키지를 거부하는 이유 또는 그 이유는 무엇입니까?
마지막으로, 데비안 정책에 관한이 질문에 대한 적절한 포럼이 아닐 수 있습니다. 누구든지이 질문을하기에 더 좋은 곳을 가리킬 수 있습니까?
감사합니다.
감사합니다. 유익한 정보입니다. "주요 프로그램이 GPL 인 경우 독점 플러그인을 연결할 수있는 라이센스 예외가 필요합니다. - 단지 궁금해서이 사실을 더 자세히 설명하는 링크가 있습니까? "트로이의 목마"에 대한 좋은 지적. 정직한 질문 - 내 접근 방식이 근본적으로 결함이 있지만 아무도 실제로는 사용자 경험을 개선하고 GPL의 정신을 고수하는 데 도움이 될 수 있습니까? 또는 내 라이브러리가 사용자 환경 (선택 사항)의 독점적 인 문제를 완화시키는 것으로 볼 수 있습니까? – Steve