64(2): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ f332-ZIVz) [sage] 2025/05/11(日) 20:12:58.46 ID:krziBUoq0(1/2) AAS
>>63
しいていえば Conan が近いと思うがビルド自体は指定したビルドツールに下請けさせる構造になってる。
プロジェクトのビルドをする仕組みが多用なので既存のプロジェクトを Conan の管理化に入れるといった状況を考えると C++ 的にはこうなるのは仕方がない……。
C/C++ では OS (ディストリビューション) のパッケージマネージャでライブラリを管理するのが普通だったので言語の側で統括的に扱うツールという文化が欠けてる。

66(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 03a6-XCeo) [sage] 2025/05/11(日) 20:21:24.40 ID:WWvVAeL50(1/4) AAS
OS提供のヘッダーファイルと連携しないといけないからね
rustだってOSのAPIとして使われるようになったら今の形のままでは済まされないはず

68(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 03a6-XCeo) [sage] 2025/05/11(日) 20:34:00.81 ID:WWvVAeL50(2/4) AAS
>>67
Windows SDKとかUNIX系なら/usr/includeにあるやつとかMacだと/Library/Developerとか
ひとつの環境に複数バージョン同時に入ってたりパスの規則もベンダーごとにばらばらだったり独自の拡張構文が使われてたりで処理系側のツールで吸収しきれるものではなく
自然>>64も言ってるOS側の管理に委ねるという方向に

70(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 03a6-XCeo) [sage] 2025/05/11(日) 20:58:44.05 ID:WWvVAeL50(3/4) AAS
別に便利ツール自体がないわけではなく、ライブラリはOS側のパッケージマネージャやcanonやバージョン管理ツールの機能等で揃えて
ビルドはcmakeというメタビルドツールで各OSの持つビルドツール向けの入力ファイルを生成したりということはする
統一感には欠けるしばらばらのものを組み合わせてるから躓く可能性もずっと高いけども