Add support for make install.

[ioquatix]

I don't know a lot about CMake but I tested this locally and it seems to work.

[ioquatix]

Fixes #317

[samuel-williams-shopify]

@kazuho can we merge this?

[kazuho]

Thank you for the pull request, but unfortunately, I'm afraid we cannot.

We never plan to freeze the API provided by picotls. Having a supported make install path would strongly imply that picotls is meant to be consumed as a library with a reasonably stable API/ABI — i.e., something third-party applications can build against and expect to keep working across updates. This expectation applies regardless of dynamic vs static linking: once headers are installed for external consumption, they effectively become a public interface that downstreams will rely on across updates.

For that reason, we cannot support installing picotls as a library. If you would like to use picotls, the supported approach is to vendor it into your source tree and update it as needed, rather than depending on an installed copy.

[ioquatix]

@kazuho I want to use make install to install the vendored libraries, why is that not acceptable? Basically, I do an out of tree build, and install into a vendorered directory (set by prefix).

[kazuho]

@ioquatix I see. The problem is that while you can use make install for installing into a vendor directory, it can be (and most often is) used to install software into the system directory.

I would be less worried if the sub-command was like make vendor-install PREFIX=foo, though I am not sure if that's needed at all, when you could:

1. add picotls/include to the include path, and
2. 1. create a directory for storing and build picotls there (using cmake --build).

[ioquatix]

I have a standard set of cmake integration scripts and I don't want to write bespoke commands just for picotls. All the dependencies are installed into a vendored root.

it can be (and most often is) used to install software into the system directory.

I don't really see why this is your problem, but you could:

• Add documentation.
• Add a warning.

[kazuho]

@ioquatix Your use case makes perfect sense. However, once we provide the make install target, documentation or warnings are not enough to prevent other users (including packagers and people following build recipes) from installing into system prefixes and then expecting the installed headers/library to remain compatible across upgrades.

cmake --install is a good example: it's a standard command that performs the project's install step into the configured prefix (often a system prefix like /usr/local, which is the default value of CMAKE_INSTALL_PREFIX). Once we provide that upstream, people will use it as the "standard" way to consume the library.

When upgrades then break consumers, support issues will be opened against the upstream project, and "but we warned you" doesn't reduce that burden in practice. That's why we avoid providing an install target upstream.

If you need an install step for your vendored build, I'd recommend either (a) keeping this patch / maintaining a small fork, or (b) adding a wrapper in your build that copies the headers and built artifacts into your vendor prefix.