CMake Port/Enabling repo in the CI: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
(Created page with "Here are the steps to enable a new repository's CMake port in the CI / Coin. I'll use '''qtopcua''' as an example. '''Prerequisites''': Have the CMake port merged to the dev...")
 
(IRC channels have moved to Libera.​Chat)
 
(One intermediate revision by one other user not shown)
Line 12: Line 12:




Now, if you do not have Qt Company internal VPN access, ask somebody on '''#qt-cmake''' Freenode to schedule a test build using those 2 changes as the references.
Now, if you do not have Qt Company internal VPN access, ask somebody on '''#qt-cmake''' Libre.Chat to schedule a test build using those 2 changes as the references.


If you have access to the VPN in order to schedule a test CMake build, do the following steps:
If you have access to the VPN in order to schedule a test CMake build, do the following steps:
Line 36: Line 36:
'''dependencies.yaml'''
'''dependencies.yaml'''


If your module is not part of qt5.git (like qtopcua), you will most likely want to use a dependencies.yaml file to specify what modules you depend on.
A bit unrelated, but also related to working in the dev branch.
 
If your module is not part of qt5.git (like qtopcua), you will most likely want to use a dependencies.yaml file to specify what modules you depend on, instead of depending on the whole of qt5.git.


This way you explicitly specify a list of sha1s that you know that your module builds with.
This way you explicitly specify a list of sha1s that you know that your module builds with.
Line 42: Line 44:
An example can be found here https://codereview.qt-project.org/c/qt/qtopcua/+/302962
An example can be found here https://codereview.qt-project.org/c/qt/qtopcua/+/302962


For now, you will have to manually update it whenever you want to use a newer qtbase, etc.
For now, you will have to manually update the file whenever you want to use a newer qtbase, etc.

Latest revision as of 22:00, 14 August 2021

Here are the steps to enable a new repository's CMake port in the CI / Coin.

I'll use qtopcua as an example.

Prerequisites: Have the CMake port merged to the dev branch (so all the CMakeLists.txt files). Some guidance on how to get that done can be found at Porting Guide

Gerrit Steps:

  1. Copy qtsvg/coin folder (dev branch) into under qtopcua/coin. That folder should have a module_config.yaml file. This file is used to tell Coin how to configure and build your module.
  2. Commit and push that as a new change to Gerrit to the dev branch (here's a sample change like that https://codereview.qt-project.org/c/qt/qtopcua/+/303007/4/coin/module_config.yaml )
  3. Checkout a copy of the qt5.git dev branch, go into the coin/platform_configs folder, make a copy of qtsvg.yaml and rename it to qtopcua.yaml. This file is used by Coin to know what platforms to build and test, and what configure arguments to pass.
  4. Commit and push that file as new change to Gerrit. (Here's a sample change like that https://codereview.qt-project.org/c/qt/qt5/+/302955/2/coin/platform_configs/qtopcua.yaml)


Now, if you do not have Qt Company internal VPN access, ask somebody on #qt-cmake Libre.Chat to schedule a test build using those 2 changes as the references.

If you have access to the VPN in order to schedule a test CMake build, do the following steps:

Coin test steps:

  1. Connect to full VPN
  2. Go to Coin's internal webpage
  3. Choose Schedule build in the top-right menu
  4. Copy the qtopcua Gerrit change URL you pushed in step 1 and paste it into the URL field and press Resolve. Wait for it to resolve, it can take a while if the CI is overloaded with work.
  5. Go to the gerrit qt5 change you pushed (e.g. https://codereview.qt-project.org/c/qt/qt5/+/302955) copy the SHA1 of the change using the Web UI
  6. Switch back to the Coin schedule build page, paste the copied sha1 into the "Product ref" field
  7. Check the "Post comment on Gerrit" and the "Do not abort integration on failure" checkmarks, and uncheck "Abort testing on first failure" checkmark
  8. Press List configurations
  9. You should have some CMake configurations appear under the qmake ones.
  10. Either checkmark only the CMake configurations and then press "Build and test on these configurations" or press "Run all configurations"
  11. Coin should start the job, and post a message with success or errors to the qtopcua gerrit change that you pushed

Once you've confirmed that all CMake configurations build and pass all tests (check the logs of each test config to be sure), you can first stage the qtopcua change. Once that's merged, stage the qt5.git change you created.


dependencies.yaml

A bit unrelated, but also related to working in the dev branch.

If your module is not part of qt5.git (like qtopcua), you will most likely want to use a dependencies.yaml file to specify what modules you depend on, instead of depending on the whole of qt5.git.

This way you explicitly specify a list of sha1s that you know that your module builds with.

An example can be found here https://codereview.qt-project.org/c/qt/qtopcua/+/302962

For now, you will have to manually update the file whenever you want to use a newer qtbase, etc.