Skip to content

fix(tools): set *_IS_TOP_LEVEL cmake values at project() calls (IDFGH-16745) #17830

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: release/v5.5
Choose a base branch
from
+9 −0
Open

fix(tools): set *_IS_TOP_LEVEL cmake values at project() calls (IDFGH-16745) #17830

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 9 additions & 0 deletions tools/cmake/project.cmake
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -632,6 +632,15 @@ macro(project project_name)
set(${PROJECT_NAME}_VERSION_TWEAK "${${PROJECT_NAME}_VERSION_TWEAK}" PARENT_SCOPE)
set(${PROJECT_NAME}_DESCRIPTION "${${PROJECT_NAME}_DESCRIPTION}" PARENT_SCOPE)
set(${PROJECT_NAME}_HOMEPAGE_URL "${${PROJECT_NAME}_HOMEPAGE_URL}" PARENT_SCOPE)
if(${CMAKE_VERSION} VERSION_GREATER_EQUAL "3.21")
if(CMAKE_CURRENT_SOURCE_DIR STREQUAL CMAKE_SOURCE_DIR)
set(PROJECT_IS_TOP_LEVEL ON PARENT_SCOPE)
Copy link
Collaborator

@fhrbata fhrbata Nov 6, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this does not mimic how cmake sets PROJECT_IS_TOP_LEVEL. Specifically

The variable value will be true in:
a directory added by add_subdirectory() that does not also contain a project() call`

as described in docs

Copy link
Author

@benedekkupper benedekkupper Nov 6, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's also a change in the documentation between 3.23 and 3.24, so if we want to handle these variables completely up to spec, this should be reflected too. I'm a bit out of my depth here, do you have a proposal for the condition here?

Copy link
Collaborator

@fhrbata fhrbata Nov 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's also a change in the documentation between 3.23 and 3.24, so if we want to handle these variables completely up to spec, this should be reflected too.

Ah, nice catch, I haven't noticed the change between 3.23 and 3.24.

I'm a bit out of my depth here, do you have a proposal for the condition here?

TBH I'm not sure neither. I guess it would be best to fully understand how the IsRootMakefile() function, used to set the PROJECT_IS_TOP_LEVEL variable, is implemented. I tried to take a look, but I would definitely need more time to understand the logic.

My worry is that with this change, which does not fully mimic cmake's behavior, we may fix problems for one set of people, but at the same time, we may change the expected behavior for others and break their components. At this point, I'm not sure this issue can be fully resolved, but I could be completely off here.

We are currently working on a next version of the build system, which is currently available as technical preview and it does not have this issue.

Thank you very much for looking into this problem!

Copy link
Author

@benedekkupper benedekkupper Nov 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does that mean that there won't be further releases from 5.5? What is the timeline for releasing this new build system?

Copy link
Collaborator

@dobairoland dobairoland Nov 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does that mean that there won't be further releases from 5.5?

Please see https://github.com/espressif/esp-idf?tab=readme-ov-file#esp-idf-release-support-schedule. We will release bugfix releases for v5.5 up until 2028. All PRs should be targeted to the master branch and we can backport them to v5.5 if possible (patch is without breaking changes).

The build system what you know in v5.5 will be available in v6.0 as well. This is referred as cmakev1 in #17833. cmakev2 is available from v6.0 in preview state. cmakev2 will became the default build some later version of ESP-IDF. I'm unable to tell when will this happen.

Copy link
Author

@benedekkupper benedekkupper Nov 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still think it is better to fix this in 5.5 one way or another, I don't believe that anybody is depending on the current wrong behavior and gets a worse experience with this fix.

Copy link
Collaborator

@fhrbata fhrbata Nov 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hello @benedekkupper ,

I still think it is better to fix this in 5.5 one way or another, I don't believe that anybody is depending on the current wrong behavior and gets a worse experience with this fix.

This build system quirk is present for a long time and people may have worked around it already. For example there is another issue #17773 and the ESP_PLATFORM variable was used as a workaround(if(PROJECT_IS_TOP_LEVEL AND NOT ESP_PLATFORM)). Maybe this is something that could be used for your use case too. Note I don't think that your change would break this particular workaround, but we cannot be sure how the PROJECT_IS_TOP_LEVEL may be used in other components.

IIUC with the change you proposed we would actually set the PROJECT_IS_TOP_LEVEL variable always to OFF for components, which is now always ON. As stated above, I think this may break components which already worked around this unfortunate behavior.

I agree that it would be best to fix this, but I'm not sure if replacing one quirky behavior with another is the ideal solution. I of course can be wrong and maybe others have a different opinion.

Thank you very much

set(${PROJECT_NAME}_IS_TOP_LEVEL ON PARENT_SCOPE)
else()
set(PROJECT_IS_TOP_LEVEL OFF PARENT_SCOPE)
set(${PROJECT_NAME}_IS_TOP_LEVEL OFF PARENT_SCOPE)
endif()
endif()
endfunction()

# Prepare the following arguments for the idf_build_process() call using external
Expand Down