C 및 C ++ 용 패키지 관리 시스템이없는 이유는 무엇입니까? [닫은]

78

패키지 관리 시스템에는 몇 가지 프로그래밍 언어가 있습니다.

그러한 시스템에 다른 언어가 있습니까? C와 C ++는 어떻습니까? (주요 질문입니다!) 왜 그러한 시스템이 없는가? 그리고위한 패키지 생성되지 않는 yum, apt-get또는 다른 일반 패키지 관리 시스템 개선을?

c++  c  builds  packages 
— m0nhawk
소스
3
Objective-C에는 Cocoapod가 있습니다 (루비 보석 및 번 들러와 매우 유사). C ++에 비슷한 것이 없다는 것이 이상합니다. 아마도 C ++은 덜 동종이기 때문입니다. Apple은 패키지를 빌드 할 때보다 표준적인 것을 제공합니다. C ++에서는 사용할 문자열 클래스에 거의 동의 할 수 없습니다.
— Erik Engheim 2016 년
다른 언어의 패키지 관리자가 완벽하지 않다는 것을 지적하고 싶습니다. 예를 들어, Ruby Gems에서는 특정 OS (Windows보다 가능성이 높음)에서 작동하지 않는 보석이 종종 발견 될 수 있으며 설명서에는 해당 OS에서 작동하지 않는다고 알려주지 않습니다.
— 트래비스 페 셋토
— Ciro Santilli 新疆 改造 中心 法轮功 六四 事件

답변:

28

실제로 ( 명예로운 부스트 명성을 가진) 일부 사람들은 Ryppl 이라는 그러한 시스템을 만들고 구축하기 위해 열심히 노력하고 있습니다 . 이를 지시 할 수있는 단일 플레이어가 없으므로 C ++ 용 시스템을 설정하기가 어렵습니다. --UPDATE : 불행히도 그것은 버려졌습니다.

두 번째 질문에서, 일반 패키지 관리자 (크로스 플랫폼이 아닌 것)는 개발자의 특정 요구를 처리하지 않습니다.

— 파비오 프라 카시
소스
2
와우, 나는 그들이 20 년 동안 "패키지 관리자가 필요 없다!"
— TheLQ
8
글쎄, 그들은 부스트 ​​명성을 가지고 있으며, 나는 그들에게 의심의 혜택을보고 엿볼 것입니다. 부스트, 결국 놀랍습니다 :)
— Onno
2
@ TheLQ-아무도 이전에 실행 가능한 솔루션을 제시하지 않은 것 외에는 싸울 것이 없다고 생각합니다. '패키지 관리자를 악취 할 필요가 없습니다'는 없습니다. '아무도 유용한 것으로 보이는 사람은 아무도 없습니다'. 전자는 해결하기 어려울 수 있지만 후자는 간단합니다. 실제로 개발자가 업무를 수행하는 데 도움이되는 것을 제시하십시오.
— Michael Kohne
1
이 답변은 업데이트되어야합니다 : 1) Ryppl은 죽은 프로젝트이며 웹 사이트는 죽었습니다. 2) cpm과 같은 다른 프로젝트 (상업용이든 아니든)는 최근에 생성되었으므로 C ++의 패키지 관리자를 얻는 데 많은 작업이 수행되고 있습니다. 3) 모듈이 언어에 있고 도구 중 하나가 그것을 최대한 활용하기까지는 승자가 없을 것이라고 믿습니다.
— Klaim
2
@Klaim re : {모듈이 언어로 작성 될 때까지} 모듈이 일을 더 쉽게 만들지 않는다는 것을 이해하는 한, #include명령 의 구문 설탕 일뿐 입니다. 버전 관리 / 다운로드 / 설치 / 호환성 / 플랫폼 간 C ++ 문제의 주요 문제는 해결되지 않습니다.
— ruslo
17

