Delphi ソリューションを Linux で利用できるようにする必要があり、Wine と Lazarus の両方でテストしました。メンテナンスの悪夢に陥らないようにするために、長期的に考慮すべき技術的な考慮事項 (プログラミング、展開、メンテナンスなど) は何ですか。クロスプラットフォームで発生する可能性のある複雑さを避けるために、Windows コンポーネントをかなり標準的に使用しています。主観的であることを超えた確固たる事実を探しています。私は .Net/Mono を検討したくありません。これは、すぐに (市場投入までの大幅な遅れ) 余裕がないためです。
私はいくつか考えることができます：
これに関するあなたの貢献は大歓迎です。
そこには黄金律はないと思います。使用するコンポーネントのどれだけがLazarusでサポートされているかによって異なります。
私はlazarusでテストを開始し、必死になった場合に備えてWineをバックアップとして保持します。
Codegearの計画はまだ非常にあいまいです（彼らは「それを見ている」だけですが、同時に2つのフルバージョンで64ビットロールアウトを塗りつぶしているので、これが進んだとしても、これにはかなり時間がかかる可能性があります）
タイムラインが速いので、AppleバージョンはネイティブAPIではなくQTを使用すると思います。
更新：ほぼ4年、まだLinuxのサポートはありません。木はより速く成長します。
私はここにいる他の全員と意見を異にする必要があり、Wine を使用することを提案します。Google は Wine をインストールした状態で Picassa を出荷していますが、同じことができます。ディストリビューションによってインストールされたバージョンに依存するのではなく、事前に構成され、テストできる既知のバージョンを持つプログラム ディレクトリにコピーがあります。
基本的には、Wine ラッパーが提供しないものをネイティブ ポートが提供するものを尋ねるだけです。ほとんどの Delphi アプリの場合、答えはおそらくテーマであり、それ以外はほとんどありません。下位レベルでファイルシステムにアクセスできるようにネイティブ ポートを作成しましたが、それ以前は、当社の製品は何年にもわたって Wine でほぼ完全に動作していました。
経験から言えば、ネイティブ ポートは公園を散歩するようなものではありません。
一般的には、Lazarus を使用することをお勧めします。WINE に依存している場合は、製品の品質に影響を与える可能性のある WINE バグにも翻弄されます。Windows 環境で Lazarus + FPC を使用すると便利な場合もあります。
別の方法として仮想化を使用することもできますが、これは作成しているアプリケーションの種類によって異なります。
LinuxとMacでネイティブDelphiを提供するためのCodegearの計画（DelphiLive 2009でロードマップのヒントのいくつかを検索）を見て、今のところLazarusを使用します。Wineの管理を惜しまず、後でアプリをネイティブに移植できます。（誰かが言っているように、Delphiはペンギン、トラ、ヒョウ、ユキヒョウがいる大きな動物園のようになります。）
もちろん、移植にはいくつかの作業をやめることが含まれます。しかし、Unicodeのような問題を注意深く調べて、最も一般的な障害を防ぐことができれば、それはかなり簡単なはずです。
さらなるヒントについては、 delphifeedsでユニコードとロードマップを検索してください。
Free Pascal Compiler/Lazarus は、最新の Delphi 機能に近いものではありませんが、発見すべきバグがまだあるにもかかわらず、非常に安定しています。
また、生成される実行可能ファイルは大きく見えますが、VM を使用したり、Wine 自体をデプロイしたりするよりも確実に小さくなります。
しかし、それは Delphi/Kylix が一度試みたことを実行します。クロスビルド！これを使用すると、あるプラットフォームから別のプラットフォームにコンパイルできます。
実際、ShareTeam製品にはWineを使用しています... Lazarusにはテスト版があります。これは優れたツールであり、多くの利点がありますが、現時点では完全ではありません。現時点では、作業が単純でない場合はワインを使用する方がよいと思います。DelphiアプリケーションをLazarus/FreePascalに変換するのは簡単ではありません。個人的には、EmbarcaderoがDelphiと多くの違いがあるPrismのように、Delphiのクロスプラットフォームバージョンを作成することを望んでいます。
まず、GUI コードと非 GUI バックエンド コードが GUI アプリとライブラリに明確に分離されていない場合は、それらが明確に分離されていることを確認する必要があります。これにより、テストが容易になり、コマンド ライン インターフェイスや Web インターフェイスなどの実装も簡単になります。ほとんどの場合、これらのライブラリ (オブジェクトとプロシージャを含むユニット ファイル) は FreePascal で簡単にコンパイルできますが、非 GUI コードをチェックしてデバッグする必要があります。最初。
それが終わったら、GUI を見てみましょう。クローズド ソースのサード パーティの商用コンポーネントを多数使用している場合、GUI を簡単に変換することは難しいかもしれません。主にストック コンポーネントや Lazarus に移植されたコンポーネントを使用している場合は、実際に GUI を変換してそのまま使用できる場合があります。
Mac OS と Linux のプログラムは見た目が異なることが多いため、アプリケーションによってはそれを考慮する必要があることに注意してください。1. Windows でも Lazarus を使用し、すべてのプラットフォームで同じ GUI コードを使用します。2. OS X と Linux でのみ Lazarus を使用し、GUI をカスタマイズして、変換後に多少ネイティブに見えるようにします。3. OS X 用のネイティブ GUI をコーディングし (Cocoa とおそらく XCode を使用)、非 GUI 処理のために Pascal コードにリンクします。この種のことは Linux ではあまり必要ありませんが、LCL (VCL) バックエンドが作成するツールキットを選択できます。
それぞれのアプローチには強力な支持者がいますが、どれが正しいかは、「状況」と目標によって異なります。
主な関心が OS X である場合は、MacPascal リストへの参加を検討してください。
Linux/OS X アプリをほとんど変更せずに明日リリースする必要がない限り、Wine は非常にやり過ぎです。(その場合、なぜ VMWare を使用しないのでしょうか?)