Free Pascal이 Apache Maven과 같은 이점을 누릴 수 있습니까?

https://stackoverflow.com/questions/1893469

19-09-2019
|

문제

아파치 메이븐 Java 오픈 소스 생태계에서 매우 인기 있는 빌드 및 종속성 관리 도구입니다.컴파일된 내용을 처리할 수 있는지 알아보기 위해 몇 가지 테스트를 수행했습니다. 프리파스칼 / Delphi 유닛은 구현이 쉽다는 것을 알았습니다.그래서 그것은 가능할 것입니다

공개 Maven 저장소에 Free Pascal(또는 Delphi)용으로 미리 컴파일된 오픈 소스 라이브러리를 릴리스합니다.
종속성 정보가 포함된 이 저장소에 메타데이터를 포함합니다.
명령줄에서 Maven을 사용하여 공개 저장소에서 오픈 소스 라이브러리를 다운로드하고 모든 종속성을 자동으로 해결합니다.
프록시로 작동하는 로컬 저장소는 자주 사용되는 바이너리를 캐시하는 데 사용될 수 있습니다.
자동 체크섬 생성 및 확인(Maven 제공)을 사용하면 손상된 바이너리를 다운로드할 위험이 줄어듭니다.
소스 코드와 문서 파일까지 바이너리와 함께 제공될 수 있습니다.
디버그 정보 유무에 관계없이 바이너리가 제공될 수 있습니다.
다음과 같은 지속적인 통합 서버 허드슨 강, 팀시티 또는 크루즈 컨트롤 변경 사항이 소스 제어 시스템에 제출될 때마다 프로젝트를 빌드하고 개발자에게 빌드 오류에 대해 알리는 데 사용할 수 있습니다.

이러한 종속성 관리 방법은 복잡한 종속성이 있는 많은 타사 라이브러리를 사용하는 오픈 소스 프로젝트에 매우 유용할 수 있습니다.잘못된 버전을 사용하여 발생하는 일반적인 충돌을 피할 수 있습니다.

개발자의 경우 프로젝트 편집 및 빌드 작업 흐름이 최소한으로 줄어듭니다.

내부 버전 관리 시스템에서 프로젝트 소스 체크아웃
소스 파일 편집
달리다 mvn package 필요한 모든 타사 라이브러리(미리 컴파일된 단위)가 아직 워크스테이션의 로컬 저장소에 없는 경우 자동으로 다운로드합니다.
컴파일 및 실행

프로젝트 폴더에 필요한 유일한 Apache Maven 추가 파일은 프로젝트 정보가 포함된 POM.XML 파일입니다.

편집하다:Maven은 일부 필수 작업에 사용할 수 있지만 기본 Free Pascal에서 Maven과 같은 솔루션을 구현하면 몇 가지 장점이 있습니다.Java SDK가 필요하지 않으며 Free Pascal을 사용할 수 있는 모든 개발 플랫폼을 지원하며 Pascal에서 유지 관리 및 플러그인 개발이 가능합니다.

Maven과 같은 도구를 사용하는 것은 오픈 소스 프로젝트에만 도움이 되지 않습니다. 상용 프로젝트에서도 동일한 방식으로 공용 Maven 저장소의 아티팩트에 액세스하고 사용할 수 있습니다.

Maven 기능은 다음에 나열되어 있습니다. http://maven.apache.org/maven-features.html

업데이트:

한 가지 사용 사례는 Maven이 필요한 모든 라이브러리를 다운로드하고 필요한 빌드 경로 인수를 사용하여 컴파일러를 호출하는 Lazarus의 빌드일 수 있습니다.낮은 수준의 종속성 변경 사항은 상위 빌드까지 자동으로 전파됩니다.

가능한 이점:

새 워크 스테이션을 설정하는 데 시간이 줄어들고 제 3 자 라이브러리의 수동 설치가 필요하지 않습니다.
잘못된 라이브러리 버전으로 인한 오류, 버전 충돌 감지 (예 : 두 라이브러리가 세 번째 라이브러리의 다른 버전에 의존하는 경우)
사내에서 생성 된 아티팩트는 현지 Maven 저장소에 추가 될 수 있으며 개발자와 프로젝트간에 공유 할 수 있습니다.
동일한 소스 및 프로젝트 메타 데이터 파일 (pom.xml)을 사용하여 빌드가 재현 가능합니다.
개발 시간을 줄이고 프로젝트 안정성을 높일 수 있습니다

