text:
qt5 静态链接， 无法打开输入文件“Qt5PlatformSupport.lib”

注：提问题时若使用不能用/没效果/有问题/报错此类模糊表达，但又没有根据下面的模板给出任何相关辅助信息的，将会直接标记为Invalid。

描述问题
qt 5.12.9 静态链接  无法打开输入文件“Qt5PlatformSupport.lib”
期待的结果
请尽量清晰精准地描述你所期待的结果。
错误信息
PS D:\test\testqt> xmake f -a x64
checking for Microsoft Visual Studio (x64) version ... 2019
checking for Qt SDK directory ... C:/qt/Qt5.12X64
checking for Qt SDK version ... 5.12.9
PS D:\test\testqt> xmake
[ 25%]: compiling.qt.moc src\widget.h
[ 75%]: compiling.release build.qt\plugin\testqt\static_import.cpp
[ 87%]: linking.release testqt.exe
error: LINK : fatal error LNK1181: 无法打开输入文件“Qt5PlatformSupport.lib”
warning: target(testqt).add_includedirs("C:\qt\Qt5.12X64\include\QtPlatformSupport") path not found at @programdir\rules\qt\load.lua:211
warning: add -v for getting more warnings ..
PS D:\test\testqt>
相关环境
请提供编译和运行环境信息，下面是一些必须填写的基础信息，便于我们针对性排查问题：

xmake版本：
xmake运行平台：vs 2019
xmake目标平台：windows 10

其他信息
请提供其他附加信息帮助我们诊断问题(比如截图，xmake.lua或者可复现的demo)，以及你遇到的问题的一些背景信息。

静态链接 得用支持静态链接的qt sdk，给我看下 你这 Qt5PlatformSupport.lib 所在库路径，确认下库是否，如果你的qt sdk里面没有这个库，那就支持不了了
我记得这个库应该是必须的

编译的qt静态库，qtcreator 编译运行没问题。
https://github.com/xmake-io/xmake/issues/619
"Qt5PlatformSupport" has been renamed to “Qt5PlatformCompositorSupport” after Qt 5.9
Starting with QT 5.9+ Qt5PlatformSupport.lib is no longer available and has been split into different libraries. To create a static build under windows one needs to link the following additional libraries:
Qt5FontDatabaseSupport.lib
Qt5EventDispatcherSupport.lib
Qt5ThemeSupport.lib
Qt5PlatformCompositorSupport.lib
Qt5AccessibilitySupport.lib
Qt5WindowsUiAutomationSupport.lib
qwindows.lib
and load the windows plugin statically:
#include
Q_IMPORT_PLUGIN (QWindowsIntegrationPlugin);

那就是5.9改名了 我回头改下

你再更新下试试呢

参考 ：https://stackoverflow.com/questions/57373791/using-qt-static-what-lib-is-required-for-qwindowsguieventdispatcher-qwindows
release（MT）需要添加
add_links("Version", "Userenv","Netapi32", "Dwmapi", "wtsapi32")
add_links("Qt5WindowsUiAutomationSupport", "Qt5FontDatabaseSupport", "Qt5ThemeSupport","Qt5EventDispatcherSupport")
debug（MTd）需要添加
add_cxflags("/MTd")
qt_add_static_plugins("QSvgPlugin", {linkdirs = "plugins/imageformats", links = {"qsvgd"}})
add_links("Qt5WindowsUiAutomationSupportd", "Qt5FontDatabaseSupportd", "Qt5ThemeSupportd","Qt5EventDispatcherSupportd")
可以正常编译运行，目前使用的是
xmake.lua
add_rules("mode.debug", "mode.release")
includes("qt_add_static_plugins.lua")
target("qttt")
add_rules("qt.widgetapp_static")
add_headerfiles("src/.h")
add_files("src/.cpp")
add_files("src/mainwindow.ui")
--add_cxflags("/MD")
-- add files with Q_OBJECT meta (only for qt.moc)
add_files("src/mainwindow.h")
add_links("Version", "Userenv","Netapi32", "Dwmapi", "wtsapi32")
if is_mode("debug") then
    add_cxflags("/MTd")
    add_links("Qt5WindowsUiAutomationSupportd", "Qt5FontDatabaseSupportd", "Qt5ThemeSupportd","Qt5EventDispatcherSupportd")
else
    add_links("Qt5WindowsUiAutomationSupport", "Qt5FontDatabaseSupport", "Qt5ThemeSupport","Qt5EventDispatcherSupport")
end

-- add plugin: QSvgPlugin (optional)
add_frameworks("QtSvg")
if is_mode("debug") then
    qt_add_static_plugins("QSvgPlugin", {linkdirs = "plugins/imageformats", links = {"qsvgd"}})
else
    qt_add_static_plugins("QSvgPlugin", {linkdirs = "plugins/imageformats", links = {"qsvg"}})
end

参考 ：https://stackoverflow.com/questions/57373791/using-qt-static-what-lib-is-required-for-qwindowsguieventdispatcher-qwindows
release（MT）需要添加
add_links("Version", "Userenv","Netapi32", "Dwmapi", "wtsapi32")
add_links("Qt5WindowsUiAutomationSupport", "Qt5FontDatabaseSupport", "Qt5ThemeSupport","Qt5EventDispatcherSupport")
debug（MTd）需要添加
add_cxflags("/MTd")
qt_add_static_plugins("QSvgPlugin", {linkdirs = "plugins/imageformats", links = {"qsvgd"}})
add_links("Qt5WindowsUiAutomationSupportd", "Qt5FontDatabaseSupportd", "Qt5ThemeSupportd","Qt5EventDispatcherSupportd")
可以正常编译运行，目前使用的是
xmake.lua
add_rules("mode.debug", "mode.release")
includes("qt_add_static_plugins.lua")
target("qttt")
add_rules("qt.widgetapp_static")
add_headerfiles("src/.h") add_files("src/.cpp")
add_files("src/mainwindow.ui")
--add_cxflags("/MD")
-- add files with Q_OBJECT meta (only for qt.moc)
add_files("src/mainwindow.h")
add_links("Version", "Userenv","Netapi32", "Dwmapi", "wtsapi32")
if is_mode("debug") then
    add_cxflags("/MTd")
    add_links("Qt5WindowsUiAutomationSupportd", "Qt5FontDatabaseSupportd", "Qt5ThemeSupportd","Qt5EventDispatcherSupportd")
else
    add_links("Qt5WindowsUiAutomationSupport", "Qt5FontDatabaseSupport", "Qt5ThemeSupport","Qt5EventDispatcherSupport")
end

-- add plugin: QSvgPlugin (optional)
add_frameworks("QtSvg")
if is_mode("debug") then
    qt_add_static_plugins("QSvgPlugin", {linkdirs = "plugins/imageformats", links = {"qsvgd"}})
else
    qt_add_static_plugins("QSvgPlugin", {linkdirs = "plugins/imageformats", links = {"qsvg"}})
end

https://github.com/xmake-io/xmake/issues/1031
1031的问题是qt5.6.3的，当前问题是qt5.12.9

?? 现在到底还有啥问题呢？你刚反馈的 Qt5PlatformSupport 的问题，到底解了么？

?? 现在到底还有啥问题呢？你刚反馈的 Qt5PlatformSupport 的问题，到底解了么？

已经解决了，主要是报告给你一下
qt5.12.9 需要添加
add_links("Version", "Userenv","Netapi32", "Dwmapi", "wtsapi32")
add_links("Qt5WindowsUiAutomationSupport", "Qt5FontDatabaseSupport", "Qt5ThemeSupport","Qt5EventDispatcherSupport")

哦 这块我回头会补进去

关于静态库链接和插件这块，我下版本会稍微做些重构，来简化配置，当前2.3.9版本暂时先不动了，我最近会先发个版。

关于静态库链接和插件这块，我下版本会稍微做些重构，来简化配置，当前2.3.9版本暂时先不动了，我最近会先发个版。

未来版本是否可以考虑识别vcpkg的qt sdk？

关于静态库链接和插件这块，我下版本会稍微做些重构，来简化配置，当前2.3.9版本暂时先不动了，我最近会先发个版。

未来版本是否可以考虑识别vcpkg的qt sdk？

这个看情况吧 最近issues排满了，下个版本也不一定有时间搞这个，vcpkg的qt结构完全不同，弄起来很花时间，还得处理3个平台
还是先把常用的qt sdk搞好再说吧

好的，已经解决了。谢谢

repo: xmake-io/xmake


text:
Linker/package error building with package ("fmt") on MinGW

Note of interest, I use xmake on Windows with MSVC and with MinGW, usually via MSYS2. fmt is installed and works with MSVC and clang toolchains.
Issue
The mingw build fails at the linker stage. Here is the -vD output for the config and build stages from a MSYS2/mingw64 shell - it never tries to build fmt for mingw:
dev>:/c/sandpit/fmt-test$ xmake f -cv
checking for architecture ... x86_64
checking for mingw directory ... C:/dev/msys64/mingw64
checking for unzip ... ok
checking for git ... ok
checking for gzip ... ok
checking for tar ... ok
checking for ping ... ok
pinging for the host(github.com) ... 27 ms
pinging for the host(gitlab.com) ... 93 ms
pinging for the host(gitee.com) ... 216 ms
checking for xmake::fmt ... no
checking for vswhere.exe ... C:\Program Files (x86)\Microsoft Visual Studio\Installer\vswhere.exe
checking for vcpkg ... C:\dev\tools\vcpkg\vcpkg
checking for fmt ... no
checking for Microsoft Visual Studio (x86_64) version ... no
please run:
    - xmake config --vs=xxx [--vs_toolset=xxx]
or  - xmake global --vs=xxx
dev>:/c/sandpit/fmt-test$ xmake -rvD
checking for C:\dev\msys64\mingw64\bin\x86_64-w64-mingw32-g++ ... ok
checking for flags (-fvisibility-inlines-hidden) ... ok
> x86_64-w64-mingw32-g++ "-fvisibility-inlines-hidden"
checking for flags (-O3) ... ok
> x86_64-w64-mingw32-g++ "-O3"
checking for ccache ... no
[ 50%]: compiling.release src\main.cpp
C:\dev\msys64\mingw64\bin\x86_64-w64-mingw32-g++ -c -fvisibility=hidden -fvisibility-inlines-hidden -O3 -isystem C:\Users\paul-\AppData\Local\.xmake\packages\f\fmt\7.1.3\775bdf9fb7cd40bc83dfdff5782ee263\include -o build\.objs\sandpit\windows\x64\release\src\main.cpp.obj src\main.cpp
checking for flags (-MMD -MF) ... ok
> x86_64-w64-mingw32-g++ "-MMD" "-MF" "C:\dev\msys64\tmp\.xmake\201207\_FE235770079144608B077FD3C37DFDA0"
checking for flags (-fcolor-diagnostics) ... no
> x86_64-w64-mingw32-g++ "-fcolor-diagnostics"
checkinfo: @programdir\core\sandbox\modules\os.lua:258: x86_64-w64-mingw32-g++: error: unrecognized command-line option '-fcolor-diagnostics'

stack traceback:
    [C]: in function 'error'
    [@programdir\core\base\os.lua:789]: in function 'raise'
    [@programdir\core\sandbox\modules\os.lua:258]: in function 'runv'
    [@programdir\modules\detect\tools\gcc\has_flags.lua:42]:
    [C]: in function 'trycall'
    [@programdir\core\sandbox\modules\try.lua:121]: in function 'try'
    [@programdir\modules\detect\tools\gcc\has_flags.lua:42]: in function 'hasflags'
    [@programdir\modules\lib\detect\has_flags.lua:115]: in function 'has_flags'
    [@programdir\modules\core\tools\gcc.lua:367]: in function '_has_color_diagnostics'
    [@programdir\modules\core\tools\gcc.lua:444]:
    [C]: in function 'trycall'
    [@programdir\core\sandbox\modules\try.lua:121]: in function 'try'
    [@programdir\modules\core\tools\gcc.lua:429]:
    [C]: in function 'compile'
    [@programdir\modules\private\action\build\object.lua:78]: in function 'script'
    [@programdir\modules\private\action\build\object.lua:91]: in function '_build_object'
    [@programdir\modules\private\action\build\object.lua:116]: in function 'jobfunc'
    [@programdir\modules\private\async\runjobs.lua:188]:
    [C]: in function 'trycall'
    [@programdir\core\sandbox\modules\try.lua:121]: in function 'try'
    [@programdir\modules\private\async\runjobs.lua:182]: in function 'cotask'
    [@programdir\core\base\scheduler.lua:317]:
