[irods/irods#6251,irods/irods#6256] find_package for fmt and spdlog

[SwooshyCueb]

In service of irods/irods#6251
In service of irods/irods#6256

Once this is merged, a 4-3-stable branch should be created.

[korydraughn]

Pound it.

[SwooshyCueb]

#'d

[alanking]

Created 4-3-stable branch based on 78ef388.

We may need to create a branch for development against 4.3.1's build system (thinking about the open PRs and possible other development work going on). Thoughts?

[korydraughn]

@alanking I'm assuming that's because the externals are changing?

@SwooshyCueb Do these changes depend on new externals packages? Are those new externals packages incompatible with 4.3.1?

[SwooshyCueb]

Do these changes depend on new externals packages?

Not these. The changes in #256 and #257 do though.

Are those new externals packages incompatible with 4.3.1?

Yes. All externals explicitly built against libc++ have moved into different subfolders, clang and clang-runtime have updated, and spdlog now has a shared library.

[korydraughn]

I see. So once #256 and #257 are merged, we'll have to consider whether we want a branch for 4.3.1 development.

Got it.

[alanking]

Right, just depends on whether we are okay with releasing while building against unreleased dev and/or runtime packages (if I'm understanding everything correctly). This is pre-1.0, so... maybe okay?

[alanking]

Y'know what, it doesn't really matter. I think I got confused and assumed the fmt find module was something we made. Carry on.

[korydraughn]

I just confirmed tip of main for this repo no longer compiles with 4.3.1 packages and that's fine.

We can create a new branch for 4.3.1 development when that time comes. The SHA to branch from is 0720f71 (according to @SwooshyCueb).

[korydraughn]

Thinking about it more, let's go ahead and create a branch for 4.3.1 development.

@MartinFlores751's OIDC work will need to be available for 4.3.1 once it's complete.