업데이트 #2:FPMake

그만큼 FPMake Free Pascal용 빌드 시스템은 많은 잠재력을 지닌 도구인 것으로 보이며, 많은 세부 사항에서 Maven과 매우 유사합니다.

FPMake는 FPC용으로 개발 및 배포되는 파스칼 기반 빌드 시스템입니다.
FPMake는 표준 디렉토리와 같은 몇 가지 제한을 정의하여 건물을 표준화합니다.
명령 fppkg <packagename> 데이터베이스에서 패키지를 찾아 추출한 다음 fpmake.pp를 컴파일하고 실행합니다.
표준 빌드 대상(정리, 빌드, 설치 등)이 있습니다.
저장소로 가져오기에 적합한 '매니페스트' 파일을 생성할 수 있습니다(예: mvn deploy 또는 mvn install), 매니페스트는 Maven의 pom.xml과 매우 유사한 XML 파일입니다.

FPMake 매니페스트 파일:

      <packages>
        <package name="my-package">
          <version major="0" minor="7" micro="6" build="1"/>
          <filename>my-package-0.7.6-1.zip</filename>
          <author>my name</author>
          <license>GPL</license>
          <homepageurl>http://www.freepascal.org/</homepageurl>
          <email>myname@freepascal.org</email>
          <description>this is the package description</description>
          <dependencies>
            <dependency>
              <package packagename="rtl"/>
            </dependency>
          </dependencies>
        </package>    
      </packages>

올바른 솔루션이 없습니다

다른 팁

Freepascal은 apt-get과 freebsd 포트 스타일을 혼합한 자체 패키지 시스템을 개발해 왔습니다.(자동으로 소스 다운로드/빌드/설치), fppkg라고 합니다.그러나 작업이 중단되었습니다.병목 현상은 도구를 선택하려는 사람들이 아니라 시간을 투자하는 사람들에게 있습니다.

Maven에 관한 한, 나는 거대한 외부 런타임을 설치해야 하는 보조 도구를 좋아하지 않습니다.Open Office와 같은 대규모 주요 앱에는 적합하지만 유틸리티에는 적합하지 않을 수 있습니다.

또한 저는 FPC 현실과 작업 흐름에 맞게 설계된 도구를 선호합니다.문서화 도구, 빌드 도구, 다운로드 시스템, 테스트 스위트 시스템은 이미 모두 갖추어져 있으며, 이를 실현하려면 많은 시간을 할애하는 사람이 필요합니다.

FPC로 프로젝트에 새로운 기술을 도입할 때 발생하는 몇 가지 일반적인 문제와 자체 도구를 만드는 경향이 있는 이유는 다음과 같습니다.

파트타임으로 20명 이상의 커미터를 교육해야 합니다.
여러분이 가정할 수 있는 유일한 COMMON 프로그래밍 언어는 Free Pascal입니다.Delphi 내부 작업조차도 당연하게 여겨질 수 없습니다. (많은 커미터가 FPC에 직접 왔고 심지어 여전히 TP 또는 Mac Pascal을 통해 왔습니다.)
- 분명히 그것은 다른 언어로 된 플러그인을 사용하는 것을 짜증나게 만듭니다.
Bash 스크립트는 가까운 초입니다.(g)세 번째로 만들지만 이미 크기가 작아졌습니다.
모든 서버는 *nix와 유사하지만(FreeBSD, OS X, Linux) 모든 서버가 Apache를 실행하는 것은 아닙니다.(예:내 FreeBSD 미러는 XSHTTPD를 실행합니다)
가장 지식이 풍부한 사람은 오랫동안 헌신적인 관리자여야 합니다.문제 해결, 업데이트/마이그레이션 수행 등분명한 이유로 하나 이상의 것이 바람직합니다.
가장 큰 문제는 Linux 배포판(그리고 그 정도는 덜하지만 FreeBSD)입니다. 대부분의 *nix 패키지 관리자는 "./configure;make;make install" 이상의 작업을 수행할 수 없으며 거의 빌드 가능한 저장소와 보조 파일을 스푼피드해야 합니다. .
- FPC/Lazarus의 유통 내 패키징은 항상 중요했으며 계속 증가하고 있습니다.
- 모든 배포에는 메타데이터, 종속성 및 소스 게시 방법에 대한 고유한 특수 규칙이 있습니다.특히 데비안/우분투는 매우 관료적이고 느립니다.
- 대부분은 시스템 위에 제3자 자동 설치 프로그램을 설치하는 것을 좋아하지 않습니다(종속성 제어를 우회하기 때문입니다).

