Should we keep OT_CONFIG file?

[bukepo]

I noticed OT_CONFIG is marked as deprecated in the CMakeLists.txt in root. And it suggests using OT_PROJECT_CONFIG and OT_PLATFORM_CONFIG instead.

OT_PROJECT_CONFIG is mapped to OPENTHREAD_PROJECT_CORE_CONFIG_FILE and OT_PLATFORM_CONFIG is mapped to OPENTHREAD_PLATFORM_CORE_CONFIG_FILE, both are only included by openthread-core-config.h.

Currently OpenThread has a couple of libraries in addition to core library. It's looks OT_CONFIG is a good config file for the whole project affects more than core library. So I'm considering perhaps we shouldn't deprecate it. Thoughts? @abtink

[abtink]

Currently, OpenThread has several libraries in addition to the core library. It seems OT_CONFIG is a good candidate for a configuration file that affects the entire project, not just the core library.

I think OT_PROJECT_CONFIG could be used as a configuration file for the entire project, including the core.

We already offer two configuration options: project config and platform config. Introducing a third config might not be beneficial.

For the different libraries, I propose allowing each to have its own dedicated config header tailored to its specific functionality. This approach offers greater flexibility than a single shared config across all libraries.

• A project integrator can choose to share a single common header file and use it for all library configurations.
• Alternatively, they can utilize separate header files for each library, providing more control.

---

I noticed OT_CONFIG is marked as deprecated in the CMakeLists.txt in root

OT_CONFIG is leftover from when Autotools build systems was supported by OpenThread (we removed it in #9027) . Autotools generated a config.h which would be used. We still have config.h which does #include OPENTHREAD_CONFIG_FILE (from OT_CONFIG).

[bukepo]

The problem of OT_PROJECT_CONFIG is it's designed for core only because it maps to the macro OPENTHREAD_PROJECT_CORE_CONFIG_FILE. If we want to use it as the project level configuration, we may need to rename it. Thoughts?

[abtink]

Here's what I would suggest:

• Each library defines its own dedicated configuration header macro, accompanied by a CMake option to set it.
• If the library-specific CMake option is not explicitly set, the OT_PROJECT_CONFIG can be used to set lib-specific macro.
• Libraries will not use the OPENTHREAD_PROJECT_CORE_CONFIG_FILE macro directly (intended for internal core use). Instead, they have their own macro, which may be potentially set from OT_PROJECT_CONFIG.

[bukepo]

For units don't have dedicated configuration header macro, do you think it acceptable to include OT_PROJECT_CONFIG for now? I hope to submit a PR so that we have a project wide configuration header macro.

[abtink]

Yes. Sounds good to me.