[question] What replaces custom generator packages in Conan v2?

[db4]

What is your question?

How to create and share a custom generator with generator packages chapter of Conan 1.x docs says:

This is a deprecated feature. Please refer to the Migration Guidelines to find the feature that replaced this one.

But I don't see any mention of custom generators in the Migration Guidelines. How to replicate their functionality in Conan v2?

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[memsharded]

Thanks @db4 for your question.

There are 2 things that replace the 1.X previous custom generators packages, depending on the use case:

• For the general case, explicit python_requires are recommended, that instantiate a helper explicitly in the consumers generate(). That means that the consumers should be conanfile.py with a generate() method. This method is good for many reasons:
  • Independent, private versioned dependencies: so every package can evolve at their pace, and doing a breaking change to the generator doesn't break all consumers at all
  • python_requires affect package_id of the consumers, so correct versioning can be used to trigger re-builds or to not trigger to save CI time
• Global generators, installable in the cache with conan config install will be added in 2.0.5: custom global generators in cache extensions/generators folder #13718

[db4]

@memsharded Thanks!

[db4]

Hi @memsharded,
I'm trying to follow your first advice. This method

conan/conan/tools/microsoft/nmakedeps.py

Lines 17 to 27 in 113cf5a

	# TODO: This is similar from AutotoolsDeps: Refactor and make common
	def _get_cpp_info(self):
	ret = CppInfo()
	deps = self._conanfile.dependencies.host.topological_sort
	deps = [dep for dep in reversed(deps.values())]
	for dep in deps:
	dep_cppinfo = dep.cpp_info.aggregated_components()
	# In case we have components, aggregate them, we do not support isolated
	# "targets" with autotools
	ret.merge(dep_cppinfo)
	return ret

does what I need (a properly ordered list of all dependent libraries), but it uses CppInfo() from an internal namespace (conans.model.build_info). Can it be made publicly available? Or maybe it's possible to achieve the same result by other means?

[memsharded]

Thanks for the feedback.
Yes, making public those interfaces is in our todo-list. Not only the CppInfo, also the aggregated_components() is not documented publicly yet.

Adding this ticket for next iteration, not sure if it will be possible, but lets try.