빌드 도구가 기본 프로그래밍 언어와 다른 스크립팅 언어를 사용하는 이유는 무엇입니까?

최근에 대부분의 언어의 기본 빌드 도구 / 시스템이 기본 프로그래밍 언어 자체와 다른 언어를 사용한다는 것을 깨달았을 때 직장에서 Nodejs 프로젝트에 일부 빌드 도구를 사용하고 있습니다.

예를 들어, make 는 스크립트를 작성하기 위해 C 또는 C ++를 사용하지 않으며 Ant (또는 Maven)는 스크립트를위한 언어로 Java를 사용하지 않습니다.

Ruby와 같은 최신 언어는 rake 와 같은 빌드 도구에 동일한 언어를 사용합니다 . 그러나 왜 항상 그렇지 않은가? 기본 언어와 다른 언어를 사용하는 빌드 도구를 사용하면 어떤 이점이 있습니까?

어떤 작업을 수행하기 위해 사용할 프로그래밍 언어의 선택은 해당 프로젝트의 다른 작업이 아니라 해당 목표의 특정 기능에 따라 달라집니다.

빌드 도구는 매우 구체적인 작업을 수행하며 기본 프로젝트에 어떤 언어를 사용하든 빌드 도구는 자체 소프트웨어입니다.

메인 프로젝트와 빌드 도구를 연결하는 것은 매우 잘못된 결정일 수 있습니다. 빌드 도구로 필요한 것은 주로 파일과 IO를 빠르게 관리하는 간단한 규칙의 빠른 프로세스입니다.

루비와 같은 언어가 자체 빌드 도구를 구현하는 데 사용하는 경우 모든 것을 동일한 언어로 작성해야한다고 가정하는 것보다 해당 언어의 기능과 더 관련이 있습니다.

C 또는 Java와 같은 언어를 스크립팅 언어로 사용하는 빌드 도구를 작성하는 것은 불가능하지 않습니다. 그러나 빌드 도구는보다 선언적인 스크립팅 언어 를 사용하면 이점이 있습니다. C로 makefile (또는 build.xml 등)을 작성하는 데 따르는 고통과 비판을 상상해보십시오.

빌드 도구는 C가 특히 적합하지 않은 작업 인 DSL 사용의 이점을 제공합니다. C는 빌드 툴 에는 너무 일반적 이며, 오류가 발생하기 쉬운 하위 레벨 세부 사항과도 관련이 있습니다. 예를 들어, 빌드 도구에서 명시 적 메모리 관리에 관심을 갖기를 원하지 않습니다! 따라서 C와 같은 구문을 사용하더라도 스크립팅 도구에서 가비지 수집을 사용하고있을 것입니다.이 시점에서 단순히 전용 DSL을 사용하지 않는 이유는 무엇입니까?

Ruby는 C 또는 Java보다 더 높은 수준의 선언적 언어이기 때문에 Ruby를 사용할 수 있습니다. 또한보십시오 : Gradle, sbt.

실제 예를 들어 봅시다.

약 15 년 전에 저는 C로 작성된 대형 시스템을 Unix에서 Windows로 포팅하는 작업을했습니다. 약 3 백만 줄의 코드였습니다. 규모에 대한 아이디어를 제공하기 위해 일부 유닉스 시스템 (RS6000)에서 컴파일하는 데 24 시간이 걸렸습니다. 창은 약 4 시간 안에 시스템을 컴파일 할 수 있습니다.

(우리는 또한 통역 언어로 2 백만 줄의 코드를 가지고 있었지만 파일 처리를 위해 설계된 적이 없으므로 빌드 시스템에 언어를 사용하지 않기로 결정했습니다. 또한 언어를 구현 한 C 코드를 컴파일하기 위해 빌드 시스템이 필요했습니다. .)

빌드 시스템을 여러 셸 스크립트로 작성하고 파일을 만들 당시에는 Windows로 이식 할 수 없었으므로 자체 빌드 시스템을 작성하기로 결정했습니다.

우리는 C를 사용할 수 있었지만 파이썬을 사용하기로 결정했지만 몇 가지 이유가있었습니다. (우리는 또한 파이썬으로 소스 코드 제어 시스템을 다시 작성했으며, 이는 빌드 시스템과 매우 인터 그레이드되었으므로 체크인 된 모듈의 오브젝트 파일은 개발자가 공유 할 수 있습니다.)

