search

aurora-opensource / au

A C++14-compatible physical units library with no dependencies and a single-file delivery option. Emphasis on safety, accessibility, performance, and developer experience.
Apache License 2.0
309 stars 19 forks source link

Provide pre-generated header-only versions in future releases #257

Open AbrilRBS opened 2 weeks ago

AbrilRBS commented 2 weeks ago

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 commented 1 week ago

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 commented 1 week ago

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 commented 1 week ago

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!