vcpkg now requires a builtin-baseline entry in vcpkg.json (or a separate vcpkg-configuration.json file)

[cube1us]

After installing vcpkg and running the .bat inside to haul down vcpkg.exe, and setting VCPKG_ROOT, I cloned the project from Github per the instructions

But when I try to process CMakeLists.txt I get the following error (see after the dashes, below), and the log file contains the same reference.

Earlier, after getting this the first time, I also tried running the PDP11.vcxproj, which worked for a "Debug" target, but failed with what seems to be a typical libpng error for a "Release" target. I then removed everthing, installed vcpkg set VCPKG_ROOT, and got the same error -- vcpkg seems to be installed as part of VS 2022 as well, in my case at C:\Program Files\Microsoft Visual Studio\2022\Community\VC\vcpkg.

So, then I tried pointing VCPKG_ROOT at C:\Program Files\Microsoft Visual Studio\2022\Community\VC\vcpkg , and got the same error.

The sometimes helpful Google AI suggests:

Add "builtin-baseline" to your manifest file:

   Open your vcpkg.json manifest file. 

Add a line like this within the JSON object: "builtin-baseline": "".
Replace with the appropriate commit hash from the vcpkg repository.

I found a workaround for this. vcpkg has an EXPERIMENTAL command to add the necessary baseline identification:

vcpkg x-update-baseline --add-initial-baseline
updated registry 'https://github.com/microsoft/vcpkg': baseline '' -> '0ca64b4e1c70fa6d9f53b369b8f3f0843797c20c'

It added this to the vcpkg.json file, at the end, replacing the last lines with ] and } with the following:

  ],
  "builtin-baseline": "0ca64b4e1c70fa6d9f53b369b8f3f0843797c20c"
}

The possible issue I see with this is that particular commit of the modules used by open simh was of couse not tested by the open simh developers.

JRJ

---

1> CMake generation started for default configuration: 'x64-Debug'.
1> Command line: "C:\WINDOWS\system32\cmd.exe" /c "%SYSTEMROOT%\System32\chcp.com 65001 >NUL && "C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\2022\COMMUNITY\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\CMake\bin\cmake.exe" -G "Ninja" -DCMAKE_BUILD_TYPE:STRING="Debug" -DCMAKE_INSTALL_PREFIX:PATH="D:\Users\jay\VisualStudioProjects\simh\out\install\x64-Debug" -DCMAKE_C_COMPILER:FILEPATH="C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.42.34433/bin/Hostx64/x64/cl.exe" -DCMAKE_CXX_COMPILER:FILEPATH="C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.42.34433/bin/Hostx64/x64/cl.exe" -DCMAKE_MAKE_PROGRAM="C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\2022\COMMUNITY\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\Ninja\ninja.exe" "D:\Users\jay\VisualStudioProjects\simh" 2>&1"
1> Working directory: D:\Users\jay\VisualStudioProjects\simh\out\build\x64-Debug
1> [CMake] -- CMAKE_MODULE_PATH: D:/Users/jay/VisualStudioProjects/simh/cmake;D:/Users/jay/VisualStudioProjects/simh/cmake/installer-customizations
1> [CMake] -- SIMH_CMAKE_TOOLCHAIN_FILE is C:/Program Files/Microsoft Visual Studio/2022/Community/VC/vcpkg/scripts/buildsystems/vcpkg.cmake
1> [CMake] -- Executing deferred vcpkg toolchain initialization.
1> [CMake] .. VCPKG target triplet is x64-windows-static
1> [CMake] .. VCPKG_CRT_LINKAGE is static
1> [CMake] -- Running vcpkg install

