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

[scripts-audit] vcpkg_fixup_pkgconfig #19658

Merged
merged 10 commits into from
Sep 27, 2021

Conversation

strega-nil
Copy link
Contributor

Redo of #19348 (since that was buggy)

@PhoebeHui PhoebeHui added category:scripts-audit Part of the scripts audit effort. info:internal This PR or Issue was filed by the vcpkg team. labels Aug 20, 2021
Copy link
Contributor

@ras0219-msft ras0219-msft left a comment

Choose a reason for hiding this comment

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

I recommend testing this by:

  1. Install a bunch of packages containing .pc files before this change
  2. Install the same packages with this change into a different install dir
  3. Diff all .pc files across the two. They must be the same.

At a minimum, I recommend 20 different packages with .pc files. I see a bunch of hits via git grep '\.pc' ports to use for this.

endif()
vcpkg_list(JOIN pkg_config_path "${VCPKG_HOST_PATH_SEPARATOR}" pkg_config_path)
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this guaranteed to be a no-op when VCPKG_HOST_PATH_SEPARATOR is ;? What about in the face of empty elements?

Copy link
Contributor Author

@strega-nil strega-nil Aug 23, 2021

Choose a reason for hiding this comment

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

@ras0219-msft it's actually not a no-op when VCPKG_HOST_PATH_SEPARATOR is ;: it removes one \ in front of ;s. In the face of empty elements, it is correct.

I think this ends up working by accident?

scripts/cmake/vcpkg_fixup_pkgconfig.cmake Outdated Show resolved Hide resolved
@dg0yt
Copy link
Contributor

dg0yt commented Aug 20, 2021

  1. Install a bunch of packages containing .pc files before this change

...
At a minimum, I recommend 20 different packages with .pc files. I see a bunch of hits via git grep '\.pc' ports to use for this.

Install gdal into a fresh root... it pulls in a lot of packages with pc files, because its configuration depends on it. And find some more ports which are not used by gdal.

@Neumann-A
Copy link
Contributor

If the gtk chain fails it is probably also due to not working pc files. (mostly meson build system but some deps have cmake fallbacks)

"${CURRENT_INSTALLED_DIR}${PATH_SUFFIX_${config}}/lib/pkgconfig"
"${CURRENT_INSTALLED_DIR}/share/pkgconfig"
"${CURRENT_PACKAGES_DIR}${PATH_SUFFIX_${config}}/lib/pkgconfig"
"${CURRENT_PACKAGES_DIR}/share/pkgconfig"
Copy link
Contributor

Choose a reason for hiding this comment

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

Only loosely related to this PR:
Is there a point in installing pc files to share/pkgconfig? Are there ports which do that? IIUC this location is unable to separate debug builds from release builds. This could be a subtle source for errors when pc files specify transitive dependencies as Libs, not as Requires.

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 xorg-proto does that. Basically it allows for arch independent data to be looked up. pc files can be and are use for more than just for finding libraries.

Copy link
Contributor

Choose a reason for hiding this comment

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

Okay...
So proper usage is to be ensured by review. Or is this another case for an automated check:
No Libs(.private) field in share/pkgconfig?

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 xorg-proto does that

There is no such port?

Copy link
Contributor

Choose a reason for hiding this comment

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

There is no such port?

#9966 the mother of all vcpkg pkgconfig stuff. Didn't have time to work on it and won't take the time unless it is clear how to integrate the x stuff into vcpkg without messing linux totally up ;)

@strega-nil
Copy link
Contributor Author

strega-nil commented Aug 23, 2021

Alright, with the new changes, the following ports have no changes besides ordering of lines (I just installed a bunch of ports that called vcpkg_fixup_pkgconfig) (on arm64-osx):