C와 C ++의 문제점은 이기종 언어라는 것입니다. 이러한 언어가 표준화되었지만 다른 옵션이나 지원되는 기능 세트를 가진 다른 컴파일러가 있습니다. 예를 들어 GCC / Linux에서 완벽하게 작동하는 예제를 사용하여 스택 오버플로에 C ++에 대한 질문을 게시 한 사람이 있고 내 코드가 비표준이라는 답변을 즉시 게시했습니다.

질문에 언급 된 것과 같은 패키지 시스템이 있으면 모든 공통 운영 체제의 모든 주요 컴파일러가 균일하게 지원하는 공통 언어 및 라이브러리가 있음을 의미합니다. 예를 들어, C ++ 패키지를 다운로드하고 다른 운영 체제의 컴파일러 Y에서 개발 되었기 때문에 사용중인 컴파일러 X 버전에서 컴파일되지 않는다는 것을 발견하고 싶지 않습니다.

Linux 및 cygwin 및 기타 Unix 버전에서 일반적으로 사용되는 make 및 configure 스크립트 기반 시스템이 작동 할 수 있다고 생각할 수 있습니다. 그러나 왜 Visual Studio 사용자가이를 채택해야합니까? Microsoft 컴파일러 (및 라이브러리)를 기반으로 패키지 시스템을 시작한 경우에도 마찬가지입니다.

C ++은 빠르게 발전하는 언어이며 표준이 모든 컴파일러에서 완전히 지원되기 전에 항상 시간이 걸리기 때문에 문제가 완화되지는 않습니다.

— 조르지오
소스
포터블 C ++를 작성하거나 특정 툴체인에 작성할 수 있습니다. 후자에게 이점이 없을 때 전자를하지 않는 것이 다소 차선책이지만 귀하의 선택과 잘못은 없습니다.
— 중복 제거기
2
이식 가능한 C 및 C ++가 있습니다. 설치 관리자가 라이브러리를 독립형 방식으로 쉽게 설치할 수없는 경우 다시 만들어야합니다. 이것을 달성하는 것은 완벽하게 가능합니다. NodeJS에서도 많은 모듈이 Windows에서 빌드되지 않지만 여전히 존재하므로 관리 문제가 발생하지 않으며 중앙 집중식 패키지 관리자가 사용자의 피드백을 간소화하고 문제를 처리하는 데 더 많은 인센티브를 제공합니다.
— Dmitry
4

귀하의 질문에 답변하기 위해 우리가 요구해야 할 질문은 "다른 언어 / 생태계가 자체 중앙 집중식 패키지 저장소를 보유함으로써 얻는 이점은 무엇입니까?" "C / C ++에 적용됩니까?"

첫 번째 질문에 대한 답은 새로운 언어의 초기 홍보와 관련이 있다고 생각합니다. 얼리 어답터는 초보자가 생태계에 들어가고 유용하고 테스트 된 코드를 획득하고 스스로 기여할 수 있도록 가능한 한 쉽게 만들고 싶어합니다. 명백한 이유로, "사용 그래프"에는 항상 언어의 작성자 인 단일 루트가 있습니다. 일반적으로 하나의 참조 구현이 있으며 (최소한 초기에) 공유하려는 코드는이를 준수해야합니다.

따라서 다운로드 및 컴파일 만하는 패키지를 쉽게 만들 수 있습니다. 확실히, 2013 년에 C 또는 C ++가 도입 된 이후, 그들의 커뮤니티는 비슷한 진화 경로를 따를 수 있었지만 패키지 관리자를 적용 할 단일 툴킷은 없었습니다. 이것은 그러한 프로그램의 구현이 번거롭지 않을 정도로 번거 롭다. (사용자가 libfoo-gcc와 libfoo-vs 중에서 선택하도록해야합니까? 해결하기 위해 패키저에 맡기시겠습니까? 아니면 빌드 프로세스입니까? 그렇다면 패키지가 직선 타르볼과 어떻게 다른가요?)

첫 번째 질문에 대한 대답을 요약하면 패키지 관리자를 만드는 패턴이 대부분 채택 을 유도하는 데 도움이된다고 생각합니다 .

