저는 개미 + cpptasks으로 구축 된 커다란 C++ 시스템에서 일하고 있습니다. 잘 작동하지만 build.xml 파일은 다른 라이브러리/실행 가능 타겟을 추가하기위한 표준 운영 절차로 인해 이미 다른 lib/exe의 규칙 (이미 상당히 크기가 많음)으로 인해 손을 떼게됩니다. 이것이 "적절한 코드"라면 리팩토링에 대한 비명을 지르지 만 개미 노릇을하는 사람 (VisualStudio 솔루션을 만드는 데 많이 사용됨)이 무엇인지 모릅니다.ant build.xml 파일을 어떻게 "리팩터링"합니까?
개미 빌드 파일을 폭발시키는 ant 사용자의 모범 사례는 무엇입니까?
하나의 분명한 옵션은 XSLT를 통해 build.xml을 생성하여 일반적으로 반복되는 패턴에 대해 자체 태그를 정의하는 것입니다. 누구든지 그렇게합니까, 아니면 더 좋은 방법이 있습니까?
규칙이 반복적이면 매크로 정의를 사용하여 ant 매크로로 인수를 정하고 해당 매크로를 재사용 할 수 있습니다.
관리하기 어려운 파일의 크기가 작 으면 더 작은 파일로 나누고 해당 파일 내에서 기본 build.xml 호출 대상을 가질 수 있습니다.
이 둘 모두가 아닌 경우 빌드 시스템을 사용하는 것이 좋습니다. Maven을 직접 사용하지는 않았지만 크고 관리하기 어려운 빌드 파일의 많은 문제를 해결할 수 있다고 들었습니다.
나는 Ant-Ivy-the agile dependency manager을 시도 할 것입니다. 우리는 최근에 좀 더 복잡한 시스템을 위해이를 사용하기 시작했으며 매력처럼 작동합니다. 여기서 이점은 당신이 maven에 오버 헤드와 전환 비용을주지 않는다는 것입니다 (이것은 ant 타겟을 사용하므로 현재 설정과 함께 작동합니다). Here is a comparison 두 개 사이.
일반적으로 빌드 파일이 크고 복잡하면 폴더 및 패키지 측면에서 코드를 레이아웃하는 방식이 복잡하고 복잡하다는 것을 분명히 나타냅니다. 나는 복잡한 앤트 스크립트가 잘못 배치 된 코드 기반의 명백한 냄새라는 것을 알았다.
이 문제를 해결하려면 코드 레이아웃 방법을 고려하십시오. 얼마나 많은 프로젝트가 있습니까? 이 프로젝트는 개별 프로젝트/앱/구성 요소를 더 큰 전체로 묶는 방법을 알고있는 마스터 빌드 스크립트로 스스로를 빌드하는 방법을 알고 있습니다.
코드를 리팩토링 할 때, 한 가지를 수행하는 작은 메소드, 작은 클래스, 메소드 및 클래스 - 이해하기 쉽도록 메소드를 분해하거나 분해합니다. 이 같은 원칙을 코드 기반에도 적용해야합니다.
기능적으로 응집력이 있고 나머지 코드와 매우 느슨하게 분리 된 더 작은 구성 요소를 만듭니다. 빌드 스크립트를 사용하여 해당 구성 요소를 라이브러리로 빌드하십시오. 이 작업을 나머지 코드와 함께하십시오. 이제 모든 라이브러리를 묶어 응용 프로그램에 빌드하는 방법을 알고있는 마스터 빌드 스크립트를 작성하십시오. 여러 개의 응용 프로그램이있는 경우 각 응용 프로그램에 대한 빌드 스크립트와 응용 프로그램을 배포 가능 패키지로 묶는 방법을 알고있는 마스터 스크립트를 만듭니다.
빌드 스크립트를 보면 코드베이스의 레이아웃과 구조를보고 이해할 수 있어야합니다. 그것들이 깨끗하고 이해할 수 없다면 당신의 소스 코드도 마찬가지입니다.
Antlib 파일을 사용하십시오. 그것은 당신이 내가 해요 build script의 일부에서 좀 걸릴 수 있습니다 당신은 예를보고 싶다면
을 정의
antlib는 매우 재사용 가능한 라이브러리입니다. +1 – dfa
링크가 더 이상 작동하지 않습니다. 고정 링크 : http://ant.apache.org/manual/Tasks/macrodef.html 및 http://ant.apache.org/manual/Tasks/import.html 및 http://ant.apache.org/manual /Tasks/subant.html –
끊어진 링크가 수정되었습니다. –