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

[protobuf] Allow protobuf to be crosscompiled. #14165

Closed
wants to merge 7 commits into from

Conversation

Nemirtingas
Copy link
Contributor

Protobuf port now asks for the host protoc, so .proto files can be built.

Describe the pull request
It adds a check for the native protoc binary for cross-compilation like the case when you were cross-compiling on Windows for another OS.

Protobuf port now asks for the host protoc, so .proto files can be built.
@Nemirtingas Nemirtingas changed the title Allow protobuf to be crosscompiled. [protobuf] Allow protobuf to be crosscompiled. Oct 22, 2020
@NancyLi1013 NancyLi1013 added the category:port-feature The issue is with a library, which is requesting new capabilities that didn’t exist label Oct 23, 2020
Copy link
Contributor

@JackBoosY JackBoosY left a comment

Choose a reason for hiding this comment

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

I think there is always a need to generate protobuf tools.

ports/protobuf/portfile.cmake Outdated Show resolved Hide resolved
if(CMAKE_HOST_WIN32 AND NOT VCPKG_TARGET_ARCHITECTURE MATCHES "x64" AND NOT VCPKG_TARGET_ARCHITECTURE MATCHES "x86")
if(CMAKE_HOST_WIN32)
set(HOST_PROTOBUF_TRIPLET "x86-windows")
if(NOT VCPKG_TARGET_ARCHITECTURE MATCHES "x64" AND NOT VCPKG_TARGET_ARCHITECTURE MATCHES "x86")
set(protobuf_BUILD_PROTOC_BINARIES OFF)
Copy link
Contributor

Choose a reason for hiding this comment

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

I think the uwp triplet also need to generate binaries.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't know, it was disabled before my change, was there any reason why ?

Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe the reviewer ignored it.

Copy link
Contributor Author

@Nemirtingas Nemirtingas Oct 23, 2020

Choose a reason for hiding this comment

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

Actually, it is built on UWP.

NOT (VCPKG_TARGET_IS_WINDOWS AND NOT VCPKG_TARGET_IS_UWP) =>
NOT (TRUE AND NOT TRUE) =>
NOT (TRUE AND FALSE) =>
NOT (FALSE) =>
TRUE

Am i right ?

ports/protobuf/portfile.cmake Outdated Show resolved Hide resolved
ports/protobuf/portfile.cmake Outdated Show resolved Hide resolved
Comment on lines 119 to 131
if(protobuf_BUILD_PROTOC_BINARIES)
file(GLOB EXECUTABLES ${CURRENT_PACKAGES_DIR}/bin/protoc*)
foreach(E IN LISTS EXECUTABLES)
file(INSTALL ${E} DESTINATION ${CURRENT_PACKAGES_DIR}/tools/${PORT}
PERMISSIONS OWNER_READ OWNER_WRITE OWNER_EXECUTE GROUP_READ GROUP_WRITE GROUP_EXECUTE WORLD_READ)
endforeach()
else()
file(GLOB EXECUTABLES ${_VCPKG_INSTALLED_DIR}/${HOST_PROTOBUF_TRIPLET}/tools/${PORT}/protoc*)
foreach(E IN LISTS EXECUTABLES)
file(INSTALL ${E} DESTINATION ${CURRENT_PACKAGES_DIR}/tools/${PORT}/
PERMISSIONS OWNER_READ OWNER_WRITE OWNER_EXECUTE GROUP_READ GROUP_WRITE GROUP_EXECUTE WORLD_READ)
endforeach()
endif()
Copy link
Contributor

Choose a reason for hiding this comment

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

We prefert to use vcpkg_copy_tools instead of this.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Problem is that its not generic enought. protoc is a symbolic link on OS that are not Windows:

ll installed/x64-linux/tools/protobuf/
lrwxrwxrwx 1 root root      15 oct.  22 14:11 protoc -> protoc-3.13.0.0*
-rwxrwxr-- 1 root root 5602472 oct.  22 14:11 protoc-3.13.0.0*

So if I use vcpkg_copy_tools, it will only copy the symbolic link. And protoc has the version appended to it, thats why I use the wildcard instead of vcpkg_copy_tools.

Copy link
Contributor

Choose a reason for hiding this comment

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

So I think we should expand vcpkg_copy_tools instead of modifying it here. Please open an issue to report this.

Copy link
Contributor

@traversaro traversaro Oct 23, 2020

