@microsoft-github-policy-service agree

@JonLiu1993 The x86 build has been running and stuck for over a day 😅 Can it be restarted?

@mrowrpurr Just sync the branch with master via github. It will automatically restart then

@JonLiu1993 ping to un-stuck-ify. Triggered fresh build with a pull from master but, as a first time contributor, looks like it needs another manual approval to run the builds

@JonLiu1993 ping to un-stuck-ify. Triggered fresh build with a pull from master but, as a first time contributor, looks like it needs another manual approval to run the builds

@mrowrpurr, Thanks for your pr, I always keep an eye on this PR.

The ci error will be fixed by #28089

The ci error will be fixed by #28089

No, the actual fix is #28160.

Given that the CMake update nearly rebuilds the world, can we integrate another change with the next push?

Please update

vcpkg/scripts/ports.cmake

Line 87 in 30a20e8

vcpkg_minimum_required(VERSION 2021-11-02)

This should be bumped to 2022-10-12 to generally enable the use of ${VERSION} in portfiles.
Cf. #28240 (comment), cc @Neumann-A

@dg0yt Bumped

fda3307

- vcpkg_minimum_required(VERSION 2021-11-02)
+ vcpkg_minimum_required(VERSION 2022-10-12)

@dg0yt My bad if I should've waited for #28160 before "rebuilding the world" 🌍

Consider syncing with master again. Maybe the CI run gets lucky and skips the problem ;)

CI won't get happy if the baseline fixes are not merged.
IMO this PR could be merged despite the well-known baseline regressions.

CI won't get happy if the baseline fixes are not merged.

That is only true for full rebuilds not partial rebuilds ;)

IMO this PR could be merged despite the well-known baseline regressions.

Yeah I agree with that.

CI won't get happy if the baseline fixes are not merged.

That is only true for full rebuilds not partial rebuilds ;)

A CMake update is not so much different from a full rebuild. That's why this PR is affected by the baseline regressions.
(Well, at least we skip the known failures.)

A CMake update is not so much different from a full rebuild.

A CMake update is always a full rebuild in the first run. After that it should just be partial rebuilds.

@JonLiu1993 I can sync to HEAD anytime again as needed (although I think you can do it too)

Any way to get movement here?

This is breaking my projects for everyone who doesn't manually install CMake 3.25.1 into their PATH because of the 3.25.0 PCH bug. Could we please find a way to merge this?

@JonLiu1993 I can sync to HEAD anytime again as needed (although I think you can do it too)

Any way to get movement here?

This is breaking my projects for everyone who doesn't manually install CMake 3.25.1 into their PATH because of the 3.25.0 PCH bug. Could we please find a way to merge this?

The strange thing is that I can't reproduce the error on ci locally. I'm thinking whether we can temporarily fail the triplet that reported the error in ci in cibaseline to bypass these errors. But this operation may obviously be dangerous or incorrect, I need to discuss it with my colleagues.

Port protobuf installs libprotobuf.lib, but libphonenumer looks for protobuf, #28522 (comment).

libphonenumber builds with CMake 3.25.0 due to a temporary behaviour which was reverted in CMake 3.25.1:
Trying the lib name prefix when searching for libs on Windows,
Kitware/CMake@4c2952c

Possible fix: patch https://github.com/google/libphonenumber/blob/9741ae82fdf85e12d40e9d1f78632378c4e0f885/cpp/CMakeLists.txt#L59

+  set(CMAKE_FIND_LIBRARY_PREFIXES "" "lib")
  find_library (${NAME}_LIB NAMES ${LIBRARY})

+  set(CMAKE_FIND_LIBRARY_PREFIXES "" "lib")
  find_library (${NAME}_LIB NAMES ${LIBRARY})

To not interfere, with default order, guard with if(MSVC) or use
set(CMAKE_FIND_LIBRARY_PREFIXES "${CMAKE_FIND_LIBRARY_PREFIXES};lib")

@dg0yt @JonLiu1993

Could I get some guidance? I see requires: author-response added.

Is that a response of the libphonenumber port author or from myself?

@dg0yt's patch helps google/libphonenumber which had a PR merged a couple days ago:
google/libphonenumber#2818 "CPP: Fix cmake build failure + export libphonenumber-config.cmake"

I don't think y'all need me for anything, in which case, "as you were." Just poking.

I don't think you need to continue this PR: There is #28522.
Unfortunately, new regressions are merged faster than fixes.

@mrowrpurr, thanks for your contribution. this PR duplicate of #28522.
can we close this PR and continue tracking progress in another PR?

#28522 was merged (which was a duplicate of this one)