Add Au support for conan

[AbrilRBS]

Hi!
I'm trying to package the library to make it available in Conan Center Index, and I noticed that the pre-built header-only versions provided are only for the main branch, and are not present in the releases

I'd love to give users the ability to use this file for the version they choose (instead of building the package), but as of right now the release tar does not contain the files, so I'd like to request that in future releases, those files are added as part of the release at that point, thanks! :)

[chiphogg]

Thanks for writing! I've wanted to see Au available in Conan for a while. I thought we would need to support CMake first --- an effort which is actively underway (#215). But it sounds like you know an alternative way that doesn't require this, which is intriguing. (I don't know one way or another, because I don't use Conan myself.)

Note that we do have single-file versions going all the way back to 0.3.1, because our documentation website hosts docs simultaneously for different releases. For example, the single-file releases for 0.3.2 can be found at https://aurora-opensource.github.io/au/0.3.2/install/#pre-built-single-file.

That said --- I'm inferring from your conan use case that it wouldn't be enough to simply be able to download the files. It sounds like you would need to have the single-file versions present inside of the release tarball. Is that accurate? I don't know how this works. (Incidentally, if you have any Conan docs that would help me understand how I would need to package the single-file releases, that would be very helpful!)

By the way, one more question: would this whole issue go away if Au supported CMake? I'm assuming it would be easier to make a "full install" available in Conan, so the demand for the single-file alternative would be reduced.

[AbrilRBS]

Hi @chiphogg sorry for the delay, busy week :)

I thought we would need to support CMake first

Conan has integrations with many build systems, and Bazel is one of those! We have less experience packaging those than CMake ones, but Conan is perfectly capable of using your already-existing build system to generate packages! (But yes, CMake is usually a bit easier to work with)

I'm inferring from your conan use case that it wouldn't be enough to simply be able to download the files. It sounds like you would need to have the single-file versions present inside of the release tarball. Is that accurate?

So, the idea here is to, in the end, offer users two ways to consume project: By specifying that they only want the header-only version, Conan would fetch the package with only the single-file headers. Those can come from a different source than the main source files, as long as it's as stable as the release tars, we can fetch multiple sources to address different needs. Then, the other option would be to have the full library. So I was requesting the single-file headers as part of the releases because it's easier that way to just download 1 tar and be done with it, but if the docs are also valid mirrors for the header-only files, then we can add those no problem :)

For now, my idea was to start with the header-only variant, and once that's published, work on supporting the Bazel build (Or the CMake one if/once you feel that's up-to-speed with Bazel's, or at least close enough to be used!)

would this whole issue go away if Au supported CMake?

Not quite in that we would still like for users to be able to choose the header-only version, but the install version would be easier to implement in CMake yes! (As I said, we have more experience there)

Hope this clears things up, and thanks for pointing me to the header files - I'll ping you once we have something working :)

[chiphogg]

Yep --- I can confirm that the single-header-file packagings associated with a numbered release's docs should never change.

As for the progress in CMake support: I just posted what I think is the final PR (except for doc updates) for #215 today. So I think we're very close to getting native CMake support for Au!

[chiphogg]

Update: CMake support has fully landed. We are going to cut an 0.3.5 release which will include it. (Docs aren't reviewed yet, but they're in #270 and should be landed soon.)

[chiphogg]

Hi! Friendly ping, @AbrilRBS. Is there any outstanding action item on our side for this issue? Thanks!

[AbrilRBS]

Hi @chiphogg sorry for the radio silence, I got my backlog a bit all over the place after summer vacation. I'll get to this this week and get back to you once I achieve something good, thanks a lot for your patience :)

[chiphogg]

@AbrilRBS, we needed an issue for "support Conan", and this seemed like a logical choice, so I'm repurposing it to that end.

FYI @ericriff: I think this will be a good home for discussion and strategy. We've been chatting on #215, but that's a closed issue, so this makes more sense IMO.

[chiphogg]

I'll reproduce the "plan of record" portion of this comment here:

Let's take stock of where we're at, and where we hope to end up. In order to support conan, here are the steps I see:

1. Tweak the library structure.
   1. That's the main job that this present PR Rework folder structure and cmake files #298 was doing, but Rework folder structure and cmake files #298 is discussion-only.
   2. I created Consolidate Au CMake targets #300 to do this, and just now took it out of draft.
2. Add the GTest-related variables.
   1. I'm planning to use Make building unit tests optional to simplify packaging #297 for this, mainly because it's a great start, and because I want you to formally get credit by showing up in the git logs for this project. 🙂 I may end up pushing some commits to that branch before landing, if that turns out to be the most natural approach.
   2. Roughly, I think the plan will be to get Consolidate Au CMake targets #300 fixed up and landed; then, merge the new main into Make building unit tests optional to simplify packaging #297; then, figure out exactly what CMake options we should add and how they should behave.

LMK what you think of this plan, and thanks again for helping make Au more broadly accessible!

Step 1 has now already landed (#300), so it's time to finish up and set the CMake variables we want to have!

Now for step 2. Getting #297 fixed up and landed is the first part of this. After that, I'll follow up with a PR to add the second CMake variable, the one that lets users opt out of taking any GTest library dependency.