[develop2] Design for further 'conan install' command customization

[ssrobins]

I'd like to propose a potential way forward on allowing all sorts of conan install command customizations, while not having to duplicate all the flags explicitly in conan_provider.cmake. I'm happy to do the work, but wanted to get some alignment on how to go about it first.

I think overall, really common customizations should be explicit options. That's what's already done for profiles. That's also what I'm proposing for build options in #594.

The last explicit option I would add is for --update like CONAN_INSTALL_UPDATE?. When I'm just iterating on code changes, I don't want --update set because it takes too long. However, in continuous integration, and in local builds when I know a recipe has been updated, I want to be able to toggle that on in the cmake command with a variable.

Beyond that, I think there should be a generic arg variable like CONAN_INSTALL_ARGS that will allow you to add one or more other command flags to conan install. Here's what I would typically with such a command:

• --conf tools.system.package_manager:mode=install: Make sure that any packages with system package dependencies can actually get installed so that the build will work in a clean environment such as continuous integration. For my personal use, this is important for the SDL and SFML packages.
• --conf tools.system.package_manager:sudo=True: Make sure system package manager commands are properly escalated. Handy for continuous integration.
• --conf tools.cmake.cmaketoolchain:generator=Ninja Multi-Config: SDL's system checks that run during CMake configuration are significantly slower with Xcode generator than Ninja or Makefile generators. I'd love to one day get to the bottom of why that is, but until then, I'd like to just use an alternative generator that's different than the one I chose for CMake build.

If instead there is a preference for having explicit options for --conf:build, --conf:host, and --conf:all options, much like we already do for --profile:host and --profile:build, I would be totally fine for that. I still figure it would be worthwhile to still have a generic argument for lesser used options. I think in my case, if I needed to get fancier than what I've outlined above, I'd probably just use conan commands directly.

What do you think? Happy to implement whatever is decided here!

[ssrobins]

@memsharded @jcar87 kind ping on this, just in case it got lost in the shuffle. If you're already aware and this just isn't the priority at the moment, I totally understand.

[valgur]

+1, I've been adding CONAN_INSTALL_EXTRA_ARGS to all of my conan_provider.cmake for additional deployer args and what not. I preferred "extra" as it otherwise sounds like it would override the entire arguments string to me.

I also think the -g CMakeDeps part really needs to be overridable. It works ok with a plain conanfile.txt, but causes conflicts when the generators have been explicitly listed in the conanfile.txt/.py.

[ssrobins]

+1, I've been adding CONAN_INSTALL_EXTRA_ARGS to all of my conan_provider.cmake for additional deployer args and what not. I preferred "extra" as it otherwise sounds like it would override the entire arguments string to me.

I also think the -g CMakeDeps part really needs to be overridable. It works ok with a plain conanfile.txt, but causes conflicts when the generators have been explicitly listed in the conanfile.txt/.py.

Thanks Martin, I like that name better too, I updated my original post. I agree on overridable generator as well.

[ssrobins]

#612 takes care of all the requirements here so I'm closing this.

Wow, this was the last thing keeping me from directly using develop2 branch for all my projects. Thanks for all the hard work and accepting my contributions. Feel free to tag me in on things that come up and likewise, I'll work on any issues I run into.

[memsharded]

Thanks to you for your contributions! 🙂