conan
conan copied to clipboard
conan-io
[feature] location of the generated CMakeUserPresets.json
The Conan documentation states:
If you declare a layout() in the recipe and your CMakeLists.txt file is found in the conanfile.source_folder folder, Conan will place a CMakeUserPresets.json to include the CMakePresets.json generated with the above specification.
However, there is no way to set the source folder from the conan install command. Besides the obvious use case to override the defaults from the command line, such an option could also be useful in big projects to select which directory with CMakeLists.txt should be used as an entry point for CMake build. For example, if I have several standalone subprojects in the tree and only one conanfile.py to define the dependencies with conan install --source-folder I could control where the CMakeUserPresets.json is being generated and then build such a subproject in isolation using CMake presets.
Alternatively, CMakeUserPresets.json could be generated in the path of conan install invocation, but probably this is a worse solution.
- [x] I've read the CONTRIBUTING guide.
The conanfile.source_folder directory is the join of the folder where the conanfile.py is located (path of the conan install x) and the folders.source that is declared in the layout() method. The source-folder is not meant to specify where the CMakeUserPresets.json is written but describes where your library sources are (for building editable packages and so on...)
In the situation you describe, I don't know if it is better to copy the CMakeUserPresets.json to the subfolders N times than to call conan install N times. Take into account that the CMakeUserPresets.json will include the CMakePresets.json for the installed configurations that will likely be familiar to all the projects.
We currently don't have a mechanism to put the CMakeUserPresets.json in a different place, actually for the multi-project situation you describe, it is likely that the file is never written because you probably don't have a CMakeLists.txt in the folder of the conanfile.py.
Yes, for the case I described a file will not be generated. For others, I do copy a CMakeUserPresets.json manually, and it works. Such scenarios might be the one I described in my Conan talks where we have two CMake entry points in the project. One for the development (with all the unit tests, examples, compilation warnings set, etc.) and the one in a ./src subdirectory for customers. If I want just to build and install the ./src subdirectory I have to copy CMakeUserPresets.json to this place.
Before I was doing:
cd src
mkdir build && cd build
conan install ../.. # use Conanfile from the top directory
cmake .. # use the ./src subdirectory entry point
cmake --build . # just build the public package code (without development-specific stuff)
With layout usage, this scenario does not work unless you copy a presets file manually.
The conanfile.source_folder directory is the join of the folder where the conanfile.py is located (path of the conan install x) and the folders.source that is declared in the layout() method.
How this relates to: https://docs.conan.io/en/latest/developing_packages/package_dev_flow.html#package-dev-flow where we can provide --source-folder explicitly (different than the one hardcoded in layout())?
How this relates to: https://docs.conan.io/en/latest/developing_packages/package_dev_flow.html#package-dev-flow where we can provide --source-folder explicitly (different than the one hardcoded in layout())?
The docs in https://docs.conan.io/en/latest/developing_packages/package_dev_flow.html#package-dev-flow are legacy, they were written before the layout() existed, before generate() and all the new build system integrations. That doc page disappears in Conan 2.0
Hi, I renamed the issue and assigned it to the next release just to think about it. If we come up with some idea we could implement something.
I would just like to add another observation. I have been using CMakeSettings.json which is Visual Studio specific and a kind of precursor for CMakePresets.json. Since the latest VS 2022 Microsoft is officially promoting using CMakePresets.json instead of CMakeSettings.json which is definitely a good move.
However, the way CMakeSettings.json were and CMakePresets.json are supposed to be used in VS IDE is quite different from what conan expects. So basically neither conan generated CMakePresets.json, nor CMakeUserPresets.json are really useful (in VS IDE context) and one would rather want a handcrafted CMakePresets.json which will include conan_toolchain.cmake as it did before, and would not want having conan messing with that. So an option to not generate those files could be useful too.
