quickapp_qt 模板產生出來的專案，編譯成功後，執行失敗

[orzuk-lmj]

產生專案的指令：

$ xmake create -l c++ -t quickapp_qt qt5_app
$ xmake f --qt=D:\Qt5\5.9.3
$ xmake project -k vs2015

無論是直接xmake或是開啟.sln，編譯成功後，執行時都會出現錯誤訊息：

QQmlApplicationEngine failed to load component
qrc:/main.qml:-1 No such file or directory

後來嘗試把自動生成的 .qt\qrc\qt5_app\qml.cpp 強制加入專案一起編譯，才可以正常運作。

• 請問沒有自動把qml.cpp加入編譯是否為預期中的行為? 使用者得自行加入?

[waruqi]

会自动编译进来的，我这边之前测试是可以的，回头我看下

[waruqi]

我试了下，直接xmake运行是可以的，没问题：

$ xmake create -l c++ -t quickapp_qt qt5_app
$ cd qt5_app
$ xmake
$ xmake run

qml.cpp是会正常编译进去的，运行也没问题。。

不要使用xmake project -k vs2015去创建工程，qt工程暂时还不支持vcproj工程创建，会丢失部分预处理文件的。。

[orzuk-lmj]

開發過程中， 需要debug的時候，vs系列IDE還是挺重要的工具，我們很難在流程中放棄這個。
原本打算將xmake腳本中的before_build和after_build用來作為輔助工具，意外的發現這兩者在產生出來的vs2015專案中貌似沒有被運行。

如此一來，建構流程中發生了兩個問題：

• 與cmake相比，目前xmake command和IDE project運行的過程不一致，通過plugin產生project的流程非常有可能編譯出不一樣的結果 。
• xmake的IDE文件產生器是以plugin形式存在，從解耦合的角度看來的確會讓IDE plugin比較容易寫。但是也因為運行過程不一致，讓維護多個 IDE plugin 且讓它和command一致，成為非常麻煩的事情。

舉個例子來說，我們開發過程 ps4/xbox1/pc 都必須使用到 vs2015/2017格式的sln專案檔，檔案結構其實90%內容相同，僅僅多了些額外選項可以設定；這在以往用cmake的時候，設定完編譯過程後，可以按照需要在command 和 IDE project 兩者間切換，但最終編譯結果是一樣的。

xmake是一個潛力巨大，擴充能力強大的工具，對於已經在使用lua的人來說其實具備非常大的吸引力，期望未來能更加完善 :D

[waruqi]

開發過程中， 需要debug的時候，vs系列IDE還是挺重要的工具，我們很難在流程中放棄這個。
原本打算將xmake腳本中的before_build和after_build用來作為輔助工具，意外的發現這兩者在產生出來的vs2015專案中貌似沒有被運行。

并没有放弃，只是目前xmake重点在xmake command运行为主，所以很多新特性会优先实现，但是IDE工程文件生成，毕竟依赖于第三方IDE的支持力度，很多新特性（像rules，after_xxx）要加到vcproj文件中去，会比较麻烦些

虽然也有解决办法是实现支持，但是个人时间精力有限，所以如果用户需求不强烈，我一般不会重点考虑立马支持上，还是以command模式为主，如果你有这需要，可以提issues特性请求，我会考虑排期实现，但是进度上把控，需要根据我的实际时间来安排了，可能需要等上一段时间

当然，如果用户能够帮忙贡献相关代码的话，我也是非常乐意的，这也是为什么做成了plugin方式提供出来的原因，隔离核心代码，方便维护和扩展。

與cmake相比，目前xmake command和IDE project運行的過程不一致，通過plugin產生project的流程非常有可能編譯出不一樣的結果 。

同上说明，只是暂时部分特性还不支持，cmake主推IDE生成，所以模式上是有差异的，但是cmake这种方式太过依赖第三方IDE支持力度，这样加新特性会很被动，也很受限制，比如on_install这种，即使也支持，但是不同IDE/makefile下，对用户的操作处理方式都是不一致的。。