checking for flags (-fdiagnostics-color=always) ... ok
> x86_64-w64-mingw32-g++ "-fdiagnostics-color=always"
[ 75%]: linking.release sandpit.exe
C:\dev\msys64\mingw64\bin\x86_64-w64-mingw32-g++ -o build\windows\x64\release\sandpit.exe build\.objs\sandpit\windows\x64\release\src\main.cpp.obj -s -LC:\Users\paul-\AppData\Local\.xmake\packages\f\fmt\7.1.3\775bdf9fb7cd40bc83dfdff5782ee263\lib -lfmt
error: @programdir\modules\private\async\runjobs.lua:210: @programdir\actions\build\kinds\binary.lua:73: @programdir\core\sandbox\modules\os.lua:258: C:/dev/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: build\.objs\sandpit\windows\x64\release\src\main.cpp.obj:main.cpp:(.text.startup+0x4e): undefined reference to `fmt::v7::vprint(fmt::v7::basic_string_view<char>, fmt::v7::format_args)'
collect2.exe: error: ld returned 1 exit status

stack traceback:
    [C]: in function 'error'
    [@programdir\core\base\os.lua:789]: in function 'raise'
    [@programdir\core\sandbox\modules\os.lua:258]: in function 'runv'
    [@programdir\modules\core\tools\gcc.lua:356]:
    [C]: in function 'link'
    [@programdir\actions\build\kinds\binary.lua:73]: in function 'callback'
    [@programdir\modules\core\project\depend.lua:186]: in function 'on_changed'
    [@programdir\actions\build\kinds\binary.lua:54]: in function '_do_link_target'
    [@programdir\actions\build\kinds\binary.lua:94]:
    [@programdir\actions\build\kinds\binary.lua:115]: in function '_link_target'
    [@programdir\actions\build\kinds\binary.lua:137]: in function 'jobfunc'
    [@programdir\modules\private\async\runjobs.lua:188]:
    [C]: in function 'trycall'
    [@programdir\core\sandbox\modules\try.lua:121]: in function 'try'
    [@programdir\modules\private\async\runjobs.lua:182]: in function 'cotask'
    [@programdir\core\base\scheduler.lua:317]:

stack traceback:
        [C]: in function 'error'
        @programdir\core\base\os.lua:789: in function 'raise'
        @programdir\modules\private\async\runjobs.lua:210: in function 'catch'
        @programdir\core\sandbox\modules\try.lua:127: in function 'try'
        @programdir\modules\private\async\runjobs.lua:182: in function 'cotask'
        @programdir\core\base\scheduler.lua:317: in function <@programdir\core\base\scheduler.lua:315>

Expected behavior
For the xmake-repo package to be downloaded and linked against.
Related Environment
Please provide compiling and running environment information:

xmake version: xmake v2.3.9+202011262021
os: Win10
target platform: mingw

I have fixed it on dev branch, you try it again.

Thanks, I am getting a new error caused by /EHsc being passed to g++ :
dev>:/c/sandpit/fmt-test$ xmake f -cv
checking for architecture ... x86_64
checking for mingw directory ... C:/dev/msys64/mingw64
checking for unzip ... ok
checking for git ... ok
checking for gzip ... ok
checking for tar ... ok
checking for ping ... ok
pinging for the host(gitlab.com) ... 21 ms
pinging for the host(github.com) ... 79 ms
pinging for the host(gitee.com) ... 232 ms
checking for xmake::fmt ... no
checking for vswhere.exe ... C:\Program Files (x86)\Microsoft Visual Studio\Installer\vswhere.exe
checking for vcpkg ... C:\dev\tools\vcpkg\vcpkg
checking for fmt ... no
checking for Microsoft Visual Studio (x86_64) version ... no
please run:
    - xmake config --vs=xxx [--vs_toolset=xxx]
or  - xmake global --vs=xxx
dev>:/c/sandpit/fmt-test$ xmake -rvD
checking for C:\dev\msys64\mingw64\bin\x86_64-w64-mingw32-g++ ... ok
checking for flags (-fvisibility-inlines-hidden) ... no
> x86_64-w64-mingw32-g++ "-fvisibility-inlines-hidden" "/EHsc"
checkinfo: @programdir\core\sandbox\modules\os.lua:258: x86_64-w64-mingw32-g++: error: /EHsc: No such file or directory

stack traceback:
    [C]: in function 'error'
    [@programdir\core\base\os.lua:789]: in function 'raise'
    [@programdir\core\sandbox\modules\os.lua:258]: in function 'runv'
    [@programdir\modules\detect\tools\gcc\has_flags.lua:42]:
    [C]: in function 'trycall'
    [@programdir\core\sandbox\modules\try.lua:121]: in function 'try'
    [@programdir\modules\detect\tools\gcc\has_flags.lua:42]: in function 'hasflags'
    [@programdir\modules\lib\detect\has_flags.lua:115]: in function 'has_flags'
    [@programdir\modules\core\tools\gcc.lua:98]: in function 'mapper'
    [@programdir\core\tool\builder.lua:353]: in function '_add_flags_from_language'
    [@programdir\core\tool\builder.lua:191]: in function '_add_flags_from_target'
    [@programdir\core\tool\compiler.lua:318]: in function 'compflags'
    [@programdir\modules\private\action\build\object.lua:42]: in function 'script'
    [@programdir\modules\private\action\build\object.lua:91]: in function '_build_object'
    [@programdir\modules\private\action\build\object.lua:116]: in function 'jobfunc'
    [@programdir\modules\private\async\runjobs.lua:188]:
    [C]: in function 'trycall'
    [@programdir\core\sandbox\modules\try.lua:121]: in function 'try'
    [@programdir\modules\private\async\runjobs.lua:182]: in function 'cotask'
    [@programdir\core\base\scheduler.lua:317]:
checking for flags (-O3) ... no
> x86_64-w64-mingw32-g++ "-O3" "/EHsc"
checkinfo: @programdir\core\sandbox\modules\os.lua:258: x86_64-w64-mingw32-g++: error: /EHsc: No such file or directory

stack traceback:
    [C]: in function 'error'
    [@programdir\core\base\os.lua:789]: in function 'raise'
    [@programdir\core\sandbox\modules\os.lua:258]: in function 'runv'
    [@programdir\modules\detect\tools\gcc\has_flags.lua:42]:
    [C]: in function 'trycall'
    [@programdir\core\sandbox\modules\try.lua:121]: in function 'try'
    [@programdir\modules\detect\tools\gcc\has_flags.lua:42]: in function 'hasflags'
    [@programdir\modules\lib\detect\has_flags.lua:115]: in function 'has_flags'
    [@programdir\core\tool\builder.lua:354]: in function '_add_flags_from_language'
    [@programdir\core\tool\builder.lua:191]: in function '_add_flags_from_target'
    [@programdir\core\tool\compiler.lua:318]: in function 'compflags'
    [@programdir\modules\private\action\build\object.lua:42]: in function 'script'
    [@programdir\modules\private\action\build\object.lua:91]: in function '_build_object'
    [@programdir\modules\private\action\build\object.lua:116]: in function 'jobfunc'
    [@programdir\modules\private\async\runjobs.lua:188]:
    [C]: in function 'trycall'
    [@programdir\core\sandbox\modules\try.lua:121]: in function 'try'
    [@programdir\modules\private\async\runjobs.lua:182]: in function 'cotask'
    [@programdir\core\base\scheduler.lua:317]:
checking for ccache ... no
[ 50%]: compiling.release src\main.cpp
C:\dev\msys64\mingw64\bin\x86_64-w64-mingw32-g++ -c /EHsc -fvisibility=hidden -isystem C:\Users\paul-\AppData\Local\.xmake\packages\f\fmt\7.1.3\775bdf9fb7cd40bc83dfdff5782ee263\include -o build\.objs\sandpit\windows\x64\release\src\main.cpp.obj src\main.cpp
checking for flags (-MMD -MF) ... no
> x86_64-w64-mingw32-g++ "-MMD" "-MF" "C:\dev\msys64\tmp\.xmake\201207\_B14FE4C5E24B4B508A9E3E551632C770" "/EHsc"
checkinfo: @programdir\core\sandbox\modules\os.lua:258: x86_64-w64-mingw32-g++: error: /EHsc: No such file or directory

stack traceback:
    [C]: in function 'error'
    [@programdir\core\base\os.lua:789]: in function 'raise'
    [@programdir\core\sandbox\modules\os.lua:258]: in function 'runv'
    [@programdir\modules\detect\tools\gcc\has_flags.lua:42]:
    [C]: in function 'trycall'
    [@programdir\core\sandbox\modules\try.lua:121]: in function 'try'
    [@programdir\modules\detect\tools\gcc\has_flags.lua:42]: in function 'hasflags'
    [@programdir\modules\lib\detect\has_flags.lua:115]: in function 'has_flags'
    [@programdir\modules\core\tools\gcc.lua:434]:
    [C]: in function 'trycall'
    [@programdir\core\sandbox\modules\try.lua:121]: in function 'try'
    [@programdir\modules\core\tools\gcc.lua:429]:
    [C]: in function 'compile'
    [@programdir\modules\private\action\build\object.lua:78]: in function 'script'
    [@programdir\modules\private\action\build\object.lua:91]: in function '_build_object'
    [@programdir\modules\private\action\build\object.lua:116]: in function 'jobfunc'
    [@programdir\modules\private\async\runjobs.lua:188]:
    [C]: in function 'trycall'
    [@programdir\core\sandbox\modules\try.lua:121]: in function 'try'
    [@programdir\modules\private\async\runjobs.lua:182]: in function 'cotask'
    [@programdir\core\base\scheduler.lua:317]:
checking for flags (-fcolor-diagnostics) ... no
> x86_64-w64-mingw32-g++ "-fcolor-diagnostics" "/EHsc"
checkinfo: @programdir\core\sandbox\modules\os.lua:258: x86_64-w64-mingw32-g++: error: /EHsc: No such file or directory
x86_64-w64-mingw32-g++: error: unrecognized command-line option '-fcolor-diagnostics'

stack traceback:
    [C]: in function 'error'
    [@programdir\core\base\os.lua:789]: in function 'raise'
    [@programdir\core\sandbox\modules\os.lua:258]: in function 'runv'
    [@programdir\modules\detect\tools\gcc\has_flags.lua:42]:
    [C]: in function 'trycall'
    [@programdir\core\sandbox\modules\try.lua:121]: in function 'try'
    [@programdir\modules\detect\tools\gcc\has_flags.lua:42]: in function 'hasflags'
    [@programdir\modules\lib\detect\has_flags.lua:115]: in function 'has_flags'
    [@programdir\modules\core\tools\gcc.lua:367]: in function '_has_color_diagnostics'
    [@programdir\modules\core\tools\gcc.lua:444]:
    [C]: in function 'trycall'
    [@programdir\core\sandbox\modules\try.lua:121]: in function 'try'
    [@programdir\modules\core\tools\gcc.lua:429]:
    [C]: in function 'compile'
    [@programdir\modules\private\action\build\object.lua:78]: in function 'script'
    [@programdir\modules\private\action\build\object.lua:91]: in function '_build_object'
    [@programdir\modules\private\action\build\object.lua:116]: in function 'jobfunc'
    [@programdir\modules\private\async\runjobs.lua:188]:
    [C]: in function 'trycall'
    [@programdir\core\sandbox\modules\try.lua:121]: in function 'try'
    [@programdir\modules\private\async\runjobs.lua:182]: in function 'cotask'
    [@programdir\core\base\scheduler.lua:317]:
checking for flags (-fdiagnostics-color=always) ... no
> x86_64-w64-mingw32-g++ "-fdiagnostics-color=always" "/EHsc"
checkinfo: @programdir\core\sandbox\modules\os.lua:258: x86_64-w64-mingw32-g++: error: /EHsc: No such file or directory

stack traceback:
    [C]: in function 'error'
    [@programdir\core\base\os.lua:789]: in function 'raise'
    [@programdir\core\sandbox\modules\os.lua:258]: in function 'runv'
    [@programdir\modules\detect\tools\gcc\has_flags.lua:42]:
    [C]: in function 'trycall'
    [@programdir\core\sandbox\modules\try.lua:121]: in function 'try'
    [@programdir\modules\detect\tools\gcc\has_flags.lua:42]: in function 'hasflags'
    [@programdir\modules\lib\detect\has_flags.lua:115]: in function 'has_flags'
    [@programdir\modules\core\tools\gcc.lua:370]: in function '_has_color_diagnostics'
    [@programdir\modules\core\tools\gcc.lua:444]:
    [C]: in function 'trycall'
    [@programdir\core\sandbox\modules\try.lua:121]: in function 'try'
    [@programdir\modules\core\tools\gcc.lua:429]:
    [C]: in function 'compile'
    [@programdir\modules\private\action\build\object.lua:78]: in function 'script'
    [@programdir\modules\private\action\build\object.lua:91]: in function '_build_object'
    [@programdir\modules\private\action\build\object.lua:116]: in function 'jobfunc'
    [@programdir\modules\private\async\runjobs.lua:188]:
    [C]: in function 'trycall'
    [@programdir\core\sandbox\modules\try.lua:121]: in function 'try'
    [@programdir\modules\private\async\runjobs.lua:182]: in function 'cotask'
    [@programdir\core\base\scheduler.lua:317]:
error: @programdir\modules\private\async\runjobs.lua:210: @programdir\modules\private\action\build\object.lua:78: @programdir\modules\core\tools\gcc.lua:480: x86_64-w64-mingw32-g++: error: /EHsc: No such file or directory
stack traceback:
    [C]: in function 'error'
    [@programdir\core\base\os.lua:789]: in function 'raise'
    [@programdir\modules\core\tools\gcc.lua:480]: in function 'catch'
    [@programdir\core\sandbox\modules\try.lua:127]: in function 'try'
    [@programdir\modules\core\tools\gcc.lua:429]:
    [C]: in function 'compile'
    [@programdir\modules\private\action\build\object.lua:78]: in function 'script'
    [@programdir\modules\private\action\build\object.lua:91]: in function '_build_object'
    [@programdir\modules\private\action\build\object.lua:116]: in function 'jobfunc'
    [@programdir\modules\private\async\runjobs.lua:188]:
    [C]: in function 'trycall'
    [@programdir\core\sandbox\modules\try.lua:121]: in function 'try'
    [@programdir\modules\private\async\runjobs.lua:182]: in function 'cotask'
    [@programdir\core\base\scheduler.lua:317]:

stack traceback:
        [C]: in function 'error'
        @programdir\core\base\os.lua:789: in function 'raise'
        @programdir\modules\private\async\runjobs.lua:210: in function 'catch'
        @programdir\core\sandbox\modules\try.lua:127: in function 'try'
        @programdir\modules\private\async\runjobs.lua:182: in function 'cotask'
        @programdir\core\base\scheduler.lua:317: in function <@programdir\core\base\scheduler.lua:315>

That works from MSYS2/mingw64 shell now, thanks!
Should we also be able to build with MinGW installed via MSYS2/mingw64 in a non-MSYS2 shell? See below...

➜  fmt-test xmake f --toolchain=mingw
checking for architecture ... x64
checking for mingw directory ... C:/dev/msys64/mingw64
checking for Microsoft Visual Studio (x64) version ... 2019
➜  fmt-test xmake f -v --toolchain=mingw
configure
{
    kind = static
    toolchain = mingw
    mingw = C:/dev/msys64/mingw64
    vs = 2019
    arch = x64
    mode = release
    buildir = build
    cross = x86_64-w64-mingw32-
    theme = default
    bin = C:\dev\msys64\mingw64\bin
    plat = windows
    proxy_pac = pac.lua
    ndk_stdcxx = true
    clean = true
    ccache = true
    network = public
    host = windows
}
➜  fmt-test xmake -rv
checking for x86_64-w64-mingw32-g++ ... C:\dev\msys64\mingw64\bin\x86_64-w64-mingw32-g++
checking for the linker (ld) ... x86_64-w64-mingw32-g++
checking for the c++ compiler (cxx) ... x86_64-w64-mingw32-g++
checking for C:\dev\msys64\mingw64\bin\x86_64-w64-mingw32-g++ ... ok
checking for flags (-fvisibility-inlines-hidden) ... ok
checking for flags (-O3) ... ok
checking for ccache ... no
[ 50%]: compiling.release src\main.cpp
C:\dev\msys64\mingw64\bin\x86_64-w64-mingw32-g++ -c -fvisibility=hidden -fvisibility-inlines-hidden -O3 -isystem C:\Users\paul-\AppData\Local\.xmake\packages\f\fmt\7.1.3\775bdf9fb7cd40bc83dfdff5782ee263\include -o build\.objs\sandpit\windows\x64\release\src\main.cpp.obj src\main.cpp
checking for flags (-MMD -MF) ... ok
checking for flags (-fcolor-diagnostics) ... no
checking for flags (-fdiagnostics-color=always) ... ok
[ 75%]: linking.release sandpit.exe
C:\dev\msys64\mingw64\bin\x86_64-w64-mingw32-g++ -o build\windows\x64\release\sandpit.exe build\.objs\sandpit\windows\x64\release\src\main.cpp.obj -s -LC:\Users\paul-\AppData\Local\.xmake\packages\f\fmt\7.1.3\775bdf9fb7cd40bc83dfdff5782ee263\lib -lfmt
error: C:/dev/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: build\.objs\sandpit\windows\x64\release\src\main.cpp.obj:main.cpp:(.text.startup+0x4e): undefined reference to `fmt::v7::vprint(fmt::v7::basic_string_view<char>, fmt::v7::format_args)'
collect2.exe: error: ld returned 1 exit status

