This part won't work good on Windows if the model_cache_dir contains non-ASCII chars.
First, in your code you need to put a comment to clarify the encoding of mgx_state->model_cache_dir. Is it ANSI encoding(that maps to a Windows codepage) or UTF-8?
Usually, most multibyte strings in ORT are UTF-8 strings. Then please convert the string to a wide string and do all the concatenation/modification in UTF-16.
On Linux all these strings should be UTF-8.

Should all be UTF-8 I assume. We shouldn't be using non ascii characters here.

Not that simple. You need to carefully examine the code. Add a comment to the definition of the variable.

better to follow this guideline: https://abseil.io/tips/168 You may directly use std::string_view instead of absl::string_view since we have C++17.
Or, I think you need to declare them as inline static constexpr const char*.

wouldn't that be covered by the auto here though? We're enforcing style checks that aren't in the liner?

Just want some clarity on this.

Actually, auto is discouraged to use except in the cases where the type is very obvious to see. https://google.github.io/styleguide/cppguide.html#Type_deduction
"Use type deduction only if it makes the code clearer to readers who aren't familiar with the project, or if it makes the code safer. Do not use it merely to avoid the inconvenience of writing an explicit type."

I think there it is not that obvious. The keyword inline is needed.

Sure but again, why is this style comment not part of your linter profile checks then? This isn't a technical comment but style and if you want to enforce that, make it part of your lint runner checks/lint stage.

While you are welcomed to use std::filesystem::path, every time when you assign a value to this type you need carefully check the source string's encoding.
On Windows we expect the source string is in native code page encoding. Otherwise if the string is encoded as UTF-8 you must manually convert it to std::wstring before assign it to a path.
Or you may change type of model_cache_dir to const ORTCHAR_T*.

Odd, these came from windows side changes and we haven't seen this effecting our runs.

So, if you have a std::wstring or ORT_CHART* string, you have no problem. Otherwise try to explicitly state the encoding. Otherwise people will assume the string is a UTF-8 string.

On Windows You should never assign a UTF-8 string to a std::filesystem::path.

Make the type explicit, and check the encoding.

Why?

I just checked, onnxruntime::GetEnvironmentVar returns an ANSI string, not a UTF-8 string. As you are define a new var, it's better to state it there this string is not a UTF-8 string(while most std::string variables are).

Remove the const

Same as the above. Consider using std::string_view instead.

Remove the const.

.string().c_str() returns a temporary pointer I believe. You need to store the result of internal_options.model_cache_dir.string() at somewhere.

Try to see if std::filesystem has a function for doing so. Then you will not need to use the low level Windows APIs.

Always use wide Windows APIs when possible.

Should this be split between windows/linux builds then around #ifdefs?

I mean when a Windows API has an ANSI version and Wide version, you need to use the Wide version.
The buffer here should be std::wstring.

This change usually is not needed. Usually it prefers the folder of the executable module that LoadLibraryEx is loading

See: https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order#alternate-search-order-for-unpackaged-apps

The change is required for AMD MIGraphX, not for the MIGraphX Execution Provider. The MIGraphX DLL loads the target DLLs (i.e., MIGraphX GPU target) at runtime. It does not use an absolute path and expects the target DLLs to be in the same directory as the MIGraphX DLL.

For example, we bundle MIGraphX binaries with MIGraphX EP Python WHL. Without this change, the MIGraphX does not know where to look for the GPU target. For Python, the executable working path is usually the location of a Python script or the Python executable.

So there is something wrong with the LoadLibrary calls

For Python, the executable working path is usually the location of a Python script or the Python executable.

It's not about working dir. It's more about DLL search order. We should never search that directory.