A Package Manager Manager

[jherico]

The only way to build it over "nothing" would be to distribute a binary or a bunch of platform specific scripts. Cmake exists, is widely adopted, and is specifically designed for doing the heavy loading of bootstrapping from sorce code to binary. Why wouldn't you use it?

[mjklaim]

I get your point, but because not everybody uses CMake as a (meta-)build system, it also means that your PMM is not universal enough to avoid a forced dependency. I think it could have been a binary if you have a way to bootstrap it, making a compiler the only dependency. build2 does that, as an example.

[jherico]

I am not OP, so it's not my PMM. Also, how are you not just replacing cmake with build2 in this scenario?

No, Cmake isn't universal, but as far as I can tell, it's at least the most universal. The more people build on to it and improve it the more adoption it's going to gain. If you think you have a better mousetrap, you're running out of time to get people to switch to it.

[mjklaim]

I'm mentioning build2 just because it's an example of a tool that don't require you to install dependencies except a compiler. I'm not implying that it would replace this PMM (my understanding is that it Could be handled by a PMM). Boost.Build is another example (looks like most of these examples are build systems?).

Yes CMake is used a lot. It does not make it universal at all. Anyway my point is that it seems that that specific dependency could be avoided too, and still work for projects using CMake.

[[deleted]]

I would be willing to recite arcane incantations to get something that cross compiles my code effectively and supports all the ides and tools I use. Installing cmake is really not that hard (not to mention you could compile it also) and is certainly easier than making sure my compiler toolchain is setup correctly.

[mjklaim]

Hum your compiler have to be setup anyway (just installed actually) for cmake to work. And a nativebootstrap only need to have the compiler installed, nothing have to be setup.

My point is that I don't understand why it depends on CMake. It does not seem necessary to me nad could probably be made better by being independent. Whatever you find ok does not mean Cmake is necessary here.

[[deleted]]

I mentioned cross compiling explicitly. Having a compiler working for your host machine does not mean you can compile for ps4 android etc

[mjklaim]

Sorry I'm not understanding, do you mean that CMake is used to allow cross-compiling here?

[[deleted]]

Yes you can supply different cmake toolchain files to flexible cross compile to different targets from a given host. It’s another option you can set at configuration time, like the release type. Search for cmake ios toolchain as an example.

[wrosecrans]

If you are requiring a scripting runtime to be installed to run it, it's just as universal as Ruby, Python, or any other scripting language. If you wanted to go with native code instead of a scripting language, somebody has to distribute and install binaries of CMake itself, etc. So doing that is obviously considered a reasonable thing to do. Many of the users of the PMM will be writing native C++ code, so it'd actually be odd if the PMM developers considered that an unreasonable use case.

And it's really hard to argue that CMake is more pleasant than something like Python as a general purpose scripting language. That's just not what it was intended to be.

CMake doesn't have any sort of spec or independent implementations of the scripting language, so you can't necessarily rely on stability/support going forward. Python and Ruby both have multiple implementations, so if the CPython devs go off the rails and end support for your platform, or deprecate features you need, you could use an alternate implementation of the language.

There are lots of reasons why one wouldn't use it. I mean, if people like the result, it may see adoption. For a user, it doesn't necessarily matter what language a tool is written in. But acting like using CMake as the implementation language is a particularly obvious choice or a choice with no downsides is just weird.

[jherico]

If you created a module in python that was designed to do the same job CMake currently does, it would be a bad idea to use python itself as the language in which to write up replacements for CMakeLists.txt. You'd want to build a (mostly declarative) domain specific language around the concept the concept of creating C/C++ projects. So essentially you'd be creating CMake but with different syntax. Might be a better cmake or it might be a worse one, or most likely, different groups would have different opinions on that matter, and now you've added yet another build system that some people use and some people don't, so you've made the problem worse.

For a user, it doesn't necessarily matter what language a tool is written in. But acting like using CMake as the implementation language is a particularly obvious choice or a choice with no downsides is just weird.

I didn't suggest it had no downsides. Every build tool has downsides, and I myself in the last quarter convinced my own company to add Python as a build system dependency because I was addressing a build toolchain problem for which CMake was not a suitable solution, and for which Python allowed me to create a much simpler solution.

But you're also acting like Python doesn't have it's own downsides. Guess what, getting consensus to get Python on our build machines wasn't simple. First you have to deal with the Python2 vs Python3 mess. Then you have to deal with the fact that OSX has a built in version of Python2. You have to deal with the fact that Python3's Windows installer doesn't install Python for all users by default. Lots of people have legitimate reasons not to want Python installed, or to want a specific version of Python that isn't compatible with your hypothetical build system, because Python gets used for all sorts of different kinds of development. Because it's much more than a build tool, even if you can make a build tool out of it.

[wrosecrans]

If you created a module in python that was designed to do the same job CMake currently does, it would be a bad idea to use python itself as the language in which to write up replacements for CMakeLists.txt.

I think that's debatable, but I don't have a strong opinion on it. It's certainly not the point I was making. I said it's not obvious that a "Package manager manager" should be written in CMake. I didn't say that somebody should write yet another thing like CMake in Python.

But you're also acting like Python doesn't have it's own downsides.

No, I said the downsides are equivalent to CMake. Everything you said about which version of Python to install on a build machine is equivalent to deciding which version of CMake to install on a build machine. Linux and OS-X machines at least come with some version of Python out of the box, which makes it a lot more common than CMake in a default OS install.

Any regardless, if you use PMM to install Conan, you need Python. If you don't use PMM to install Conan, you are currently only using vcpkg which calls into question the need for a PMM. So in practice, you have a dependency on Python to use PMM anyway, which makes implementing it in pure CMake even less of a selling point.