Single-arg CPMAddPackage

[iboB]

This is a feature proposal. If you approve of it, I can implement in my spare time by the end of the week.

• Check if CPMAddPackage is called with a single argument.
• If yes, split it along "@". Interpret the first part as a git repo, and the second as a version
• If the git repo matches <user>/<name> or gh:<user>/<name> interpret it as a GitHub package
• If the git repo matches gl:<user>/<name> interpret it as a GitLab package
• Otherwise interpret it as a git repository uri

Thus some valid uses would include:

CPMAddPackage(catchorg/Catch2@2.5.0)
CPMAddPackage(gl:graphviz/graphviz@2.46.1)
CPMAddPackage(https://example.com/myrepo.git@1.0.0)

[TheLartians]

I love where this is going, the concise syntax does bring a much nicer "package-manager" feeling to CMake!

Not sure if it's already too much for a first version, but perhaps we could extend the specification to support other tag versioning schemes as well. Say allowing specification of a git tag after # (like npm does): e.g.

# version determined from tag
CPMAddPackage("gh:google/googletest#release-1.8.0")
# explicit version and commit
CPMAddPackage("gh:jbeder/yaml-cpp@0.6.3-beta#012269756149ae99745b6dafefd415843d7420bb")

Other thing to consider is what kind of default options we want to support. For example, I'd say using the new syntax is a good opportunity to enable EXCLUDE_FROM_ALL (#152) as a default.

PS: I'm a bit unsure how I feel about defaulting to GitHub as a provider. This would be difficult to change in the future, e.g. if another provider becomes predominant. Perhaps it's better to stick to an explicit gh: syntax.

[iboB]

I like the # for tags. I don't think it's too much. I'll add it in

Aa for EXCLUDE_FROM_ALL, there are positive and negative aspects of both defaults. So... yeah. If you were starting CPM from scratch today, would you make EXCLUDE_FROM_ALL YES the default?

[TheLartians]

Aa for EXCLUDE_FROM_ALL, there are positive and negative aspects of both defaults. So... yeah. If you were starting CPM from scratch today, would you make EXCLUDE_FROM_ALL YES the default?

I think so, but I would probably need to do some testing first. In my current understanding any targets that an installable target depends on are automatically installed alongside. Then it should be fairly easy to promote a dependency to be installed alongside the main project, while leaving out anything unnecessary. If that is indeed the case I think it would be great to use as a default option.

With such a feature we would need to do a bit of testing before stabilising it anyways, to see if it works as expected and doesn't have unintended consequences.