Skip to content
This repository was archived by the owner on Jan 12, 2024. It is now read-only.
This repository was archived by the owner on Jan 12, 2024. It is now read-only.

Update qsharp-runtime/src/QirRuntime/README.md #583

@kuzminrobin

Description

@kuzminrobin

File.
Details:
[9:27 AM] Bettina Heim
Hi both,
It looks like the readme for the QIR runtime is outdated. It still contains the paragraph:

"Currently the files are checked-in as part of the project but in the future they will be replaced by automatic generation during build. To regenerate the files, run generateqir.py
or build/test scripts without specifying noqirgen. To use the checked-in files without regenerating them, run build/test
scripts with noqirgen argument."
I double checked and it looks like indeed there are no more .ll files checked in (yay!), and the files are generated automatically as part of the build. Robin Kuzmin Could you please update the readme when you get a chance? No rush.

More info:
[Yesterday 11:33 PM] Bettina HeimLocal build of QIR runtime fails
With the latest changes to QIR runtime I am running into the following error when I try to use build.py or test.py:

running: cmake --build . --target install --config Debug
ninja: error: '../../../test/FullstateSimulator/qir-test-simulator.ll', needed b
y 'test/FullstateSimulator/qir-test-simulator-u.lib', missing and no known rule
to make it

Any ideas what might be going on here?

​[Yesterday 11:36 PM] Stefan Wernli
looks like it's missing the generated .ll files. Try building the Simulation.sln first
​[Yesterday 11:38 PM] Stefan Wernli
also, while I kept them around for reference and to avoid upending existing workflows, I haven't been paying close attention to keeping the python scripts up to date. The powershell scripts were always what was used for pipeline builds, and I improved them to try and make them more robust for local builds as well. I'd recommend switching to those (note you must use powershell core, aka pwsh).
​[Yesterday 11:38 PM] Stefan Wernli
they will check for the presence of the .ll files and build the corresponding project if they are missing
​[Yesterday 11:44 PM] Bettina Heim
We need to make a clean-up pass over those scripts. For the thing I actually wanted to check, I can make a guess, but we need to get the readme and the scripts into a state again where people can follow it - having a proper runtime package certainly will also help.
​[Yesterday 11:45 PM] Stefan Wernli
agreed. I did update the readme to remove mention of the python scripts and point towards the powershell scripts, but it's still in need of some clean up given how much has changed.
​[8:27 AM] Robin Kuzmin

I'll make another pass through the scripts and documentation later today. There is also related #583

Another thing is worth mentioning is that the .ll files are regenerated from .qs, only if .ll is absent.
If the .qs is newer than .ll, the .ll is not re-generated. Looks like a certain dependency is missing in the CMake files or .ps1 files.

(1 liked)Edited​[8:35 AM] Stefan Wernli
Yes, that’s correct, and intentional. The pipeline gets very mad when the script tries to build the individual csproj files, which is why I added them to the solution. The expected workflow is to use the QIR scripts to build the QIR runtime, and if any changes to .qs files has been made to rebuild those using dotnet build on the Simulation.sln
​[8:35 AM] Stefan Wernli
Yet another thing it would be good to clarify in the readme, now that I’m thinking of it
​[10:34 AM] Robin Kuzmin

Stefan, I assume you meant the following:
"The pipeline gets very mad when the script (e.g. qsharp-runtime\src\QirRuntime\build-qir-runtime.ps1 ) tries to build the individual csproj files (e.g. qsharp-runtime\src\QirRuntime\test\QIR-static\qsharp\qir-gen.csproj ), which is why I added them to the solution (qsharp-runtime\Simulation.sln)".
As I now understand, the dependency that causes the regeneration of the .ll files upon the update of the .qs files, is observed in (or is built into) the Simulation.sln.
If that's the way such dependencies work, then may be we can create one more .sln somewhere inside of qsharp-runtime\src\QirRuntime and add the .csproj files (e.g. test\QIR-static\qsharp\qir-gen.csproj) to that .sln too? As a result, the .csproj will be included into two solutions - Simualtion.sln and QirRuntime local .sln. And the .ll files will be rebuilt upon update to the .qs, both when building QirRuntime only, and when building the whole repo qsharp-runtime. (Just an idea to consider. I'm not sure if this idea works or is needed at all)

Metadata

Metadata

Assignees

Labels

maintenanceImprove codebase quality

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions