question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Currently a wrap needs a meson.build file. This means if the upstream project uses CMake, you will need to write a custom meson.build replicating what is already in the CMake file, if you want to use the project as a fallback. On the other hand you can use a CMake project as a subproject already today.

To work around this limitation, today you can add a subproject, let’s call it olm-wrap, which in turn depends on the actual project, let’s call it olm, which is using cmake. In the olm-wrap project you then build the cmake project using the cmake module and expose the dependency, which is then used by the parent project. This can look like the following:

project('olm-wrap', 'cpp', version: '3.1.4', meson_version: '>=0.55.0')

cmake = import('cmake')

olm_subproj = cmake.subproject('Olm')
olm_dep = olm_subproj.dependency('olm')

That way in the parent project, you can use ['olm-wrap', 'olm_dep'] as the fallback and everything will work as usual. (If you did the cmake.subproject in the parent project, the wrap_mode overrides wouldn’t work.)

In my opinion, while functional, this is very ugly. Instead the following should be added to meson:

An additional key to the wrap file format in the wrap-file and comparable section called buildsystem, which defaults to meson, but allows an addition value of cmake (for now). If it is set to cmake, the subproject should be treated as a cmake subproject. Any provided targets should be listed in the [provide] section, with the cmake target they correspond to. This would look like follows:

[wrap-git]
directory = Olm
url = https://git.matrix.org/git/olm.git
revision = 3.1.4
buildsystem = cmake

[provide]
Olm = olm

I think this is a natural extension of the existing features and would simplify wrap files for existing cmake projects a lot. What do you think?

Issue Analytics

  • State:open
  • Created 3 years ago
  • Reactions:16
  • Comments:16 (7 by maintainers)

github_iconTop GitHub Comments

5reactions
xclaessecommented, Feb 19, 2021

AFAIK, this is a voluntary limitation because @jpakkane did not want to transparently use cmake subprojects that are much less reliable, at least at the early stage. Forcing to go through the cmake module is kind of “yes, I know that could explode on my face”.

That being said, I personally think we should remove that arbitrary limitation, the cmake module matured over time and as far as I can tell it’s actually being successfully used by many people (did not try it much myself).

There is no need to specify the build system in the wrap file, we can easily just check if there is CMakeLists.txt at the root source dir. From an implementation POV it’s really just a couple lines to change, this issue is more a design decition.

2reactions
germandiagogomezcommented, Mar 31, 2021

@deepbluev7 Well, this is more sort of an opinion than a propsal from me. I do not consider myself entitled to take decisions since I am not a main contributor, but yes, it would make sense to mark the build system provided what the documentation says, as I mentioned. No issues on my side, I guess.

Read more comments on GitHub >

github_iconTop Results From Across the Web

wrap/CMakeLists.txt at master · borglab/wrap - GitHub
Wrapper generator for C++ projects with multiple language support - wrap/CMakeLists.txt at master · borglab/wrap.
Read more >
proper way to wrap an imported target around a third-party target
When declaring dependency to in , I wrap it into third::third. on CMake 3.19.2 it works fine on CMake 3.5.1 (that I must...
Read more >
How does target_link_libraries(--wrap) work? - Stack Overflow
c, and CMakeLists.txt. #include <ext_decl.h> //Declares struct ext_lib_struct_t in a CMake target ext_decl_lib int ...
Read more >
Tests/Wrapping · master - cmake - Kitware GitLab
Name Last commit Last update Wrap.c Revise C++ coding style using clang‑format 6 years ago fakefluid.cxx Revise C++ coding style using clang‑format‑6.0 4 years ago hints...
Read more >
Formatting Algorithm — cmakelang 0.6.13 documentation
cmake -format implements three styles of wrapping. ... If horizontal wrapping fails to emit an admissible layout, then a node will advance to...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found