Renaming cmake project, targets, etc.

[LecrisUT]

Tldr

Things that will be renamed:

---

Details

The naming convention is getting out of hand and it should be simplified. For now this issue is gathering the targets to be renamed. Will update the details down below.

[pboettch]

The naming convention is getting out of hand. [..]

rofl

But you're right. KISS.

[pboettch]

This could go along with namespace refactoring.

[LecrisUT]

CMake project name

Proposed nlohmann_json_schema_validator -> Json_Validator

Affects

• Naming convention of other targets/options etc. There is no agreed standard but the most common one is:
  • options: <PROJECT_NAME_UPPERCASE>_<Option_Name>
  • targets: <Project_Name>_<Target_Name> (internally) and <Project_Name>::<Target_Name> (externally)
  • namespace: <Project_Name> (This might be enforced in cmake upstream in the future)
  • cmakeConfig file: <Project_Name>Config.cmake (Enforced, use find_package(NAMES) for compatibility)
  • targets file: <Project_Name>Targets.cmake (invisible to the user, does not really matter)
• Auto-generated variables like <Project_Name>_VERSION

Cautions

• Avoid name clashing with other projects

Notes

• Before #262 the project would not have been properly importable via FetchContent, so there shouldn't be an established convention for cmake users

---

Main library

Proposed nlohmann_json_schema_validator -> json-validator.so

Affects

• Mostly manual importers. Downstream should move to the automated build methods with cmake/conan/etc.

---

Targets

Proposed:

• nlohmann_json_schema_validator -> Json_Validator_library + Json_Validator::Json_Validator (convention breaking for the main target)
• tests, etc. -> namespaces according to CMake project name notes.

Affects

• cmake importers

Notes

• same as CMake project name

[LecrisUT]

I don't know about bazel/conan side if there is anything to be discussed there.