Automatically created conanfile.txt shows different generators

[akalali]

I'm using the CMake wrapper by downloading the conan.cmake-file and I'm calling

conan_cmake_run(REQUIRES <PACKAGE>/<VERSION>
				BASIC_SETUP
				CMAKE_TARGETS
				GENERATORS cmake_find_package cmake_paths
				OPTIONS ${CONAN_OPTIONS}
				BUILD missing
)

This leads to the creation of several files in my output folder. The CMake output shows:

conanfile.txt: 
Generator cmake created conanbuildinfo.cmake

conanfile.txt: 
Generator txt created conanbuildinfo.txt

conanfile.txt: 
Generator cmake_paths created conan_paths.cmake

conanfile.txt: 
Generator cmake_find_package created Find<PACKAGE>.cmake

conanfile.txt: 
Generated conaninfo.txt

conanfile.txt: 
Generated graphinfo

In my output folder I find the conanfile.txt, which is "the recipe" created by the wrapper for my <PACKAGE>, I guess. Now when I open this file, I see the following:

[generators]
cmake

[requires]
<PACKAGE>/<VERSION>

[options]
...
some options
...

[imports]

I was wondering why [generators] is set to cmake and not cmake_find_package and cmake_paths?

[czoido]

Hi @akalali,
The temporary conanfile.txt that is created always has the cmake generator that is the default. Additional generators are added through the command line here:

cmake-conan/conan.cmake

Lines 424 to 426 in cf7110d

	foreach(ARG ${ARGUMENTS_GENERATORS})
	set(CONAN_GENERATORS ${CONAN_GENERATORS} -g=${ARG})
	endforeach()

That will lead to the same result in the end than if it was in the conanfile.txt

[akalali]

And why is the cmake generator used in the first place? I created a small testproject with a simple conanfile.txt containing

[generators]
cmake_find_package_multi

and this results in an output similar to

Generator txt created conanbuildinfo.txt

conanfile.txt: 
Generator cmake_find_package created Find<PACKAGE>.cmake

I then set(CMAKE_PREFIX_PATH ${CMAKE_BINARY_DIR} ${CMAKE_PREFIX_PATH}) and this will allow me to find the package. No need to include the conanbuildinfo.cmake file.

[czoido]

The cmake generator is always used as a default for cmake-conan, but that's right, if you use the cmake_find_package_multi or cmake_find_package generators you don't have to include conanbuildinfo.cmake and those generated files will not be used.

[akalali]

The cmake generator is always used as a default for cmake-conan

Yes, that what I understood. My question was more in the direction, why the default is not overridden by what's used in the conan_cmake_run-call since the output of the cmake-generator (conanbuildinfo.cmake) is not needed.

[czoido]

Hi @akalali,
Thanks for the feedback, that's probably something we can do for future releases, anyway, if you want not to load the conanbuildinfo.cmake by default you can use the NO_LOAD argument in conan_cmake_run (it will be generated but not loaded).

[akalali]

I tried to use the NO_LOAD argument. It's working (although the conanbuildinfo.cmake is obviously still created) but I had to remove the BASIC_SETUP argument since this would call conan_basic_setup, which is defined inside conanbuildinfo.cmake.

Until now I did not experience any side-effects but I remember having another project that used the CMAKE_TARGETS argument combined with BASIC_SETUP. I guess using targets is not possible with NO_LOAD?
Or would this be possible using the <PACKAGE>Targets.cmake-file?

[czoido]

Hi @akalali,

Yes, if you want to use NO_LOAD, BASIC_SETUP and CMAKE_TARGETS have to be removed (we should probably add a warning message for this).

You can use the targets generated by the cmake_find_package generator. Here is an example on how to use them (also using the cmake_paths_generator that is going to define the CMAKE_MODULE_PATH folder, here the docs for that)

cmake_minimum_required(VERSION 2.8.12)
project(FormatOutput)
add_definitions("-std=c++11")

include(conan.cmake)

conan_cmake_run(REQUIRES fmt/6.1.2
                NO_LOAD
                GENERATORS cmake_find_package 
                GENERATORS cmake_paths
                BUILD missing)

# conan_paths.cmake generated by cmake_paths generator
include(${CMAKE_BINARY_DIR}/conan_paths.cmake)
# Findfmt.cmake generated by cmake_find_package generator
find_package(fmt)

add_executable(main main.cpp)
target_link_libraries(main fmt::fmt)

[akalali]

Thanks for the clarification.
My current project looks very similar to your example although I'm not using cmake_paths anymore and set(CMAKE_PREFIX_PATH ${CMAKE_BINARY_DIR} ${CMAKE_PREFIX_PATH}) / set(CMAKE_MODULE_PATH ${CMAKE_BINARY_DIR} ${CMAKE_MODULE_PATH}) manually, as @memsharded suggest here (third point). This is also an alternative option as explained in your linked documentation.

I think my initial question is answered. We / you can close the topic depending on whether you want to address the two other mentioned issues / improvements:

• override the default
• add a warning message

[czoido]

Hi @akalali,
Thanks a lot, I'll leave this open for the moment to evaluate addressing those issues.

[FranckRJ]

I would like to remove the default generator as well. I can make a PR if you want, i just need to know how it should be done.

I was thinking about a parameter "NO_DEFAULT_GENERATOR", is it ok for you ? With a FATAL_ERROR message if no GENERATORS and CONANFILE is provided.

If a CONANFILE is provided but contains no [generators] then i have no idea how to handle it, but i think conan install will fail so maybe it's ok.

EDIT : Oh and about the load of the conanbuildinfo.cmake, i was think about only adding the fact that the option NO_LOAD should be added as well in the README.md. Because if it's enabled by default if NO_DEFAULT_GENERATOR is enabled then it could cause issues if one of the manually added generator is cmake (how to enable the load ? A FORCE_LOAD option that override NO_LOAD ? It would be ugly i think, it's better to do nothing).

[czoido]

I'm closing this as for the future we are moving in the direction of deprecating the use of conan_cmake_run and using separate calls to conan_cmake_configure, conan_cmake_autodetect and conan_cmake_install proposed here: #310. This is more explicit and can use latest Conan features because you can skip the auto-detection part if you want. Also, that way you can use just what you need without having nothing generated as default.