discussions and roadmap related questions

[roscopecoltran]

Hi guys,

Hope you are all well !

I was wondering if you could create a quick gitter.im chat for inglued ?! :-)

I am also using hunter and polly but have a couple of questions that would maybe better fit a chat room first then some official issues/suggestions.

Cheers, Richard

[daminetreg]

Hi Richard,

I'm not used to gitter.im but I'll take a look at it. In any case I would prefer discussing everything related to inglued here for the moment. The project isn't much famous for the moment.

You can drop me a private mail if really you have something secret. 😊

Nice that you have interest in inglued, it's still a young piece of software, we are working hardly on it, (added llvm/clang tool to support it in a 3 day streak this weekend).

What are your questions regarding the roadmap?

[roscopecoltran]

Hi,

Hope you are all well and thanks for your reply !

I was mainly wondering why we could not create some CMake macros or more simply a python based script in order to add the config mode in any CMake based project.

Initially, I was looking to modify a quite important number of CMakeLists.txt too (something like 20-30), and mainly to update some forks of some computer vision projects, where lots of CMakeLists.txt are altered in various way.

So I wanted to have something that would help me to save time in order to update/add CMake's config mode, and benefit of Hunter's cache system and Polly cross-build features, written by Ruslo...

I was thinking about these 2 ways to create this pre-processing scripting:

- With CMake++

• By creating a special target to process the whole project, print the list of targets and their properties, the to override the find_package command and wrap them with hunter.
  • refs:
    • find_package override
    • [print_targets] (https://github.com/toeb/cmakepp/blob/master/cmake/cmake/targets/print_targets.cmake#L2)

- With Python

• By extending Polly or Fips and extracting projects AST with the cmakeast package and extracting some parts (find_package, add_executable, add_library commands).
  • print cmakelist ast example

So in a nutshell, I was wondering if it would be more convenient to modify the CMakeLists.txt, and adding these instructions link, with some CMake macros, maybe added in the HunterGate.cmake file, or to use a python based function to replace infile, like Conan.io (example), the CMakeLists.txt based on some macros.

I am just a little bit confused to have another utility as probably it could be embedded somewhere else that would already be common to many of my projects.

It would be awesome if you could share a little bit 'inglued' context and how you decided its approach. And if you have any feedbacks about my 2 ideas, it would be awesome too.

Ps. i saw that you have contributed to Hunter so that's why I did not go in details on those scripts, thinking that you know them. If I am wrong, just tell me :-)

Talk to u later.

Cheers, Richard

[daminetreg]

On 23/05/2017 15:17, roscopecoltran wrote:

Hi,

Hope you are all well and thanks for your reply !

Hope you are well too. :-)

I was mainly wondering why we could not create some CMake macros or more simply a python based script in order to add the config mode in any CMake based project.

Initially, I was looking to modify a quite important number of CMakeLists.txt too (something like 20-30), and mainly to update some forks of some computer vision projects, where lots of CMakeLists.txt are altered in various way.

So I wanted to have something that would help me to save time in order to update/add CMake's config mode, and benefit of Hunter's cache system and Polly cross-build features, written by Ruslo...

Automagically generating the right CMakeLists right ? This is one goal of inglued, but not the main goal. Because inglued essence is to be meta-buildsystem-agnostic, as cmake is buildsystem agnostic.

I was thinking about these 2 ways to create this pre-processing scripting:

- With CMake++

• By creating a special target to process the whole project, print the list of targets and their properties, the to override the find_package command and wrap them with hunter. o refs:
  • find_package override https://github.com/toeb/cmakepp/blob/master/cmake/cmake/targets/overrides/find_package.cmake#L17
  • [print_targets] (https://github.com/toeb/cmakepp/blob/master/cmake/cmake/targets/print_targets.cmake#L2)

- With Python

• By extending Polly https://github.com/ruslo/polly or Fips https://github.com/floooh/fips and extracting projects AST with the cmakeast package https://github.com/polysquare/cmake-ast/tree/master/cmakeast and extracting some parts (find_package, add_executable, add_library commands).
  • pint cmakelist ast example https://github.com/chrisvm/pymake/blob/master/pymake/cmake_list.py#L39-L78

So in a nutshell, I was wondering if it would be more convenient to modify the CMakeLists.txt, and adding these instructions link https://github.com/header-only/inglued/blob/master/src/inglued/cmakelist_tpl.hpp#L78-L161, with some CMake macros, maybe added in the HunterGate.cmake file, or to use a python based function to replace infile, like Conan.io (example https://github.com/thoughton/conan-glfw/blob/07ff12a02ef30db75b147b421e72925d335e50cb/conanfile.py#L20-L22), the CMakeLists.txt based on some macros.

Indeed the cmake stuffs you link are way to verbose, and this is due to this nice habit of CMake of handling just ALL situations. If you are interested in building reusable simpler macros I will help, I already wanted to work on it and contribute it back to CMake directly as a Module.

In our company some of our developer tend to be lazy doing the targets export because of the verbosity of it, and I would like to avoid them be lazy.

I am just a little bit confused to have another utility as probably it could be embedded somewhere else that would already be common to many of my projects.

It would be awesome if you could share a little bit 'inglued' context and how you decided its approach. And if you have any feedbacks about my 2 ideas, it would be awesome too.

Ps. i saw that you have contributed to Hunter so that's why I did not go in details on those scripts, thinking that you know them. If I am wrong, just tell me :-)

Yes I know Hunter and I introduced it in the company I work and in private projects, I also know cmake a bit as I'm the cmake-boy of the company and had the luck to be helped by Brad King from CMake on libclang's cmake package.

inglued initial reason of existence is to ship easily the dependencies of the libraries I write, so that the users get the ease-of-use of a dependency-free library, without the annoyances of it : possibility in system-distribution-builds to disable the hidden inglued dependency.

I don't want to compete with hunter, because hunter is for the today landscape of C++.

inglued is thought for tomorrow's landscape of C++ : dependencies just simple.

inglued is borned from the realization that CMakeLists.txt, or meson-build file or whatever-buildsystem.file exists only to bridge the code and developers habits.

inglued is 2 things :

• the dream that C++ code is self-sufficient
• the acceptance that C++ is a rich ocean made of many islands : https://meetingcpp.com/index.php/newsreader/items/islands-of-c.html

The reason is that as you, I love CMake and hunter but my colleague sitting 2m from me loves autoreconf ( i.e. he really shouldn't ), contributions I made to Boost obliged me to learn BJam, others likes buck, bazel or meson. (I realized that long after debating long why CMake was the way with the leader of biicode / conan.io).

So basically I think C++ use cases are so wide that there isn't the one-size-fits-all. But there is one thing in common : #include directives, and the role of inglued is to make anybody's code consumable, reusable without any other pain than typing #include.

[daminetreg]

Closing due to inactive discussion.