MGL週報 #64 - ビルド環境の諸問題あれこれ
このエントリはゲーム開発用フレームワーク「MGL」の開発記録です。MGLはzlibライセンスの下に無償で提供されています。
ドキュメントはこちら
進捗状況の確認と問い合わせはこちら
ビルド環境の諸問題あれこれ
Visual Studio 2022でMGLのプロジェクト(VS2019)をそのまま使用する方法
先週さらっとだけお伝えしましたが、MGLのVisual Studio向けプロジェクトは2022でも変換なしにそのまま使用できるみたいです。
実は把握していなかったのですが、最近のVisual Studioはコンポーネントを追加することで古いバージョンのプロジェクトを利用できるみたいでした。新調したPCに2019を入れようとしても既に公開されておらず途方に暮れていたのですが、どうやら今は複数のバージョンを入れる必要は無いようです。
方法は簡単で、初回インストール時、もしくは同時にインストールされる「Visual Studio Installer」を使用して、追加のコンポーネントとして「MSVC v142」とそれに対応するATLをインストールする事。この状態でプロジェクトを開くとv143(VS2022)にアップデートするか、そのままのバージョンで開くかの選択が出るので、好きな方を選択してください。
また、その際にSDKのバージョンも質問されますが、これは最新で問題ありません。元々MGLのプロジェクトは常に最新のSDKを使用するようになっています。(MSVCのバージョンとSDKのバージョンが別々なのがちょっと分かりにくいところ)
注意点としては、対応するATLのインストールが必須である事。と、言うのも、最新バージョンのATLは自動でインストールされるのに対して、古いバージョンに対応したATLは手動でインストールする必要があるらしいです。MGLがATLを必要としている事はドキュメントにも書かれていませんので、この辺は知らなければ沼る可能性があります。
なお、普通にMGLを利用する限りはこのような手順を踏む必要はありません。先述の通りMGLは常に最新のSDKを使用するようになっているため、むしろVS2022向けに変換して使用することを推奨します。
gccにおける問題点
次のMGL 1.1.13からは環境依存コードを含まないコア部分のみをビルドするための設定ファイルが追加されます。具体的には、SCons向けのSConstructとCMake向けのCMakeLists.txtが用意され、どちらか一方を使用することでMGLコアのみをスタティックライブラリとしてビルドできるようになります。
が、この環境を用意したことで今更とんでもない事に気付きました。何と、MGLはgccでコンパイルが通りません。MGLの標準構成のターゲットに含まれていなかったため気付かなかったのですが、Linux系のOSではgccが標準的に使用されているため、これは大問題です。
理由は細かい問題が複数あるのですが、多くは標準と思って使用していた機能が実は非標準で、gccがそれをエラーとみなしているというケースです。ほとんどは単純な置き換えで対応可能ですが、一部どう対処しようか悩んでいる部分があります。
その1つが、ユニークポインタの取得が実は定数式でなかったという問題です。例によって、cpprefjpさんのリンクを。
見ての通り、std::unique_ptr::get()にconstexprが付与されるのはC++23からです。一方、MGLはC++17準拠ですので、この関数は本来は定数式として書かれた関数内では使用できません。しかし、MGLが定数式として提供しているAPIの一部はこの関数を使用しており、その部分が軒並みエラーとなってしまっています。
では何故MSVCやclangではエラーにならないのかというと、正直なところ正確な理由は分かりません。試しに手元のXcodeのSDKにバンドルされているclangのlibc++を調べてみたところ、確かに該当関数が定数式になるのはC++23以降からでした。
clangが他のコンパイラと比べて定数式にできる条件が若干緩いのは使用していて何となく気付いていたので、もしかしたらその辺がコンパイラ依存なのかもしれません。少なくともlibc++がこっそりconstexprを付与している訳では無さそう。
さて、理由が何であれ修正必須な問題ではあるのですが、その修正方法はどうしようかと悩み中です。
最も単純な方法は、エラーの出ている全ての関数からconstexprを省く事なのですが、これは影響範囲が大きそうなのですよね。恐らく根っこを修正することで芋づる式に他の関数も影響を受け、その影響はアプリケーション側にまで及んでしまうでしょう。
加えて、今回大掛かりな破壊的変更を加えつつ、将来C++23に対応させる場合に元に戻すというのも何だかなぁという感じ。何か上手い方法でラップできないかと検討中です。
ツール類のビルド環境
MGL 1.1.13のビルド環境の更新に合わせて、MGL向けツール類のビルド環境も同じ方式でビルドできるよう対応中です。
具体的には、今までSConsでのビルドにしか対応していなかったのに対して、CMakeでのビルドやclang-tidyによるチェックも可能な状態で提供します。これによって、VSCodeやCLionなどのIDEを用いた開発がかなり容易になる見込みです。
実際のところ、私の書いたツールに対して他の誰かが手を加える機会はそうそう無いとは思いますが、現実問題と万が一の場合の準備は別のお話。他人の書いたプログラムで不審な挙動に遭遇した際に、ビルドが簡単だったりデバッガで追える環境が用意されていたりすると心強いですからね。むしろ、ツールの導入を検討する際の重要なチェックポイントだと思っています。
あと、新規に作りたいツールをいくつか思い付いているので、その準備も兼ねています。
その他
新調したPCのセットアップがなかなか進んでいませんでしたが、本日ようやく一通りの移行が完了しました。
ゲームの開発環境はいつもの事なのでスムースだったのですが、苦戦したのは作業配信の環境の移行。そもそもそっちは素人同然で、3年くらい前に調べながら構築した内容なんて覚えている訳もなく、中には開発終了していたソフトなんかもあって色々と大変でした。移行と言うよりは実質再構築になりましたが、とりあえず多分大丈夫というくらいには準備できたので多分大丈夫でしょう。多分。
古いPCは一度バラしてクリーニングした後に、何らかのLinuxをインストールする予定です。良い機会なのでgccでビルドが通らない問題はこれで対応する事にしましょう。
この記事が気に入ったらサポートをしてみませんか？