私は2台の異なるマシンで作業しています。1 つは Windows で、もう 1 つは Linux です。同じプロジェクトに交互に取り組んでいて、両方の OS を切り替えた場合、最終的にコンパイル エラーが発生しますか? 私が尋ねるのは、一方ではサポートされていても、他方ではサポートされていない標準があるかもしれないからです。
4 に答える
その質問はかなり広いものであり、厳密に言えば、ツールチェーンに依存します。同じツールチェーン(GCC / MinGWやClangなど)を使用する場合は、このクラスのエラーの可能性を最小限に抑えることができます。WindowsでVisualStudioを使用し、Linux側でGCCまたはClangを使用する場合、ヘッダーの一部が異なるため、単独でさらに多くの問題が発生します。したがって、プログラムが厳密なANSI C(C89)の領域を離れると、自分で作業できるようになります。
ただし、注意しないと、Windows側のエディターにこれらを使用するように指示しなかった場合に、Linuxのコンパイラーが行末を窒息させるなど、他の多くのより一般的なエラーに遭遇する可能性があります。
ああ、そして実際にクロスコンパイルしたいのであれば、GCCが最良の選択かもしれないので、私の答えで最初に述べた部分が論点になることも覚えておいてください。GCCは、両端で実証済みの選択肢です。そして、あなたの質問を考えると、カーネルモードドライバのようなものを書き込もうとしている可能性は低いです-それは根本的に異なります。
これは、アプリケーションが特定の API を使用している場合にのみ発生する可能性があります。
コードをコンパイルするのに問題なく、両方のプラットフォームで動作するコードを書くことは完全に可能です。しかし、それはいくつかの困難がないわけではありません。コンパイラーを使用すると、コンパイラーで非標準の機能を使用できます。また、「テキストの行をそのまま読む」以上のことをしたいと思うとすぐに、より凝ったユーザーインターフェイスを実行するのは難しいことがよくあります。シェルに入る」、それは「非標準」の土地にあります。
標準Cライブラリで実行できる以上のことを実行する必要がある場合は、コードのこれらの部分を別のファイル(または、Linux / Unixスタイルのシステム用とWindowsシステム用の2つのファイル)に分離してください。 )。
同じコンパイラ(gcc)を使用すると、「コンパイラBがコンパイラAで正常に動作するコードをコンパイルしない」という問題を回避するのに役立ちます。
しかし、それは絶対的な必要性からはほど遠いです。両方のプラットフォームでコードをコンパイルし、すべての「サポートされている」コンパイラを使用して、それを発見する前に抜け出すのが難しい非常に深い穴を掘らないようにしてください。 「他のシステムでは動作していません」。(少なくとも)他のOSを実行している仮想マシンがある場合は確かに役立つので、両方のバリアントを簡単に試すことができます。
理想的には、自動化されたシステムをセットアップして、コードを変更したときに[そして変更が「完了した」と感じたときに]、使用するすべてのプラットフォームとすべてのコンパイラーで自動的にビルドされるようにします。そして、可能であれば、自動的にテストされます!
また、バージョン管理の使用を真剣に検討します。そうすれば、どちらかの側で何かが壊れたときに、コードが機能しなくなる前に戻ってコードがどのように見えたかを確認し、(うまくいけば)それがはるかに速く壊れた理由を見つけることができます「うーん、それは私がfoo.cに加えた変更だと思います、それを取り除こう...いいえ、それではありません、ここでの変更はどうですか...」-少なくともバージョン管理では、「わかりました。バージョン1234が機能しないので、バージョン1220を試してみましょう。これでうまくいきます。1228を試してみてください。それでも機能します。1229と1234を変更してください。1232を試してください。ああ、壊れています...」ファイルを編集しないでください。それでも、ほとんど問題なく、好きな他のバージョンに移動できます。私はMercurialをかなり使用し、gitを少し使用し、いくつかの破壊を行い、Perforceで数年間プロジェクトに取り組みました。
副作用として:ほとんどのバージョン管理システムは、これを手動で行うよりも、ファイル名と行末をより適切な方法で処理します。
バージョン管理システムをJenkinsなどの「自動ビルドおよびテストシステム」と組み合わせると、すべてを非常に自動化できます。Jenkinsは無料で、WindowsとLinuxの両方で実行され、バージョン管理システムにコードを送信するときに、コードを自動的にビルドしてテストするために使用できます。
それぞれの OS でソース コードを再コンパイルするまで、問題は発生しません。Windows(.exeまたは.obj)によって生成されたコンパイル済みファイルをLinuxで実行したい場合、またはその逆の場合、間違いなく問題が発生し、不可能になります。ただし、ソース コード (拡張子 .c/.c++ のファイル) を任意の os に移動できます。また、別のヘッダー ファイルで問題が発生する場合もありますので、その点にも注意してください。ベスト プラクティスは、プロジェクト全体で 1 つの OS を使用することです。非常に必要になるまで、複数の OS は使用しないでください。