堕天使の煉獄
2016-06
19
06:05:56
やったー出来たー
わりと良くあることで、もう諦めた……って打ち切ったあとに、なんとなく未練がましく検索してると、ぽろっと解決の糸口が見つかったりして。
QT上でvc++2015のコンパイラ使う方法。
解決してみれば、理由は、環境がwin10でQT初導入の場合には起らない不具合っぽいんですよね。そんなん判るかっw
Why is Qt identifying MSVC 2015 as MSVC 2005?
ttps://www.reddit.com/r/Qt5/comments/3xzwqm/why_is_qt_identifying_msvc_2015_as_msvc_2005/
全く同じ状況。
どうも、インスコされてるvcのverの取得に失敗してるかなにかで、MSVC2015がMSVC2005となってしまっている模様。
解答してるのはQTの開発者? それともそういう要望だしてみるよって話なのかな。QT Creator上からは再検出みたいな事ができないため、再検出ボタンを追加するようにしてみるYO! とかいってるっぽいんですが、この記事五ヶ月前_| ̄|○
とりあえず、QT Creatorで読み込むtoolchains.xmlてのを削除すれば再作成(再検出)してくれるらしいというのを他の記事で発見。
が、QT Creatorの中のフォルダ検索してみると
C:\Qt\Tools\QtCreator\share\qtcreator\QtProject\qtcreator\toolchains.xml
これかー。
中を覗いてみると、あるぇー? mingwの設定しか無い。
msvcの設定は何処よ? とりあえずコレ消してみる。したらQT Creator上では、自動設定から手動の所にmingwが移動。msvcはそのまんま変化無し。
なんでだーとおもったら……。
QtCreator Qt 5.6.0 VS2015 - don't accept compilers
ttps://forum.qt.io/topic/65535/qtcreator-qt-5-6-0-vs2015-don-t-accept-compilers/2
C:\Users\ユーザー名\AppData\Roaming\QtProject\qtcreator\toolchains.xml
えーユーザーディレクトリに設定あるんかいっ。
よくよく一番最初のURLの記事みると
>> delete ApplicationData/...QtProject/qtcreator/toolChains.xml (or just the MSVC compilers found in that file)
て書いてあったね。見落としてたw
てかこのユーザーディレクトリに設定残すの止めて欲しいな。バージョンあがったら、たいてい互換破壊する感じなので、共用設定とか邪魔になるどころかトラブルの原因にしかならんのだけど。QTに関して言えば。
で、ユーザーディレクトリの中のtoolchains.xmlを削除。QtCreator再起動。MSVC2005だったのがちゃんとMSVC2015になってる。
これでようやくビルドできる?
……したら今度はcorecrt.hが無いとか抜かしやがる。
ググってみると
New Qt Quick application does not build with VS2015 (cannot include corecrt.h)
ttps://bugreports.qt.io/browse/QTBUG-50191
corecrt.hはWindows SDKの中にあるらしい。
あるぇー? vc++2015はWindows SDK統合とかしたんじゃなかったっけか。
それ以前に、その前にvc++2012とかの辺りでwin7用のSDK入れた記憶もあるんだけどなぁ。vc++2015入れるときには、なんかweb toolとかwin10用のSDKなんか選択画面にあったけど、それはチェック外してた気がする。
そも、GUIアプリはQTでやって、vc++はDXライブラリつかったゲーム開発用のつもりだったので、SDKとかいらんやん。てかんじだったんですが、QTのプロジェクトをビルドするのにはWindows SDK必要だとか。うへー。
C:/Program Files (x86)/Windows Kits/10/Include/10.0.10240.0/ucrt
このucrtんなかにcorecrt.hはあるんだそうな。
SDKは8GBかあるしぃ。時間掛かるのう。悔しいのう、あんちゃん……。(なんとなく無駄なものを大量に入れさせられてる感じがして気分的に……w)
こんでどうじゃーい
と思ったら今度はrc.exeが実行出来ませんとか。
rc.exeってみたまんまリソース関係っぽいんですが。見つからないじゃなくて実行出来ない?? なんかver違いとかそういう厄介なの?? win7用とwin10用ごっちゃになってる的な。
Visual Studio can't build due to rc.exe
ttp://stackoverflow.com/questions/14372706/visual-studio-cant-build-due-to-rc-exe
うーん。
どうもwin7環境の場合なら
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Bin
のなかのRC.exe と RcDll.Dllってのをvcのbinフォルダの中にいれるか、そこまでのパスを環境変数に追加しろってことらしい。
えーとwin10環境だと多分そのまま問題なかったのかな。
win7だと、RC.exeだけはwin7用のものを使わないと行けないみたいなかんじなのか。
んでもこれ、なんでファイル名へんな大文字小文字混じりなの、気持ちワルー。
とりあえず、なんかパス追加だと、win10用とwin7用同名の物があったりすると厄介なことになりそうなので、とりあえずRC.exe と RcDll.Dllをコピーする方法で試してみる。
……ビルド出来たー!!
てか、結局全部英語サイトの情報……。
ほんと日本のQT界隈寂れてるなぁ……。
あとは、公式でなく、みんなフォーラムとか外部の所ってのもなんだかなぁ。
QTはやっぱWin向けじゃなくてunix系が主導なんだなぁ。unix系なら、環境変数とか最初から整えるのが当然て心構えがあるからなぁ。
winだと、自動で追加されてるはずのものが無いとか古い設定が残ってるとかでも大騒ぎ。unix系の人からすれば情弱も良いとこだよな……(ぉ
しかし関係ないけど、vc++2015の更新インスコでSDKとか追加してたんですが……。
なにこのmsのF#のごり押し感。チェック外しても戻ってくると再チェックされてる。他の項目はそんなこと無いのにw
てか、F#て関数型言語だっけか。将来性はある分野ではあるのかもしれないけど、現時点では使ってるやつとか見たことも聞いたこともねぇよ。
将来的にはどうなるかは判らないとしても、現時点では、手段が目的になる(言語自体への興味)タイプの人以外にはなんの用もないですよね。それで何かを生産したいという目的のある人にはHDDの肥やしにしかならんぽ。
んでもってwinの環境変数の画面……windows3.1の頃から変わってないのは何で?
狭くて幅の変更も出来ないテキストボックスからしか入力出来ないとか拷問だろこれ。
そんなしょっちゅう環境変数なんて弄らないからアレだけど、今回我慢できずに外部のツールで有名どころらしいRapidEE使ってみる。
嗚呼快適。
てかMSはこの画面変えるつもり一生ないのかね(ぉ
VCディレクトリの設定もそうだし、SendToのフォルダもそうだけど、よく使う重要な機能ほど、どんどん奥のわかりにくいところに持って行くmsの方針はよくわからん……。コントロールパネルもエクスプローラに統合されたために、返って邪魔くさい感じなうえ、ちょいちょい名称も場所も変えやがるので、たまに親のノート(vista)のメンテとかさせられるときに、呼び出したい機能は分かってるのにそれが何処にあるのか判らなくて混乱することも多い。
この辺のユーザビリティの低さはほんと酷いよな……ms。
とりあえず、QT Creator上でvc++2015のコンパイラでビルド出来る用になった……。やっぱmingwより速い~。リリースビルドだとそんな遜色無いのかもだけど。
あとはvcビルドだと文字化けしないようにしないとな。
てかvcはいつまでshift-jisなんか使い続けるのだろうか……。デフォルトではshift-jisが使われるために文字化けしちゃうので。時代遅れも良いところだ。だ。なんてもう、vc++2008ぐらいのころから言われてるのになぁ。
んでも……DXライブラリの公式掲示板で、とある脆弱性のfixした報告記事のなかで管理人氏が、unicode版使ってる人はほとんどいないでしょうが……的な発言してて。
……個人的にはマルチバイト版使ってる人なんて今時いるの? 保守のために古いアプリとか使ってるところが仕方なくマルチバイト版つかってるだけでしょ? ぐらいの認識持ってたんですが。
そうでもないのかな……w
cgiとかでは、鯖はunix鯖だし、QTはutf8がデフォだし、unityもutf8がデフォだったかな。
なので、わりと早い段階でソースコードの文字コードをunicodeで運用する方向に切り替えたのですが、
DXライブラリ関係のみしかPGやらない分にはマルチバイト文字(shift-jis)でも困らないから気にすることでもないからなのかな。(_Tマクロとか無駄なもの書かなくて済むし)
そいやbom無しのutf8には対応したのだろうか……vc++2015の段階ではダメーってことを確認したのだけどもsp当たってからは確認してなかったっけな。
その所為でQTの方もbom付をデフォ設定にしてるので、今のところ同じコード同じソースファイルでもvc++でビルド来てるんですが。
とにかくまあ、これでQT上でvc++のコンパイラ使ったビルド出来る様に……。
んでもあとは……c++11回りがなぁ、QT。
auto(型推論)や可変長テンプレート回りのインテリセンスとかが効かないのがめんどくさい。clangコードモデル使うとその辺は解決するんだけど、いまのverだとどうなるか判らないケド、QT5.6のQT creator3.6、4.0だとソースコードのファイルをロックしたままハングって、ソースコードの保存が出来なくなるっていう結構致命的なバグ? 不具合があったりしたので。
そうなると、vc++とQT両方立ち上げて行き来しながらコード書く方法もありなのかなと言う気も……。
とりあえず、ひとごこちついた~。
QT上でvc++2015のコンパイラ使う方法。
解決してみれば、理由は、環境がwin10でQT初導入の場合には起らない不具合っぽいんですよね。そんなん判るかっw
Why is Qt identifying MSVC 2015 as MSVC 2005?
ttps://www.reddit.com/r/Qt5/comments/3xzwqm/why_is_qt_identifying_msvc_2015_as_msvc_2005/
全く同じ状況。
どうも、インスコされてるvcのverの取得に失敗してるかなにかで、MSVC2015がMSVC2005となってしまっている模様。
解答してるのはQTの開発者? それともそういう要望だしてみるよって話なのかな。QT Creator上からは再検出みたいな事ができないため、再検出ボタンを追加するようにしてみるYO! とかいってるっぽいんですが、この記事五ヶ月前_| ̄|○
とりあえず、QT Creatorで読み込むtoolchains.xmlてのを削除すれば再作成(再検出)してくれるらしいというのを他の記事で発見。
が、QT Creatorの中のフォルダ検索してみると
C:\Qt\Tools\QtCreator\share\qtcreator\QtProject\qtcreator\toolchains.xml
これかー。
中を覗いてみると、あるぇー? mingwの設定しか無い。
msvcの設定は何処よ? とりあえずコレ消してみる。したらQT Creator上では、自動設定から手動の所にmingwが移動。msvcはそのまんま変化無し。
なんでだーとおもったら……。
QtCreator Qt 5.6.0 VS2015 - don't accept compilers
ttps://forum.qt.io/topic/65535/qtcreator-qt-5-6-0-vs2015-don-t-accept-compilers/2
C:\Users\ユーザー名\AppData\Roaming\QtProject\qtcreator\toolchains.xml
えーユーザーディレクトリに設定あるんかいっ。
よくよく一番最初のURLの記事みると
>> delete ApplicationData/...QtProject/qtcreator/toolChains.xml (or just the MSVC compilers found in that file)
て書いてあったね。見落としてたw
てかこのユーザーディレクトリに設定残すの止めて欲しいな。バージョンあがったら、たいてい互換破壊する感じなので、共用設定とか邪魔になるどころかトラブルの原因にしかならんのだけど。QTに関して言えば。
で、ユーザーディレクトリの中のtoolchains.xmlを削除。QtCreator再起動。MSVC2005だったのがちゃんとMSVC2015になってる。
これでようやくビルドできる?
……したら今度はcorecrt.hが無いとか抜かしやがる。
ググってみると
New Qt Quick application does not build with VS2015 (cannot include corecrt.h)
ttps://bugreports.qt.io/browse/QTBUG-50191
corecrt.hはWindows SDKの中にあるらしい。
あるぇー? vc++2015はWindows SDK統合とかしたんじゃなかったっけか。
それ以前に、その前にvc++2012とかの辺りでwin7用のSDK入れた記憶もあるんだけどなぁ。vc++2015入れるときには、なんかweb toolとかwin10用のSDKなんか選択画面にあったけど、それはチェック外してた気がする。
そも、GUIアプリはQTでやって、vc++はDXライブラリつかったゲーム開発用のつもりだったので、SDKとかいらんやん。てかんじだったんですが、QTのプロジェクトをビルドするのにはWindows SDK必要だとか。うへー。
C:/Program Files (x86)/Windows Kits/10/Include/10.0.10240.0/ucrt
このucrtんなかにcorecrt.hはあるんだそうな。
SDKは8GBかあるしぃ。時間掛かるのう。悔しいのう、あんちゃん……。(なんとなく無駄なものを大量に入れさせられてる感じがして気分的に……w)
こんでどうじゃーい
と思ったら今度はrc.exeが実行出来ませんとか。
rc.exeってみたまんまリソース関係っぽいんですが。見つからないじゃなくて実行出来ない?? なんかver違いとかそういう厄介なの?? win7用とwin10用ごっちゃになってる的な。
Visual Studio can't build due to rc.exe
ttp://stackoverflow.com/questions/14372706/visual-studio-cant-build-due-to-rc-exe
うーん。
どうもwin7環境の場合なら
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Bin
のなかのRC.exe と RcDll.Dllってのをvcのbinフォルダの中にいれるか、そこまでのパスを環境変数に追加しろってことらしい。
えーとwin10環境だと多分そのまま問題なかったのかな。
win7だと、RC.exeだけはwin7用のものを使わないと行けないみたいなかんじなのか。
んでもこれ、なんでファイル名へんな大文字小文字混じりなの、気持ちワルー。
とりあえず、なんかパス追加だと、win10用とwin7用同名の物があったりすると厄介なことになりそうなので、とりあえずRC.exe と RcDll.Dllをコピーする方法で試してみる。
……ビルド出来たー!!
てか、結局全部英語サイトの情報……。
ほんと日本のQT界隈寂れてるなぁ……。
あとは、公式でなく、みんなフォーラムとか外部の所ってのもなんだかなぁ。
QTはやっぱWin向けじゃなくてunix系が主導なんだなぁ。unix系なら、環境変数とか最初から整えるのが当然て心構えがあるからなぁ。
winだと、自動で追加されてるはずのものが無いとか古い設定が残ってるとかでも大騒ぎ。unix系の人からすれば情弱も良いとこだよな……(ぉ
しかし関係ないけど、vc++2015の更新インスコでSDKとか追加してたんですが……。
なにこのmsのF#のごり押し感。チェック外しても戻ってくると再チェックされてる。他の項目はそんなこと無いのにw
てか、F#て関数型言語だっけか。将来性はある分野ではあるのかもしれないけど、現時点では使ってるやつとか見たことも聞いたこともねぇよ。
将来的にはどうなるかは判らないとしても、現時点では、手段が目的になる(言語自体への興味)タイプの人以外にはなんの用もないですよね。それで何かを生産したいという目的のある人にはHDDの肥やしにしかならんぽ。
んでもってwinの環境変数の画面……windows3.1の頃から変わってないのは何で?
狭くて幅の変更も出来ないテキストボックスからしか入力出来ないとか拷問だろこれ。
そんなしょっちゅう環境変数なんて弄らないからアレだけど、今回我慢できずに外部のツールで有名どころらしいRapidEE使ってみる。
嗚呼快適。
てかMSはこの画面変えるつもり一生ないのかね(ぉ
VCディレクトリの設定もそうだし、SendToのフォルダもそうだけど、よく使う重要な機能ほど、どんどん奥のわかりにくいところに持って行くmsの方針はよくわからん……。コントロールパネルもエクスプローラに統合されたために、返って邪魔くさい感じなうえ、ちょいちょい名称も場所も変えやがるので、たまに親のノート(vista)のメンテとかさせられるときに、呼び出したい機能は分かってるのにそれが何処にあるのか判らなくて混乱することも多い。
この辺のユーザビリティの低さはほんと酷いよな……ms。
とりあえず、QT Creator上でvc++2015のコンパイラでビルド出来る用になった……。やっぱmingwより速い~。リリースビルドだとそんな遜色無いのかもだけど。
あとはvcビルドだと文字化けしないようにしないとな。
てかvcはいつまでshift-jisなんか使い続けるのだろうか……。デフォルトではshift-jisが使われるために文字化けしちゃうので。時代遅れも良いところだ。だ。なんてもう、vc++2008ぐらいのころから言われてるのになぁ。
んでも……DXライブラリの公式掲示板で、とある脆弱性のfixした報告記事のなかで管理人氏が、unicode版使ってる人はほとんどいないでしょうが……的な発言してて。
……個人的にはマルチバイト版使ってる人なんて今時いるの? 保守のために古いアプリとか使ってるところが仕方なくマルチバイト版つかってるだけでしょ? ぐらいの認識持ってたんですが。
そうでもないのかな……w
cgiとかでは、鯖はunix鯖だし、QTはutf8がデフォだし、unityもutf8がデフォだったかな。
なので、わりと早い段階でソースコードの文字コードをunicodeで運用する方向に切り替えたのですが、
DXライブラリ関係のみしかPGやらない分にはマルチバイト文字(shift-jis)でも困らないから気にすることでもないからなのかな。(_Tマクロとか無駄なもの書かなくて済むし)
そいやbom無しのutf8には対応したのだろうか……vc++2015の段階ではダメーってことを確認したのだけどもsp当たってからは確認してなかったっけな。
その所為でQTの方もbom付をデフォ設定にしてるので、今のところ同じコード同じソースファイルでもvc++でビルド来てるんですが。
とにかくまあ、これでQT上でvc++のコンパイラ使ったビルド出来る様に……。
んでもあとは……c++11回りがなぁ、QT。
auto(型推論)や可変長テンプレート回りのインテリセンスとかが効かないのがめんどくさい。clangコードモデル使うとその辺は解決するんだけど、いまのverだとどうなるか判らないケド、QT5.6のQT creator3.6、4.0だとソースコードのファイルをロックしたままハングって、ソースコードの保存が出来なくなるっていう結構致命的なバグ? 不具合があったりしたので。
そうなると、vc++とQT両方立ち上げて行き来しながらコード書く方法もありなのかなと言う気も……。
とりあえず、ひとごこちついた~。
Sun
Mon
Tue
Wed
Thu
Fri
Sat
01
02
■
■
腕がぷるぷる
03
04
05
06
■
■
形からの
07
■
■
突然死
08
■
■
思ったより早いのと遅いの
09
10
■
■
素材がない
11
■
■
やっぱ問題ありぽ
12
■
■
そんな気にする物でもなさげ?
13
14
■
■
やはり殿下
15
■
■
やっと読了
16
17
■
■
いろいろ環境みなおし
18
■
■
やっぱりだめか…
19
■
■
やったー出来たー
20
■
■
少しずつだけど
21
22
23
24
■
■
いろいろ細々と
25
26
■
■
さらに細々と
27
28
29
■
■
ムー
30
■
■
環境整備
total:2076795 t:307 y:396
■記事タイトル■
■年度別リスト■
2024年
2024年12月(0)2024年11月(0)
2024年10月(1)
2024年09月(2)
2024年08月(1)
2024年07月(1)
2024年06月(5)
2024年05月(2)
2024年04月(1)
2024年03月(6)
2024年02月(4)
2024年01月(3)
2023年
2023年12月(3)2023年11月(1)
2023年10月(2)
2023年09月(3)
2023年08月(3)
2023年07月(3)
2023年06月(7)
2023年05月(8)
2023年04月(2)
2023年03月(1)
2023年02月(2)
2023年01月(3)
2022年
2022年12月(4)2022年11月(3)
2022年10月(1)
2022年09月(3)
2022年08月(3)
2022年07月(2)
2022年06月(1)
2022年05月(3)
2022年04月(2)
2022年03月(2)
2022年02月(1)
2022年01月(6)
2021年
2021年12月(8)2021年11月(3)
2021年10月(4)
2021年09月(6)
2021年08月(2)
2021年07月(1)
2021年06月(3)
2021年05月(2)
2021年04月(2)
2021年03月(3)
2021年02月(1)
2021年01月(4)
2020年
2020年12月(3)2020年11月(7)
2020年10月(2)
2020年09月(3)
2020年08月(1)
2020年07月(3)
2020年06月(7)
2020年05月(5)
2020年04月(8)
2020年03月(4)
2020年02月(2)
2020年01月(4)
2019年
2019年12月(1)2019年11月(1)
2019年10月(2)
2019年09月(1)
2019年08月(3)
2019年07月(2)
2019年06月(2)
2019年05月(2)
2019年04月(4)
2019年03月(1)
2019年02月(7)
2019年01月(1)
2018年
2018年12月(1)2018年11月(1)
2018年10月(5)
2018年09月(1)
2018年08月(5)
2018年07月(1)
2018年06月(1)
2018年05月(1)
2018年04月(2)
2018年03月(2)
2018年02月(1)
2018年01月(1)
2017年
2017年12月(2)2017年11月(1)
2017年10月(2)
2017年09月(5)
2017年08月(8)
2017年07月(2)
2017年06月(1)
2017年05月(1)
2017年04月(3)
2017年03月(5)
2017年02月(7)
2017年01月(8)
2016年
2016年12月(7)2016年11月(2)
2016年10月(3)
2016年09月(7)
2016年08月(8)
2016年07月(10)
2016年06月(17)
2016年05月(6)
2016年04月(8)
2016年03月(10)
2016年02月(5)
2016年01月(10)
2015年
2015年12月(7)2015年11月(7)
2015年10月(13)
2015年09月(7)
2015年08月(7)
2015年07月(5)
2015年06月(4)
2015年05月(5)
2015年04月(2)
2015年03月(4)
2015年02月(1)
2015年01月(7)
2014年
2014年12月(12)2014年11月(8)
2014年10月(4)
2014年09月(6)
2014年08月(7)
2014年07月(4)
2014年06月(2)
2014年05月(5)
2014年04月(4)
2014年03月(8)
2014年02月(4)
2014年01月(8)
2013年
2013年12月(15)2013年11月(8)
2013年10月(3)
2013年09月(3)
2013年08月(8)
2013年07月(0)
2013年06月(0)
2013年05月(0)
2013年04月(0)
2013年03月(0)
2013年02月(0)
2013年01月(0)
■レス履歴■
■ファイル抽出■
■ワード検索■
堕天使の煉獄
https://rengoku.sakura.ne.jp
管理人
織田霧さくら(oda-x)
E-mail (■を@に)
oda-x■rengoku.sakura.ne.jp