librdata: enable to build on Windows#30014
Conversation
|
bump |
uilianries
left a comment
uilianries
left a comment
There was a problem hiding this comment.
@shun2wang Hello! Thank you for bringing your suggestion of supporting MSVC into the Conan Center. 👋
Just like the last time on the PR #26024, this time we discussed internally again about librdata, and based on what we found, we unfortunately can not accept your PR this time. Here are the main reasons:
On the last PR, we accepted librdata as it's supported by other package managers, but all of them are related to Linux only (except for msys).
The project looks abandoned, as we pointed out last time, its last commit is from 3 years ago: https://github.com/WizardMac/librdata/commits/master/, which results in your PR WizardMac/librdata#52 having a small chance of being reviewed or accepted by the upstream.
You change not only adds a non-official build script (CMake), but also changes the source code. Which is not approved by upstream, and as a unique patch, the Conan Center Index will become the single maintainer of this new behavior, not following who is consuming librdata from its project. This will result in a higher complexity for this recipe and an extra effort of maintenance for Conan Center Index in the end.
Also, any new bug discovered during the Windows support would be our responsibility, as we introduced it, and it would not be possible to address as expected: We can open an issue to the upstream, but no proper solution would be available in a new release, or immediate support from the author.
In case the upstream authors decide to continue working on the project and accept your PR, we can revisit and accept your PR as well.
On the other hand, it does not stop you from distributing/using this new patch for librdata: You can use a few features that may make this possible across your own fork:
-
First, you still use MinGW + GCC on Windows, and it works with librdata, I just tested locally: librdata-0.0.0.cci.20231003-windows-mingw-gcc.log, so I would recommend trying this way if possible, as it's the official support.
-
In case you really can't using mingw and need MSVC, you still can use a local recipes index and point your GitHub fork as a new remote: People will be able to consume your changed recipes, not only for librdata, but for any other customization around. Initially, it will make only the Conan recipe available, so they can export and build it locally or under a build machine/service.
-
You can use an Artifactory instance to publish your pre-built packages if operating it in an enterprise. So your teammates can download from a centralized instance, instead of consuming from Conan Center and being dependent on an internet connection.
-
If this is a small experiment, or even working in a very small team, you may find Conan Server enough if you want to distribute artifacts, include pre-built packages, but running a small server on your machine, for instance.
This decision is not a blocker for future contributions. Please feel free to open new issues to discuss your needs or propose alternative approaches before pushing your PRs, so we can gain insight before taking any action. We welcome future contributions and appreciate your involvement.
Regards!
|
Thank you for your detailed and constructive explanation! I accept all of these opinions,I will use this recipe in other ways. |
2 participants
Summary
Changes to recipe: librdata/0.0.0.cci.20231003
Motivation
Enable to build librdata on Windows.
Details
Add a 👍 reaction to pull requests you find important to help the team prioritize, thanks!