jack2
boost-io
freexl
mailio
tool-meson
cairomm
glib
blas
freealut
mbedtls[pthreads]
boost-integer
boost-iterator
boost-regex
graphene
lapack-reference[blas-select,noblas]
boost-math
tiff[jpeg,lzma,zip]
openblas
atk
libjpeg-turbo
json-c
sdl2
boost-rational
brotli
opengl
boost-core
libtheora
boost-array
openh264
boost-preprocessor
boost-concept-check
boost-vcpkg-helpers
szip
boost-tokenizer
cairo[fontconfig,freetype,gobject]
getopt
gmp
libffi
c-ares
zstd
gdk-pixbuf
fribidi
boost-lexical-cast
boost-smart-ptr
boost-build
trantor
boost-type-traits
boost-atomic
boost-assert
libtasn1
abseil
boost-container
boost-mpl
libsigcpp
libssh[crypto,mbedtls]
pcre
boost-asio
libvorbis
boost-static-assert
libjuice
boost-algorithm
pixman
libepoxy
console-bridge
boost-unordered
lzo
catch2
plog
opusfile
dirent
glew
vcpkg-cmake-config
pthreads
boost-config
freetype[bzip2]
pugixml
openssl
boost-ratio
qhull
fontconfig
boost-throw-exception
libiconv
boost-conversion
boost-move
boost-typeof
expat
vcpkg-cmake
boost-date-time
libsndfile[external-libs]
boost-modular-build-helper
boost-system
icu
boost-fusion
boost-lambda
boost-range
libdatachannel[ws]
rapidjson
libzip[bzip2]
boost-functional
boost-uninstall
zlib
boost-optional
boost-bind
protobuf
boost-container-hash
jsoncpp
speexdsp
boost-chrono
openal-soft
libpng
libgpg-error
boost-exception
boost-tuple
libzip[commoncrypto,default-aes]
boost-winapi
allegro5
physfs
minizip-ng
opus
boost-function-types
boost-detail
liblzma
bzip2
boost-function
boost-utility
libuuid
drogon
gettext
boost-intrusive
cfitsio
libogg
fann
boost-predef
freetype[brotli,png,zlib]
pthread
boost-align
boost-numeric-conversion
nlohmann-json
boost-type-index
pcre2
usrsctp
libflac

@strega-nil-ms strega-nil-ms force-pushed the vcpkg_fixup_pkgconfig branch from 0a2d444 to cca3b43 Compare August 23, 2021 23:48
@strega-nil-ms
Copy link
Contributor

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@strega-nil-ms
Copy link
Contributor

strega-nil-ms commented Aug 24, 2021

Additionally, the same is true for x64-windows-static with gdal's dependencies (tho not gdal itself, since gdal:x64-windows-static fails to build).

@dg0yt
Copy link
Contributor

dg0yt commented Aug 24, 2021

gdal:x64-windows-static fails to build

Where does it fail now?

@dg0yt
Copy link
Contributor

dg0yt commented Aug 24, 2021

gdal:x64-windows-static fails to build

Where does it fail now?

Anyway, gdal:x64-windows-static doesn't use pc files. That's a different story. A lot of open source GIS-related ports use msbuild for windows (non-mingw) and lack a mechanism to exchange usage requirements between ports.
But gdal:x64-mingw-static uses pc files.

@strega-nil-ms
Copy link
Contributor

strega-nil-ms commented Sep 8, 2021

@dg0yt yeah I just wanted to test with x64-windows-static that it worked, gdal isn't necessarily that important.

Comment on lines 64 to 71
if("${VCPKG_HOST_PATH_SEPARATOR}" STREQUAL ";")
vcpkg_list(APPEND pkg_config_path $ENV{PKG_CONFIG_PATH})
else()
set(ENV{PKG_CONFIG_PATH} "${PKGCONFIG_INSTALLED_DIR}${VCPKG_HOST_PATH_SEPARATOR}${PKGCONFIG_INSTALLED_SHARE_DIR}${VCPKG_HOST_PATH_SEPARATOR}${PKGCONFIG_PACKAGES_DIR}${VCPKG_HOST_PATH_SEPARATOR}${PKGCONFIG_PACKAGES_SHARE_DIR}")
vcpkg_list(JOIN pkg_config_path "${VCPKG_HOST_PATH_SEPARATOR}" pkg_config_path)
if(NOT "$ENV{PKG_CONFIG_PATH}" STREQUAL "")
string(APPEND pkg_config_path "${VCPKG_HOST_PATH_SEPARATOR}$ENV{PKG_CONFIG_PATH}")
endif()
endif()
Copy link
Member

