Add the ability to supply multiple library paths in SearchPathContainer

[Beyley]

Summary of the PR

Closes #1333
Allows passing multiple library paths to CreateDefaultContext, and add multiple library path support into SearchPathContainer

Related issues, Discord discussions, or proposals

Links go here.

Further Comments

This also brings into consideration the possibility cleaning up of places such as OpenAL, so that it tries the native OpenAL, then later tries OpenAL-soft, instead of the "choose one or the other" that we have now,
@Perksey should the AL.GetApi(bool) be deprecated with ObsoleteAttribute and the new non-deprecated behaviour be Native Platform -> Soft?

[Khitiara]

re: openal id like the ability to choose to prioritize soft but its not a huge deal

[Beyley]

re: openal id like the ability to choose to prioritize soft but its not a huge deal

perhaps it should be changed to "prioritize" instead of "only soft" or "only native", true means prefer soft, then try native, false means prefer native, then try soft

[Perksey]

I agree with this, prioritise makes sense.

[HurricanKai]

I don't think overrides should be activated whenever the list contains something.

I don't have all the info on this, but in my mind in there the candidate to search for should've already been decided and simply loaded, with some logic higher up iterating through the array and finding the first functional candidate.

I think it's reasonable to account for a situation where one possible candidate is __Internal which needs the override, but another candidate can simply use the normal logic and should not also trigger the override.

I'm also not sure what happens it a candidate not ment to hit an override ends up in the override branch. They do all sorts of casting insanity to be efficient and trick the JIT into accepting invariants that are not immediately obvious otherwise. Breaking those might cause all sorts of bugs that I can't foresee anymore.

[Beyley]

I don't think overrides should be activated whenever the list contains something.

I don't have all the info on this, but in my mind in there the candidate to search for should've already been decided and simply loaded, with some logic higher up iterating through the array and finding the first functional candidate.

I think it's reasonable to account for a situation where one possible candidate is __Internal which needs the override, but another candidate can simply use the normal logic and should not also trigger the override.

I'm also not sure what happens it a candidate not ment to hit an override ends up in the override branch. They do all sorts of casting insanity to be efficient and trick the JIT into accepting invariants that are not immediately obvious otherwise. Breaking those might cause all sorts of bugs that I can't foresee anymore.

ah yeah i completely blanked on the override problem, thats an interesting one to solve hmm

[Beyley]

@Perksey do we just not allow multiple libnames on platforms with P/Invoke overrides? i cant think of a way this can really be done cleanly, unless we want to try all libnames as dynamically loaded using our dynamic loader first, and if that fails, then use the P/Invoke override, unless it is possible that the P/Invoke override may be detected as being able to be dynamically loaded, but shouldnt be for x or y reason

[Perksey]

I recommend:

• Adding a static function in DefaultNativeContext called TryCreate. You will probably need to do the same in UnmanagedLibrary and probably something in LibraryLoader as well. The goal here is to make a code path that does not throw when failing to load.
• Iterating through each item in the names array
• Attempting to load each item using the same logic as in CreateDefaultContext today (but using the new non-throwing method), and moving onto the next candidate if this fails.

This way the priority is still respected.

[HurricanKai]

I agree with perksey. Attempting different candidates and deciding which ones to use should be done at a higher level then overrides.

[Beyley]

I recommend:

* Adding a static function in DefaultNativeContext called TryCreate. You will probably need to do the same in UnmanagedLibrary and probably something in LibraryLoader as well. The goal here is to make a code path that does not throw when failing to load.

* Iterating through each item in the names array

* Attempting to load each item using the same logic as in CreateDefaultContext today (but using the new non-throwing method), and moving onto the next candidate if this fails.

This way the priority is still respected.

This has now been implemented, with the codegen of

        [System.ObsoleteAttribute("This function is obsolete! Please use the string[] overload!")]
        public static INativeContext CreateDefaultContext(string n)
        {
            if (n == "libSDL2.so")
                return new OVERRIDE_1();
            else if (n == "__Internal")
                return new OVERRIDE_0();
            else
                return new Silk.NET.Core.Contexts.DefaultNativeContext(n);
        }

        public static INativeContext CreateDefaultContext(string[] n)
        {
            foreach (string name in n)
            {
                if (name == "libSDL2.so")
                    return new OVERRIDE_1();
                else if (name == "__Internal")
                    return new OVERRIDE_0();
                else if (Silk.NET.Core.Contexts.DefaultNativeContext.TryCreate(name, out DefaultNativeContext context))
                    return context;
            }

            throw new System.IO.FileNotFoundException("Could not load from any of the possible library names! Please make sure that the library is installed and in the right place!");
        }

[Perksey]

Perfect, thank you!