added CMakeLists.txt to support building via cmake

[thorsten-klein]

Simplify cross compilation and integration into other build systems by using cmake.
Additionally simplify usage within other cmake projects by providing a cmake EXPORT (find_package(linenoise))

[antirez]

Thank you for your contribution, @thorsten-klein
I believe that small libraries like that should not be required to provide things to work more easily with one or another build system. The Makefile included is just to build the examples. For the same reason, I believe that cmake users can write their own files. I'll keep this issue open so that the file is easy to find :) Thanks.

[thorsten-klein]

Thank you for your fast reply! 👍🏻

I believe that cmake users can write their own files

What do you mean with this?
Currently there is no usage via cmake possible, except copy&paste the source code into your own project (in order to build the linenoise library).

I think it would be a very big benefit for users with only this small change. Also many other projects (no matter if big or very small) are moving to cmake.

Feel free to merge this PR whenever you want to use cmake as well.
Until then we will keep this CMakeLists.txt file as patch (within our linenoise conan package).

[antirez]

Unfortunately I don't see (for personal tastes) mass-moving to CMake a good thing. So what I meant is that people willing to use CMake, should be able to integrate Linenoise with CMake easily. I find it strange that a build system requires libraries to explicitly adapt to it.

[thorsten-klein]

Out of curiosity:
Why does the Makefile only build the example executable and not a library?
How do expect users to integrate linenoise into their project? Shall they copy the .c file and compile it as part of their project?

I would expect that there is at least some library of linenoise which I can link.
In this case: How would you expect users to integrate a library into their build system?
Isn't it common that tools provide some pkg-config or cmake integration?

[remexre]

We ship this pkg-config file in the nixpkgs (NixOS) version, fwiw: https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/linenoise/linenoise.pc.in

On the other hand, I'd expect most distros wouldn't need to ship anything: you'd put linenoise.h in /usr/include, linenoise.{a,so} in /usr/lib, and most build systems should do the right thing.

If something like this were to be upstreamed, I'd strongly support pkg-config over CMake -- a plain Makefile-based project can much more easily depend on a library that uses pkg-config than one that uses CMake.

[antirez]

Out of curiosity: Why does the Makefile only build the example executable and not a library? How do expect users to integrate linenoise into their project? Shall they copy the .c file and compile it as part of their project?

Because the Makefile is just an example of integration with a toy program. You build it with make and can play with the library in 2 seconds. The library is not built because linenoise "default" usage is to include a copy of it inside your project. It's a single C file, no dependencies, and so forth. Of course who have other needs can take the C file and package it in other ways. But in my opinion this is outside the goals of the project itself.

[friendlyanon]

The second argument is for a documentation string.

[friendlyanon]

Do not abuse PROJECT_NAME like this.

[friendlyanon]

Use install(TARGETS ... INCLUDES DESTINATION) instead for specifying includes for the install.

[friendlyanon]

Don't hardcode toolchain flags. These can be provided from the command line or (more conveniently for developers) a preset.

[friendlyanon]

You set the minimum to be 3.4, but this command invocation relies on defaults provided only by 3.14.
Spell out the RUNTIME, LIBRARY and ARCHIVE destinations or raise the minimum requirement.

[friendlyanon]

Please prefer to put things closer to where they are used.

[friendlyanon]

When and why does an example need to be installed?

[friendlyanon]

I believe that small libraries like that should not be required to provide things to work more easily with one or another build system.

The size of a project is absolutely irrelevant when it comes to CMake. The point of providing CMake build tooling that also installs a CMake package that can be found by find_package is to make building and package management easier for downstream users. Every package manager knows how to deal with a well behaved CMake project and how to tweak details that CMake lets us tweak for different scenarios.

I believe that cmake users can write their own files.

CMake makes that possible certainly, but it's also better to have the instructions be written once instead of N times. You also have to figure out how to acquire the project now.
Vendor it? This is routinely removed by package managers, because they usually want to have projects use packages as they already provide them.
Use find_path and find_library manually? You can't be sure as a project maintainer that your audience will be able to make this work.

If the project already provides a CMake package, there is no doubt how to package and consume the project. find_package(linenoise REQUIRED) followed by target_link_libraries(my_target PRIVATE linenoise::linenoise) is a lot simpler than cascading if()/elseif() statements (potentially for every project trying to use linenoise) trying to guess where to get linenoise from.

[friendlyanon]

Please also add an ALIAS target that matches this name.

[antirez]

The size of a project is absolutely irrelevant when it comes to CMake.

Understand your point of view. I don't agree. This library wants to have zero involvement with building systems and the software "supply chain". So I'll refrain from commenting more :) Peace & Love.