Added support for use of units as subdirectory when *dependencies* are *also* subdirectories

[Cazadorro]

Added check for gsl::gsl-lite to avoid find_package if targets already added by add_subdirectory(...) and did the same for fmt::fmt and ranges-v3, with out these changes, impossible to use library if dependencies are also subdirectories, complains about not being able to find package (when it no longer needs to)

[gitpod-io[bot]]

[JohelEGP]

I think https://cmake.org/cmake/help/latest/command/cmake_language.html#set-dependency-provider can be used to work around that.

[Cazadorro]

Thanks!

Unfortunately, I have mixed feelings about that. On one side, I understand your point, and I see how this PR fixes your problem. On the other hand, doing dependency management via add_subdirectory is really wrong, and I wouldn't like to encourage it or complicate the code logic to provide support for such scenarios.

definitely agree, but the problem is 7 fold:

• This library still advertises subdirectory support,
• this library even advertises header only support, as in drop in place headers, an infinitely worse practice.
• We still need escape hatches when our tools fail us, makes it hard to troubleshoot things that have nothing to do with your library on our end if we can't isolate the library from the package management chain.
• VCPKG and conan only got "good" in 2017, many projects predate this, and many critical features weren't available in either until 2021. Package management in C++ is very new, and there's still a lot of gotchas. Certainly I wouldn't suggest the equivalent in something like Rust.
• I haven't been able to use conan across two companies corporate networks, and it's left the conan devs scratching their heads, and leaves conan unusable in many nominal environments.
• VCPKG is "roughly" universal, and I do use it, but it's offline functionality is rather... lacking, and getting export and --only_download to work for my problem has been problematic, and does not work right with manifest mode, which is also something everybody should just be using according to MS, but these problems leave us with out ideal solutions.
• I need to use this project in an offline environment, the above solution fixes what would have taken months of work into minutes to get working.

The practical reality on the ground is why other libraries support such use cases out of the box, we have no other real option. Trust me, myself and the thousands of other engineers that work in these kinds of environments would much rather be using package managers, but unlike rust's cargo, or heck even PIP, neither Conan or VCPKG provide adequate solutions to these problems. IME, 99% of the people who have the same issues simply don't attempt to use libraries like this if they don't immediately work offline. I know at my company, I'm at least the fourth person to attempt to use this library, and the only person to attempt to actually stick with it despite the dev ops problems associated with it, and I was hoping this would kind of pave the way for further usage.

Now if you want to do something that requires a newest stable version of CMake, that doesn't impede us, or really anybody because CMake is so portable and easy to get, even in legacy environment.

[mpusz]

Thanks for your "attempt to use this library" and being "the only person to attempt to actually stick with it" :-D You convinced me with tour answer. Thanks again!