9

Apache Mavenは、Java オープン ソース エコスフィアで非常に人気のあるビルドおよび依存関係管理ツールです。コンパイル済みのFree Pascal / Delphi ユニットを処理できるかどうかを確認するためにいくつかのテストを行ったところ、実装が簡単であることがわかりました。だからそれは可能だろう

  • Free Pascal (または Delphi) 用にプリコンパイルされたオープン ソース ライブラリをパブリック Maven リポジトリでリリースする
  • 依存関係情報を含むこのリポジトリにメタデータを含めます
  • コマンド ラインで Maven を使用して、パブリック リポジトリからオープン ソース ライブラリをダウンロードし、すべての依存関係を自動的に解決します。
  • プロキシとして機能するローカルリポジトリは、頻繁に使用されるバイナリをキャッシュするために使用できます
  • チェックサムの自動生成と検証 (Maven が提供) により、破損したバイナリをダウンロードするリスクが軽減されます。
  • ソース コードやドキュメント ファイルでさえ、バイナリと共に提供される可能性があります。
  • バイナリは、デバッグ情報ありまたはなしで提供できます
  • Hudson、TeamCity、CruiseControlなどの継続的インテグレーション サーバーを使用して、変更がソース管理システムに送信されるたびにプロジェクトをビルドし、ビルド エラーについて開発者に通知できます。

この依存関係管理の方法は、複雑な依存関係を持つ多くのサードパーティ ライブラリを使用するオープン ソース プロジェクトにとって非常に有益です。間違ったバージョンを使用することによって引き起こされる典型的な競合を回避できます。

開発者にとって、プロジェクトの編集と構築のワークフローは最小限に抑えられます。

  • 内部バージョン管理システムからプロジェクト ソースをチェックアウトする
  • ソースファイルを編集
  • mvn packageワークステーションのローカル リポジトリにまだない場合は、必要なすべてのサード パーティ ライブラリ (プリコンパイル済みユニット) を自動的にダウンロードするために実行します。
  • コンパイルして実行

プロジェクト フォルダーに必要な Apache Maven の唯一の追加ファイルは、プロジェクト情報を含む POM.XML ファイルです。

編集: Maven は必要なタスクの一部に使用できますが、ネイティブ Free Pascal で Maven のようなソリューションを実装すると、いくつかの利点があります。Java SDK が不要、Fr​​ee Pascal が利用可能なすべての開発プラットフォームのサポート、Pascal でのメンテナンスとプラグイン開発。

Maven のようなツールの使用は、オープン ソース プロジェクトだけでは役に立ちません。商用プロジェクトでも、パブリック Maven リポジトリにあるアーティファクトに同じ方法でアクセスして使用できます。

Maven 機能は、http://maven.apache.org/maven-features.htmlにリストされています。

アップデート：

ユースケースの 1 つは Lazarus のビルドで、Maven が必要なすべてのライブラリをダウンロードし、必要なビルド パス引数を指定してコンパイラを呼び出します。下位レベルの依存関係の変更は、親ビルドまで自動的に伝播されます。

考えられる利点:

  • 新しいワークステーションのセットアップに必要な時間を短縮し、サードパーティ製ライブラリを手動でインストールする必要がありません
  • 間違ったライブラリ バージョンによるエラーの減少、バージョンの競合の検出 (たとえば、2 つのライブラリが 3 番目のライブラリの異なるバージョンに依存している場合)
  • 社内で作成されたアーティファクトは、ローカルの Maven リポジトリに追加して、開発者とプロジェクトの間で共有できます。メタデータを含むすべてのアーティファクトの中央ストレージ
  • 同じソースとプロジェクト メタデータ ファイル (pom.xml) を使用するだけで、ビルドを再現できます。
  • 開発時間を短縮し、プロジェクトの安定性を高めることができます

更新 #2: FPMake

Free Pascal 用のFPMakeビルド システムは、多くの可能性を秘めたツールのようです。多くの点で、Maven と非常によく似ています。

  • FPMake は、FPC 用に開発され、FPC とともに配布される Pascal ベースのビルド システムです。
  • 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>
4

2 に答える 2

1

Freepascal は、apt-get と freebsd ポート スタイルを組み合わせた独自のパッケージ システムに取り組んできました。(ソースのダウンロード/ビルド/インストールを自動的に)、fppkg と呼ばれます。しかし、仕事は停滞しています。ツールを選択したい人ではなく、時間を投資する人がボトルネックです。

Maven に関する限り、巨大な外部ランタイムのインストールが必要な補助ツールは好きではありません。大規模なメジャー アプリ (Open Office など) では問題ないかもしれませんが、ユーティリティでは問題ありません。

また、FPC の現実とワークフローに合わせて設計されたツールも好みます。ドキュメンテーション ツール、ビルド ツール、ダウンロード システム、テスト スイート システムはすでにすべて揃っており、それを実現するには多くの時間を費やす人が必要です。