*** ERROR HERE ***
1> [CMake] error: this vcpkg instance requires a manifest with a specified baseline in order to interact with ports. Please add 'builtin-baseline' to the manifest or add a 'vcpkg-configuration.json' that redefines the default registry.
1> [CMake] -- Running vcpkg install - failed
1> [CMake] CMake Error at C:/Program Files/Microsoft Visual Studio/2022/Community/VC/vcpkg/scripts/buildsystems/vcpkg.cmake:904 (message):
1> [CMake] vcpkg install failed. See logs for more information:
1> [CMake] D:\Users\jay\VisualStudioProjects\simh\out\build\x64-Debug\vcpkg-manifest-install.log
1> [CMake] Call Stack (most recent call first):
1> [CMake] cmake/vcpkg-setup.cmake:88 (include)
1> [CMake] CMakeLists.txt:85 (include)
1> [CMake] -- Configuring incomplete, errors occurred!
1> 'C:\WINDOWS\system32\cmd.exe' '/c "%SYSTEMROOT%\System32\chcp.com 65001 >NUL && "C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\2022\COMMUNITY\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\CMake\bin\cmake.exe" -G "Ninja" -DCMAKE_BUILD_TYPE:STRING="Debug" -DCMAKE_INSTALL_PREFIX:PATH="D:\Users\jay\VisualStudioProjects\simh\out\install\x64-Debug" -DCMAKE_C_COMPILER:FILEPATH="C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.42.34433/bin/Hostx64/x64/cl.exe" -DCMAKE_CXX_COMPILER:FILEPATH="C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.42.34433/bin/Hostx64/x64/cl.exe" -DCMAKE_MAKE_PROGRAM="C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\2022\COMMUNITY\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\Ninja\ninja.exe" "D:\Users\jay\VisualStudioProjects\simh" 2>&1"' execution failed with error: ''C:\WINDOWS\system32\cmd.exe' '/c "%SYSTEMROOT%\System32\chcp.com 65001 >NUL && "C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\2022\COMMUNITY\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\CMake\bin\cmake.exe" -G "Ninja" -DCMAKE_BUILD_TYPE:STRING="Debug" -DCMAKE_INSTALL_PREFIX:PATH="D:\Users\jay\VisualStudioProjects\simh\out\install\x64-Debug" -DCMAKE_C_COMPILER:FILEPATH="C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.42.34433/bin/Hostx64/x64/cl.exe" -DCMAKE_CXX_COMPILER:FILEPATH="C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.42.34433/bin/Hostx64/x64/cl.exe" -DCMAKE_MAKE_PROGRAM="C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\2022\COMMUNITY\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\Ninja\ninja.exe" "D:\Users\jay\VisualStudioProjects\simh" 2>&1"' returned with exit code: 1'.

[LegalizeAdulthood]

IMO, this is why it's better to use vcpkg as a submodule instead of putting the onus on the user to download and configure it.

With a submodule, the project gets to control the version of vcpkg and the expected behavior.

If the user doesn't want to use vcpkg, then they don't need to initialize and update the submodule.

[cube1us]

Well said - I had the same thought - it would give the project better control, and remove one variable making it harder to reproduce a given problem, besides removing a "trap for young players" as EEVBLOG puts it. If it turns out a dependency being updated, then all the project wouild need to do is update the appropriate .json file.

JRJ

[LegalizeAdulthood]

@cube1us Yeah, I forgot about that as well -- when you control vcpkg via a submodule you're also controlling the version of the recipes used to obtain dependencies. Users get a consistent experience with CI builds too.

[bscottm]

@cube1us, @LegalizeAdulthood: Just came across this looking for issues with my name on it.

I fully endorse using submodules, which is how I was developing for libslirp. While the three of us (and @larsbrinkhoff, @rcornwell) may be comfortable with submodules, I suspect that most SIMH users/devs aren't. That's a consideration I made when I first submitted the libslirp PR -- submodule updates wouldn't necessarily be understood by the SIMH users who compile from source, even if documented.

OTOH, if compiling from the scripts, handling submodule updates is trivial.

It'll also cause increasing divergence from Pizz's SIMH. That's not necessarily a bad thing, although possibly undesirable from his perspective.

[bscottm]

@cube1us: I haven't run into this particular issue with my vcpkg instance. Did you run the vcpkg bootstrap after updating?

[cube1us]

@bscottm Not entirely sure what you mean by "updating". This was my first time building open-simh, but from the comment regarding "vcpkg bootstrap" I expect you are referring to updating vcpkg. I did not do any such update unless you are referring to the command "vcpkg x-update-baseline --add-initial-baseline".

[LegalizeAdulthood]

I couldn't reproduce the bug with current vcpkg.... here's what I did

