Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

back to autotools build on unix for now #130

Merged
merged 2 commits into from
Sep 7, 2022

Conversation

h-vetinari
Copy link
Member

Undo effects of #128, see post-merge discussion there.

@conda-forge-linter
Copy link

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@h-vetinari h-vetinari merged commit 62d849e into conda-forge:main Sep 7, 2022
@h-vetinari h-vetinari deleted the auto_main branch September 7, 2022 07:47
script: build-lib.sh # [unix]
script: build-shared.sh # [unix]
# cmake script currently disabled due to compatibility issues with
# existing builds; see #49 for potential solution, or switch with 3.22
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Switching with 3.22 is not a good idea. We want to be able to switch between cmake and autotools build if the need arises. Therefore #49 is the best way forward.

Copy link
Member Author

@h-vetinari h-vetinari Sep 12, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please see this comment. Upstream already aligned the names and soversions, but it still broke.

I also don't see the benefit of being able to switch back to autotools. It just a large surface for breakage for very little gain AFAICT, especially now that upstream has graduated CMake to first class citizen.

Copy link
Member

@isuruf isuruf Sep 12, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please see this #68 (comment).

I know. Please see my comment on #49 about fixing protobuf_SO_VERSION and other variables.

I also don't see the benefit of being able to switch back to autotools. It just a large surface for breakage for very little gain AFAICT, especially now that upstream has graduated CMake to first class citizen.

AFAICT, CMake was not a first class citizen up-to-now. If that becomes the default installation, that is fine.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Upstream already aligned the names and soversions, but it still broke.

Yes, it was done by someone without a good understanding of how autotools works. I specifically added a feature to CMake to make it easier to replicate autotools behaviour because of protobuf.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAICT, CMake was not a first class citizen up-to-now. If that becomes the default installation, that is fine.

That is how I interpret protocolbuffers/protobuf#9596

@h-vetinari
Copy link
Member Author

AFAICT, CMake was not a first class citizen up-to-now. If that becomes the default installation, that is fine.

That is how I interpret protocolbuffers/protobuf#9596

FYI, autotools was removed completely from the upcoming v3.22. Salient quote:

The ideal future will have Bazel as the source of truth, with generated configurations for other supported build systems (e.g. CMake, Rake, Composer, etc.).

@h-vetinari h-vetinari mentioned this pull request Feb 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants