I thought the previous change worked for me, and it unblocked vcpkg upgrade. Are there differences in behavior depending on how specifically the package is discovered?

IMPORTED_GLOBAL could affect it. Finding at the top-level could too. I'm not sure why VTK wasn't complaining. Maybe there's a silent policy involved?

Yeah I double-checked and the previous change worked for me in a simple test as well. Were you able to reproduce the reported error locally? Unsure what the setup differences are.

This change works for me as well, so there's no harm in it but I'd like to make sure that it fixes the problem @randyfan encountered before tagging a new patch release.

make sure that it fixes the problem

Agreed on that, especially given that I couldn't trigger the problem locally either. I think vcpkg does some weird things with find_package sometime, so it could be something there too(?).

I would suggest to use target_link_libraries(pugixml INTERFACE pugixml::pugixml), rather than setting the property directly.

Does that work with IMPORTED targets? Testing it out…

It does. Updated. Thanks.

I was able to fix this issue locally after changing our worker image from Visual Studio 2017 to Visual Studio 2019 in appveyor.yml.

Hmm, that doesn't sound right. What else changed in that uplift? Does this change fix the original problem (namely because I wouldn't want to have to ask people to upgrade to vs2019 to fix this)?

This is all I changed in our local repo to fix the appveyor build: randyfan/NOME3@0998d8d.

To summarize, I removed flex and bison installation (should be unrelated to the issue), and changed the following to 2019:
"call "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvars64.bat""

so changing to 2019 seems to have fixed the problem I had with ALIAS

VS2019 env on AppVeyor has CMake 3.18, and 2017 has 3.16. I only tested this with 3.15... maybe related? I also wonder if you’re using any caching in the build so that a change f environment would have cleared it.

Could you please test this change in the original, failing, configuration to know if this addresses it please (since we haven't been able to reproduce the error)? Caching wouldn't (sigh shouldn't) affect this; the target needs to be made every configuration.

Sure. To test the change, do I just revert to the original failing appveyor.yml and check my appveyor build? Sorry I'm kind of new to this

Hmm. Not sure. You probably have to apply a patch to a vcpkg build, but that's outside my knowledge here :/ .

Sure. To test the change, do I just revert to the original failing appveyor.yml and check my appveyor build? Sorry I'm kind of new to this

@randyfan Yes, it makes sense to revert to the original failing appveyor.yml and test the build.
Please check, that the original error is still there and test, if the error disappears with the change from this PR here.

How do I test the change from this PR? Vcpkg is automatically installing the most recent version of pugixml for me rn. Is there a way I can specify a branch or version?

@randyfan You can download a patch from the PR here using:
https://patch-diff.githubusercontent.com/raw/zeux/pugixml/pull/389.patch
Then update your vcpkg\ports\pugixml\portfile.cmake and add the patch there (see vcpkg_from_github.md for instructions).

The updated, required files are attached here for your convenience.
pugixml_vcpkg_with_patch_PR389.zip

VS2019 env on AppVeyor has CMake 3.18, and 2017 has 3.16.

Here is some releated info from the CMake 3.18 Release Notes:
https://cmake.org/cmake/help/v3.18/release/3.18.html#commands

The add_library() and add_executable() commands learned to create Alias Targets referencing non-GLOBAL Imported Targets.

I was able to reproduce the original issue after a bit more testing; not sure what exactly the difference in my setup was wrt earlier, I think I might have used a different version of CMake after all, or perhaps some accidentally cached CMake output.

On current pugixml master, when using cmake-3.18.4-win64-x64 everything works great; when using cmake-3.17.5-win64-x64 I get the following:

CMake Error at C:/work/pugixml-build/pugixml-config.cmake:16 (add_library):
  add_library cannot create ALIAS target "pugixml" because target
  "pugixml::pugixml" is imported but not globally visible.

This explains why the AppVeyor upgrade to VS2019 fixed the issue. Obviously pugixml CMake shouldn't require 3.18, and I confirmed that with the patch CMake 3.17 as well as some earlier versions (3.16, 3.15; I can't confirm 3.10 since it doesn't support VS2019 which is the only VS version I have installed so that will have to do) work as well. So I'm going to merge this and tag 1.11.2 to make sure this works for all versions...

... and this is now done. Thanks everyone for the help with these issues! I hope CMake problems are behind us now.