git clone https://github.com/open-simh/simh
git clone https://github.com/microsoft/vcpkg
cd vcpkg
.\bootstrap-vcpkg.bat
set VCPKG_ROOT=%CD%
set PATH=%PATH%;%CD%
cd ..\simh
vcpkg install
cd ..
mkdir build
cd build
cmake ../simh

Everything configured without requiring any baseline to be set.

Maybe I'm doing something wrong or omitting something; I find the build instructions incredibly complicated -- way more complicated than they should be. With a vcpkg submodule and a CMake presets file, it should be as simple as:

git clone https://github.com/open-simh/simh
cd simh
git submodule init
git submodule update --depth 1
cmake --workflow --preset default

...assuming you've setup a workflow preset named default to configure, build and test the code. The above should work for any platform: Windows, macOS or linux.

[cube1us]

This is something that would only occur during the first setup of vcpkg. So, if one already had the baseline entry in the manifest, it presumably would not happen again.

It is also apparently only an issue with the latest (or maybe only certain) release(s) of vcpkg. I have no idea.

As you mentioned, this all seems unfortunately complicated. I understand what vcpkg is there for - but I'm not sure its use is an improvement.

I submitted this as an FYI more than anything, having found the recommended workaround to add the baseline entry, and in case others experienced the same problem.

JRJ

[LegalizeAdulthood]

This is something that would only occur during the first setup of vcpkg.

That's exactly what I did; I didn't get any messages about baselines being required.

If you can reproduce it with a specific series of commands, please post them.

[bscottm]

@LegalizeAdulthood: vcpkg install is probably unnecessary; the dependency installs happen during the CMake build. But, if that works and there's a good reason for it, I'll update the documentation.

Let me play with this idea a bit with my mainpath branch, which I need to update anyway. Let you know when I have something workable.

Q: With the cmake-builder.ps1 and cmake-builder.sh scripts: Should they do the submodule init and updates before configuring CMake?

[LegalizeAdulthood]

If you want those scripts to be "fire and forget" then if you're using submodules they should do the submodule update and init steps IMO.

Additionally, providing a CMakePresets.json for common configurations would make everything simpler and if you provide isolated building blocks for the configure step, then a user's CMakeUserPresets.json with custom presets likely becomes a simple aggregation of building blocks, but that's a fairly advanced use case. I like to have a configure, build, test and workflow preset named "default" that does the most common case, but that's just my personal convention.

[bscottm]

If you want those scripts to be "fire and forget" then if you're using submodules they should do the submodule update and init steps IMO.

It's what I thought, good to have confirmation.

Additionally, providing a CMakePresets.json for common configurations

Only for CMake >= 3.19, which is not always a given. Worth considering, appreciate the suggestion!

[LegalizeAdulthood]

If you don't have a CMake that can use presets, then you don't have to use the preset and you can do things manually.

CMake 3.19 was released 5 years ago, if someone has a CMake that old then they're already accustomed to configuring everything manually by either running cmake-gui or setting a bunch of stuff on the command-line.

Anyone reasonably approaching this code for the first time is going to want the easiest way to build everything with a reasonable default configuration and the easiest way to do that is to provide presets. Just because you provide a preset doesn't force anyone to use it.

[bscottm]

CMake 3.19 was released 5 years ago, if someone has a CMake that old then they're already accustomed to configuring everything manually by either running cmake-gui or setting a bunch of stuff on the command-line.

There's a SIMH user who uses a Visual C 2010 out there. I'm not going to be particularly surprised at the wailing, gnashing of teeth, sackcloth and ashes that the world, as we know it, will end for SIMH. Or something like that. (Interesting note: Visual Studio 2022 uses Clang and Ninja to support CMake projects.)

Seriously, though, we should split this into two different PRs: one with vcpkg as a submodule (just to get the steering committee used to the idea) and another with CMake presets.

[LegalizeAdulthood]

There's a SIMH user who uses a Visual C 2010 out there.

That's unrelated because we're not talking about the version of the compiler you use.

And again, at the risk of sounding like a broken record, presets are a convenience, not a requirement. They simply make things easier without imposing a cost on anyone.

we should split this into two different PRs

This isn't a PR, it's a bug report and as near as I can tell nobody can reproduce the issue raised, so it should just be closed until such time as someone can provide reproducing steps.