FPC としてプロジェクトに新しい技術を導入する際の典型的な問題と、独自のツールを作成する傾向がある理由:

  • パートタイムで 20 人以上のコミッターをトレーニングする必要があります。
  • 想定できる唯一の COMMON プログラミング言語は Free Pascal です。Delphi の内部構造でさえ、当然のように知られているわけではありません (多くのコミッターが FPC に直接アクセスしたり、TP や Mac Pascal を介してアクセスしたりしていました)。
    • 明らかに、それは別の言語のプラグインで何かを面倒にします。
  • Bash スクリプトは僅差です。(g) 3 番目にしますが、すでに大きさが小さくなっています。
  • すべてのサーバーは *nix ライク (FreeBSD、OS X、Linux) ですが、すべてが Apache を実行しているわけではありません。(たとえば、私の FreeBSD ミラーは XSHTTPD を実行しています)
  • 最も知識のある人は、長い間献身的なメンテナーでなければなりません。問題を修正し、更新/移行などを行います。明らかな理由から、できれば複数。
  • 主な問題は Linux ディストリビューション (および程度は低いが FreeBSD) であり、*nix パッケージのメンテナーのほとんどは「./configure;make;make install」以上のことを行うことができず、ほぼビルド可能なリポジトリと補助ファイルを追加する必要があります。 .
    • FPC/Lazarus の流通パッケージングは​​常に重要であり、さらに増え続けています。
    • すべてのディストリビューションには、メタデータ、依存関係、およびソースの公開方法に関する独自の特別なルールがあります。特に Debian/Ubuntu は非常に官僚的で遅いです。
    • ほとんどの人は、システムの上にあるサードパーティの自動インストーラーを好みません (依存関係の制御をバイパスするため)。

これはすべて、最小限のスクリプトで Pascal のツールを所有するのが最も効果的であるという効果的な実践につながります。使用したツール:

  • Gmake は主に、ディレクトリ レベルごとにビルド プロセスをパラメータ化するために使用されます。その後継である fpcmake (名前にもかかわらず実際には make の派生物ではありません) が開始されましたが、移行は完了していません。
  • Latex と latex から html への変換 (tex4ht、しかし debian は hevea を使用) は、ドキュメントの構築 (非ライブラリ ドキュメント) で使用されます。
  • コミュニティ サイト (TCL スクリプトを使用するネットスケープ コミュニティ サーバー、重く複雑なアプリケーション サーバー) は、開始以来ずっと問題を抱えていましたが、特に最近、メンテナーがあまり活動的でなくなったためです。
  • Mantis には問題がありました (特に、メール モジュールがクラッシュしたり、ボリュームが原因でサーバーが機能しなくなったりする可能性があります)、継続的な更新といくつかの lazarus 開発者の懸命な作業によって形に整えられました。現在、それはまともな主力製品です。
  • lazarus.freepascal.org PHPBB フォーラム OTOH は、多くの若い人たちが対処方法を知っているため、比較的簡単です。
  • 同じことがサブバージョンにも当てはまります (より高度なスケールには調整が必要ですが、誰もがマージトラッキングの内外に深く関わっているわけではありません)

誰かが Maven に真剣に取り組んでいる場合、私は通常、次のように尋ねます。

  • プロジェクトの使用を決定的に調査します。スケジュールと時間の見積もりとともに、非常に具体的な方法で。俯瞰レベルの「すべてが可能だ」という概観は、本質的に価値がありません。
  • 使用される技術の将来の変化について考えてください。すべてのテクノロジーは、18 年以上のプロジェクトで、社内のものであっても、最終的には置き換えられます。新しいテクノロジーによって、他のインフラストラクチャ コンポーネントの移行が困難になったり、複雑になったりしてはなりません。すべての新技術を終わらせる新技術は存在しません。
  • 移行計画を立てます。移民はしばしば過小評価され、過小評価されています。
  • そして最後に、毎日のメンテナンスを誰が行うのかという 1000000 ユーロの質問が常にあります。

会社では、アプリケーション サーバーの責任者を蹴るだけだということを覚えておいてください。しかし、人々の生活、職業、プロジェクトに費やされる時間はさまざまであるため、非公式な環境では、特に長期的には、これは非常に困難です。

于 2009-12-12T14:43:47.087 に答える
0

興味深い計画のように聞こえますが、Delphiコミュニティ（およびFPCはさらにそうだと思います！）は、プリコンパイルされたライブラリよりもはるかに多くのソースとしてライブラリを評価しています。一般的なコンセンサスは、バイナリのみのライブラリを使用する人は誰でもばかだということです。理由は2つあります。ライブラリにあるバグを修正できないことと、コンパイラを変更すると互換性が失われることです。

于 2009-12-12T13:52:22.390 に答える