xmake的IDE文件產生器是以plugin形式存在，從解耦合的角度看來的確會讓IDE plugin比較容易寫。但是也因為運行過程不一致，讓維護多個 IDE plugin 且讓它和command一致，成為非常麻煩的事情。

这个我上面也说了，以plugin方式提供，方便扩展，也方便贡献者参与进来帮忙贡献，与command保持一致，需要做更多的工作，因为受限于不同IDE的支持力度，所以隔离plugin/command 更有好处，这样command至少极大的提供了xmake的灵活性，一致性，新特性的快速支持。。

虽然IDE生成plugin部分功能受限制，但如果只要花时间，用户有需求，之后也会考虑支持上的，但毕竟不是xmake的重点，个人时间精力有限，所以会有些滞后，不会及时同步支持，这个也请谅解。。

[waruqi]

如果你确实急需同步支持这些，请耐心等待一段时间，后续版本如果有时间，会尽量想办法支持上去的。。

[orzuk-lmj]

關於before_build和after_build，能分享一下你傾向的實作方法嗎?
cmake貌似是另存一份腳本，並填入*.vcproj的欄位中，讓IDE在固定時候執行
現階段有 xmake l 和 xmake m 可以做類似的事情

[waruqi]

这块我还没仔细考虑，初步想法是 通过在vcproj里面对应阶段添加custom command 去执行类似 xmake l target.before_build xxx的命令去加载运行它们。。

理论上对于 before_build和after_build 以及qt的这种自定义rules里面的on_build_file 应该都可以这么搞。。

而且这种方式对于makefile，以及其他工程文件格式，支持上更加友好通用些

后期等实现的时候 ，我会更深入的研究下。。

[waruqi]

#174

[waruqi]

我会在2.2.3版本支持上

[waruqi]

近期打算先发个版本，当前版本主要还是以改进包管理为主，这个特性改进需要花点时间，因此考虑挪到下个版本实现，请耐心等待。。

[waruqi]

v2.2.4版本增加和改进的特性太多了，暂时没时间支持这个，暂定到v2.2.5版本去支持，请谅解。

[OpportunityLiu]

我觉得生成那样的 文件纯属用力过猛

下面这个绝对表现和XMake完全一致

<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <ItemGroup Label="ProjectConfigurations">
    <ProjectConfiguration Include="debug|x86">
      <Configuration>debug</Configuration>
      <Platform>x86</Platform>
    </ProjectConfiguration>
    <ProjectConfiguration Include="release|x86">
      <Configuration>release</Configuration>
      <Platform>x86</Platform>
    </ProjectConfiguration>
    <ProjectConfiguration Include="debug|x64">
      <Configuration>debug</Configuration>
      <Platform>x64</Platform>
    </ProjectConfiguration>
    <ProjectConfiguration Include="release|x64">
      <Configuration>release</Configuration>
      <Platform>x64</Platform>
    </ProjectConfiguration>
  </ItemGroup>
  <PropertyGroup Label="Globals">
    <VCProjectVersion>16.0</VCProjectVersion>
    <ProjectGuid>{4C89F191-E698-402F-B838-5275FE40C3F1}</ProjectGuid>
    <WindowsTargetPlatformVersion>10.0</WindowsTargetPlatformVersion>
    <OutDir>$(ProjectDir)build\windows\$(Platform)\$(Configuration)</OutDir>
    <TargetName>main</TargetName>
  </PropertyGroup>
  <Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
  <Import Project="$(VCTargetsPath)\Microsoft.Cpp.props" />
  <ItemGroup>
    <ClCompile Include="m.cpp" />
  </ItemGroup>
  <Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets" />
  <Target Name="Configure">
    <Message Text="Configure: mode=$(Configuration), arch=$(Platform)" />
    <Exec Command="xmake f -m $(Configuration.ToLower()) -a $(Platform.ToLower())" ConsoleToMsBuild="true" ConsoleOutput="$(XmakeBuildOutput)" />
    <Message Text="$(XmakeBuildOutput)" />
  </Target>
  <Target Name="Build">
    <Message Text="Build" />
    <CallTarget Targets="Configure"/>
    <Exec Command="xmake build" ConsoleToMsBuild="true" ConsoleOutput="$(XmakeBuildOutput)" />
    <Message Text="$(XmakeBuildOutput)" />
  </Target>
  <Target Name="Rebuild">
    <Message Text="Rebuild" />
    <CallTarget Targets="Configure"/>
    <Exec Command="xmake build -r" ConsoleToMsBuild="true" ConsoleOutput="$(XmakeBuildOutput)" />
    <Message Text="$(XmakeBuildOutput)" />
  </Target>
