[vcpkg] Add missing autoconf dependencies to osx provisioning

[dg0yt]

• What does your PR fix?
  This PR is to install dependencies which are required by autoconf when building ports such as libtasn1 or libidn2. The lack of these dependencies breaks a number of PRs (e.g. [vcpkg/scripts/make] determine whether to use automake wrappers #17215, [vcpkg] Don't override pkg-config prefix #17205, [vcpkg] Fix lib uuid handling for x64-mingw-dynamic #17137, [libtasn1] build failure in osx pipeline #17098, [libidn2] build failure on osx pipeline #17057).

• Which triplets are supported/not supported? Have you updated the CI baseline?
  linux, osx

• Does your PR follow the maintainer guide?
  -/-

[dg0yt]

I added gettext also to osx, as suggest in #17057. So similar changes are done to linux and osx now

I would like to add that wile gettext/autopoint don't have significant dependencies (m4 on linux), gtk-doc-tools/gtk-doc come with a longer list on Ubuntu and macOS.

And for gettext, there is also a port.

[strega-nil]

You may want to split out linux and osx, since osx is a lot easier to update (and I can personally do it).

[dg0yt]

You may want to split out linux and osx, since osx is a lot easier to update (and I can personally do it).

This PR is now reduced to osx (matching my initial branch naming). Linux is in #17278.

Looing forward to see the autoconf backlog being resolved.

[strega-nil]

cool, thanks @dg0yt. I will try this out soon.

[PhoebeHui]

@Neumann-A, I noticed that you have already added feature 'tools' which contains autopoint to gettext port by PR #17278, is it possible to replace 'brew install gettext' on osx or linux?

[Neumann-A]

@PhoebeHui You can try it but I don't exactly know how it interacts which the whole m4 stuff which is normally needed. Just put the corresponding binary on PATH and it should be found. Be aware that building gettext[tools] is also a bit time consuming.

[dg0yt]

On Linux, the gettext port is empty at the moment:

vcpkg/ports/gettext/portfile.cmake

Lines 1 to 7 in b1e352c

	if(VCPKG_TARGET_IS_LINUX)
	set(VCPKG_POLICY_EMPTY_PACKAGE enabled)
	if (NOT EXISTS "/usr/include/libintl.h")
	message(FATAL_ERROR "Please use command \"sudo apt-get install gettext\" to install gettext on linux.")
	endif()
	return()
	else()

Regarding build time, it might be possible to create a separate feature for autotoolsautopoint. It is a script file which has its own target in make. Maybe its enough to satisfy the autoconf.

[dg0yt]

... for autotools ...

"for autopoint"

[PhoebeHui]

Verified it on macOS platform, and it works. however, the gettext doesn't work on linux, and building gettext[tools] is also a bit time consuming, we may consider to install gettext on pipeline test machines?

@strega-nil, what do you think?

Verified:

1. ./vcpkg install 'gettext[tools]'
2. Add 'vcpkg_add_to_path(PREPEND "${CURRENT_INSTALLED_DIR}/tools/gettext/bin")' to fontconfig portfile.
3. ./vcpkg install fontconfig
4. fontconfig:x64-osx successfully installed.

[Neumann-A]

vcpkg_add_to_path(PREPEND "${CURRENT_INSTALLED_DIR}/tools/gettext/bin")
should be
vcpkg_add_to_path(PREPEND "${CURRENT_HOST_INSTALLED_DIR}/tools/gettext/bin")

[dg0yt]

I'm playing with the gettext port on Linux, but it is relevant for osx as well:

I was able to establish an pure "autopoint" feature, running configure in /gettext-tools (slow) and running install in /gettext-tools/misc (fast). At the end, the package is just the autopoint script and a compressed tarball.

Given that this "build" just consists of configuring the autopoint.in script template (with @variable@ placeholders) and compressing a tarball, the slow configure step could be eliminated by using a small cmake script instead of using configure + make. The script has to fill in some paths and platform details, and install the script and tarball.

[dg0yt]

a small cmake script instead of using configure + make

Works for me, for windows/linux/osx/mingw.

Looking at the gtkdocize: I don't know about the build times, but brew install gtk-doc takes some time and disk space when it pulls in "docbook"

The autopoint solution pattern could work for gtkdocize, too: it is a script which runs during autoconf and doesn't come with direct dependencies. However there is no gtk-doc port yet, for adding a feature. Creating a full port with all dependencies is a much bigger task.

[dg0yt]

a small cmake script instead of using configure + make

Works for me, for windows/linux/osx/mingw.

#17317

[autoantwort]

Looking at the gtkdocize: I don't know about the build times, but brew install gtk-doc takes some time and disk space when it pulls in "docbook"

Huh on my machine it is as fast as installing other packages. It needs 10 seconds to install the package and dependencies.

[dg0yt]

Huh on my machine it is as fast as installing other packages. It needs 10 seconds to install the package and dependencies.

I need to do this in Azure Pipelines, and it takes more than one minute:

2021-04-16T07:16:19.8328510Z ==> Installing dependencies for gtk-doc: docbook, docbook-xsl, libxml2, boost and source-highlight
...
2021-04-16T07:17:24.8477650Z   /usr/local/etc/bash_completion.d

And now I see that it also pulls in boost. This takes some time, and generates /usr/local/Cellar/boost/1.75.0_2: 15,058 files, 524.2MB.

[PhoebeHui]

Installing dependencies for gtk-doc: docbook, docbook-xsl, libxml2, boost and source-highlight

Yes, I concerned to install gtk-doc on osx test machines, I'm not sure if it would cause conflicts with these packages which installed by vcpkg.

[autoantwort]

Yes, I concerned to install gtk-doc on osx test machines, I'm not sure if it would cause conflicts with these packages which installed by vcpkg.

It is already installed on some machines. Otherwise the pipelines would not fail randomly based on the machine they run on.

[dg0yt]

I have no clue if there is any interest in offering a lightweight gtk-doc[gtkdocize] feature (without the rest of gtk-doc), similar to the lightweight gettext[autopoint] feature. I decided to not start work on it until I see interest in such contributions.

[strega-nil]

I think this is good; however, I'd prefer to roll this into PR #17376

[dg0yt]

Thanks.
I think the main decision is still whether the autoconf dependencies are a user/CI responsibility, or if vcpkg includes (at least minimimal) ports to be used by port maintainers as host dependencies. It might be helpful to add a note to vcpkg_configure_make documentation.

[dg0yt]

Assuming that autopoint and gtkdocize are maintainer tools which are rarely actually needed for vcpkg ports, I offer one more alternative proposal to updating CI provisioning, now in #17406: Replace the calls to the missing maintainer tools by no-op calls to true (i.e. /usr/bin/true).

• This is the fastest solution for vcpkg ports which don't really need to update to these parts of the build systems.
• It solves the issue both for CI and for vcpkg users.
• It is entirely implemented in vcpkg_configure_make.
• It will still make use of the tools when (made) available.

[ras0219-msft]

LGTM, though this will be blocked until we reprovision OSX.

I also do very much like fast solutions :) and if we can get effectively identical results while doing less work I'm all for it.

Finally, if gettext tools can be made fast enough, building our own copies of the tools would be better than needing the system copies.

[dg0yt]

Today I would rather propose to not merge this. It solves issues in CI but not for users, and better solutions start to get merged.

• The gtkdocize aspect of libidn2 and libtasn1 is resolved by merging [Libidn2] disable documentation #17419, [Libtasn1] disable documentation #17420.
  One only has to remember to add set(ENV{GTKDOCIZE} true) in ports which don't need to build documentation.
• The autopoint aspect is solved with host dependencies either on gettext[tools] (slow) or on gettext[autopoint] (fast, from [gettext] Add "autopoint" tool to gettext[core] #17317)

[JackBoosY]

@dg0yt So please close this issue or change it to draft.