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.

Sign up for GitHub

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

Jump to bottom

Update/expand CPS history #83

Merged
merged 1 commit into from
Nov 6, 2024
Merged

Update/expand CPS history #83

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
111 changes: 92 additions & 19 deletions history.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,18 +6,76 @@ Building a project which consumed a different, external project
typically involved hand coding build directives
based on assumptions where the external would be located.

Along came `pkg-config`_.
This was an improvement,
but it was designed for UNIX-like platforms
and isn't entirely portable.
Also, while pkg-config does an adequate job
describing the necessary compile and link flags to consume a package,
this information is not always sufficient.

Some time later, CMake_ entered the scene,
eventually gaining its own mechanism to describe a package.
While this system solved many earlier problems,
it relies on the CMake language
The first attempts to tame this mess were disorganized,
with hundreds of projects
each developing their own bespoke mechanisms
for managing dependencies
and making themselves available
to further dependents in turn.
One approach that saw wider adoption
was to provide a script or micro-application
which described the capabilities and usage directives of a project.
These "config" tools, when queried,
provided the necessary compile and link flags
to build against a given library.
(As of 2024, some projects
continue to ship such tools,
though often in conjunction
with other, more modern alternatives.)

GNOME dreamed of a single package configuration script to rule them all,
providing all the necessary flags from a single pseudo-database.
Entries in the database would be distributed alongside their libraries,
which would no longer have to maintain their own utilities.
This dream first arrived as gnome-config,
which encompassed all the libraries in the GNOME project,
but would not be enough.
This was followed by the venerable `pkg-config`_,
which could encompass all the libraries in the world,
and is still in use over two decades later.

Meanwhile, CMake_, making its own foray
into this untamed wilderness at almost the same time,
was faced with the problem that many packages
came with only a library and header files.
(This was especially true on Windows,
which lacked autotools,
and even cross-platform projects
often treated Windows as an afterthought at best.)
Needing an immediate solution,
CMake could not rely on information
shipped alongside libraries,
so it provided a library of built-in "find modules"
to cover many common dependencies.
Although augmented by the ability
for consumers to write and ship their own find modules
for packages not included in the CMake distribution,
this resulted in developers working independent of each other
writing multiple versions of such modules
that were often incompatible with each other
(or with "first party" modules
which sometimes became available as time progressed).

Cataloging all the world's software was not practical,
and the superiority of each package describing itself was evident
(in this respect, pkg-config had the right idea).
This spreads the workload and ensures consistency.
To this end, CMake created its own means for projects to "export"
their own descriptions of their usage requirements.
Compared to pkg-config, these descriptions
provided much more information about the libraries themselves,
allowing CMake to derive the appropriate compile and link arguments
rather than hoping that the pre-computed arguments are adequate.
This represented a significant advancement
in the state of package information exchange,
although it retains its own limitations.

While pkg-config does an adequate job
describing the necessary compile and link flags to consume a component,
its approach is suboptimal for describing related but separable consumables,
and `flag soup`_ is semantically lossy and not always sufficient (see below).
CMake's most recent system solves many problems,
but relies on the CMake language
and is therefore tightly coupled to that build system.

CPS attempts to solve these issues
Expand All @@ -28,9 +86,14 @@ that is not tied to the language of a particular build system.
What's wrong with pkg-config?
'''''''''''''''''''''''''''''

pkg-config was created
way back in the bad old days of autotools,
when everyone was using the same compiler and linker.
Although pkg-config was a huge step forward
in comparison to the chaos that had reigned previously,
it retains a number of limitations.
For one, it targets UNIX-like platforms
and is somewhat reliant on the |FHS|_.
Also, it was created at a time when autotools reigned supreme
and, more particularly, when it could reasonably be assumed
that everyone was using the same compiler and linker.
It handles everything by direct specification of compile flags,
which breaks down when multiple compilers
with incompatible front-ends come into play
Expand All @@ -40,7 +103,7 @@ requiring C++14 and C++11, respectively,
pkg-config requires the build tool
to translate compile flags back into features
in order to know that the consumer
should not be build with ``-std=c++14 ... -std=c++11``.)
should not be built with ``-std=c++14 ... -std=c++11``.)

Specification of link libraries
via a combination of ``-L`` and ``-l`` flags is a problem,
Expand All @@ -62,7 +125,13 @@ CMake exported targets provide a richly featured mechanism
for describing packages as a set of individual components,
along with the necessary details for consuming each individual component.
This generally works well... *for CMake*.
The biggest problem with this system

Even so, it is not perfect.
Version compatibility management remains partly bespoke,
and official support for transitive dependencies
is only partially implemented as of CMake 3.30.

However, the biggest problem by far
is not any internal flaw in the system,
but the fact that it relies on the CMake language.
Consumers have to parse not only CMake syntax,
Expand Down Expand Up @@ -90,8 +159,12 @@ to a wider audience of consumers.

.. _CMake: https://cmake.org/

.. _P0235: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0235r0.pdf
.. _flag soup: https://wg21.link/p2800

.. _FHS: https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

.. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... .. ... ..

.. _WG21: http://www.open-std.org/jtc1/sc22/wg21/
.. |FHS| replace:: Filesystem Hierarchy Standard

.. kate: hl reStructuredText