search

ArthurSonzogni / FTXUI

:computer: C++ Functional Terminal User Interface. :heart:
MIT License
6.73k stars 401 forks source link

Question about packaging FTXUI for Gentoo distribution #223

Closed Petross404 closed 2 years ago

Petross404 commented 2 years ago

Hi,

I came across FTXUI and it seems very nice. I want to write an ebuild for Gentoo users to install system-wide this library, but I have two questions:

1) I noticed that compiling with Portage this software, there were static libraries installed

>>> Merging sys-libs/ftxui-9999 to /
--- /usr/
--- /usr/lib64/
>>> /usr/lib64/ftxui-screen.a
>>> /usr/lib64/ftxui-dom.a
>>> /usr/lib64/ftxui-component.a
--- /usr/lib64/cmake/

Looking at the top-level CMakeLists.txt I see that you are importing your targets as static libraries. Can we provide an option for that?

And 2) Your example here fetches FTXUI as an external project or something. Is it possible for cmake to find it somehow if it installed in the system?

Thanks!

ezzieyguywuf commented 2 years ago

I want to write an ebuild for Gentoo

😍 you beat me to it.

Do you plan to publish the ebuild in one of the official gentoo overlays or in your own local overlay?

ArthurSonzogni commented 2 years ago

Thanks for using FTXUI!

The current cmake install produce the following tree:

.
├── include
│   └── ftxui
│       ├── component
│       │   ├── captured_mouse.hpp
│       │   ├── component_base.hpp
│       │   ├── component.hpp
│       │   ├── component_options.hpp
│       │   ├── deprecated.hpp
│       │   ├── event.hpp
│       │   ├── mouse.hpp
│       │   ├── receiver.hpp
│       │   └── screen_interactive.hpp
│       ├── dom
│       │   ├── deprecated.hpp
│       │   ├── elements.hpp
│       │   ├── node.hpp
│       │   ├── requirement.hpp
│       │   └── take_any_args.hpp
│       ├── screen
│       │   ├── box.hpp
│       │   ├── color.hpp
│       │   ├── color_info.hpp
│       │   ├── deprecated.hpp
│       │   ├── screen.hpp
│       │   ├── string.hpp
│       │   └── terminal.hpp
│       └── util
│           ├── autoreset.hpp
│           └── ref.hpp
└── lib
    ├── cmake
    │   └── ftxui
    │       ├── ftxui-config.cmake
    │       ├── ftxui-config-version.cmake
    │       └── ftxui-config-version-noconfig.cmake
    ├── ftxui-component.a
    ├── ftxui-dom.a
    └── ftxui-screen.a

It can be downloaded from the release page:

This indeed contains only static library. There are no dynamic ones. Is it a problem? After making a library for building C++ webassembly games, I took the habit of building everything statically. It simplifies a lot of thing IMO.

I see that you are importing your targets as static libraries. Can we provide an option for that?

I am not sure to understand what is that? Do you want dynamic library instead?

2) Your example here fetches FTXUI as an external project or something. Is it possible for cmake to find it somehow if it installed in the system?

I recommend developers to point their project to a given git commit of FTXUI, and let cmake automatically fetch and compile this dependency for them. This way, they don't need to install anything and upgrading to the next version is as easy as switching toward a different git COMMIT or git TAG.

However, I believe what cmake produces

lib
    ├── cmake
    │   └── ftxui
    │       ├── ftxui-config.cmake

should be enough for developers to use via find_package(ftxui) after installing the library. I have 90% confidence in this.

ezzieyguywuf commented 2 years ago

I recommend developers to point their project to a given git commit of FTXUI, and let cmake automatically fetch and compile

This is great for a dev environment or someone that wants to manage their installation locally. However, most packaging systems (I'm most familiar with gentoo's Portage) have some restrictions on network access during compilation/installation - this is a security feature.

Because of that, packaging systems such as Portage need to be able to:

  1. Download all necessary artifacts on their own (e.g. using wget or something else)
  2. Compile the payload (library and/or executable) without accessing network
  3. Install payload to a designated location (again, without accessing the network)

I see that you are importing your targets as static libraries. Can we provide an option for that?

I am not sure to understand what is that? Do you want dynamic library instead?

Yes, I think he's asking that a cmake option be added for compiling as static or dynamic: if you think this will be challenging, I can take a look at the cmake config and probably submit a PR (this is pretty easy in cmake)

I think a cmake flag for static vs dynamic as well as auto-fetch (your current behaviour) versus "provide your own deps" should probably be all that's needed. Cmake does a pretty good job of "following the rules" regarding installation, so number 3 above shouldn't be an issue.

ArthurSonzogni commented 2 years ago

Developers can also install FTXUI locally and use the static library without internet access. FTXUI do not have any dependency.

Out of curiosity, why would people prefer the dynamic libraries in FTXUI's case?

I will take a look and maybe let developer set "BUILD_SHARED_LIBS" to decide which type of libraries to build, or build both.

ezzieyguywuf commented 2 years ago

Out of curiosity, why would people prefer the dynamic libraries in FTXUI's case?

Well, in general I think the response to "why use dynamic libraries instead of static" goes something like this:

When dynamic libraries are used, the security fix can be done in-place (assuming it is ABI compatible, which I would argue the fix should be since it's a security bug)

Another reason it allows all users of libFoo to reduce their size, though this is much less of an argument with modern storage sizes/prices.

Petross404 commented 2 years ago

It seems I am a little late at the party.

It's nice that we can have dynamic libraries and also use ftxui-config.cmake.

@ezzieyguywuf I will have the ebuild at a local repo at first. But I will share it here.