Hi, I think you might have missed the question there.
It does not work when building from Windows using mingw64 installed in MSYS2 (see log in previous comment). Should this work? Also should mingw builds check for Visual Studio and vcpkg?

xmake f --toolchain=mingw

Please use xmake f -p mingw -c
Currently installing dependent packages only supports judging by platform.
Just switch the toolchain, then the package you actually install is still fmt for msvc.

Aaaah, that explains it. Everything working now, thanks very much!

source: gharchive/issue

authors: paul-reilly waruqi

license_type: permissive

license_source: github-api


text:
add_filegroups with empty group name

Xmake Version
2.7.7
Operating System Version and Architecture
Windows 10 version 1909
Describe Bug
Creating a filegroup with no name have an inconsistant behaviour with a named group. (also note the empty filter and the '.' filter)

Expected Behavior
The filtered files should be at the project's root.

Project Configuration
Folders structure:
\---project
    |   xmake.lua
    |
    \---src
        |   main.cpp
        |
        \---folder1
                source1.cpp

xmake.lua:
target("named_group_default_mode")
	add_files("src/**.cpp")
	add_filegroups("group", {rootdir = "src", files = "**.cpp"})

target("unnamed_group_default_mode")
	add_files("src/**.cpp")
	add_filegroups("", {rootdir = "src", files = "**.cpp"})

target("named_group_plain_mode")
	add_files("src/**.cpp")
	add_filegroups("group", {rootdir = "src", files = "**.cpp", mode = "plain"})

target("unnamed_group_plain_mode")
	add_files("src/**.cpp")
	add_filegroups("", {rootdir = "src", files = "**.cpp", mode = "plain"})

project.zip
Additional Information and Error Logs
No response

Try it again, xmake update -s dev
BTW, why do you want to use empty string as filegroup. It's invalid group name for xmake.

ok, so does it work now?

No it doesn't on dev

? dot group has been removed

try it again.

Does it work now?

authors: WubiCookie waruqi


text:
使用 Clang 工具链为 MinGW 目标平台安装基于 CMake 的包时出错

Xmake 版本
xmake v2.9.6+HEAD.abd15c255
操作系统版本和架构
Windows 10
描述问题
在目标平台设置为 MinGW 的情况下，使用 Clang 工具链安装基于 CMake 的包时，CMake 在创建静态库阶段报错。
这可能是 XMake 在调用 CMake 时传递了参数 -DCMAKE_AR=ar.exe，CMake 将此认为是 ar 的绝对路径，从而引发错误。
期待的结果
能正常使用 Clang 工具链为 MinGW 平台安装基于 CMake 的包
工程配置
xrepo install -vD -p mingw --toolchain=clang gflags
附加信息和错误日志
日志
$ xrepo install -vD -p mingw --toolchain=clang gflags
D:\projects\xmake\core\build\xmake.exe f -c --require=n -vD -p mingw --toolchain=clang
checking for architecture ... x86_64
checking for clang ... ok
configure
{
    mode = release
    clean = true
    mingw = D:/Applications/Scoop/apps/mingw-mstorsjo-llvm-ucrt/current/
    proxy = socks5://127.0.0.1:20170
    theme = default
    ndk_stdcxx = true
    proxy_pac = pac.lua
    toolchain = clang
    plat = mingw
    buildir = build
    host = windows
    ccache = true
    network = public
    kind = static
    arch = x86_64
}
D:\projects\xmake\core\build\xmake.exe require -v -D -j 14 --extra={system=false} gflags
checking for git ... ok
checking for gzip ... ok
checking for tar ... ok
git rev-parse HEAD
checking for cl.exe ... C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.42.34433\bin\HostX64\x64\cl.exe
checking for Microsoft Visual Studio (x64) version ... 2022
checking for Microsoft C/C++ Compiler (x64) version ... 19.42.34435
checkinfo: cannot runv(nim.exe --version), No such file or directory
checking for nim ... no
checkinfo: cannot runv(nim.exe --version), No such file or directory
checking for nim ... no
checking for cmake ... no
checking for cmake ... no
checking for cmake ... no
checking for cmake ... ok
finding gflags from xmake ..
checking for xmake::gflags ... no
note: install or modify (m) these packages (pass -y to skip confirm)?
in myrepo:
  -> gflags v2.2.2 [toolchains:"clang", license:BSD-3-Clause]
please input: y (y/n/m)

checking for ping ... ok
pinging the host(github.com) ... 106 ms
tar -xf C:\Users\leemu\AppData\Local\.xmake\cache\packages\2412\g\gflags\v2.2.2\v2.2.2.tar.gz
patching D:\projects\xmake-repo\packages\g\gflags\patches\v2.2.2\fix-cmake.patch to gflags-v2.2.2 ..
applying patch C:\Users\leemu\AppData\Local\Temp\.xmake\241216\patches\gflags\v2.2.2\fix-cmake.patch
git apply --reject --ignore-whitespace C:\Users\leemu\AppData\Local\Temp\.xmake\241216\patches\gflags\v2.2.2\fix-cmake.patch
Checking patch cmake/config.cmake.in...
Applied patch cmake/config.cmake.in cleanly.
checking for clang ... ok
checking for the c compiler (cc) ... clang
checking for clang ... ok
checking for the c++ compiler (cxx) ... clang
checking for ninja ... ok
checking for clang ... ok
checking for the assember (as) ... clang
checking for ar ... ok
checking for the static library archiver (ar) ... ar
checking for ranlib ... ok
checking for the archive index generator (ranlib) ... ranlib
checking for llvm-rc ... ok
checking for the windows resource compiler (mrc) ... llvm-rc
checking for clang++ ... ok
checking for the linker (ld) ... clang++
checking for clang++ ... ok
checking for the shared library linker (sh) ... clang++
checking for pkg-config ... ok
checking for cmake ... ok
checking for pkg-config ... ok
cmake -DBUILD_TESTING=OFF -DGFLAGS_REGISTER_BUILD_DIR=OFF -DGFLAGS_REGISTER_INSTALL_PREFIX=OFF -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=OFF -DBUILD_STATIC_LIBS=ON -DBUILD_gflags_LIB=ON -DBUILD_gflags_nothreads_LIB=OFF -DCMAKE_POSITION_INDEPENDENT_CODE=ON -DCMAKE_INSTALL_PREFIX=C:\Users\leemu\AppData\Local\.xmake\packages\g\gflags\v2.2.2\6758891cfbde4f4cb92634e6368a5498 -DCMAKE_INSTALL_LIBDIR:PATH=lib -G Ninja "-DCMAKE_MODULE_LINKER_FLAGS=-m64 --target=x86_64-w64-windows-gnu" -DCMAKE_SYSTEM_PROCESSOR=x86_64 -DHAVE_FLAG_SEARCH_PATHS_FIRST=0 -DCMAKE_MAKE_PROGRAM=ninja -DCMAKE_C_COMPILER=clang.exe -DCMAKE_OSX_SYSROOT= -DCMAKE_FIND_ROOT_PATH_MODE_PROGRAM=NEVER -DCMAKE_FIND_ROOT_PATH_MODE_INCLUDE=BOTH "-DCMAKE_CXX_FLAGS=-m64 --target=x86_64-w64-windows-gnu" -DCMAKE_FIND_ROOT_PATH_MODE_LIBRARY=BOTH -DCMAKE_ASM_COMPILER=clang.exe "-DCMAKE_C_FLAGS=-m64 --target=x86_64-w64-windows-gnu" -DCMAKE_STATIC_LINKER_FLAGS= -DCMAKE_FIND_ROOT_PATH=D:/Applications/Scoop/apps/mingw-mstorsjo-llvm-ucrt/current/ "-DCMAKE_EXE_LINKER_FLAGS=-m64 --target=x86_64-w64-windows-gnu" -DCMAKE_FIND_ROOT_PATH_MODE_PACKAGE=BOTH -DCMAKE_RANLIB=ranlib.exe "-DCMAKE_SHARED_LINKER_FLAGS=-m64 --target=x86_64-w64-windows-gnu" -DCMAKE_AR=ar.exe -DCMAKE_RC_COMPILER=llvm-rc.exe "-DCMAKE_ASM_FLAGS=-m64 --target=x86_64-w64-windows-gnu" -DCMAKE_CXX_COMPILER=clang++.exe "-DCMAKE_EXE_LINKER_FLAGS_RELEASE=-m64 --target=x86_64-w64-windows-gnu" "-DCMAKE_SHARED_LINKER_FLAGS_RELEASE=-m64 --target=x86_64-w64-windows-gnu" "-DCMAKE_C_FLAGS_RELEASE=-m64 --target=x86_64-w64-windows-gnu -O3 -DNDEBUG" -DCMAKE_STATIC_LINKER_FLAGS_RELEASE= "-DCMAKE_CXX_FLAGS_RELEASE=-m64 --target=x86_64-w64-windows-gnu -O3 -DNDEBUG" C:\Users\leemu\AppData\Local\.xmake\cache\packages\2412\g\gflags\v2.2.2\source
CMake Deprecation Warning at CMakeLists.txt:73 (cmake_minimum_required):
  Compatibility with CMake < 3.10 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value.  Or, use the <min>...<max> syntax
  to tell CMake that the project requires at least <min> but has been updated
  to work with policies introduced by <max> or earlier.

