install error with vcpkg on linux

[endingly]

log is

Detecting compiler hash for triplet x64-linux...
Compiler found: /usr/bin/c++
The following packages will be built and installed:
    libmesh:x64-linux@1.5.0#6
Restored 0 package(s) from /home/endingly/.cache/vcpkg/archives in 4.69 us. Use --debug to see more details.
Installing 1/1 libmesh:x64-linux@1.5.0#6...
Building libmesh:x64-linux@1.5.0#6...
-- Using cached libMesh-libmesh-21f623c837b3865ed65ec9608b357bdb1935d428.tar.gz.
-- Cleaning sources at /home/endingly/code_tools/vcpkg/buildtrees/libmesh/src/db1935d428-7b6bc82081.clean. Use --editable to skip cleaning for the packages you specify.
-- Extracting source /home/endingly/code_tools/vcpkg/downloads/libMesh-libmesh-21f623c837b3865ed65ec9608b357bdb1935d428.tar.gz
-- Using source at /home/endingly/code_tools/vcpkg/buildtrees/libmesh/src/db1935d428-7b6bc82081.clean
-- Getting CMake variables for x64-linux-dbg
-- Getting CMake variables for x64-linux-rel
-- Configuring x64-linux-dbg
CMake Error at scripts/cmake/vcpkg_execute_required_process.cmake:112 (message):
    Command failed: /usr/bin/bash -c "V=1 ./../src/db1935d428-7b6bc82081.clean/configure  \"--disable-silent-rules\" \"--verbose\" \"--disable-shared\" \"--enable-static\" \"--with-methods=dbg\" \"--prefix=/home/endingly/code_libs/plasma_emulator/out/build/linux_gcc_x64_debug/vcpkg_installed/x64-linux/debug\" \"--bindir=\\${prefix}/../tools/libmesh/debug/bin\" \"--sbindir=\\${prefix}/../tools/libmesh/debug/sbin\" \"--libdir=\\${prefix}/lib\" \"--includedir=\\${prefix}/../include\" \"--datarootdir=\\${prefix}/share/libmesh\""
    Working Directory: /home/endingly/code_tools/vcpkg/buildtrees/libmesh/x64-linux-dbg
    Error code: 1
    See logs for more information:
      /home/endingly/code_tools/vcpkg/buildtrees/libmesh/config-x64-linux-dbg-config.log
      /home/endingly/code_tools/vcpkg/buildtrees/libmesh/config-x64-linux-dbg-out.log
      /home/endingly/code_tools/vcpkg/buildtrees/libmesh/config-x64-linux-dbg-err.log

Call Stack (most recent call first):
  scripts/cmake/vcpkg_configure_make.cmake:863 (vcpkg_execute_required_process)
  ports/libmesh/portfile.cmake:18 (vcpkg_configure_make)
  scripts/ports.cmake:175 (include)


error: building libmesh:x64-linux failed with: BUILD_FAILED
Elapsed time to handle libmesh:x64-linux: 26 s
Please ensure you're using the latest port files with `git pull` and `vcpkg update`.
Then check for known issues at:
  https://github.com/microsoft/vcpkg/issues?q=is%3Aissue+is%3Aopen+in%3Atitle+libmesh
You can submit a new issue at:
  https://github.com/microsoft/vcpkg/issues/new?title=[libmesh]+Build+error+on+x64-linux&body=Copy+issue+body+from+%2Fhome%2Fendingly%2Fcode_libs%2Fplasma_emulator%2Fout%2Fbuild%2Flinux_gcc_x64_debug%2Fvcpkg_installed%2Fvcpkg%2Fissue_body.md

And, /home/endingly/code_tools/vcpkg/buildtrees/libmesh/config-x64-linux-dbg-err.log is

configure: error: Cannot find m4 utility. Install m4 and try again.
configure: error: ../../.././../src/db1935d428-7b6bc82081.clean/contrib/netcdf/v4/configure failed for contrib/netcdf/v4

[roystgnr]

You're reporting this in the wrong place (we didn't write those build scripts and don't support things we didn't write), but if you're looking for a workaround for your own sake then surely the answer is

Install m4 and try again.

libMesh doesn't require m4 to configure itself (I just tested this with a configure --disable-netcdf on a system with m4 uninstalled) but if NetCDF does and if you want NetCDF (either because you need ExodusII support or because you also don't want to futz with someone else's build scripts) then you're going to need m4.

[endingly]

Do you plan to add cmake support ?

[roystgnr]

No; I've been disappointed with cmake every time I've interacted with it (including recently), and I definitely don't want to employ it myself. Autotools is of course also disappointing, but disappointing in different ways which we mostly manage to work around.

(the above might be unfair to cmake - it's quite possible that the core software is fine but the various packages I've run into have been flaky - but part of what I like about autotools is the abundance of pre-existing much-less-flaky archives)

I do need to look at more recently developed build systems one of these days, though. I heard good things about https://bazel.build/ not long ago. Even if there were no downsides I couldn't imagine switching over any time soon, though; there's a bit of a chicken-and-egg problem with making that large of a change to a system we don't have a lot of experience with.

[pbauman]

Sadly, CMake seems to be the most widely accepted hot garbage for building C++ libraries and applications these days. It's slowly improving, but it's a massive PITA to do even slightly atypical things. But it's probably possible, with substantial effort, to closely match what is done here with Autotools, including testing and packaging.

This is NOT a plug for switching to CMake. Just adding color to the discussion.

[roystgnr]

Well, I would hope it's still Turing-complete. ;-) And I'm not entirely opposed to switching to something, I just dream of something better than "with substantial effort" for "closely match". I probably need to keep an eye on both recently-developed and long-developed build systems, since it's not unimaginable that one of the latter will fix its problems before one of the former gets good. Either way, I'm too lazy to switch for anything short of "fixed" or "good"; hot garbage, just not worse than autotools anymore, wouldn't be worth the time.

The most interesting very-recent development I've seen was https://gitlab.com/esr/autodafe/-/blob/master/de-autoconfiscation.adoc - a new ESR project designed to turn autotools setups into plain (albeit gmake-specific) Makefiles, but not in the write-only way that autotools itself does. POSIX-environments-only, but WSL is less rickety than Cygwin so that's not the end of the world.