This enables project(... VERSION x.y.z.a ...) and DESCRIPTION etc.. usage (IDFGH-11310)

[kohait00]

the current implementation of project.cmake
overrides the

project()

function with a macro which then calls the overridden function, but only provides the project name along with some predefined LANGUAGES..
in case someone wanted to specify additional LANGUAGES, DESCRIPTION etc... this is entirely ignored.
probably to keep things simple.

this fix enables the usage of all the parameters for project() including LANGUAGES

it splits the provided ARGV when there is LANGUAGES present, and eliminates the predefined languages that the project.cmake already wants to specify itself.

everything else is untouched.

this also has the benefit that the cmake own PROJECT_VERSION now is able to be specified via the project(VERSION x.y.z.a ...) and then can be used to initalize the PROJECT_VER, no need to specify the PROJECT_VER explicitly as a set(PROJECT_VER x.y.z.a)..

I admit that the solution is probly not optimal, feel free to improve on it.

[github-actions]

	Messages
📖	You might consider squashing your 4 commits (simplifying branch history).

---

👋 Welcome kohait00, thank you for your first contribution to espressif/esp-idf project!

📘 Please check Contributions Guide for the contribution checklist, information regarding code and documentation style, testing and other topics.

🖊️ Please also make sure you have read and signed the Contributor License Agreement for espressif/esp-idf project.

Pull request review and merge process you can expect

Espressif develops the ESP-IDF project in an internal repository (Gitlab). We do welcome contributions in the form of bug reports, feature requests and pull requests via this public GitHub repository.

1. An internal issue has been created for the PR, we assign it to the relevant engineer
2. They review the PR and either approve it or ask you for changes or clarifications
3. Once the Github PR is approved, we synchronize it into our internal git repository
4. In the internal git repository we do the final review, collect approvals from core owners and make sure all the automated tests are passing
   • At this point we may do some adjustments to the proposed change, or extend it by adding tests or documentation.
5. If the change is approved and passes the tests it is merged into the master branch
6. On next sync from the internal git repository merged change will appear in this public Github repository

---

_{🔁 You can re-run automatic PR checks by retrying the DangerJS action}

Generated by 🚫 dangerJS against 96e2a8a

[igrr]

Thanks for the nice improvement @kohait00!

The code looks good to me overall, I have left a few cosmetic comments. My main concern is that the part about LANGUAGES seems to be a piece of fairly complex string/list manipulation code. I think we need to have some test coverage for it to prevent regressions.

Do you think you can add a few test cases to validate the behavior of this code?

I see we have two test cases for the version related logic,

esp-idf/tools/test_build_system/test_git.py

Line 28 in b4268c8

def test_get_version_from_git_describe(test_git_template_app: Path, idf_py: IdfPyFunc) -> None:

and, somewhat badly named,

esp-idf/tools/test_build_system/test_kconfig.py

Line 129 in b4268c8

def test_kconfig_get_version_from_describe(idf_py: IdfPyFunc, test_app_copy: Path) -> None:

Probably it makes sense to

• create a new test file, test_versions.py
• move the two existing tests there
• add one new test case about version from project call
• add another new test case (there or in another file) to validate the logic related to LANGUAGE argument handling

If you don't have time to work on adding test cases, please let us know anyway.

[kohait00]

regarding the oetending of test cases that @igrr suggested, I could try but to be honest, I am a newby in python, barely read it.. It would take some time for sure.. But then again, I am also learning CMake now..

Probably easier for me would be to provide some project(xxx) string that can be used as a starting point..

My suggestion:
I provide review changes ASAP, including ducumentation and the test case ideas for VERSION, LANGUAGES etc
Then depending on the time frame that you guys have we can decide who would write the unit tests

[kohait00]

the promised test cases:

syntax reference
https://cmake.org/cmake/help/latest/command/project.html

usual simple case may not break. Nothing more than that was possible before

project(hello_world)

this should be possible but wont work, due to project.cmake internal LANGUAGES definition

project(hello_world CSharp C CXX ASM)

bit more sophisticated with version, probably the future default

project(hello_world VERSION 2.4.3)

even more complicated, order as in CMake documentation

project(hello_world VERSION 2.4.3 DESCRIPTION "Cool New Project" LANGUAGES C CXX ASM)

order reversed, also in the languages definitions

project(hello_world VERSION 2.4.3.6 LANGUAGES CXX C ASM DESCRIPTION "Cool New Project" )

to trigger the special case of C at the end

project(hello_world VERSION 2.4.3 DESCRIPTION "Cool New Project" LANGUAGES CXX ASM C )

adding more to languages

project(hello_world VERSION 2.4.3 DESCRIPTION "Cool New Project" LANGUAGES CSharp C CXX ASM )

duplicates

project(hello_world VERSION 2.4.3 DESCRIPTION "Cool New Project" LANGUAGES CSharp C CXX ASM C )

full blown, strict docu conform order

project(hello_world VERSION 2.4.3 DESCRIPTION "Cool New Project" LANGUAGES CSharp C CXX ASM HOMEPAGE_URL "http://www.hello-world.com")

full blown, arbitrary order

project(hello_world DESCRIPTION "Cool New Project" VERSION 2.4.3.6 LANGUAGES CSharp C CXX ASM HOMEPAGE_URL "http://www.hello-world.com")

this schows that not all cases are caught, description will result in 'Cool new Project', the C at the end is gone

project(hello_world VERSION 2.4.3.6 LANGUAGES CXX C ASM DESCRIPTION "Cool New ProjectC" )

this wont ever work,

project(hello_world VERSION 2.4.3 DESCRIPTION "Cool New Project" CSharp C CXX ASM C )

[kohait00]

I had to force push because I forgot to correct the 'unlikly' and fixed it via amend..

so that's the only change there..
I did an amend on f0d8b3f (which I have seen you already cleared) and cherry pick on the documentation commit.. sorry for the hassle

there are no other changes so far

[sudeep-mohanty]

@kohait00 Thanks for the suggestions and apologies for getting back to you late on this. I would be pulling in your changes but we might have to enable each project() argument gradually with some unit-tests for sanity so that we do not introduce any regression or breaking changes. Therefore, I would incorporate the addition of the VERSION argument first and then investigate the others subsequently.

[sudeep-mohanty]

sha=96e2a8a51c7c9613d0699e46e00c4ca160b5eace

[kohait00]

@kohait00 Thanks for the suggestions and apologies for getting back to you late on this. I would be pulling in your changes but we might have to enable each project() argument gradually with some unit-tests for sanity so that we do not introduce any regression or breaking changes. Therefore, I would incorporate the addition of the VERSION argument first and then investigate the others subsequently.

I dont mind at all.. Do whatever is desired, since I currently can't provide additional testcases apart from what I tested locally.
If there is anything else I can do here to support, let me know..
Have fun.

[Alvin1Zhang]

Thanks for contribution again, changes have been merged with 9beda4c.