Closed SchaichAlonso closed 1 year ago
Nice, I wanted to post these vcpkg ports into the vcpkg central repo but I still couldn't find enough time for it. 🙂
You did a great job on this. Nice to see. I'm gonna address these patches so we can entirely remove them.
I also removed this comment because it's not relevant anymore, it was left there after refactoring. I spent a few minutes on this yesterday.
I have done the qmake
refactor so now I can spend time on this.
Work in progress still, just to inform, I have refactored tinyorm
and tinyorm-qt5
, I made them as clean as possible, these ports will contain only the vcpkg_cmake_xyz()
CMake functions, nothing more, everything else was moved to the TinyDeployment.cmake
.
I also added all TinyORM
CMake options and also Tom
example application and also tested x64-windows-static
and x64-windows-static-md
triplets.
I'll let you know when I'm done because I'll need you to test it as you have a nice GitHub repo where you are testing much more than I do.
I think everything is fixed, all patches will be able to removed (still not merged to the main branch, will be in the next release).
Also, I would wait a while before finally posting it to the vcpkg
repo to test it correctly, I haven't tried all scenarios yet like Linux and MSYS2 shared and static builds.
Great progress today, I have finished CI
for vcpkg ports to correctly support them here.
The TinyORM-HelloWorld
project is not yet finished, is used by these workflows internally.
I have it done, I had to move CI
for vcpkg
to self-hosted runners also with Clang-Tidy
and Clazy
analyzers because they took too many minutes, 3 runs took me more than 1000 minutes from 2000 minutes (which are for free) and that is a lot, I was out of minutes last month after one or two deploy-s 🙃🫤
The currently deployed TinyORM v0.36.0
is ready to be merged to the vcpkg
repo, can you invoke your workflows and also test it? If there are any other bugs or problems? @SchaichAlonso
A new release pushed today v0.36.1
, I have enabled the tom example for vcpkg on Linux and did some workaround for microsoft/vcpkg#33551 here.
Also, how are running your workflows? Any fails? @SchaichAlonso
I have created PR at microsoft/vcpkg#34640, also a new release was pushed today v0.36.2.
Also, how are running your workflows? Any fails? @SchaichAlonso
all buildsystems can build the consumer, though I only used tinyorm-0.35.0, as I haven't updated the port yet.
I noticed, though, that passisng -DORM=Off -DTOM=Off -DTOM_EXAMPLE=Off to cmake causes the setup logic to emit a diagnositc confirming the 3 were disabled, but then installing orm/tiny/model.hpp nevertheless.
I noticed, though, that passisng -DORM=Off -DTOM=Off -DTOM_EXAMPLE=Off to cmake causes the setup logic to emit a diagnositc confirming the 3 were disabled, but then installing orm/tiny/model.hpp nevertheless.
I will check it if I can find something.
Sry, I accidentally edited your reply 😂
all buildsystems can build the consumer, though I only used tinyorm-0.35.0, as I haven't updated the port yet.
This is good, there are minimal changes in later releases.
I noticed, though, that passisng -DORM=Off -DTOM=Off -DTOM_EXAMPLE=Off to cmake causes the setup logic to emit a diagnositc confirming the 3 were disabled, but then installing orm/tiny/model.hpp nevertheless.
I tried now and can't reproduce it, I tried single-config debug build and install. The code responsible is here it can't install.
What was your config., single-config, multi, vcpkg install?
What was your config., single-config, multi, vcpkg install?
vcpkg's cmake-ninja default setup:
-- The following features have been disabled:
* BUILD_SHARED_LIBS, Build using shared libraries (default: ON)
* BUILD_TESTS, Build TinyORM unit tests (default: OFF)
* MSVC_RUNTIME_DYNAMIC, Use MSVC dynamic runtime library (-MD) instead of static (-MT), also considers a Debug configuration (-MTd, -MDd) (default: ON; depends on condition: MSVC;NOT DEFINED CMAKE_MSVC_RUNTIME_LIBRARY)
* MYSQL_PING, Enable MySQL ping on Orm::MySqlConnection
* DISABLE_THREAD_LOCAL, Remove all the thread_local storage duration specifiers (disables threading support)
* ORM, Controls the compilation of all ORM-related source code, when this option is disabled, then only the query builder without ORM is compiled.
* TOM, Controls the compilation of all tom related source code (command line interface).
* TOM_EXAMPLE, Build the tom command-line application example (default: OFF; depends on condition: TOM)
-- Installing: /home/alonso/projects/Bougainvillea/vcpkg/packages/tinyorm_x64-freebsd/include/orm/tiny/relations/relationproxies.hpp
-- Installing: /home/alonso/projects/Bougainvillea/vcpkg/packages/tinyorm_x64-freebsd/include/orm/tiny/model.hpp
-- Installing: /home/alonso/projects/Bougainvillea/vcpkg/packages/tinyorm_x64-freebsd/include/orm/macros
config-x64-freebsd-out.log install-x64-freebsd-rel-out.log
Corresponding x64-windows
and x64-windows-static
build logs can be obtained from the buildlogs artifact evaluated by the github actions run linked in the previous comment
cmake-ninja default setup
You mean "default-features": false
in vcpkg.json
file and in manifest mode?
cmake-ninja default setup
You mean
"default-features": false
invcpkg.json
file and in manifest mode?
Yes.
A cmake invokation by VCPKG might fail to pass the correct options to tinyorm due to bugs in the portfile or vcpkg logic, but tinyorm's cmake should be consistent between it's diagnostic and the installed features.
I.e. if it reports ORM is disabled, it shouldn't install orm components, while a build with the default options should install ORM only if it's configure step didn't report it was being disabled.
I check it tomorrow, these features are reported by feature_summary()
module and function.
But vcpkg and default-features it already sounds like a pain 😂 and I haven't even started testing 😎 and you can double this feeling in manifest mode
The port from microsoft/vcpkg#34640 can provision a TinyORM that works with all build systems here, though I suppressed the unsupported statement of the portfile.
The issue with the header file seems to persist.
The issue with the header file seems to persist.
With which header file? I don't remember any issue with a header file.
You mean
"default-features": false
invcpkg.json
file and in manifest mode?Yes.
Now I tried it and can't reproduce it, tried with HelloWorld example app. and this vcpkg.json, I also removed this line from vcpkg.json.
Then looked inside the build folder HelloWorld-builds-cmake\build-debug\vcpkg_installed\x64-windows\include\orm
and the ORM
header files are not there, also the tom
header files are not installed.
Looked also into the buildtrees\tinyorm\install-x64-windows-dbg-out.log
and looks correct too:
-- Installing: O:/Code/c_libs/vcpkg/packages/tinyorm_x64-windows/debug/lib/TinyOrm0d.lib
-- Installing: O:/Code/c_libs/vcpkg/packages/tinyorm_x64-windows/debug/bin/TinyOrm0d.dll
-- Installing: O:/Code/c_libs/vcpkg/packages/tinyorm_x64-windows/debug/share/tinyorm/TinyOrmTargets.cmake
-- Installing: O:/Code/c_libs/vcpkg/packages/tinyorm_x64-windows/debug/share/tinyorm/TinyOrmTargets-debug.cmake
-- Installing: O:/Code/c_libs/vcpkg/packages/tinyorm_x64-windows/debug/bin/TinyOrm0d.pdb
And the following for the release install buildtrees\tinyorm\install-x64-windows-rel-out.log
:
I forgot, I also tried vcpkg classic mode like vcpkg install tinyorm[core]
and also can't reproduce.
Integrated by microsoft/vcpkg#34640
microsoft/vcpkg#31087 is requesting to integrate tinyorm into upstream vcpkg's centralized ports repository.
I have prepared a vcpkg fork which contains a tinyorm port deriving from the overlay port that is part of TinyORM as well as a TinyORM consumer project that uses the tinyorm package generated with the vcpkg fork. It can run the simplistic test on all primary supported vcpkg platforms other then Mac OS X using GitHub hosted runners.
The patches applied address
Further, I modified the microsoft CI ruleset to assert Mac OS X builds fail ( silverqx/TinyORM#28 ). However I'm not sure what to do about the other targets blacklisted in vcpkg.json:9 (which is copy-pasted from the manifest variant's same line). Are these platforms known not to work, or just untested?