-- The CXX compiler identification is Clang 19.1.5
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: D:/Applications/Scoop/apps/mingw-mstorsjo-llvm-ucrt/current/bin/clang++.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Looking for C++ include unistd.h
-- Looking for C++ include unistd.h - found
-- Looking for C++ include stdint.h
-- Looking for C++ include stdint.h - found
-- Looking for C++ include inttypes.h
-- Looking for C++ include inttypes.h - found
-- Looking for C++ include sys/types.h
-- Looking for C++ include sys/types.h - found
-- Looking for C++ include sys/stat.h
-- Looking for C++ include sys/stat.h - found
-- Looking for C++ include fnmatch.h
-- Looking for C++ include fnmatch.h - not found
-- Looking for C++ include shlwapi.h
-- Looking for C++ include shlwapi.h - found
-- Looking for C++ include stddef.h
-- Looking for C++ include stddef.h - found
-- Check size of uint32_t
-- Check size of uint32_t - done
-- Looking for strtoll
-- Looking for strtoll - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Check size of pthread_rwlock_t
-- Check size of pthread_rwlock_t - failed
-- Configuring done (6.3s)
-- Generating done (0.1s)
CMake Warning:
  Manually-specified variables were not used by the project:

    CMAKE_ASM_COMPILER
    CMAKE_ASM_FLAGS
    CMAKE_C_COMPILER
    CMAKE_C_FLAGS
    CMAKE_C_FLAGS_RELEASE
    CMAKE_FIND_ROOT_PATH
    CMAKE_FIND_ROOT_PATH_MODE_LIBRARY
    CMAKE_INSTALL_LIBDIR
    HAVE_FLAG_SEARCH_PATHS_FIRST

-- Build files have been written to: C:/Users/leemu/AppData/Local/.xmake/cache/packages/2412/g/gflags/v2.2.2/source/build_6758891c
checking for pkg-config ... ok
ninja install -C C:\Users\leemu\AppData\Local\.xmake\cache\packages\2412\g\gflags\v2.2.2\source\build_6758891c -v -j 14
ninja: Entering directory `C:\Users\leemu\AppData\Local\.xmake\cache\packages\2412\g\gflags\v2.2.2\source\build_6758891c'
[1/6] D:\Applications\Scoop\apps\mingw-mstorsjo-llvm-ucrt\current\bin\clang++.exe -DGFLAGS_IS_A_DLL=0 -IC:/Users/leemu/AppData/Local/.xmake/cache/packages/2412/g/gflags/v2.2.2/source/build_6758891c/include -IC:/Users/leemu/AppData/Local/.xmake/cache/packages/2412/g/gflags/v2.2.2/source/src -IC:/Users/leemu/AppData/Local/.xmake/cache/packages/2412/g/gflags/v2.2.2/source/build_6758891c/include/gflags -m64 --target=x86_64-w64-windows-gnu -m64 --target=x86_64-w64-windows-gnu -O3 -DNDEBUG -MD -MT CMakeFiles/gflags_static.dir/src/windows_port.cc.obj -MF CMakeFiles\gflags_static.dir\src\windows_port.cc.obj.d -o CMakeFiles/gflags_static.dir/src/windows_port.cc.obj -c C:/Users/leemu/AppData/Local/.xmake/cache/packages/2412/g/gflags/v2.2.2/source/src/windows_port.cc
[2/6] D:\Applications\Scoop\apps\mingw-mstorsjo-llvm-ucrt\current\bin\clang++.exe -DGFLAGS_IS_A_DLL=0 -IC:/Users/leemu/AppData/Local/.xmake/cache/packages/2412/g/gflags/v2.2.2/source/build_6758891c/include -IC:/Users/leemu/AppData/Local/.xmake/cache/packages/2412/g/gflags/v2.2.2/source/src -IC:/Users/leemu/AppData/Local/.xmake/cache/packages/2412/g/gflags/v2.2.2/source/build_6758891c/include/gflags -m64 --target=x86_64-w64-windows-gnu -m64 --target=x86_64-w64-windows-gnu -O3 -DNDEBUG -MD -MT CMakeFiles/gflags_static.dir/src/gflags_reporting.cc.obj -MF CMakeFiles\gflags_static.dir\src\gflags_reporting.cc.obj.d -o CMakeFiles/gflags_static.dir/src/gflags_reporting.cc.obj -c C:/Users/leemu/AppData/Local/.xmake/cache/packages/2412/g/gflags/v2.2.2/source/src/gflags_reporting.cc
[3/6] D:\Applications\Scoop\apps\mingw-mstorsjo-llvm-ucrt\current\bin\clang++.exe -DGFLAGS_IS_A_DLL=0 -IC:/Users/leemu/AppData/Local/.xmake/cache/packages/2412/g/gflags/v2.2.2/source/build_6758891c/include -IC:/Users/leemu/AppData/Local/.xmake/cache/packages/2412/g/gflags/v2.2.2/source/src -IC:/Users/leemu/AppData/Local/.xmake/cache/packages/2412/g/gflags/v2.2.2/source/build_6758891c/include/gflags -m64 --target=x86_64-w64-windows-gnu -m64 --target=x86_64-w64-windows-gnu -O3 -DNDEBUG -MD -MT CMakeFiles/gflags_static.dir/src/gflags_completions.cc.obj -MF CMakeFiles\gflags_static.dir\src\gflags_completions.cc.obj.d -o CMakeFiles/gflags_static.dir/src/gflags_completions.cc.obj -c C:/Users/leemu/AppData/Local/.xmake/cache/packages/2412/g/gflags/v2.2.2/source/src/gflags_completions.cc
[4/6] D:\Applications\Scoop\apps\mingw-mstorsjo-llvm-ucrt\current\bin\clang++.exe -DGFLAGS_IS_A_DLL=0 -IC:/Users/leemu/AppData/Local/.xmake/cache/packages/2412/g/gflags/v2.2.2/source/build_6758891c/include -IC:/Users/leemu/AppData/Local/.xmake/cache/packages/2412/g/gflags/v2.2.2/source/src -IC:/Users/leemu/AppData/Local/.xmake/cache/packages/2412/g/gflags/v2.2.2/source/build_6758891c/include/gflags -m64 --target=x86_64-w64-windows-gnu -m64 --target=x86_64-w64-windows-gnu -O3 -DNDEBUG -MD -MT CMakeFiles/gflags_static.dir/src/gflags.cc.obj -MF CMakeFiles\gflags_static.dir\src\gflags.cc.obj.d -o CMakeFiles/gflags_static.dir/src/gflags.cc.obj -c C:/Users/leemu/AppData/Local/.xmake/cache/packages/2412/g/gflags/v2.2.2/source/src/gflags.cc
[5/6] C:\Windows\system32\cmd.exe /C "cd . && D:\Applications\Scoop\apps\cmake\3.31.2\bin\cmake.exe -E rm -f lib\libgflags_static.a && C:\Users\leemu\AppData\Local\.xmake\cache\packages\2412\g\gflags\v2.2.2\source\build_6758891c\ar.exe qc lib\libgflags_static.a  CMakeFiles/gflags_static.dir/src/gflags.cc.obj CMakeFiles/gflags_static.dir/src/gflags_reporting.cc.obj CMakeFiles/gflags_static.dir/src/gflags_completions.cc.obj CMakeFiles/gflags_static.dir/src/windows_port.cc.obj && C:\Users\leemu\AppData\Local\.xmake\cache\packages\2412\g\gflags\v2.2.2\source\build_6758891c\ranlib.exe lib\libgflags_static.a && cd ."
FAILED: lib/libgflags_static.a
C:\Windows\system32\cmd.exe /C "cd . && D:\Applications\Scoop\apps\cmake\3.31.2\bin\cmake.exe -E rm -f lib\libgflags_static.a && C:\Users\leemu\AppData\Local\.xmake\cache\packages\2412\g\gflags\v2.2.2\source\build_6758891c\ar.exe qc lib\libgflags_static.a  CMakeFiles/gflags_static.dir/src/gflags.cc.obj CMakeFiles/gflags_static.dir/src/gflags_reporting.cc.obj CMakeFiles/gflags_static.dir/src/gflags_completions.cc.obj CMakeFiles/gflags_static.dir/src/windows_port.cc.obj && C:\Users\leemu\AppData\Local\.xmake\cache\packages\2412\g\gflags\v2.2.2\source\build_6758891c\ranlib.exe lib\libgflags_static.a && cd ."
'C:\Users\leemu\AppData\Local\.xmake\cache\packages\2412\g\gflags\v2.2.2\source\build_6758891c\ar.exe' is not recognized as an internal or external command,
operable program or batch file.
ninja: build stopped: subcommand failed.
error: @programdir\core\sandbox\modules\os.lua:378: execv(ninja install -C C:\Users\leemu\AppData\Local\.xmake\cache\packages\2412\g\gflags\v2.2.2\source\build_6758891c -v -j 14) failed(1)
stack traceback:
    [C]: in function 'error'
    [@programdir\core\base\os.lua:1004]:
    [@programdir\core\sandbox\modules\os.lua:378]:
    [@programdir\core\sandbox\modules\os.lua:291]: in function 'vrunv'
    [@programdir\modules\package\tools\ninja.lua:64]: in function 'install'
    [@programdir\modules\package\tools\cmake.lua:1168]: in function '_install_for_ninja'
    [@programdir\modules\package\tools\cmake.lua:1369]: in function 'install'
    [D:\projects\xmake-repo\packages\g\gflags\xmake.lua:44]: in function 'script'
    [...dir\modules\private\action\require\impl\utils\filter.lua:114]: in function 'call'
    [...\modules\private\action\require\impl\actions\install.lua:452]:

  => install gflags v2.2.2 .. failed

Update
设置工具链为 GCC 也有相同的问题
$ xrepo install -vD -p mingw --toolchain=gcc --mingw=D:/Applications/Scoop/apps/mingw/current yaml-cpp
D:\Applications\Scoop\apps\xmake\current\xmake.exe f -c --require=n -vD -p mingw --toolchain=gcc --mingw=D:/Applications/Scoop/apps/mingw/current
checking for architecture ... x86_64
checking for gcc ... ok
configure
{
    theme = default
    mode = release
    arch = x86_64
    mingw = D:/Applications/Scoop/apps/mingw/current
    toolchain = gcc
    buildir = build
    plat = mingw
    proxy_pac = pac.lua
    host = windows
    network = public
    proxy = socks5://127.0.0.1:20170
    kind = static
    ccache = true
    clean = true
    ndk_stdcxx = true
}
D:\Applications\Scoop\apps\xmake\current\xmake.exe require -v -D -j 14 --extra={system=false} yaml-cpp
checking for git ... ok
checking for gzip ... ok
checking for tar ... ok
git rev-parse HEAD
checking for cl.exe ... C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.42.34433\bin\HostX64\x64\cl.exe
checking for Microsoft Visual Studio (x64) version ... 2022
checking for Microsoft C/C++ Compiler (x64) version ... 19.42.34435
checkinfo: cannot runv(nim.exe --version), No such file or directory
checking for nim ... no
checkinfo: cannot runv(nim.exe --version), No such file or directory
checking for nim ... no
checking for cmake ... no
checking for cmake ... no
checking for cmake ... no
checking for cmake ... ok
finding yaml-cpp from xmake ..
checking for xmake::yaml-cpp ... no
note: install or modify (m) these packages (pass -y to skip confirm)?
in myrepo:
  -> yaml-cpp 0.8.0 [toolchains:"gcc", license:MIT]
please input: y (y/n/m)

checking for ping ... ok
pinging the host(github.com) ... 106 ms
tar -xf C:\Users\leemu\AppData\Local\.xmake\cache\packages\2412\y\yaml-cpp\0.8.0\0.8.0.tar.gz
checking for gcc ... ok
checking for the c compiler (cc) ... gcc
checking for gcc ... ok
checking for the c++ compiler (cxx) ... gcc
checking for ninja ... ok
checking for gcc ... ok
checking for the assember (as) ... gcc
checking for ar ... ok
checking for the static library archiver (ar) ... ar
checking for ranlib ... ok
checking for the archive index generator (ranlib) ... ranlib
checking for g++ ... ok
checking for the linker (ld) ... g++
checking for g++ ... ok
checking for the shared library linker (sh) ... g++
checking for pkg-config ... ok
checking for cmake ... ok
checking for pkg-config ... ok
cmake -DYAML_CPP_BUILD_TESTS=OFF -DCMAKE_BUILD_TYPE=Release -DYAML_BUILD_SHARED_LIBS=OFF -DCMAKE_INSTALL_PREFIX=C:\Users\leemu\AppData\Local\.xmake\packages\y\yaml-cpp\0.8.0\81efb4d5e6bf4e9a9a812b90113de55e -DCMAKE_INSTALL_LIBDIR:PATH=lib -G Ninja -DCMAKE_MODULE_LINKER_FLAGS=-m64 -DCMAKE_FIND_ROOT_PATH_MODE_PACKAGE=BOTH -DCMAKE_CXX_COMPILER=g++.exe -DCMAKE_STATIC_LINKER_FLAGS= -DCMAKE_FIND_ROOT_PATH=D:/Applications/Scoop/apps/mingw/current -DCMAKE_CXX_FLAGS=-m64 -DCMAKE_SHARED_LINKER_FLAGS=-m64 -DCMAKE_SYSTEM_PROCESSOR=x86_64 -DHAVE_FLAG_SEARCH_PATHS_FIRST=0 -DCMAKE_AR=ar.exe -DCMAKE_C_FLAGS=-m64 -DCMAKE_FIND_ROOT_PATH_MODE_LIBRARY=BOTH -DCMAKE_MAKE_PROGRAM=ninja -DCMAKE_EXE_LINKER_FLAGS=-m64 -DCMAKE_OSX_SYSROOT= -DCMAKE_FIND_ROOT_PATH_MODE_PROGRAM=NEVER -DCMAKE_ASM_COMPILER=gcc.exe -DCMAKE_C_COMPILER=gcc.exe -DCMAKE_RANLIB=ranlib.exe -DCMAKE_ASM_FLAGS=-m64 -DCMAKE_FIND_ROOT_PATH_MODE_INCLUDE=BOTH -DCMAKE_STATIC_LINKER_FLAGS_RELEASE= -DCMAKE_SHARED_LINKER_FLAGS_RELEASE=-m64 "-DCMAKE_CXX_FLAGS_RELEASE=-m64 -O3 -DNDEBUG" "-DCMAKE_C_FLAGS_RELEASE=-m64 -O3 -DNDEBUG" -DCMAKE_EXE_LINKER_FLAGS_RELEASE=-m64 C:\Users\leemu\AppData\Local\.xmake\cache\packages\2412\y\yaml-cpp\0.8.0\source

（中间省略）

[34/40] D:\Applications\Scoop\apps\mingw-mstorsjo-llvm-ucrt\current\bin\g++.exe -DYAML_CPP_STATIC_DEFINE -IC:/Users/leemu/AppData/Local/.xmake/cache/packages/2412/y/yaml-cpp/0.8.0/source/include -IC:/Users/leemu/AppData/Local/.xmake/cache/packages/2412/y/yaml-cpp/0.8.0/source/src -m64 -m64 -O3 -DNDEBUG -std=gnu++11 -Wall -Wextra -Wshadow -Weffc++ -Wno-long-long -pedantic -pedantic-errors -MD -MT CMakeFiles/yaml-cpp.dir/src/scantoken.cpp.obj -MF CMakeFiles\yaml-cpp.dir\src\scantoken.cpp.obj.d -o CMakeFiles/yaml-cpp.dir/src/scantoken.cpp.obj -c C:/Users/leemu/AppData/Local/.xmake/cache/packages/2412/y/yaml-cpp/0.8.0/source/src/scantoken.cpp
[35/40] C:\Windows\system32\cmd.exe /C "cd . && D:\Applications\Scoop\apps\cmake\3.31.2\bin\cmake.exe -E rm -f libyaml-cpp.a && C:\Users\leemu\AppData\Local\Temp\.xmake\241217\_B78CBF63B2CF483083B5B093F8539A50.dir\ar.exe qc libyaml-cpp.a  CMakeFiles/yaml-cpp.dir/src/contrib/graphbuilder.cpp.obj CMakeFiles/yaml-cpp.dir/src/contrib/graphbuilderadapter.cpp.obj CMakeFiles/yaml-cpp.dir/src/binary.cpp.obj CMakeFiles/yaml-cpp.dir/src/convert.cpp.obj CMakeFiles/yaml-cpp.dir/src/depthguard.cpp.obj CMakeFiles/yaml-cpp.dir/src/directives.cpp.obj CMakeFiles/yaml-cpp.dir/src/emit.cpp.obj CMakeFiles/yaml-cpp.dir/src/emitfromevents.cpp.obj CMakeFiles/yaml-cpp.dir/src/emitter.cpp.obj CMakeFiles/yaml-cpp.dir/src/emitterstate.cpp.obj CMakeFiles/yaml-cpp.dir/src/emitterutils.cpp.obj CMakeFiles/yaml-cpp.dir/src/exceptions.cpp.obj CMakeFiles/yaml-cpp.dir/src/exp.cpp.obj CMakeFiles/yaml-cpp.dir/src/memory.cpp.obj CMakeFiles/yaml-cpp.dir/src/node.cpp.obj CMakeFiles/yaml-cpp.dir/src/node_data.cpp.obj CMakeFiles/yaml-cpp.dir/src/nodebuilder.cpp.obj CMakeFiles/yaml-cpp.dir/src/nodeevents.cpp.obj CMakeFiles/yaml-cpp.dir/src/null.cpp.obj CMakeFiles/yaml-cpp.dir/src/ostream_wrapper.cpp.obj CMakeFiles/yaml-cpp.dir/src/parse.cpp.obj CMakeFiles/yaml-cpp.dir/src/parser.cpp.obj CMakeFiles/yaml-cpp.dir/src/regex_yaml.cpp.obj CMakeFiles/yaml-cpp.dir/src/scanner.cpp.obj CMakeFiles/yaml-cpp.dir/src/scanscalar.cpp.obj CMakeFiles/yaml-cpp.dir/src/scantag.cpp.obj CMakeFiles/yaml-cpp.dir/src/scantoken.cpp.obj CMakeFiles/yaml-cpp.dir/src/simplekey.cpp.obj CMakeFiles/yaml-cpp.dir/src/singledocparser.cpp.obj CMakeFiles/yaml-cpp.dir/src/stream.cpp.obj CMakeFiles/yaml-cpp.dir/src/tag.cpp.obj && C:\Users\leemu\AppData\Local\Temp\.xmake\241217\_B78CBF63B2CF483083B5B093F8539A50.dir\ranlib.exe libyaml-cpp.a && cd ."
FAILED: libyaml-cpp.a
C:\Windows\system32\cmd.exe /C "cd . && D:\Applications\Scoop\apps\cmake\3.31.2\bin\cmake.exe -E rm -f libyaml-cpp.a && C:\Users\leemu\AppData\Local\Temp\.xmake\241217\_B78CBF63B2CF483083B5B093F8539A50.dir\ar.exe qc libyaml-cpp.a  CMakeFiles/yaml-cpp.dir/src/contrib/graphbuilder.cpp.obj CMakeFiles/yaml-cpp.dir/src/contrib/graphbuilderadapter.cpp.obj CMakeFiles/yaml-cpp.dir/src/binary.cpp.obj CMakeFiles/yaml-cpp.dir/src/convert.cpp.obj CMakeFiles/yaml-cpp.dir/src/depthguard.cpp.obj CMakeFiles/yaml-cpp.dir/src/directives.cpp.obj CMakeFiles/yaml-cpp.dir/src/emit.cpp.obj CMakeFiles/yaml-cpp.dir/src/emitfromevents.cpp.obj CMakeFiles/yaml-cpp.dir/src/emitter.cpp.obj CMakeFiles/yaml-cpp.dir/src/emitterstate.cpp.obj CMakeFiles/yaml-cpp.dir/src/emitterutils.cpp.obj CMakeFiles/yaml-cpp.dir/src/exceptions.cpp.obj CMakeFiles/yaml-cpp.dir/src/exp.cpp.obj CMakeFiles/yaml-cpp.dir/src/memory.cpp.obj CMakeFiles/yaml-cpp.dir/src/node.cpp.obj CMakeFiles/yaml-cpp.dir/src/node_data.cpp.obj CMakeFiles/yaml-cpp.dir/src/nodebuilder.cpp.obj CMakeFiles/yaml-cpp.dir/src/nodeevents.cpp.obj CMakeFiles/yaml-cpp.dir/src/null.cpp.obj CMakeFiles/yaml-cpp.dir/src/ostream_wrapper.cpp.obj CMakeFiles/yaml-cpp.dir/src/parse.cpp.obj CMakeFiles/yaml-cpp.dir/src/parser.cpp.obj CMakeFiles/yaml-cpp.dir/src/regex_yaml.cpp.obj CMakeFiles/yaml-cpp.dir/src/scanner.cpp.obj CMakeFiles/yaml-cpp.dir/src/scanscalar.cpp.obj CMakeFiles/yaml-cpp.dir/src/scantag.cpp.obj CMakeFiles/yaml-cpp.dir/src/scantoken.cpp.obj CMakeFiles/yaml-cpp.dir/src/simplekey.cpp.obj CMakeFiles/yaml-cpp.dir/src/singledocparser.cpp.obj CMakeFiles/yaml-cpp.dir/src/stream.cpp.obj CMakeFiles/yaml-cpp.dir/src/tag.cpp.obj && C:\Users\leemu\AppData\Local\Temp\.xmake\241217\_B78CBF63B2CF483083B5B093F8539A50.dir\ranlib.exe libyaml-cpp.a && cd ."
'C:\Users\leemu\AppData\Local\Temp\.xmake\241217\_B78CBF63B2CF483083B5B093F8539A50.dir\ar.exe' is not recognized as an internal or external command,
operable program or batch file.
ninja: build stopped: subcommand failed.
error: @programdir\core\sandbox\modules\os.lua:378: execv(ninja install -C C:\Users\leemu\AppData\Local\Temp\.xmake\241217\_B78CBF63B2CF483083B5B093F8539A50.dir -v -j 14) failed(1)

可以 --toolchain=mingw，或者不设置 toolchain 。这其实不算是个问题


text:
Issue request: import of csv with paired keyword and expansion

Thanks for such a great tool!
It would be amazing to be able to bulk import/export a table containing keyword and expansion pairs.

Hi @low-decarie
That's something I had in mind a long time ago and forgot to add it as a feature request. Thanks a lot.
In you case, what would be the source of your CSV file? Another text expanding software, I guess.

There are a few sources in mind.  Among other things, we have a document that has hundreds of commonly used acronyms and their explanation.  I would add an underscore to each acronym to create a keyword that would lead to the expansion of the acronym. I would also like to share Beeftext groups with colleagues.  Thanks again for such a great tool!

OK Thanks.
I thinks I will implement CSV file support as a first step.

This could also be great for sharing combo groups!  For example, I put some work into creating a list of LaTeX macros that map onto Unicode characters (eg. \alpha → α) and another for emojis (eg. :D → 😄).  Having a way to share these would bring the power of collaborative development to Beeftext.

I finally implemented CSV import and export. It will be included in Beeftext 5.0.
More info in the dedicated wiki page.
You can grab test builds if you are willing to test:

Installer.
Portable Edition.

Note: the file format for combo lists has changed since the official 4.0 release, so if you rollback to the official release, you will get an error message on startup stating that the combo list file was created by a newer version of the application.  To fix that:

Close Beeftext.
Open your combo list file (located by default at %LOCALAPPDATA%\beeftext.org\Beeftext\comboList.json).
Locate the key fileFormatVersion and change its value from 6 to 5.
Save the file and relaunch Beeftext.

authors: low-decarie rikblok xmichelo

repo: xmichelo/Beeftext

license: MIT


text:
Improve Layout Documentation, Add Screenshots

Problem Description
We need to audit all of the layout modules and improve their documentation.  Many don't even say what they do or are very confusing.  It would also be nice to take a screenshot of each layout and include it in the xmonad wiki with a link to the screenshot in the module documentation.
What to do?

Add a bullet item to the layouts wiki page
List the name of the layout and its description
Add the layout to your xmonad configuration (or to xmonad-testing), load up some impressive looking windows, and take a screenshot.
Check the layout off the list in this issue

Module Checklist

[ ] Accordion.hs
[ ] AutoMaster.hs
[ ] AvoidFloats.hs
[ ] BinaryColumn.hs
[ ] BinarySpacePartition.hs
[ ] BorderResize.hs
[ ] BoringWindows.hs
[ ] ButtonDecoration.hs
[ ] CenteredMaster.hs
[ ] Circle.hs
[ ] Column.hs
[ ] Combo.hs
[ ] ComboP.hs
[ ] Cross.hs
[ ] Decoration.hs
[ ] DecorationAddons.hs
[ ] DecorationMadness.hs
[ ] Dishes.hs
[ ] MultiDishes.hs
[ ] DragPane.hs
[ ] DraggingVisualizer.hs
[ ] Drawer.hs
[ ] Dwindle.hs
[ ] DwmStyle.hs
[ ] FixedColumn.hs
[ ] Fullscreen.hs
[ ] Gaps.hs
[ ] Grid.hs
[ ] GridVariants.hs
[ ] Groups.hs
[ ] Groups.Examples.hs
[ ] Groups.Helpers.hs
[ ] Groups.Wmii.hs
[ ] Hidden.hs
[ ] HintedGrid.hs
[ ] HintedTile.hs
[ ] IM.hs
[ ] IfMax.hs
[ ] ImageButtonDecoration.hs
[ ] IndependentScreens.hs
[ ] LayoutBuilder.hs
[ ] LayoutBuilderP.hs
[ ] LayoutCombinators.hs
[ ] LayoutHints.hs
[ ] LayoutModifier.hs
[ ] LayoutScreens.hs
[ ] LimitWindows.hs
[ ] MagicFocus.hs
[x] Magnifier.hs
[ ] Master.hs
[ ] Maximize.hs
[ ] MessageControl.hs
[ ] Minimize.hs
[ ] Monitor.hs
[ ] Mosaic.hs
[ ] MosaicAlt.hs
[ ] MouseResizableTile.hs
[ ] MultiColumns.hs
[ ] MultiToggle.hs
[ ] MultiToggle.Instances.hs
[ ] MultiToggle.TabBarDecoration.hs
[ ] Named.hs
[ ] NoBorders.hs
[ ] NoFrillsDecoration.hs
[ ] OnHost.hs
[ ] OneBig.hs
[ ] PerScreen.hs
[ ] PerWorkspace.hs
[ ] PositionStoreFloat.hs
[ ] Reflect.hs
[ ] Renamed.hs
[ ] ResizableTile.hs
[ ] ResizableThreeColumns.hs
[ ] ResizeScreen.hs
[ ] Roledex.hs
[ ] ShowWName.hs
[ ] SimpleDecoration.hs
[ ] SimpleFloat.hs
[ ] Simplest.hs
[ ] SimplestFloat.hs
[ ] SortedLayout.hs
[ ] Spacing.hs
[ ] Spiral.hs
[ ] Square.hs
[ ] StackTile.hs
[ ] StateFull.hs
[ ] Stoppable.hs
[ ] SubLayouts.hs
[ ] TabBarDecoration.hs
[ ] Tabbed.hs
[ ] TallMastersCombo.hs
[ ] ThreeColumns.hs
[ ] ToggleLayouts.hs
[ ] TrackFloating.hs
[ ] TwoPane.hs
[ ] TwoPanePersistent.hs
[ ] VoidBorders.hs
[ ] WindowArranger.hs
[ ] WindowNavigation.hs
[ ] WindowSwitcherDecoration.hs
[ ] WorkspaceDir.hs
[ ] ZoomRow.hs

I expect that several people are going to be involved in this issue.  Things I would love to see come out of this:

Identify overlapping functionality between multiple layouts that could be merged into a single module.  In other words, let's clean up the layouts, many of them do the same thing (i.e., LayoutBuilder and Combo).

Deprecate older novelty layouts such as Roledex.  We might need to take a vote on which layouts should be deprecated.

Remove all of the redundant comments that mention how to modify your configuration file.  Let's move that out into proper documentation somewhere.  Each layout can then focus on describing its own features.

Anything else?

To make this a bit easier, let's break this issue into several phases and we'll focus on phase one for now.
Phase 1: Document all of the existing layouts.  For each layout:

Add a bullet item to the layouts wiki page

List the name of the layout and its description

Add the layout to your xmonad configuration (or to xmonad-testing), load up some impressive looking windows, and take a screenshot.

Check the layout off the list in this issue

For now let's focus on concrete layouts.  That is, skip layout combinators and layout modifiers.

I went ahead and split up all the modules into two groups: Modifiers and Layouts and for the layouts I included a short description with a minimal setup to get a working layoutHook for a screenshot session. Also I started gathering information about possible changes (see here), these are just first ideas. Any opinions/suggestions about these? How should we continue from here?
About the screenshots: What's impressive looking? Should it be a light or dark theme? Should the layout be kept unmodified, ie. no spacing or noFrillsDeco, what background image etc.?
Another suggestion would be to just generate/create a visual description like the image below (possibly add a red border around the master)? (Some of) these could also be transformed/converted to *.xbm files and used in statusbars which would be cool.

This is a great idea. I spent the last two days configuring XMonad and the docs can definitely be improved regarding the layouts.
However, I think the approach suggested here is not the primary way to go. The approach sketched here, using phases, works if someone would systematically go through all the layouts and documents them. But seeing how little activity this issue has seen, I doubt that this is going to happen.
Therefore I would suggest a more ad hoc way approach. 1) Create an issue to start a discussion about an aspect of the layouts. Be it overlapping functionality, suggestion to deprecate, etc. This way there won't be multiple discussion going on in the comments of this issue. 2) From the new issue link back to this issue. Now this issue can act as an overview and as a place more meta discussions; for example, the visual description suggestion of bforte.
I am not familiar with the way GitHub handles and groups issues, but it seems rather simplistic. So this is what I came up with.

Any thoughts on the screenshot style? Or does my ricing-idea seem good?

Maybe you could post an example screenshot?  But I also think that the focus should really be on the layout in question

Perhaps using thick borders instead of gaps could also increase the contrast

Progress update: spent a few hours making layouts. I'm almost ready to run the script. Just need to fix some ambiguous names...

@mikenrafter what's the state of this?  It would really be neat if we could include it in 0.17.1 (which may or may not be released soon-ish)

As far as I'm concerned, it's all good, use as you please. I'll add a license so it's clearer.

As far as I'm concerned, it's all production-ready.

Oh, I see; thanks!  You said that some required manual intervention, so I figured you were still trying things out.  Would you like to prepare a PR with these then?
As a side-note, I'm not sure I get the joke

What do you call Linux' bodyguards with no balls? | Unix

and perhaps these "official" pictures would do good without that :)

As a side-note, I'm not sure I get the joke

What do you call Linux' bodyguards with no balls? | Unix

"Eunuchs"

Basically what I'd love to see is this level of clarity. It doesn't need to be perfectly clean, but the background color seems like an easy win. :-)

I probably mentioned this in IRC, but to have it on record: cleaner images compress way better, whereas what we have here so far is on the order of dozens/hundreds of megabytes, which is just too much IMO.

authors: bforte geekosaur liskin mikenrafter pjones slotThe xrvdg

repo: xmonad/xmonad-contrib

license_source: bigquery


text:
added support for ToPlainText for pipetables extension

This PR adds support for ToPlainText for the pipetables extension. Before this, it would simply return all the table html elements, and render plaintext within the table. With this PR, all the table elements are removed from the plaintext output as you would expect as a result of ToPlainText

Thanks1

Pull Request Test Coverage Report for Build 2463374125

97 of 97 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.005%) to 93.206%

Totals

Change from base Build 2457016649:
0.005%

Covered Lines:
25783

Relevant Lines:
27035

💛  - Coveralls

source: gharchive/pull-request

authors: PaulVrugt coveralls xoofx

repo: xoofx/markdig


text:
🛑 Design Swan is down

In 3031e6d, Design Swan (https://www.designswan.com) was down:

HTTP code: 500
Response time: 97 ms

Resolved: Design Swan is back up in 4d18a9a.

repo: xoryorz/upptime


text:
🛑 Design Swan is down

In e41f8ab, Design Swan (https://www.designswan.com) was down:

HTTP code: 500
Response time: 88 ms

Resolved: Design Swan is back up in a23587f.


text:
🛑 Design Swan is down

In 0538ad8, Design Swan (https://www.designswan.com) was down:

HTTP code: 500
Response time: 90 ms

Resolved: Design Swan is back up in 898eb24 after 33 minutes.


text:
🛑 Design Swan is down

In ba677e9, Design Swan (https://www.designswan.com) was down:

HTTP code: 500
Response time: 124 ms

Resolved: Design Swan is back up in eef7a62 after 31 minutes.


text:
🛑 Design Swan is down

In cba2c2b, Design Swan (https://www.designswan.com) was down:

HTTP code: 500
Response time: 99 ms

Resolved: Design Swan is back up in c50238f after 24 minutes.


text:
🛑 Design Swan is down

In f89a721, Design Swan (https://www.designswan.com) was down:

HTTP code: 500
Response time: 98 ms

Resolved: Design Swan is back up in c625403 after 12 minutes.


text:
Build Fails on Ubuntu 23.04 Lunar on Armhf/Armv7h

Hello!
Absolutely fantastic project you've got going on here.  I've been trying to build Spot on Ubuntu 23.04 Lunar on Armhf/Armv7h and I've repeatedly been getting stuck at a syntax error right towards the end of the building process; I have all needed build dependencies installed to build Spot.
[26/30] Generating src/blueprints with a custom command
FAILED: src
/usr/bin/blueprint-compiler batch-compile src/. ../src ../src/app/components/album/album.blp ../src/app/components/artist/artist.blp ../src/app/components/artist_details/artist_details.blp ../src/app/components/details/album_header.blp ../src/app/components/details/details.blp ../src/app/components/details/release_details.blp ../src/app/components/device_selector/device_selector.blp ../src/app/components/headerbar/headerbar.blp ../src/app/components/library/library.blp ../src/app/components/login/login.blp ../src/app/components/now_playing/now_playing.blp ../src/app/components/playback/playback_controls.blp ../src/app/components/playback/playback_info.blp ../src/app/components/playback/playback_widget.blp ../src/app/components/playlist/song.blp ../src/app/components/playlist_details/playlist_details.blp ../src/app/components/playlist_details/playlist_header.blp ../src/app/components/playlist_details/playlist_headerbar.blp ../src/app/components/saved_playlists/saved_playlists.blp ../src/app/components/saved_tracks/saved_tracks.blp ../src/app/components/search/search.blp ../src/app/components/selection/selection_toolbar.blp ../src/app/components/settings/settings.blp ../src/app/components/user_details/user_details.blp ../src/app/components/scrolling_header/scrolling_header.blp ../src/app/components/sidebar/create_playlist.blp ../src/app/components/sidebar/sidebar_row.blp ../src/window.blp
The Meson command I used prior to running ninja install -C target was meson target -Dbuildtype=release -Doffline=false --prefix="$HOME/.local"
Help would be greatly appreciated and thank you.

I experience the same issue on Fedora 38.
/usr/bin/blueprint-compiler batch-compile src/. ../src ../src/app/components/album/album.blp ../src/app/components/artist/artist.blp ../src/app/components/artist_details/artist_details.blp ../src/app/components/details/album_header.blp ../src/app/components/details/details.blp ../src/app/components/details/release_details.blp ../src/app/components/device_selector/device_selector.blp ../src/app/components/headerbar/headerbar.blp ../src/app/components/library/library.blp ../src/app/components/login/login.blp ../src/app/components/now_playing/now_playing.blp ../src/app/components/playback/playback_controls.blp ../src/app/components/playback/playback_info.blp ../src/app/components/playback/playback_widget.blp ../src/app/components/playlist/song.blp ../src/app/components/playlist_details/playlist_details.blp ../src/app/components/playlist_details/playlist_header.blp ../src/app/components/playlist_details/playlist_headerbar.blp ../src/app/components/saved_playlists/saved_playlists.blp ../src/app/components/saved_tracks/saved_tracks.blp ../src/app/components/search/search.blp ../src/app/components/selection/selection_toolbar.blp ../src/app/components/settings/settings.blp ../src/app/components/user_details/user_details.blp ../src/app/components/scrolling_header/scrolling_header.blp ../src/app/components/sidebar/create_playlist.blp ../src/app/components/sidebar/sidebar_row.blp ../src/window.blp
error: Could not determine what kind of syntax is meant here
at ../src/app/components/album/album.blp line 4 column 10:
4 |template $AlbumWidget : Adw.Bin {
|         ^
Could this be due to an old version of blueprint-compiler? (Fedora is still on 0.6.0)

Hey, thank you for taking interest in the project & submitting an issue! I'm glad you found a fix, so Im closing this :)

authors: Diegovsky nathan-2006 svenlinker


text:
絵文字追加に伴うbotの返す文の変更

何を解決するのか
Botに絵文字を含む文を返させることで少しばかりの遊び心が加わる
レビューポイント
yukichi絵文字が実装される予定なのでそのタイミングでマージしていただければ…

masterの内容を含むようrebaseしてコンフリクトの内容にしてみました。このような変更でよろしかったでしょうか？

CI のエラーの対応お願いします〜

@s9rt
面白いアイデアありがとうございます！
そして、実装問題なさそうです！
1点。
本PRはdevelopに向いていますので、実装頂いた内容を本番に反映するためには、本PRをdevelopにマージ後にdevelopをmasterにマージする必要があります。
幸い、本PRの途中でmasterを取り込んで頂いたので、問題はないと思いますが、忘備録として。。。 🙇
(現状、そもそもdevelopがmasterについていけてないですし、私含め皆さんmasterに直接PR出すという漢の開発フローで進めてますのでw、このPRの向き先もmasterに変えて頂いても良いかもです)
本番へのデプロイ周りは @p-suke さんや @Asuforce さんにお任せ状態なので、いったん私はApproveはせずに口頭でのLGTMとさせて頂きます〜🎉

baseをmasterにし、コンフリクトを解決しました。

あ、また master が進んでいるのでコンフリクトだけ直してください〜

コンフリクト修正しました！

authors: Asuforce s9rt toshikidoi

repo: xpjp/xpfiat-bot


text:
Verification issue

For the module:
module multibit (clk, reset, x, y);
    input clk, reset;
    input [1:0] x;
    output reg y;
    always @(posedge clk or posedge reset) begin
        if (reset) begin
            y <= 0;
        end else begin
            y <= (x == 3);
        end
    end
endmodule

the apparently-false property $any(x) |=> y is proven.

This is related to #5
The property is indeed false. The reason it is proven is because it is disproven (only) in the initial state which is marked as "visited" at the start of state space exploration. Subsequent visits to the initial state are therefore ignored and no cases that disprove the property are found.
To solve this, the initial state must not be marked as visited.

repo: xprova/xprova

license: mit


text:
[FEATURE]  XGanttColumn 的 label 希望支援插槽

可能有场景需要在 label 添加一些按钮之类。现在的 label 只能是文本。希望把 label 开放出来可自定义的插槽。

具体讲一下

希望达成下面这种效果，通过 x-gantt-column 的 label 插槽。可以在表头额外添加一些组件实现一些特殊的功能。
<x-gantt
    data-id="id"
    :data="dataList"
    :ref="ganttRef"
    start-key="planStartTime"
    end-key="planEndTime"
    @row-click="rowClick"
  >
    <x-gantt-column  prop="name">
        <!--在表头添加搜索框-->
        <template #label>
            标题 <el-input  type="text" placeholder="搜索标题" />
        </template>
    </x-gantt-column>
    <x-gantt-column label="进度" prop="progress" />
    <x-gantt-column label="开始日期" width="100">
      <template #default="{ row }">
        <el-date-picker
          class="date-picker"
          v-model="row.planStartTime"
          type="date"
          placeholder="选择日期"
          size="small"
          style="width: 100%"
          :clearable="false"
          value-format="YYYY-MM-DD"
        />
      </template>
    </x-gantt-column>
    <x-gantt-column label="结束日期" width="100">
      <template #default="{ row }">
        <el-date-picker
          class="date-picker"
          v-model="row.planEndTime"
          type="date"
          placeholder="选择日期"
          size="small"
          style="width: 100%"
          :clearable="false"
          value-format="YYYY-MM-DD"
        />
      </template>
    </x-gantt-column>
    <!--在表头添加设置按钮-->
    <x-gantt-column>
        <template #label>
            <el-button icon="el-icon-setting" @click="setting" />
        </template>
    </x-gantt-column>
</x-gantt>

这个看情况吧。。。表头的插槽考虑的东西比较多，目前没有特别的想法，后续可能会考虑吧

authors: imlinhanchao jeremyjone

repo: xpyjs/gantt


text:
unexpected behavior when assignment used incorrectly

An issue came up in which unexpected behavior was resulting from the use of the assignment operator with an xray.Dataset. You can see below in the first simple example, that an attribute can be created and attached to an xray.Dataset object, that the xray is not aware of:
In [1]: import xray

In [2]: ds = xray.Dataset()

In [3]: ds.x = 1

In [4]: ds
Out[4]:
<xray.Dataset>
Dimensions:  ()
Coordinates:
    *empty*
Data variables:
    *empty*

In [5]: ds.x
Out[5]: 1

It can be seen also in a bit more detail below, showing that one could easily mistake the assignment for doing something, when in fact it seems to do nothing to the expected variable:
In [27]: ds = xray.Dataset( {'my_ones': (('dim1',), np.ones((100)))}, {'dim1':np.arange(0,100)})

In [28]: ds
Out[28]:
<xray.Dataset>
Dimensions:  (dim1: 100)
Coordinates:
  * dim1     (dim1) int64 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 ...
Data variables:
    my_ones    (dim1) float64 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 ...

In [29]: ds['new_var'] = np.random.rand(100)

In [30]: ds
Out[30]:
<xray.Dataset>
Dimensions:  (dim1: 100)
Coordinates:
  * dim1     (dim1) int64 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 ...
Data variables:
    my_ones    (dim1) float64 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 ...
    new_var  (dim1) float64 0.008922 0.4298 0.878 0.3581 0.05668 0.4459 ...

In [31]: ds.my_ones = np.random.rand(100)

In [32]: ds
Out[32]:
<xray.Dataset>
Dimensions:  (dim1: 100)
Coordinates:
  * dim1     (dim1) int64 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 ...
Data variables:
    my_ones    (dim1) float64 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 ...
    new_var  (dim1) float64 0.008922 0.4298 0.878 0.3581 0.05668 0.4459 ...

See here, my_ones are still 1.0s even though we assigned them random numbers above!
Now let's make a real attribute:
In [33]: ds.attrs['my_real_attribute'] = ds.my_ones

In [34]: ds
Out[34]:
<xray.Dataset>
Dimensions:  (dim1: 100)
Coordinates:
  * dim1     (dim1) int64 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 ...
Data variables:
    my_ones    (dim1) float64 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 ...
    new_var  (dim1) float64 0.008922 0.4298 0.878 0.3581 0.05668 0.4459 ...
Attributes:
    my_real_attribute: [ 0.8999457   0.52066577  0.08915267  0.0541855   0.45131377  0.09501768
  0.95209237  0.89464241  0.36151148  0.10759526  0.91542506  0.22980835
  0.17357796  0.19259669  0.17985614  0.20401482  0.46921508  0.27108936
  0.2420025   0.75083791  0.94271824  0.89902967  0.29649179  0.70362153
  0.73475068  0.3591411   0.79941874  0.18079561  0.23058618  0.84660496
  0.82993496  0.50236557  0.09758405  0.82851117  0.85434362  0.33170515
  0.11670085  0.37135022  0.8647876   0.18162848  0.5675491...

And we see it shows up. Somehow ds.my_ones persists, but it is not an attribute and not in fact a variable...  strange!

For the sake of cut & paste:
ds = xray.Dataset( {'my_ones': (('dim1',), np.ones((100)))}, {'dim1':np.arange(0,100)})
ds
ds['new_var'] = np.random.rand(100) / ds.my_ones
ds
ds.my_ones = np.random.rand(100)
ds
ds.attrs['my_ones'] = ds.my_ones
ds

below will initially fail because ds.my_ones is just an array and has no attribute values:
ds.my_ones.values = ds.my_ones
del ds.my_ones
ds
ds.my_ones.values = ds.attrs['my_ones']

repo: xray/xray


text:
Type error on line 453 of generate-tests-utils.xsl

@AirQuick wrote in https://github.com/expath/xspec/issues/86 :
test.xsd (defines @bar's type)
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema elementFormDefault="qualified" targetNamespace="x-urn:test" xmlns="x-urn:test"
	xmlns:xs="http://www.w3.org/2001/XMLSchema">
	<xs:element name="foo">
		<xs:complexType>
			<xs:attribute name="bar" type="xs:boolean" />
		</xs:complexType>
	</xs:element>
</xs:schema>

test.xml (an instance of test.xsd)
<?xml version="1.0" encoding="UTF-8"?>
<foo bar="true" xmlns="x-urn:test" />

test.xsl (loads test.xml with or without validation)
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet exclude-result-prefixes="#all" version="2.0"
	xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

	<xsl:import-schema schema-location="test.xsd" />

	<xsl:variable name="foo-strict">
		<xsl:copy-of select="doc('test.xml')" validation="strict" />
	</xsl:variable>

	<xsl:variable name="foo-strip">
		<xsl:copy-of select="doc('test.xml')" validation="strip" />
	</xsl:variable>
</xsl:stylesheet>

test.xspec (tests test.xsl)
<?xml version="1.0" encoding="UTF-8"?>
<x:description stylesheet="test.xsl" xmlns:x="http://www.jenitennison.com/xslt/xspec"
	xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
	<x:scenario label="Test-1">
		<x:call function="exactly-one">
			<x:param select="$foo-strict" />
		</x:call>
		<x:expect label="Result-1" select="$foo-strip" />
	</x:scenario>

	<x:scenario label="Test-2">
		<x:call function="exactly-one">
			<x:param select="$foo-strip" />
		</x:call>
		<x:expect label="Result-2" select="$foo-strict" />
	</x:scenario>
</x:description>

With those files and a schema-aware processor, XSpec fails:
C:\test>c:\xspec\bin\xspec.bat test.xspec
Creating XSpec Directory at "C:\test\xspec" ...

Creating Test Stylesheet...
"C:\test\xspec\test.xsl"
test.xspec

Running Tests...
Testing with SAXON EE 9.7.0.14
Test-1
Result-1
Test-2
Result-2
Type error on line 453 of generate-tests-utils.xsl:
  XPTY0004: Cannot compare xs:boolean to xs:string
Cannot compare xs:boolean to xs:string

Tested on the latest master branch clone.

@cirulls what? please don;t use my handle to document your code :) thanks

Sorry @bar, I copied the code verbatim and didn't realise that GitHub automatically translated it into a handle (the @ sign followed by a name indicates the name of an attribute in XML).  I have fixed this in this issue, sorry for the misunderstanding.

@AirQuick, thanks for submitting this, I confirm it is a bug. I fixed in #24 and merged into master - note that this is in the xspec repo within the xspec organisation as I don't have write access to the expath organisation.
I tested it by using the shell script and Saxon EE 9.6.0.4. Could you confirm it is working with your version of Saxon under Windows?
Thanks,
Sandro

Thank you for the fix. I'm going to test it.
Looks like you removed a "DO NOT... REMOVE" part: https://github.com/xspec/xspec/commit/86e9bbf676d027e14234338224977dc75b65d6b1#diff-e684b53ab134d1f4e4fd9d154fddbbdaL92 Is that ok?

Thanks for spotting it, I just reinstate that part of the comments for now. I think at some point I'd like to consolidate all the copyright and license notes in one single file so that the code looks cleaner.

Verified that the original problem no longer reproduced on Windows + Java 1.8 u111 x64 + Saxon 9.7.0.14-EE. Thanks! However,

Only if this condition returns false, the second condition  $node1 = '...'  is evaluated

So when the condition returns false, the same error may still happen. For example,
test.xsd (defines boolean attribute bar=false by default):
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema elementFormDefault="qualified" targetNamespace="x-urn:test" xmlns="x-urn:test"
	xmlns:xs="http://www.w3.org/2001/XMLSchema">
	<xs:element name="foo">
		<xs:complexType>
			<xs:attribute default="false" name="bar" type="xs:boolean" />
		</xs:complexType>
	</xs:element>
</xs:schema>

context.xml (has bar=true):
<?xml version="1.0" encoding="UTF-8"?>
<foo bar="true" xmlns="x-urn:test" />

expect.xml (has bar=false, but I'm lazy enough to omit the default value):
<?xml version="1.0" encoding="UTF-8"?>
<foo xmlns="x-urn:test" />

test.xsl (has a template to return the context as is. Also complements the default values in expect.xml at runtime on behalf of lazy me):
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet exclude-result-prefixes="#all" version="2.0"
	xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

	<xsl:import-schema schema-location="test.xsd" />

	<xsl:variable name="expect">
		<xsl:copy-of select="doc('expect.xml')" validation="strict" />
	</xsl:variable>

	<xsl:template match="/">
		<xsl:sequence select="." />
	</xsl:template>
</xsl:stylesheet>

test.xspec (just compares context.xml and expect.xml):
<?xml version="1.0" encoding="UTF-8"?>
<x:description stylesheet="test.xsl" xmlns:x="http://www.jenitennison.com/xslt/xspec"
	xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
	<x:scenario label="Test">
		<x:context href="context.xml" />
		<x:expect label="Result" select="$expect" />
	</x:scenario>
</x:description>

In that case, I would expect XSpec to complete the test and report the result (of failure). But XSpec is terminated by the same error:
C:\test>c:\xspec\bin\xspec.bat test.xspec
Creating XSpec Directory at "C:\test\xspec" ...

Creating Test Stylesheet...
"C:\test\xspec\test.xsl"
test.xspec

Running Tests...
Testing with SAXON EE 9.7.0.14
Test
Result
Type error on line 453 of generate-tests-utils.xsl:
  XPTY0004: Cannot compare xs:boolean to xs:string
Cannot compare xs:boolean to xs:string

That's a very good point! I think I've been lazy with my lazy evaluation (no pun intended!) and didn't check the scenario of a genuine failing test. I think I fixed this in #27 (see the pull request for technical notes) and tested it with both examples you provided. Could you confirm it works at your end and you're happy with this fix?
Thanks,
Sandro

Thanks, @cirulls. Verified the fix with the cases reported by me. On Windows 8.1 + Java 1.8 u111 x64 + Saxon 9.7.0.14-EE.

Cool, thanks for confirming. Unfortunately I can't write a test for this as a non-open source version of Saxon would be needed to run the test suite via Travis. I'll investigate if it's possible to find a workaround, it'd be good to use your examples and get this issue covered by a test.
I'll close the issue for now, thanks for flagging it and helping with the solution.

authors: AirQuick bar cirulls

repo: xspec/xspec


text:
Adding Slim Event Dispatcher

Adding Slim Event Dispatcher which uses League\Event package and integrates that with Slim 3.
P.S: I am the author of that package.

@xssc : Hi, could you please have a look at this?
Thanks!

Yup, catching up on these pull requests now

@xssc : Thanks :+1:

authors: aneek xssc

repo: xssc/awesome-slim


text:
🛑 Xstatic is down

In 238fdb5, Xstatic (https://www.xstatic.io) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Xstatic is back up in 20c14c0 after 1 hour, 2 minutes.

repo: xstaticwebdev/upptime


text:
v0418和v0428 发行文件相差好大，服务器更新，客户端使用0418是否有问题

kcptun-linux-amd64-20190418.tar.gz
kcptun-linux-amd64-20190428.tar.gz

你缺这几MB空间？
只有0418是经过upx压缩的，但后来发现有兼容性问题，所以还是提供原版不压缩的，你可以自己用upx压缩。

谢谢回答。
主要是我有个项目WinKcp_启动器项目，项目里打包的是windows版kcp二进制文件，方便小白使用
https://github.com/hongwenjun/WinKcp_Launcher
服务器安装和更新脚本，是从你的项目下载的，提供升级脚本的。
如果版本差异不大，我就只更新服务器脚本好了

应该始终检测并使用最新版本啊， 每个版本都有更新，比如0428会大量减少内存使用和CPU使用
应该是每次安装都从这里获取：https://github.com/xtaci/kcptun/releases/latest

服务端更新脚本给用的到的朋友
# 下载更新 KCPTUN
kcp_ver=$(wget --no-check-certificate -qO- https://api.github.com/repos/xtaci/kcptun/releases/latest | grep 'tag_name' | cut -d\" -f4)
kcp_gz_ver=${kcp_ver:1:8}

kcptun_tar_gz=kcptun-linux-amd64-${kcp_gz_ver}.tar.gz
wget https://github.com/xtaci/kcptun/releases/download/${kcp_ver}/$kcptun_tar_gz
tar xf $kcptun_tar_gz
mv server_linux_amd64 /usr/bin/kcp-server
rm $kcptun_tar_gz
rm client_linux_amd64

authors: hongwenjun xtaci

repo: xtaci/kcptun


text:
Add socks proxy support for m3u grabs

Is your feature request related to a problem? Please describe.
I am hosting my Plex content and xteve on a dedicated server which obviously has a business network and a non residential IP address. Unfortunately my IPTV provider has all of these blocked. They only allow residential IPs to both access their m3u lists and also to start streaming. Therefore I set up a socks proxy at home I could use with xteve. I have confirmed using curl that it indeed works. But I couldn't find a way within xteve to set up proxies.
Describe the solution you'd like
I would like to have an option to specify socks proxies within the settings.
Describe alternatives you've considered
I have considered using proxychains which can replace syscalls so they will go thru over the proxy. But that's a hacky solution and not even sure if it would work since go binaries not necessarily link to libc.
Additional context
-

Yeah, just confirmed. Since xteve is not even using the system libc, but it is a static binary, it doesn't even respect the proxychain syscall overwrites. So it could only be possible with a built in support for proxies.
[user@luna xteve]$ file ./xteve
./xteve: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, Go BuildID=az6Ob2APO9do645wF-oW/n0eQy-6U5R2mrYdn-bWU/wiXrjBPMYCayL7pAH4pB/ULQTcxIEdp33M8Qk3usE, stripped
[user@luna xteve]$ ldd ./xteve
        not a dynamic executable

xTeVe is written in Go and uses the standard Go frameworks for communication with the OS and the network.
For your use case, an SSH or VPN tunnel might also be a solution.

I assume so, but I would assume adding proxy support as a config option within xteve itself would make sense as many would probably find this option useful. Running an ssh tunnel wouldn't be beneficial in my case as that won't replace routing to my home network and running a VPN would probably work, but would involve the need of extra routing plus encryption. While a socks proxy can do all that straight away and many applications implement it anyway as a possibility to define.

I would also love to have socks proxy support directly integrated, and if possible to set it in playlist seperately for each provider.

I also would love to have socks proxy support directly integrated in xTeVe. And if possible to set it per provider (playlist) seperately. Maybe this would help to implementate -> https://github.com/extremecoders-re/go-dispatch-proxy ?

authors: Diniboy1123 gregor-hh mar-mei

repo: xteve-project/xTeVe


text:
好像不支持 NavController

问题描述（必填）
 AppBarConfiguration appBarConfiguration = new AppBarConfiguration.Builder(
                R.id.navigation_home, R.id.navigation_dashboard, R.id.navigation_notifications)
                .build();
        NavController navController = Navigation.findNavController(this, R.id.nav_host_fragment_activity_main);
        NavigationUI.setupActionBarWithNavController(this, navController, appBarConfiguration);
        NavigationUI.setupWithNavController(binding.navView, navController);

使用的XUI版本（必填）
    //androidx项目
    implementation 'com.github.xuexiangjys:XUI:1.2.0'
    implementation 'androidx.appcompat:appcompat:1.3.1'
    implementation 'androidx.recyclerview:recyclerview:1.2.1'
    implementation 'com.google.android.material:material:1.4.0'
    implementation 'com.github.bumptech.glide:glide:4.12.0'

如何重现（必填）
运行崩溃
java.lang.RuntimeException: Unable to start activity ComponentInfo{com.waytronic.wt_nfc_app/com.waytronic.wt_nfc_app.MainActivity}: java.lang.IllegalStateException: Activity com.waytronic.wt_nfc_app.MainActivity@7f7423d does not have an ActionBar set via setSupportActionBar()
        at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3778)
        at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3952)
        at android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:107)
        at android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:135)
        at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:95)
        at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2286)
        at android.os.Handler.dispatchMessage(Handler.java:106)
        at android.os.Looper.loopOnce(Looper.java:211)
        at android.os.Looper.loop(Looper.java:300)
        at android.app.ActivityThread.main(ActivityThread.java:8243)
        at java.lang.reflect.Method.invoke(Native Method)
        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:556)
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1049)
     Caused by: java.lang.IllegalStateException: Activity com.waytronic.wt_nfc_app.MainActivity@7f7423d does not have an ActionBar set via setSupportActionBar()
        at androidx.navigation.ui.ActionBarOnDestinationChangedListener.setTitle(ActionBarOnDestinationChangedListener.kt:40)
        at androidx.navigation.ui.AbstractAppBarOnDestinationChangedListener.onDestinationChanged(AbstractAppBarOnDestinationChangedListener.kt:87)
        at androidx.navigation.NavController.addOnDestinationChangedListener(NavController.kt:403)
        at androidx.navigation.ui.NavigationUI.setupActionBarWithNavController(NavigationUI.kt:284)
        at com.waytronic.wt_nfc_app.MainActivity.onCreate(MainActivity.java:35)
        at android.app.Activity.performCreate(Activity.java:8294)
        at android.app.Activity.performCreate(Activity.java:8258)
        at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1341)
        at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3758)
        at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3952)
        at android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:107)
        at android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:135)
        at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:95)
        at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2286)
        at android.os.Handler.dispatchMessage(Handler.java:106)
        at android.os.Looper.loopOnce(Looper.java:211)
        at android.os.Looper.loop(Looper.java:300)
        at android.app.ActivityThread.main(ActivityThread.java:8243)
        at java.lang.reflect.Method.invoke(Native Method)
        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:556)
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1049)

XUI 默认的主题就是没有ActionBar的，你要是想用ActionBar，请更换主题

authors: GordonHuangYong xuexiangjys

repo: xuexiangjys/XUI


text:
的height属性的值只会考虑表格高度，没有限定toolbar

（必填）请填写问题描述 Describe the bug
? 的height属性的值只会考虑表格高度，而不考虑toolbar。我想实现toolbar与表格和工具栏（toolbar）二为一的表格整体限定高度等于浏览器器的innerheight。例如样式这样

<vxe-grid
  border
  resizable
  highlight-hover-row
  remote-filter
  ref="xGrid"
  row-id="id"
  :height="tableHeight"
  :pager-config="{pageSize: 15}"
  :toolbar="tableToolbar"
  :proxy-config="tableProxy"
  :columns="tableColumn"
  :select-config="{reserve: true}"
></vxe-grid>

java：
methods: {
getHeight(){
this.tableHeight=window.innerHeight;
}
（必填）请填写能重现问题的链接，例如（jsfiddle、codesandbox、jsrun） Reproduction link
?
填写报错信息或截图 Error message or screenshots
?
（必填）请填写期望的结果 Expected behavior
?
（必填）请填写版本号 Version

os: ?
browser: ?
vue: ?
vxe-table: ?

这个问题会在 v2.6 修复

authors: flashliao xuliangzhan

repo: xuliangzhan/vxe-table