</Project>

C:\Users\lzy\Documents\Source\test\Project1> tree /f   
文件夹 PATH 列表
卷序列号为 0439-29D1
C:.
    .gitignore
    m.cpp
    Project1.sln
    Project1.vcxproj
    xmake.lua

没有子文件夹

[waruqi]

我觉得生成那样的 文件纯属用力过猛

下面这个绝对表现和XMake完全一致

? 把整个源文件树丢丢掉，直接wrap处理？ 现在这边遇到需要生成vcproj的用户需求，主要都是用来通过生成vcproj编译，方便断点调试的，以及vs的源码分析提示。。还有些用户需要 在vs里面尝试临时修改一些 flags的都有。。

这么搞法，怎么支持vs的调试功能呢，还有源码分析也失效了。

[OpportunityLiu]

你要分析啥？

[OpportunityLiu]

而且你在vs里选择清理会运行 $xmake f -c 的。。。

这个是不是删了比较好？

[waruqi]

我建议还是保留使用者各自的.user，这个不 add 到git里面，只在每个人本地维护呢？

[orzuk-lmj]

而且你在vs里选择清理会运行 $xmake f -c 的。。。
这个是不是删了比较好？

這也是個問題，行為模式和vs原生的不一樣容易讓人搞混，我現在都先暫時避開不使用清理了，真的需要就直接重跑建構腳本，乾淨的刪除整個目錄重建一個。

[orzuk-lmj]

我建议还是保留使用者各自的.user，这个不 add 到git里面，只在每个人本地维护呢？

就方便使用的角度來說，當然是會希望運行完建構腳本，就直接到目錄內開啟 .sln 工作。

[waruqi]

@OpportunityLiu 那只能在xmake project -k vsxmake执行生成前，先取出当前config缓存中，除plat/arch/mode以外的所有配置，预先写入.user中了。

[orzuk-lmj]

@OpportunityLiu 那只能在xmake project -k vsxmake执行生成前，先取出当前config缓存中，除plat/arch/mode以外的所有配置，预先写入.user中了。

若vsxmake 能維持著和運行 xmake config -> xmake build 一致的結果，是最好的了。
比較有疑問的是，真的有必要寫入.user中嗎? 是否能只保存在.xmake 目錄內的快取中?

[waruqi]

目前xmake config配置并不是增量配置的，每次都是全量配置，最后一次config都会覆盖之前的config

因为增量配置，处理起来过于复杂，还要考虑局部配置的依赖同步更新，也更容易导致各种bug 不好维护。。

所以现在每次config必须要敲全所有配置参数才行，常用配置可以放置在 xmake g的全局配置里面来简化

而vsxmake每次build都会去对当前选择的arch/mode进行config切换，这就会覆盖最初的命令行下的xmake config。。所以只有写入.user，在每次build config的时候，重新附带上.user里面这些附带的config才行

[orzuk-lmj]

所以现在每次config必须要敲全所有配置参数才行，常用配置可以放置在 xmake g的全局配置里面来简化

