qbs: add optional support for cmake_file_name property

[ABBAPOH]

As was requested by user migrating from Conan 1.x here https://bugreports.qt.io/projects/QBS/issues/QBS-1849.

Changelog: (Feature): Describe here your pull request Docs: omitted

• [ ] Refer to the issue that supports this Pull Request.
• [ ] If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
• [x] I've read the Contributing guide.
• [x] I've followed the PEP8 style guides for Python code.
• [ ] I've opened another PR in the Conan docs repo to the develop branch, documenting this one.

[ABBAPOH]

I think it might not be the case, am I missing something?

A user specifically asked for usage of cmake_file_name rather than the normal flow (pkg_config_name or dep.ref.name). My understanding is that they relied on cmake_file_name from Conan 1.x JSON generator and ask this feature to ease transition to Conan 2.x. It is indeed quite a daunting task to replace all entries Depends { name: "crashpad" } with Depends { name: "sentry-crashpad" } all over the project. I am personally not fond of this feature, but I can see the reason - setting a single flag in the generator to use CMake names is much easier than replacing multiple dependencies across the project.

[memsharded]

I am not sure if I understand.

Conan 1 never used the cmake_file_name in any of the qbs generators, not the legacy qbs one, not in QbsProfile. The JSON generator didn't serialize properties like cmake_file_name either: https://docs.conan.io/1/reference/generators/json.html. Then, this doesn't make sense from the migration point of view.

And even if that was the case, it is simply too incorrect to depend on a cmake_xxxx property for a qbs generator, unless the Qbs build system explicitly documented some kind of convention over CMake based open source libraries, which doesn't seem the case either.

So this would only make sense as a qbs_file_name property or something like that.

[memsharded]

Hi @ABBAPOH

It seems this PR went stale, did you check the above comment? The main issue seemed the abuse of a cmake_xxxx property for the qbs generators, and how this could even potentially break existing users, that relied on the previous value without the application of cmake_file_name, because the file they were already using would suddenly change name (there are quite a few packages in ConanCenter that already define cmake_file_name)

So unless qbs has a strong convention that it should follow the upstream CMake names, then it would be necessary a qbs_ property instead.