Migrate the build to Conan 2.x

[hamidelmaazouz]

Hey @steleman, @steleman, @openqasm/qe-maintainers,

I Found a few issues getting started on the project. As I got lots of warnings and errors about Conan 1 deprecations, I thought it's a good first step to try and migrate the build to latest Conan.

Changes are also reflected on the CI pipeline, which should be running fine.

[CLAassistant]

All committers have signed the CLA.

[blakejohnson]

hi @hamidelmaazouz this repo is no longer actively maintained, so it may be a while before someone from @openqasm/qe-maintainers has a chance to take a look. I looked over your changes and it looked reasonable, so if no one else responds this week, I am willing to approve PR.

[hamidelmaazouz]

hi @hamidelmaazouz this repo is no longer actively maintained, so it may be a while before someone from @openqasm/qe-maintainers has a chance to take a look. I looked over your changes and it looked reasonable, so if no one else responds this week, I am willing to approve PR.

Thanks for the update @blakejohnson, never considered this repo is about to be abandoned 😅. Not sure why, but I'm curious ^^. Come think of it, I've been putting up a similar migration for the qe-compiler repo, and I've now become somewhat discouraged from seeing it through ^^.

[blakejohnson]

I think this repo, in conjunction with qe-compiler, provide a fine framework for interfacing OpenQASM with LLVM. If experimenting with LLVM compilation of quantum circuits is of interest to you, then you will probably still find this useful. However, for what we were using for at IBM, we found LLVM to be a very heavyweight dependency. So, we have now migrated to a custom, lightweight compiler as part of our production stack.

[hamidelmaazouz]

I think this repo, in conjunction with qe-compiler, provide a fine framework for interfacing OpenQASM with LLVM. If experimenting with LLVM compilation of quantum circuits is of interest to you, then you will probably still find this useful. However, for what we were using for at IBM, we found LLVM to be a very heavyweight dependency. So, we have now migrated to a custom, lightweight compiler as part of our production stack.

While indeed it's heavy, I think I'll continue with LLVM for now. I find the IR(s), infrastructure, and tooling really useful. Anyway, thank you for the insight @blakejohnson, would be happy to contribute and merge once you're happy with it.

[mbhealy]

Hi Hamide, in general your changes look good to me, but CI is currently failing a static check. It seems the conanfile.py is not formatted with black. Please update the PR accordingly.

[mbhealy]

Apologies for the delay in responding, I've been at a workshop earlier this week and didn't get to this until now.

[hamidelmaazouz]

hello @mbhealy, @blakejohnson

Sorry it took me a while to get back to this, I believe I've addressed CI issues. Could you give it another look 🙏🏽 ?

[mbhealy]

Couple small things, but generally LGTM.

[mbhealy]

Why downgrade mpfr?

[hamidelmaazouz]

@mbhealy mpc/1.3.1 is strictly configured to mpfr/4.2.0: https://github.com/conan-io/conan-center-index/blob/master/recipes/mpc/all/conanfile.py#L52 and build fails with mpfr/4.2.1

[hamidelmaazouz]

... unless you prefer overriding transitive deps ? which can be done via the override=True flag on the Requirements object:

    def requirements(self):
        # Private deps won't be linked against by consumers, which is important
        # at least for Flex which does not expose a CMake target.
        private_deps = ["bison", "flex"]
        for req in self.conan_data["requirements"]:
            private = any(req.startswith(d) for d in private_deps)
            self.requires(req, visible=not private, override=True)