Questions regarding current state / future of the project

[drywolf]

Hi,

I just stumbled across https://github.com/toeb/cmakepp and your fork of it yesterday. I'm very happy to see that someone is interested in continuing this project, because I have created some of the same functionalities of cmakepp myself in the past, but a shared community solution would be preferable of course 😄

I have two questions though:

1. do you know why the original author stopped working on cmakepp ?

2. I saw that you recently removed the "package" module. What was the reasoning behind your decision ? getting reliable and easily usable + maintainable package management is one of my main interests for a project like this, therefore I'm curious as to why you removed it.

Thanks

[issue-label-bot]

Issue-Label Bot is automatically applying the label question to this issue, with a confidence of 0.95. Please mark this comment with 👍 or 👎 to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[AnotherFoxGuy]

Hello

Sorry for the long response time, for some reason I wasn't subscribed to notifications on this repo
To answer your questions:

1. No idea, I've started working on fixing this module long after it was abandoned
2. The reason behind this is because there are a lot of package managers for C++, so maintaining one with the same feature set as the others I don't think it will be worth the time.
   Instead, I want to add wrappers for 3rd party package managers so people can choose the one they want to use

[drywolf]

Hi no worries, I also had this happen to me in the past.

Instead, I want to add wrappers for 3rd party package managers so people can choose the one they want to use

You mean separate wrapper APIs for the diverse package managers, i.e. without a common interface ?
(I'm just asking to make sure I understood what you meant btw, I can see pros and cons with either approach)

For the approach of having a unified interface, that's what I think was attempted in the original upstream repo.
I haven't looked at it in very much detail, I just read the mentioned docs a few times, but the interfaces described there already look very fleshed out. I guess quite a lot of thought was already put into them.

Therefore I was wondering what you were planning to do for packages in this fork.
Either way I will look into my own solution / investigate what can be reused from the original upstream repo.

If you want to exchange ideas / brainstorm wrt. to this topic, I'm all for it 😉

[AnotherFoxGuy]

I was thinking about something like about adding a module for Conan and vcpkg that works around the same as PMM, so the installation and invocation of the package manager is done for you

This is what I had in mind for the API:

For conan:

conan_install_tool() -- Installs conan in a python virtualenv 
conan_install() -- Installs the packages defined in the conanfile.txt or conanfile.py 
conan_install_from_list(LIST) --  Installs the packages from a cmake list
conan_generate_profile() -- Generates a conan profile with the current compiler settings 
conan_easy_setup() -- Runs the above commands for you (the same as pmm(CONAN))
conan_add_remote(NAME URL) -- Adds a custom remote

And for vcpkg:

vcpkg_install_tool() -- Installs and builds the vcpkg executeble
vcpkg_install_from_list(LIST) --  Installs the packages from a cmake list
vcpkg_generate_profile() -- Generates a vcpkg profile with the current compiler settings 
vcpkg_easy_setup() -- Runs the above commands for you (the same as pmm(VCPKG))
vckg_copy_custom_ports(PATH) -- Copy custom ports to the vcpkg ports directory

---

And about the original package module;
I also looked at it, but it wasn't very well documented and some of the tests for it were disabled
But if you want I could look into fixing the issues and add the module back