Choose a reason for hiding this comment

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

It seems like the imbuing of pkg_config_path with $ENV{PKG_CONFIG_PATH} should be done as a separate step from transforming ; to ${VCPKG_HOST_PATH_SEPARATOR} ?

How about (with no ifs):

vcpkg_list(APPEND pkg_config_path $ENV{PKG_CONFIG_PATH})
vcpkg_list(JOIN pkg_config_path "${VCPKG_HOST_PATH_SEPARATOR}" pkg_config_path)

?

Copy link
Contributor

Choose a reason for hiding this comment

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

The reason we don't want this is:

Let PKG_CONFIG_PATH = [a;b, c, d]

Assume VCPKG_HOST_PATH_SEPARATOR = ';'. Then, PKG_CONFIG_PATH = 'a\;b;c;d', and you get:

vcpkg_list(APPEND pkg_config_path $ENV{PKG_CONFIG_PATH})
# pkg_config_path = "...;a\;b;c;d"
vcpkg_list(JOIN pkg_config_path "${VCPKG_HOST_PATH_SEPARATOR}" pkg_config_path)
# pkg_config_path = "...;a;b;c;d"

thus, pkg_config_path is wrong.

Copy link
Member

Choose a reason for hiding this comment

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

I think your "Let PKG_CONFIG_PATH" part already starts with pkg_config_path being wrong, since "a, b, c" isn't a valid PATH entry.

Copy link
Contributor

Choose a reason for hiding this comment

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

that was my attempt at array list syntax; basically, let PKG_CONFIG_PATH be the elements:

  • a;b
  • c
  • d

Copy link
Contributor

Choose a reason for hiding this comment

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

I wouldn't mind if ;wasn't supported in directory names: It is the separator on Unix anyway. But : and do matter.
Again, I would suggest a test-first approach. Someone will come and break it. Guard it with a unit test.

Copy link
Member

@BillyONeal BillyONeal left a comment

Choose a reason for hiding this comment

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

This seems OK to me but I am far Far FAR from a pkgconfig expert.

@strega-nil-ms strega-nil-ms force-pushed the vcpkg_fixup_pkgconfig branch 2 times, most recently from 6b44fa0 to a2777c6 Compare September 15, 2021 22:14
Copy link

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

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

You have modified or added at least one portfile where deprecated functions are used.

If you feel able to do so, please consider migrating them to the new functions:
vcpkg_install_cmake -> vcpkg_cmake_install (from port vcpkg-cmake)
vcpkg_build_cmake -> vcpkg_cmake_build (from port vcpkg-cmake)
vcpkg_configure_cmake -> vcpkg_cmake_configure (Please remove the option PREFER_NINJA) (from port vcpkg-cmake)
vcpkg_fixup_cmake_targets -> vcpkg_cmake_config_fixup (from port vcpkg-cmake-config)

In the ports that use the new function, you have to add the corresponding dependencies:

{
  "name": "vcpkg-cmake",
  "host": true
},
{
  "name": "vcpkg-cmake-config",
  "host": true
}

The following files are affected:

  • scripts/test_ports/unit-test-cmake/portfile.cmake

@dg0yt
Copy link
Contributor

dg0yt commented Sep 16, 2021

Can you add a check that portfiles don't contain items matching

  • ^(-l)?(optimized|debug)$
  • ::

This is typical for pc files from CMake config, and possibly only found much later. Example: #20062 (comment)

(We might eventually resolve the optimized/debug variants.)

@strega-nil-ms
Copy link
Contributor

@dg0yt given that that's not really a part of the scripts audit (and that it is in theory fine), I'd prefer not to.

@dg0yt
Copy link
Contributor

dg0yt commented Sep 23, 2021

@strega-nil-ms Okay. Finishing the audit in a short time frame is also fine. (I consider the scripts locked for other changes as long as there is an audit going on.)

@strega-nil-ms strega-nil-ms merged commit f0281bf into microsoft:master Sep 27, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
category:scripts-audit Part of the scripts audit effort. info:internal This PR or Issue was filed by the vcpkg team.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants