Boost Jam은 무엇이며 마이그레이션 할 가치가있는 Jam입니까?

Question

Boost Jam이란 무엇이며 마이그레이션 할 가치가있는 Jam입니까?

나는 잼이 perforce에 의해 만들어진 빌드 시스템이지만 이해가 어떻게 부스트 잼 & 정기적 인 잼이 다른지 잘 모르겠다.

SO 커뮤니티에 근무한 사람이 있었으면 좋겠다. 그리고 차이점이나 이점을 강조 할 수도있다.

Answer 1

제 목적을 위해, 그것은 당신을 위해 부스트 라이브러리를 구축하는 것입니다. 당신이 그걸로 무엇을 할 수 있다는 것을 몰랐기 때문에, 당신이 마이그레이션 할 수 있다는 것을 이해하지 못했습니다. 미안하지만 정기적 인 잼이 무엇인지 알지 못합니다. 아무도 대답을 제공하지 않았기 때문에 나는 그것에 대한 나의 이해를 제공 할 것이다.

Boost는 C++ 용 클래스 및 함수 모음으로 다양한 작업에 유용합니다. boost의 클래스와 함수는 라이브러리로 그룹화됩니다. 라이브러리 중 일부는 #include 전 처리기 명령문을 사용하여 간단히 사용할 수있는 헤더 파일에 모든 코드를 포함하지만 다른 일부 (파일 시스템이나 정규 표현식 라이브러리 등)는 .cpp 파일에 구현 된 부분을 포함합니다.

이러한 .cpp 파일을 컴파일하는 데 시간이 오래 걸릴 수 있습니다 (컴파일하는 대상에 따라 30 분 정도 걸릴 수 있음). 프로그램을 다시 컴파일 할 때마다 30 분이 걸리면 큰 어려움이 따릅니다. 그래서 그들이 한 일은 .cpp 파일에 부분적으로 저장되어있는 라이브러리에만 해당합니다. 라이브러리 파일을 .lib 파일로 사전 컴파일 할 수 있습니다. 이것이 바로 부스트 잼의 목적입니다. 즉, 반 시간을 들여서 을 번 작성하면 30 분을 다시 기다릴 필요가 없습니다.

그러나 각 부스트 라이브러리는 많은 cpp 파일과 많은 헤더 파일로 구성되어 있으며 각각의 다양한 버전 (디버그 버전, 릴리스 버전, 멀티 스레드 등)이 있으므로 그렇게 할 수 없습니다. 부스트 라이브러리를 직접 컴파일하는 간단한 프로세스. 이것이 바로 부스트 잼이 일어나는 곳입니다. 여러분은 라이브러리를 컴파일하라는 명령을 내리고 컴파일러에게 모든 명령을 내 보내며, 결국에는 미리 컴파일 된 .lib 파일 모음을 갖게 될 것입니다. 각 도서관의 각기 다른 맛. 헤더 파일은 링커에게 어떤 lib 파일이 포함되는지 알려주므로 올바른 경로 설정이되어 있으면 미리 컴파일 된 .lib 파일의 올바른 형식이 자동으로 프로그램에 연결되어 30 분의 컴파일 시간을 절약 할 수 있습니다.

부스트 잼에 의해 컴파일되어야하는 라이브러리와이 페이지를보고 어떤 라이브러리가 보이지 않는지 알 수 있습니다 : http://www.boost.org/doc/libs/1_37_0 - 라이브러리에 lib 파일이 필요하지 않으므로 부스트를 망칠 필요가없는 경우 jam first), "Build & Link : Header only"라고 말하지만, 라이브러리가 lib 파일을 미리 컴파일해야한다면 "Build & Link : Automatic linking"이라고 표시됩니다.

또한 Windows의 경우 미리 컴파일 된 .lib 파일을 다운로드 할 수 있으므로 부스트 잼을 사용할 필요가 없습니다. 이를 얻으려면 www.boost.org 페이지로 이동하여 시작하기 섹션으로 가서 모든 것을 올바르게 설정했는지 확인하십시오. 해당 페이지의 Windows 버전에있는 링크 중 하나는 미리 컴파일 된 .lib 파일의 위치를 ​​알려줍니다.

Answer 2

진술 한대로 Boost Jam은 빌드 시스템이며 다른 모든 부스트 라이브러리와 독립적으로 사용할 수 있습니다. Perforce Jam에 대해서는 전혀 몰라요.하지만 제 생각에 Boost jam은 매우 유사하고 대부분 호환됩니다.

가장 큰 차이점은 부스트 ​​잼은 종종 Boost Build과 함께 제공된다는 점입니다.라이브러리 컴파일, 유닛 테스트 실행, doxygen 문서 작성 등

다른 빌드 시스템과 비교하여 Boost Jam/Boost Build는 다양한 변형을 손쉽게 컴파일 할 수 있도록 설계되었습니다. 따라서 컴파일 설정을 디버그에서 릴리스 또는 단일 또는 다중 스레드로 변경하려는 경우 변경 사항을 자동으로 결정합니다.

단점은 구문이 매우 까다롭기 때문에 부스트 웹 사이트 외부에 좋은 설명서가 없다는 것입니다. 그러나 Perforce Jam이 그 점에서 나쁘다고 생각합니다.

Answer 3

빌드 도구를 선택했다면 잼으로 마이그레이션하지 않을 것입니다. 더 나은 빌드 시스템이 있습니다. C/C++ 용 CMake/SCons, Qt 용 qmake, Java 용 Ant, NAnt 및 .NET 용 MSBuild 등입니다. 그들은 기술적으로 우월하지는 않지만 훨씬 더 많은 사람들이 익숙하기 때문에 사용하기가 덜 어려울 것입니다 (다른 한편으로 그들은 기술적으로 우월합니다 : D).

Answer 4

크로스 플랫폼 C++ 개발에 Boost Jam을 사용합니다.

• 내가 내 코드가 사방 부스트 빌드를 구축하려는 때문에
• 는이 목표를 구축하는 방법을 지정하는 비교적 간단한 선언적 언어를 사용, 그것을 선택했고,
는
• 그것은 모든 다른 맛을 구축 할 수 있습니다 바이너리 (예 : 디버그 vs 릴리스, 32 비트 vs 64 비트, msvc v gcc)는 빌드 선언에 flavor 관련 예외가 절대적으로없는 단일 호출에서 사용됩니다.

각 플레이버 순열에 대해 별도의 규칙을 쓰는 대신 제 품별 설정으로 일반 규칙을 수정할 수 있습니다. 구문은 정확히 내가 선택한 것이 아니지만 익숙해지기가 너무 어렵지 않습니다. http://syrcose.ispras.ru/2009/files/04_paper.pdf

나의 이해는 잼이 부스트 커뮤니티에 의해 유지 억지로 잼의 파생물입니다 부스트, 그리고 억지로 잼 적극적으로 유지 관리되지 않습니다 :

이 논문은 CMake, SCons는, 이클립스 CDT에 잼을 밀어 비교 더 이상 (release notes에는 2003 년 4 월에 마지막 업데이트가 있습니다).

물론 플랫폼 간 개발에 신경 쓰지 않는다면 여기에 언급 된 다른 방법처럼 쉽게 이동할 수있는 방법이 있습니다. 개인적으로, 나는 이클립스 CDT를 다시 읽는 것을 의미한다. 5 년 전만해도 쓸모 없어 보였지만 오래 가지 못했다고 들었습니다.