이 모든 것은 최소한의 스크립팅 작업으로 Pascal에서 도구를 소유하는 효과적인 방법으로 이어집니다.사용된 일부 도구:

Gmake는 주로 디렉토리 수준별로 빌드 프로세스를 매개변수화하는 데 사용됩니다. 후속 버전인 fpcmake(이름에도 불구하고 실제로는 make 파생물이 아님)가 시작되었지만 마이그레이션이 완료되지 않았습니다.
라텍스와 라텍스에서 html로의 변환(tex4ht, 데비안은 hevea를 사용함)은 문서 작성(비라이브러리 문서)에서 사용됩니다.
커뮤니티 사이트(TCL 스크립팅을 사용하는 넷스케이프 커뮤니티 서버, 무겁고 복잡한 애플리케이션 서버)는 시작부터 문제가 되었지만, 특히 최근에는 관리자의 활동이 뜸해졌습니다.
Mantis는 문제가 되었지만(특히 전자 메일 모듈은 볼륨으로 인해 서버가 충돌하거나 작동하지 않을 수 있음) 여러 Lazarus 개발자의 노력과 연속적인 업데이트를 통해 모양이 바뀌었습니다.현재는 괜찮은 일꾼입니다.
lazarus.freepascal.org PHPBB 포럼 OTOH는 많은 젊은 사람들이 이를 처리하는 방법을 알고 있기 때문에 상대적으로 고통스럽지 않습니다.
Subversion의 경우에도 마찬가지입니다(더 발전된 규모에는 약간의 조정이 필요하지만 모든 사람이 병합 추적에 깊이 관여하는 것은 아닙니다).

누군가 Maven에 대해 정말로 진지하게 생각한다면 나는 보통 그에게 이렇게 묻습니다.

에게 비판적으로 프로젝트의 용도를 조사합니다.일정과 시간 추정을 통해 매우 구체적인 방법으로.조감도 수준의 "모든 것이 가능하다"는 개요는 본질적으로 가치가 없습니다.
사용되는 기술의 미래 변화에 대해 생각해보십시오.모든 기술은 결국 18년 이상의 프로젝트에서 내부 기술까지 교체됩니다.새로운 기술로 인해 다른 인프라 구성 요소의 마이그레이션이 어렵거나 복잡해져서는 안 됩니다.모든 신기술을 끝내는 신기술은 존재하지 않습니다.
마이그레이션 계획을 세우십시오.마이그레이션은 종종 과소평가되고 과소평가됩니다.
그리고 결국에는 누가 일일 유지 관리를 할 것인지에 대한 1000,000 유로의 질문이 항상 있습니다.

회사에서는 애플리케이션 서버 책임자를 쫓아낸다는 점을 명심하세요.그러나 비공식적인 환경에서는 사람들의 삶, 직업, 프로젝트에 소요되는 시간이 다양하기 때문에 이는 특히 장기적으로 훨씬 더 어렵습니다.

흥미로운 계획처럼 들리지만 델파이 커뮤니티(그리고 FPC는 훨씬 더 그럴 것 같습니다!)는 미리 컴파일된 라이브러리보다 라이브러리를 소스로 훨씬 더 중요하게 생각합니다.일반적인 합의는 바이너리 전용 라이브러리를 사용하는 사람은 누구나 바보라는 것입니다. 그 이유는 다음 두 가지입니다.여기서 발견한 버그는 수정할 수 없으며 컴파일러 변경으로 인해 호환성이 손상됩니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow