[question] Delete the Build Folder Beforehand if Exists

[viktoria7211]

What is your question?

Hi! I have a question regarding the Conan 2 build folder creation workflow.

We use the cmake_layout functionality with a single-configuration cmake-generator to create our build folders.

def layout(self):
    cmake_layout(self)

Considering the default behaviour above, a build/<build_type> would be created.
Now we would like to have the possibility to remove the build folder beforehand, if it exists already, to ensure a clean build e.g. using a wrapper script around the used conan commands.

Is there any possibility to retrieve the created build folder beforehand or tell Conan to force a clean run to enable such behaviour?

Thanks in advance!

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[memsharded]

Hi @viktoria7211

Thanks for your question.

For most cases the conan build and the local flow are not intended to do clean builds, but incremental builds. To produce clean builds from scratch, this is the main reason why the conan create command was designed. Could you please elaborate why the conan create command is not a possibility for your use case?

It should be possible to do a conan install . --format=json and then the build_folder will be there in the output.
Still it sounds that CI shouldn't be doing this behavior, either building from a clean folder (just after git-clone), or using the conan create functionality.

[viktoria7211]

Hi @memsharded

Thank you for the quick response!

The use case refers to the local development workflow. Sorry for being too imprecise in my question.

To be more precise, the use case would be that generated files in the build folder might change during the development.
For instance, if a build requirement is removed a corresponding xxx-config.cmake file would be still in the generate() folder. Also, other files which might be copied in the generate() method to the local build folder could be outdated at some point.
For such cases, a clean build might be useful locally to remove deprecated files. E.g. a python script could be executed which does the cleaning before the build to avoid a manual removal step of the build folder.

Thanks for the hint to parse the build folder on the conan install . --format=json run. This would work, but would require in total two conan install runs i.e. one to find out the build folder and another one for the actual build.

[memsharded]

To be more precise, the use case would be that generated files in the build folder might change during the development.
For instance, if a build requirement is removed a corresponding xxx-config.cmake file would be still in the generate() folder. Also, other files which might be copied in the generate() method to the local build folder could be outdated at some point.
For such cases, a clean build might be useful locally to remove deprecated files. E.g. a python script could be executed which does the cleaning before the build to avoid a manual removal step of the build folder.

Thanks for clarifying. Indeed these things can happen, but they are relatively infrequent, compared with normal incremental builds, keeping the same configurations. If that is the case, developers would do a rm -rf build to remove the build folder and start from scratch, it is not that the build folder is something weird, 99% of times it is just the "build" folder in the repo. Not sure how a Conan functionality would help with this flow, making developers add more commands or command line options to remove the build folder seems very overkill. I might still be missing something.

Thanks for the hint to parse the build folder on the conan install . --format=json run. This would work, but would require in total two conan install runs i.e. one to find out the build folder and another one for the actual build.

Yes, this is what I meant above with overkill. I am not sure the flow we are trying to improve:

• If it is CI, the build will be clean, no problem
• If it is developer local flow, most of the times developers want incremental builds. If they don't, they can do just a rm -rf build. This would be simpler than any other possible flow?

[viktoria7211]

Thanks for clarifying. Indeed these things can happen, but they are relatively infrequent, compared with normal incremental builds, keeping the same configurations. If that is the case, developers would do a rm -rf build to remove the build folder and start from scratch, it is not that the build folder is something weird, 99% of times it is just the "build" folder in the repo. Not sure how a Conan functionality would help with this flow, making developers add more commands or command line options to remove the build folder seems very overkill. I might still be missing something.

A command line option to remove the build folder before the actual build is what I have been looking for initially.

Yes, this is what I meant above with overkill. I am not sure the flow we are trying to improve:
If it is CI, the build will be clean, no problem
If it is developer local flow, most of the times developers want incremental builds. If they don't, they can do just a rm -rf build. This would be simpler than any other possible flow?

It is only about the developer's local flow. The idea is to avoid the rm -rf build manual step and to provide a wrapper script with an argument (e.g. --clean) which executes this step beforehand if forced by the developer.
But for this step, the name of the created build folder is needed.

[memsharded]

A command line option to remove the build folder before the actual build is what I have been looking for initially.

I guess that you are looking for something similar to the cmake --fresh argument.
At the moment Conan doesn't provide it, in the same way CMake hasn't provide it for decades, and the --fresh is quite recent.
I think that many developers are still doing rm -rf build instead of using the --fresh argument.

In Conan it would also be a bit more difficult to represent what is a "fresh" install, because there are user operations like deployers, custom commands or when doing builds in multi-config environments that are kind of cumulative, and Conan removing incorrect things could be unexpected and annoying. For example there are build systems such as autotools that the build might not be in a separate folder, so it is not possible to remove the "build" folder (removing it would destroy the current sources, as it would typically be the same as the "source" folder). In that case, what we want to remove is probably just the generators_folder, as long as it is not the same as the source folder...

If you are writing your own wrapper scripts, then probably doing just rm -rf build in the script will achieve your desired result in most of the cases if you define the recipes to have the cmake_layout or something like that.

I will have a look to this with the team, and discuss if it is worth considering a possible --fresh argument. Thanks for the feedback!

[viktoria7211]

Thanks for the hint to make use of the cmake --fresh argument! This is already helpful and could be integrated into our conan local development workflow.

Also, thanks for your explanations and for looking into this use case of having such a flag provided in the Conan command to provide a fresh/clean build folder.

[memsharded]

Hi @viktoria7211

Thanks for the feedback. I have been discussing with the team, and something like --fresh for Conan will not be considered at the moment. Removing the "build" artifacts shouldn't be a Conan responsibility in the first place, we have discussed if removing the generators folder would make more sense. But there are some corner cases (like generators multi-config) that were not clear.

So overall seems to add some complexity with a not very clear UX, for limited value that in the vast majority of the cases developers are already easily handling with a rm -rf build to remove the build folder.

Closing the ticket as solved, many thanks!