• 우리 코드의 대부분은 파일의 명명 규칙에서 파생 된 몇 가지 간단한 규칙 (모든 플랫폼, Windows, VMS 및 6 버전의 유닉스에 대해 수천 줄의 파이썬 만)으로 빌드 할 수 있습니다.

• RegEx가 다른 플랫폼의 C 시스템간에 표준이 아니었을 때 Python은 RegEx에 내장되었습니다.

• 일부 모듈에는 사용자 지정 빌드 단계가 필요했으며 Python에서 클래스 파일을 동적으로로드 할 수있었습니다. 폴더에 매직 이름을 가진 python 파일을 기반으로 사용자 정의 클래스를 사용하여 모듈 (lib)을 빌드 할 수있었습니다. 이것이 파이썬을 사용하는 가장 큰 이유입니다.

• 우리는 Java를 고려했지만 그 시점에서 모든 플랫폼에서 제공되지는 않았습니다.

(소스 코드 제어 시스템의 UI는 모든 플랫폼에서 휴대 할 수있는 웹 브라우저를 사용했습니다. 인터넷에 연결하기 6 개월 전이었습니다. X25를 통해 브라우저를 다운로드해야했습니다!)

이 질문에 대한 짧은 대답 은 이것이 빌드 도구라는 것입니다 . 일부 소스 파일에서 최종 제품을 빌드하기 위해 다른 도구 사용을 자동화하는 도구입니다. 제품 자체와 동일한 언어로 빌드 스크립트를 작성하는 경우 동일한 방식으로 빌드 도구로 간주되지 않는 언어 별 도구 영역에 속합니다.

이것은 왜 컴파일러가 make와 같은 도구에서 익숙한 빌드 자동화를 제공하지 않는가? 대답은 단순히 make가 존재하기 때문 입니다. "한 가지 일만하고 잘한다"는 유닉스 철학은 이것을 제공하는 것은 컴파일러의 책임이 아니라는 것을 시사합니다. 즉, 개인적으로 make 두통을 겪어 왔으며 인용 부호가없는 "기본"빌드 시스템을 제공하는 컴파일러를 사용하는 데 관심이 있습니다.

이러한 방식으로 설계된 컴파일러의 예 는 C ++ 대체 용 언어 인 Jon Blow (아직 출시되지 않은) Jai를 참조하십시오 . 컴파일러의 토크 및 데모 링크는 여기에서 수집 됩니다 . 이 언어는 컴파일러 내에서 실행되는 바이트 코드로 컴파일하고 바이트 코드에서 액세스 할 수있는 표준 라이브러리 제공 함수 인 바이너리로 컴파일합니다. 언어의 기본 구문 내에서 빌드 자동화와 메타 프로그래밍을 모두 허용합니다.

_{* Microsoft의 Visual Studio를 살펴보면 반대 철학의 예를 볼 수 있습니다. :)}

빌드 도구는 가장 먼저 'gcc', 'ls', 'awk'또는 'git'과 같은 도구입니다. 도구에 입력 (파일 이름, 매개 변수 등)을 입력하면 그에 따라 몇 가지 작업이 수행됩니다.

이러한 모든 도구를 사용하면 작성하고 이해하기에 간단한 방법으로 입력 내용을 전달할 수 있습니다. 빌드 도구의 특정 경우 입력은 프로젝트가 소스 파일에서 완제품으로 이동하는 방법을 설명하는 파일 인 레시피 파일입니다.

레시피가 프로젝트와 사용할 컴파일러가 들어있는 폴더를 전달하는 것만 큼 간단하다면 선언적인 "언어"이면 충분합니다. 더 많은 논리로 레시피가 점점 더 복잡해지면 선언적 언어로 처리하는 것이 번거로워지고 더 일반적인 언어가 사용됩니다.

빌드 레시피를 작성하는 데 사용되는 언어와 제품 코드를 작성하는 데 사용되는 언어가 목적과 요구 사항이 다르기 때문에 서로 관련이 없음이 분명합니다. 빌드 도구가 작성된 언어와 빌드 레시피를 작성해야하는 "언어"사이에는 연결이 없습니다. 항상 작업에 가장 적합한 도구를 사용하십시오!