Package naming (from CMake / consumer perspective)

[ferdnyc]

I'm guessing this is going to be an unpopular suggestion, and I'll understand if it's rejected, but I'd like to suggest that the "external" tooling of the project — specifically, things like the CMake ${PROJECT_NAME} (and by extension, the names the EXPORTED config will install under) — be changed to something different from simply "XdgUtils".

Because:

1. There's already an xdg-utils; it lives at https://people.freedesktop.org/~rdieter/xdg-utils/ and is already packaged in various distributions that way.
2. This repo is not that xdg-utils, it's 'xdg-utils-cxx' ­— that's even the name of the project repo, so it's not like there's any disagreement on that
3. By installing a CMake configuration named XdgUtilsConfig.cmake, it appears to be the configuration for that xdg-utils, not xdg-utils-cxx.
4. By the same token, when some build documentation says that a build "needs XdgUtils" as a dependency, or offers the option to USE_SYSTEM_XDGUTILS (*cough* libappimage *cough*), it doesn't seem unreasonable to assume that having xdg-utils installed would be sufficient to satisfy that option. And it seems confusing to find out, "Oh, they didn't mean xdg-utils, they meant a different xdg-utils."
5. While xdg-utils doesn't provide an EXPORTED CMake configuration today, they may in the future, which could cause a naming conflict.
6. Due to the aforementioned preexistence of xdg-utils packages in most distros, this code can't be packaged as xdg-utils, it would have to be xdg-utils-cxx, only furthering the confusion about what exactly the required dependency is for any packages that depend on xdg-utils-cxx.

Also, not part of my actual argument, but just as a side note:

1. The current naming totally missed a golden opportunity to be known as "cxxdg-utils". 😉

[azubieta]

Hello @ferdnyc,
You certainly have a point and my naming skills are the one to blame. But making a name change at this point would break our clients code. Right now I'm aware of "libappimage", this code was created to fulfill its requirements. I'll discuss the renaming with the other maintainers, to see if we can get to a better solution before the original XdgUtils creates a cmake file.
If you have other name suggestions, please feel free to share it.
Cheers

[ferdnyc]

@azubieta I totally understand. And as I said at the start, I would've totally understood if the response was just a flat-out, "No, too much trouble." So, I appreciate you indulging me even this far. 😁

As far as naming goes, xdg-utils-cxx (and XdgUtilsCxx as the CMake transliteration) strikes me as a fine name, I was mostly kidding about cxxdg-utils.

(I mean, I still think it's a good name, but changing the name completely at this point doesn't seem warranted. Just tacking the "Cxx" part onto the CMake identity, to match the main project and better differentiate from the official xdg-utils, is more than sufficient IMHO.)

Thanks again!

[ferdnyc]

And, actually, I just had an idea. I do fully appreciate the need to avoid disrupting existing users of the library, and that's honestly the last thing I'd want to see happen.

So, what if you were to take advantage of the fact that xdg-utils doesn't currently have any CMake tooling visibility, and install BOTH configurations for a time?

The targets could be installed as both XdgUtilsConfig.cmake and XdgUtilsCxxConfig.cmake, with the former issuing a developer warning on use — basically, just a message indicating that the former name is deprecated, so downstream projects should change their configuration to use find_package(XdgUtilsCxx...) instead.

Then, after a few releases and maybe a major version bump, the old config could be phased out with (hopefully) minimal disruption.

[ferdnyc]

(And I'll be happy to submit a PR with the necessary changes in CMake, if there's interest and a reasonable chance of it being merged.)

[azubieta]

Having both XdgUtilsConfig.cmake and XdgUtilsCxxConfig.cmake sounds like a good first step.

Feel free to make a PR :)

[TheAssassin]

The name of this project causes confusion over at Debian, where the package name clearly implies a relation to the normal xdg-utils, although this project is not even remotely related to that. I support changing the name to something less confusing.

Also, given your project is merely for use as a library, you should consider prefixing the name with lib.

[azubieta]

Seems reasonable, what do you think about renaming it to libxdgcxx ?

@ScarlettGatelyMoore which implications has this change on the Debian packaging?

[ScarlettGatelyMoore]

Nothing I can't fix with a breaks/replace. New name sounds reasonable to me.