Thoughts on 2023 KeyNote on C++ Dependency Management?

[juan-lunarg]

2023 Keynote on C++ Dependency Management: Bret Brown & Bill Hoffman, prerelease

TLDR: A standardized format that is superior to *.pc or *.cmake files.

They are eagerly looking for feedback on this new .cps format. I think it would be healthy for the ecosystem if Meson would also support this new .cps format in tandem with CMake.

Note: There is nothing set in stone. This very much looks to be in the prototype stage.

pkg-config does have limitations as noted in the talk.

Many developers will be familiar with the pkg-config tool, which is one of the earliest tools created to help solve the problem we are discussing. While the package specification format used by pkg-config is more or less adequate for its original audience (GNU autotools on GNU/Linux systems), it has a number of limitations. First, a .pc file can only describe a single component, which results in much duplication across multiple such files belonging to a single conceptual product. Second, it is limited to providing tool flags, which can be problematic for build tools (such as CMake) which desire the canonical location of libraries, and makes it poorly suited for describing non-library components (such as a code generating executable). Third, its ability to specify architecture information or provide component variations is limited. Fourth, it is not well suited for non-POSIX platforms where libraries use different artifacts at link-time and run-time (such as Windows).

[jpakkane]

Having a new, better purely data-driven version of pkg-config would be useful, yes.

That being said there are some inaccuracies in the pkg-config description. Yes, by default you get only compiler and linker arguments, but you can store any data in a .pc file. It is a very simple key-value database. You don't have to store libraries as -L/-l pairs. You can use an absolute path to the library file, because the linker will also accept that. It is arguably the better way to do that, since -L affects the search path of all library lookups after it on the command line.

[eli-schwartz]

I recall looking at the CPS format before and deciding it seemed very ornately over-engineered, fragile to use and create.

I'm concerned that the CMake developers' continued misunderstanding of how pkg-config works as a prerequisite for them to insist that everything needs to be rewritten from scratch, is going to mean the overall software ecosystem is not going to get the tools it could ideally benefit from.

While the package specification format used by pkg-config is more or less adequate for its original audience (GNU autotools on GNU/Linux systems), it has a number of limitations.

This in particular is laughably, laughably wrong. Clearly it is not adequate "for GNU autotools on GNU/Linux systems" since at minimum it is adequate for cmake and meson and every other build system in all of creation on GNU/Linux systems -- and also on cygwin and msys2. It also works quite well on any unix, including lots of unixes that don't use GNU software as a matter of software religion. Windows, and Windows alone, is truly the odd duck here.

and makes it poorly suited for describing non-library components (such as a code generating executable).

This no doubt comes as a tremendous surprise to, say, the gnome ecosystem, which has been embedding code generating executables as key-value database entries in pkg-config files for quite a long time. Meson automatically looks these up whenever handling gnome-based tasks:

    @staticmethod
    def _find_tool(state: 'ModuleState', tool: str) -> 'ToolType':
        tool_map = {
            'gio-querymodules': 'gio-2.0',
            'glib-compile-schemas': 'gio-2.0',
            'glib-compile-resources': 'gio-2.0',
            'gdbus-codegen': 'gio-2.0',
            'glib-genmarshal': 'glib-2.0',
            'glib-mkenums': 'glib-2.0',
            'g-ir-scanner': 'gobject-introspection-1.0',
            'g-ir-compiler': 'gobject-introspection-1.0',
        }
        depname = tool_map[tool]
        varname = tool.replace('-', '_')
        return state.find_tool(tool, depname, varname)

There is similar code in other meson modules, it's not just a gnome ecosystem thing.

...

As noted, since pkg-config is at its heart a key-value database, it per definition can record whatever arbitrary values are desirable on Windows. It would be nice as a starter if cmake would generate precisely that.