Choose a reason for hiding this comment

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

So I think we should expand vcpkg_copy_tools instead of modifying it here. Please open an issue to report this.

I think this is already tracked in #11547 .

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Interesting, I wont open a new issue then.

ports/protobuf/portfile.cmake Outdated Show resolved Hide resolved
ports/protobuf/portfile.cmake Show resolved Hide resolved
elseif(CMAKE_HOST_UNIX)
set(HOST_PROTOBUF_TRIPLET "x64-linux")
if(NOT VCPKG_TARGET_ARCHITECTURE MATCHES "x64" AND NOT VCPKG_TARGET_ARCHITECTURE MATCHES "x86")
set(protobuf_BUILD_PROTOC_BINARIES OFF)
Copy link
Contributor

Choose a reason for hiding this comment

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

See comment above.

ports/protobuf/portfile.cmake Show resolved Hide resolved
Co-authored-by: Jack·Boos·Yu <47264268+JackBoosY@users.noreply.github.com>
@Nemirtingas
Copy link
Contributor Author

Nemirtingas commented Oct 23, 2020

I can't find any VCPKG_HOST_ARCHITECTURE, any idea ? ${CMAKE_SYSTEM_PROCESSOR} and ${CMAKE_HOST_SYSTEM_PROCESSOR} seem empty. I'd like to do something like VCPKG_TARGET_ARCHITECTURE == VCPKG_HOST_ARCHITECTURE then build binaries.

Copy link

@linquize linquize left a comment

Choose a reason for hiding this comment

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

ARM and ARM64 linux support

ports/protobuf/portfile.cmake Show resolved Hide resolved
ports/protobuf/portfile.cmake Show resolved Hide resolved
@strega-nil
Copy link
Contributor

Requires cross-talk with #14318

@strega-nil strega-nil added the depends:different-pr This PR or Issue depends on a PR which has been filed label Nov 12, 2020
@Nemirtingas
Copy link
Contributor Author

Nemirtingas commented Nov 13, 2020

Requires cross-talk with #14318

Adding a new variable to VCPKG like VCPKG_HOST_TRIPLET would be nice for cross-compilation. Thats what I triied to achieve in this pr for protoc.

@BillyONeal
Copy link
Member

Requires cross-talk with #14318

To clarify: this PR tries to solve the cross compilation problems for protobuf, by repeating much of our existing triplet system within the protobuf port; we aren't fans of doing something like that because it's fragile, and it suggests that vcpkg the tool needs a more complete solution to these building a tool that we use in the build scenarios. The other PR #14318 solves a smaller subset of target architectures but gets both protobuf and grpc, so neither is a true superset of the other.

Building some kind of support for "tool ports" which use the host rather than the target settings is certainly on our radar but we don't want to expand the existing workarounds drastically right now.

Leaving this PR and the other open because at such time we address this problem more completely we're going to want to make sure both these are addressed well.

@Nemirtingas
Copy link
Contributor Author

Building some kind of support for "tool ports" which use the host rather than the target settings is certainly on our radar but we don't want to expand the existing workarounds drastically right now.

Hi, yes I can understand that.

@Nemirtingas Nemirtingas reopened this Dec 18, 2020
@NancyLi1013
Copy link
Contributor

Could you please resolve the conflicts?

@Nemirtingas
Copy link
Contributor Author

Could you please resolve the conflicts?

Is it actually worthing it ? BillyONeal seemed to say that this pr won't be merged until a suitable solution to build host tools is found. At least thats my understanding.

@BillyONeal
Copy link
Member

@Nemirtingas I think @NancyLi1013 just saw this PR get pinged due to "reopening" and didn't follow the whole thread.

@Nemirtingas
Copy link
Contributor Author

@Nemirtingas I think @NancyLi1013 just saw this PR get pinged due to "reopening" and didn't follow the whole thread.

Ah right, Thoses 2 "comment" buttons... I often hit the wrong one 🤐

@NancyLi1013
Copy link
Contributor

Sorry for my above comments. As @BillyONeal said, I didn't follow the whole thread.

@Nemirtingas Nemirtingas deleted the protoc_crosscompile branch April 12, 2021 14:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
category:port-feature The issue is with a library, which is requesting new capabilities that didn’t exist depends:different-pr This PR or Issue depends on a PR which has been filed
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[protobuf] Handle cross-compilation on Linux host
8 participants