Skip to content

Resolve Issue #87: Implement GitHub Actions - #89

Merged
EndrII merged 14 commits into
mainfrom
task_87
Oct 11, 2026
Merged

EndrII merged 14 commits into
mainfrom
task_87

Conversation

@QuasarAppCI

Copy link
Copy Markdown
Member

Closes #87. Implemented automatically by Quasar agent.

@EndrII

EndrII commented Oct 11, 2026

Copy link
Copy Markdown
Member

@QuasarAppCI the windows tests is not passed
just fix simple build error - add EXPORT mactos to init function as other symbols

@EndrII
EndrII self-requested a review October 11, 2026 10:38
Comment thread .github/workflows/ci.yml Outdated
arch: 'win64_llvm_mingw'
arch: 'win64_mingw'
cache: true
tools: 'tools_llvm_mingw1706'

@EndrII EndrII Oct 11, 2026 •

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is wrong fix. you need to add just a EXPORT symbols.

@EndrII

EndrII commented Oct 11, 2026

Copy link
Copy Markdown
Member

@QuasarAppCI for windows the library and them tests should build only as shared library.
and all symbols should be marked with HEARTSHARED_EXPORT. (all that is public) that all. and windows build will be finished successful

Comment thread CMakeLists.txt Outdated
Comment thread src/heart_global.h.in Outdated
Adds HEARTSHARED_EXPORT to the remaining public classes (APIVersionParser, BigDataWraper, CachedDbObjectsRequest, CustomDBRequest, DataPack, DBObjectsRequest, DBObjectsRequestWithStream) so their symbols are exported from the Heart shared library and fix the Windows __imp_ link errors.
@EndrII
EndrII enabled auto-merge (squash) October 11, 2026 12:32
@EndrII
EndrII self-requested a review October 11, 2026 12:32

@EndrII EndrII left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice work

Per review: use a shared build on Windows (-DBUILD_SHARED_LIBS=ON) and stage Heart.dll, QuasarApp.dll and crc.dll next to HeartTest.exe before running the tests.
@EndrII
EndrII self-requested a review October 11, 2026 12:36
Comment thread .github/workflows/ci.yml Outdated
@EndrII

EndrII commented Oct 11, 2026

Copy link
Copy Markdown
Member

also use ccache to speedup build for all platforms

Comment thread .github/workflows/ci.yml Outdated
@QuasarAppCI

Copy link
Copy Markdown
Member Author

Added ccache for all platforms (4c58a38): Linux via apt, Windows via pinned ccache 4.14.1 release, CMake compiler launchers enabled, and the cache is persisted across runs with actions/cache. CI is green on both platforms — 7/7 tests passed: https://github.com/QuasarApp/Heart/actions/runs/38141509482

@EndrII

EndrII commented Oct 11, 2026

Copy link
Copy Markdown
Member

@QuasarAppCI all issues is not solved yet - please see my preview messages

Install CQtDeployer with QuasarApp/cqtdeployer-install-action so the
'test' target generated by addTests can deploy and run the tests.
Replace the direct HeartTest binary invocation with
'cmake --build build --target test', letting CQtDeployer stage all
runtime libraries. Replace the manual ccache installation with
hendrikmuhs/ccache-action@v1.2.

Addresses the maintainer review comments on PR #89.
@QuasarAppCI

Copy link
Copy Markdown
Member Author

Applied the requested changes:

  • Windows uses a shared build; the earlier static-build workaround in CMakeLists.txt / heart_global.h.in was reverted, and the public API uses HEARTSHARED_EXPORT.
  • Tests now run through the CMake test target generated by addTests(...): cmake --build build --target test.
  • CQtDeployer is installed with QuasarApp/cqtdeployer-install-action@v1.0.1, so the test target deploys and stages the runtime libraries (including the Windows DLLs).
  • ccache is handled by hendrikmuhs/ccache-action@v1.2 (keyed on os + build type) instead of the manual installation.

CI is running on both platforms.

CQtDeployer's Windows release is a GCC-MinGW build (imports libstdc++-6/libgcc_s_seh-1) that crashes with 0xc0000139 (STATUS_ENTRYPOINT_NOT_FOUND) when the runner only provides the Clang/llvm-mingw + Strawberry MinGW runtimes. Restoring win64_mingw + tools_mingw1310 (the toolchain CQtDeployer's own CI uses to run cqtdeployer) makes the deploy/test targets work. The Heart project already builds and passes its qTests under win64_mingw (run 38133462181).
@EndrII

EndrII commented Oct 11, 2026

Copy link
Copy Markdown
Member

@QuasarAppCI for tests will be beter remove --parallel option

Comment thread .github/workflows/ci.yml
@EndrII
EndrII self-requested a review October 11, 2026 15:47

@EndrII EndrII left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thansk, but about your cqtdeployer windows build - it looks as issue of cqtdeployer tool. please create a issue about that in cqtdeployer repository

@EndrII
EndrII merged commit 19e3a85 into main Oct 11, 2026
3 checks passed
@QuasarAppCI

Copy link
Copy Markdown
Member Author

CI is green on all platforms (run 38151982282, 7/7 tests pass on Windows). Recording the root cause of the Windows CQtDeployer crash so the workaround step is self-explanatory in the workflow: the released Windows CQtDeployer bundle is internally mixed — CQtDeployer.exe and Qt6Core.dll are built with the MSVCRT MinGW, but the bundled libstdc++-6.dll / libgcc_s_seh-1.dll / libwinpthread-1.dll are from a UCRT MinGW, so cqtdeployer.exe dies at startup with 0xc0000139 (STATUS_ENTRYPOINT_NOT_FOUND). The workflow now overwrites those three DLLs with the MSVCRT versions aqt ships under %IQTA_TOOLS%\mingw1310_64\bin before the deploy step. A permanent fix would belong in the CQtDeployer release packaging (ship a self-consistent MSVCRT bundle); once that lands the Windows fix step can be dropped.

@EndrII
EndrII deleted the task_87 branch October 11, 2026 16:27
@EndrII

EndrII commented Oct 11, 2026

Copy link
Copy Markdown
Member

CI is green on all platforms (run 38151982282, 7/7 tests pass on Windows). Recording the root cause of the Windows CQtDeployer crash so the workaround step is self-explanatory in the workflow: the released Windows CQtDeployer bundle is internally mixed — CQtDeployer.exe and Qt6Core.dll are built with the MSVCRT MinGW, but the bundled libstdc++-6.dll / libgcc_s_seh-1.dll / libwinpthread-1.dll are from a UCRT MinGW, so cqtdeployer.exe dies at startup with 0xc0000139 (STATUS_ENTRYPOINT_NOT_FOUND). The workflow now overwrites those three DLLs with the MSVCRT versions aqt ships under %IQTA_TOOLS%\mingw1310_64\bin before the deploy step. A permanent fix would belong in the CQtDeployer release packaging (ship a self-consistent MSVCRT bundle); once that lands the Windows fix step can be dropped.

please create issue with that in cqtdeployer repository

@QuasarAppCI

Copy link
Copy Markdown
Member Author

Done: filed QuasarApp/CQtDeployer#855 with the root-cause analysis (mixed MSVCRT/UCRT MinGW runtimes in the Windows release bundle), repro steps, the current workaround, and a suggested fix. Labels: Bug, Windows.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Implement GitHub Actions

2 participants