用 Jenkins CI 做測試編譯的時候，它可以正確配置全局環境變數使之正常使用，但是 xmake global 的全局配置貌似會直接寫入檔案中，有機會影響到其他準備要編譯的項目。

[waruqi]

所以现在每次config必须要敲全所有配置参数才行，常用配置可以放置在 xmake g的全局配置里面来简化

用 Jenkins CI 做測試編譯的時候，它可以正確配置全局環境變數使之正常使用，但是 xmake global 的全局配置貌似會直接寫入檔案中，有機會影響到其他準備要編譯的項目。

所以要么只有在xmake project -k vsxmake生成vcproj的开始处，提取已经xmake config配置的参数数据，写入到.user，这有这样 才能满足你这边的需求，这块的提取可以放置在 vxxmake插件里面自动处理掉，也可以你自己写脚本 自己追加进去

[orzuk-lmj]

有沒有可能讓 xmake project -k vsxmake2015 運行的時候帶入額外參數 (例如 --qt=xxx)?? 或是可以優先尋找對應的環境變數 (類似VS預設的INCLUDE這種)?

[waruqi]

有沒有可能讓 xmake project -k vsxmake2015 運行的時候帶入額外參數 (例如 --qt=xxx)?? 或是可以優先尋找對應的環境變數 (類似VS預設的INCLUDE這種)?

那就要吧所有xmake config里面的参数全部在xmake project再去定义一遍，这就冗余了，也不好维护了。。

除非透传整个config字符串到 一个 -f/--config=里面去，然后写入.user

xmake project -k vsxmake -f "--qt=xxx --xxx=aa --y=yyy" 

不过这样里面还得做config参数解析，还不如直接从先前的config中提取出来了

[OpportunityLiu]

那就这样吧

1. 清理项目的时候只运行 xmake c -a
2. 把运行xmake project时的配置存在 vcxproj里，切换配置的时候执行（可以用.users里的内容覆盖）

[waruqi]

那就这样吧

1. 清理项目的时候只运行 xmake c -a
2. 把运行xmake project时的配置存在 vcxproj里，切换配置的时候执行（可以用.users里的内容覆盖）

这样也可以

[OpportunityLiu]

怎么读config？

[waruqi]

怎么读config？

import("core.project.config")
config.load()
for name, value in pairs(config.options()) do
    -- ...
end

[OpportunityLiu]

[waruqi]

那就从config cache取原始传参，只包含用户实际的传参列表和值。

  import("core.project.cache")
  local configcache = cache("local.config")
  for name, value in pairs(configcache:get("options_all")) do
  end

[orzuk-lmj]

最新的dev分支上，改成targetinfo.sourcedirs = _make_dirs(_get_values(target, "project.vsxmake.sourcedirs")) 之後，取值就失敗了，.vcxproj 內的<XmakeSourceDirs>為空。

[OpportunityLiu]

写错键名了。。

xmake/xmake/plugins/project/vsxmake/getinfo.lua

Line 162 in fab4373

targetinfo.sourcedirs = _make_dirs(_get_values(target, "project.vsxmake.sourcedirs"))

这里应该改成 "values.project.vsxmake.sourcedirs"

@waruqi 不想再开PR了，你直接改了吧

[waruqi]

@OpportunityLiu 改了，这种小改动，直接github上，对应lua文件点 edit编辑直接改下就行了。。

[orzuk-lmj]

@waruqi 、 @OpportunityLiu 非常感謝兩位幫助，使用了一段時間都沒遇到問題。
這個issues就先關了，我等 2.2.8 發布後再詳細測看看，到時候有遇到狀況再另開一個來討論。

[waruqi]

尽管 vsxmake 已经支持 rules 和 qt project 构建，不过等 2.5.1 的 #1247 和 #1246 里面提到的特性实现后，重写部分qt rules，走batchcmds，那么老的 vs generator 也能够实现对 qt project 和 rules 的构建支持了。。

包括其他的 generator，比如 compile_commands，... 等等将来都会一个个支持上 rules (with batchcmds)