이를 염두에두고 C와 C ++ 프로그래머에게는 그 필요성이 존재하지 않기 때문에 단일 시스템이 왜이 요구를 충족시키지 못했는지를 쉽게 알 수 있다고 생각합니다. C 및 C ++ 커뮤니티 (또는 실제로는 프로그래머 커뮤니티)에게 문제가되는 것은 원래 배포, 최신 상태 유지 및 백 코드 제공에 대한 내재 된 필요성입니다. 이것은 다양한 성공률을 가진 다른 사람들에 의해 여러 번 해결되었으며 실제로 하나의 시스템은 git (및 그 이전의 다른 시스템)에서 상당한 시장 점유율을 얻고 있습니다.

기본적으로 문제가 다르면 솔루션도 다르게 보이지만 타이핑 gem install과 차이 git clone는 없습니다.

— 아이 도비
소스
2
"다른 언어 / 생태계는 자체 중앙화 된 패키지 저장소를 통해 얻을 수있는 이점은 무엇입니까?" 패키지를 다운로드하고 소프트웨어와 제대로 작동하려면 신뢰할 수있는 매우 숙련 된 개발자 여야합니다. 패키지 관리자를 사용하면 상황에 맞는 빌드 지침을 처리하는 대신 패키지 사용을 시작할 수 있습니다. 나는 MinGW에서 일하기 위해 부스트를 얻는 방법을 알아낼 수 없기 때문에 그것을 사용하는 대신 기능의 많은 부분을 반복해서 쓰게됩니다. 없어서는 안됩니다.
— Dmitry
1
다양한 설치 / 빌드 스크립트 및 플래그와 싸울 필요가 없습니다.
— themihai
3

이 질문에는 약간의 혼란이 있습니다. 위에서 언급 한 소프트웨어는 특정 프로그래밍 언어의 확장을 관리합니다. 이들은 나중에 원하는 프로그래밍 언어로 프로그램에서 사용할 수있는 라이브러리와 소스 코드를 제공합니다.

일반적인 시스템 수준 패키지 관리자는 일반적으로 응용 프로그램에 관계없이 사용할 수있는 이진 패키지를 제공합니다. 그들은 시스템과 사용자에 더 중점을 둡니다. 물론 Aptitude, rpm, Entropy와 같은 시스템 레벨 패키지 관리 시스템은 바이너리 또는 소스 코드 인 모든 패키지를 제공 할 수 있습니다 . 그래서 당신은 그들과 함께 설치할 대부분의 확장을 찾을 수 있습니다 ... 예를 들어 보석 .

Yum 과 Apt-get 또는 Rigo 라고 언급 한 것은 패키지 관리 시스템을위한 사용자 인터페이스 일뿐입니다.

프로그래밍 언어 목록에 하나 더 :

  • PHP를위한 작곡가와 배
— 파트 코스 차바
소스
그래요 마지막 세 가지 질문을 쓸 때 내가 생각한 것은 무엇입니까?
— m0nhawk
문제는 이러한 패키지가 로컬이 아닌 전 세계적으로 제공되므로 프로젝트의 종속성을 단일 폴더로 묶는 것이 매우 어렵다는 것입니다. 즉, 프로젝트가 시스템에서 작동 할 수 있지만 다른 시스템에 프로젝트를 배치하자마자 그 프로젝트가 의존하는 것을 기억하고 모든 것을 가져와 프로젝트가 예상하는 정확한 위치에 배치해야합니다. 이 과정은 지옥입니다. 이에 대한 예로는 GTK, 전역 설치가 쉽고 로컬 설치가 어렵습니다.
— Dmitry
0

나는 이것이 크로스 플랫폼 솔루션이 아니라는 것을 알고 있지만 믹스에 추가해야합니다.

CoApp은 최근 NuGet을 사용하여 C ++ 패키지 관리 지원을 발표했습니다. http://blog.nuget.org/20130426/native-support.html

이것은 현재 Visual Studio 컴파일러에서만 작동하지만 다른 플랫폼에서 작동하도록 많은 요청이있었습니다.

— 조
소스
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.