유망한 대안을 만들 것인가?[닫은]
https://stackoverflow.com/questions/66800
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
나는 수년 동안 Make and Makefiles를 사용해 왔으며 개념은 건전하지만 구현에는 원하는 것이 있습니다.
문제를 과도하게 복제하지 않는 좋은 대안을 찾은 사람이 있습니까?
해결책
확인해 보세요 SCons.예를 들어 Doom 3과 Blender가 이를 사용합니다.
다른 팁
크로스 플랫폼 개발을 위해 CMake를 지지하는 친구들이 많이 있습니다.
사용되는 빌드 시스템입니다. VTK (무엇보다도) 이는 크로스 플랫폼 Python, Tcl 및 Java 바인딩이 포함된 C++ 라이브러리입니다.나는 이것이 아마도 그렇게 많은 기능을 통해 찾을 수 있는 가장 덜 복잡한 것이라고 생각합니다.
언제든지 표준을 시도해 볼 수 있습니다. 자동 도구.Automake 파일은 Unix에서만 실행하고 C/C++를 고수하는 경우 함께 구성하기가 매우 쉽습니다.통합은 더욱 복잡하며 autotools는 가장 단순한 시스템과는 거리가 멀습니다.
그놈 프로젝트 중 일부가 다음으로 마이그레이션되었습니다. 와프.
Scons와 마찬가지로 Python 기반이지만 독립형이기도 합니다. 따라서 다른 개발자에게 선호하는 빌드 도구를 설치하도록 요구하는 대신 독립형 빌드 스크립트를 프로젝트에 복사하기만 하면 됩니다.
해 파이썬 도구입니다.이는 빌드 도구의 개념을 기반으로 하지만 더 일반적입니다.
- 작업/규칙이 최신 상태인지 정의할 수 있습니다(타임스탬프 확인뿐만 아니라 대상 파일이 필요하지 않음).
- 종속성은 다른 작업에 의해 동적으로 계산될 수 있습니다.
- 작업의 작업은 Python 함수 또는 셸 명령일 수 있습니다.
다음 사항을 숙지하세요. ninja 다음의 영향을 받는 빌드 도구(v1.8.2 2017년 9월) tup 그리고 redo.
빌드 파일 생성기 cmake (예:Unix Makefiles, Visual Studio, XCode, Eclipse CDT 등의 경우 ...)도 생성할 수 있습니다. ninja 버전 2.8.8(2012년 4월) 이후 빌드 파일 및 afaik, ninja 이제는 에서 사용하는 기본 빌드 도구이기도 합니다. cmake.
능가할 것으로 예상된다. make 도구(더 나은 종속성 추적 및 병렬화됨)
cmake 이미 잘 정립된 도구입니다.구성 파일을 수정하지 않고도 나중에 빌드 도구를 언제든지 선택할 수 있습니다.따라서 향후에 더 나은 빌드가 개발되면 cmake 편리하게 전환할 수 있습니다.
c/C++의 경우 전처리기를 통해 헤더가 포함되어 있기 때문에 컴파일 시간이 제한되는 경우가 있습니다(특히 헤더 전용 라이브러리를 사용하는 경우 등). 후원 & 고유) 이는 다음의 제안으로 대체되기를 바랍니다. 모듈 (c++11의 기술 검토에서 또는 최종적으로는 c++1y에서).이것을 확인해보세요 프레젠테이션 이 문제에 대한 자세한 내용은
나는 다음과 같은 도구를 작성했습니다. 동기 makefile과 같은 것을 읽고 쓰기 쉽게 만들려고 노력했습니다.
그것은 당신이 무엇을 하려는지에 달려 있습니다.만약에 모두 당신이 원하는 것은 make 스타일 대상 종속성과 명령 호출입니다. 그러면 Make는 실제로 작업에 더 나은 도구 중 하나입니다.:-) Rake는 매우 훌륭하지만 일부 간단한 경우에는 어색할 수 있습니다.Ant는 물론 장황한 도시이지만 Java와 유사한 언어(Scala 및 Groovy 포함) 구축에 대한 더 나은 지원을 제공합니다.또한 Ant도 사용 가능합니다. 어디에나.그것이 내가 그것을 사용하는 주된 이유입니다.Windows에서 일관되게 작동하기 때문에 실제로 Make보다 훨씬 더 크로스 플랫폼입니다.
Java와 유사한 라이브러리에 대한 종속성 관리를 원한다면 Maven이 표준 선택이지만 개인적으로 Buildr를 훨씬 더 좋아합니다.사용자 정의가 더 빠르고 훨씬 쉽습니다(Rake 기반).불행하게도 아직은 Maven만큼 널리 사용되지는 않습니다.
나는 여러 대안을 고려한 후에도 여전히 make를 선호합니다.컴파일러나 fastdep과 같은 것을 통해 종속성을 자동 생성하면 할 일이 별로 없습니다.특히 나는 내 빌드 스크립트가 구현 언어에 묶이는 것을 원하지 않으며, 더 읽기 쉬운 대안이 있을 때 XML로 내용을 작성하는 것을 좋아하지 않습니다.범용 언어를 노출하는 도구에는 장점이 있지만 또 다른 해석 언어는 그렇지 않습니다. Make에 어떤 문제가 있나요? Make에서 벗어나는 것에 대한 귀하의 관점에 호소할 수 있습니다.
/앨런
Ruby의 make 시스템을 rake라고 합니다. http://rake.rubyforge.org/
꽤 유망 해 보입니다.
항상 Ant가 있습니다. http://ant.apache.org, 개인적으로 끔찍하다고 생각합니다.그러나 이는 Java 개발을 위한 사실상의 표준입니다.
여기서 질문하시는 것이 맞는지 잘 모르겠습니다.
단순화된 제작을 원하시나요?어떤 경우에는 make에 매우 익숙한 사람이 문제를 단순화할 일련의 (M|m)ake 파일을 생성하도록 해야 합니다.
아니면 기본 기술을 살펴보고 싶으신가요?코드 설계에 내장되어 시행되는 계약별 설계 유형 아키텍처를 시행하고 싶습니까?또는 언어 자체일 수도 있습니다.Ada와 그 사양(인터페이스) 및 본문(구현) 개념은 무엇입니까?
당신이 추구하는 방향은 그러한 질문의 잠재적 결과에 확실히 영향을 미칠 것입니까?
기본적으로 실제로 변경된 구성 요소만으로 시스템을 구축하는 새로운 방법과 설계에 이러한 메커니즘이 내장된 새로운 기술을 채택하는 것입니다.
죄송합니다. 직접적인 답변은 아닙니다.단지 당신이 어느 길로 가고 싶은지 평가해 보고 싶었을 뿐입니다.
건배,
롭
RTDA의 FlowTracer는 대규모 환경(수만 개의 작업)에서 상업적으로 사용되는 또 다른 좋은 선택입니다. http://www.rtda.com/flowtracer-design-flow-infrastructure-software
여기에는 작업에 대해 색상으로 구분된 상자와 파일에 대한 타원이 포함된 종속성 그래프를 표시하는 GUI가 있습니다.작업 및 파일 수가 많아지면 FlowTracer와 같은 GUI 기반 도구가 매우 중요합니다.
초기 설정 비용이 Make보다 높습니다.이를 사용하여 첫 번째 흐름을 설정하기 위한 학습 곡선이 있습니다.그 이후에는 더 빨라집니다.
