-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MSVC compatibility #963
Comments
Hi, I think I would not like to add some code which "tries" to find some binary based on some heuristic like using System;
using System.Runtime.InteropServices;
namespace Gio;
public static class Module
{
private static bool IsInitialized;
private static DllImportResolver? CustomDllImportResolver;
/// <summary>
/// Initialize the <c>Gio</c> module.
/// </summary>
/// <remarks>
/// <para>
/// Calling this method is necessary to correctly initialize the bindings
/// and should be done before using anything else in the <see cref="Gio" />
/// namespace.
/// </para>
/// <para>
/// Calling this method will also initialize the modules this module
/// depends on:
/// </para>
/// <list type="table">
/// <item><description><see cref="GObject.Module" /></description></item>
/// </list>
/// </remarks>
public static void Initialize()
{
if (IsInitialized)
return;
GObject.Module.Initialize();
NativeLibrary.SetDllImportResolver(typeof(Module).Assembly, CustomDllImportResolver ?? Internal.ImportResolver.Resolve);
Internal.TypeRegistration.RegisterTypes();
IsInitialized = true;
}
/// <summary>
/// Set a custom DllImportResolver. This disables the automatic loading of native binaries for
/// Gio. If the given DllImportResolver receives the library name "Gio" it has to return a pointer
/// to the desired native Gio binary.
/// </summary>
/// <remarks>This method must be called before any application is created and Module.Initialize is called.</remarks>
/// <param name="customDllImportResolver">Custom DllImportResolver to use.</param>
public static void SetCustomDllImportResolver(DllImportResolver customDllImportResolver)
{
if (IsInitialized)
throw new Exception("Can't set a custom DllImportResolver after initialization is done");
CustomDllImportResolver = customDllImportResolver;
}
} As there is a May I ask where you get your binaries from and why you use them over the MSYS2 ones? @cameronwhite do you have some thoughts on this? |
Yeah I think we probably need some more info on what the naming conventions are for these libraries. Maybe the substring is being used to a strip a "lib" prefix or something like that? |
I'm building them with gvsbuild just because is the recommended by gtk4-rs wich I'm already using
Meson doc says about
|
Could you give the concrete name of the created GTK binary / DLL? If you already build GTK yourself you probably build its dependencies, too? In this case you could consider building your own set of GirCore binaries which match exactly your self compiled binaries. The instructions are in the readme. You would probably only need to update the gir files to the ones created by your build. The correct binary name would then be taken automatically from your own gir file. |
This is the output of ls -R in the build output directory Filtering dlls:
I'll give it a try |
I think we should try to support this if it's not too much effort, that way the default Nuget packages are usable with either the MSVC or GNU (msys) toolchain rather than requiring MSYS GtkSharp seems like it had some handling for this: https://github.com/GtkSharp/GtkSharp/blob/develop/Source/Libs/Shared/GLibrary.cs#L23 |
I don't want to hardcode some library names like in GTK sharp. I'm fine with adding some hook to allow to exchange the library loading like shown above. But using this method would mean leaving any supported terrain as it means hooking the bindings up to some binary nobody knows which version it is or how it got compiled and so on. I think it is a bad idea to allow this to happen automatically. If using msvc means building GTK manually I would even strongly recommend building GirCore manually, too, to keep both in sync. This allows to benefit from GirCore improvements without the need to update to newer GTK versions. |
My build wasn't generating gir files so I modified them manually and all works. The problem now is that it's not multiplatform |
Yeah the distribution of software is a bit tricky. Currently there is no support from GirCore as no C binaries are distributed. I'm not even sure of the current distribution model is going to stay or if there will be platform dependent nugets some day as the sources of the different platforms move at different speeds. It gets even more complicated if you mix custom builds in the mix. If you are planing to create some enterprise application please be aware that this is not recommended currently due to the early state of the code. Meaning there are currently no api stability guarantees. If you don't plan to distribute your application as a flatpak you can even have different library versions depending on your operating system. In this case it could be better to create custom GirCore binaries for your distribution. The distribution usually ship the Gir files in some package. Otherwise you risk using some binaries which are older than the ones the bindings were build for. If you use some unavailable api the program will crash at runtime. So to have a stable program it makes sense to have some set of APIs you know will be there:
Which platforms do you want to support? How do you do this using the rust bindings? Because there you would have the same problem. The bindings need to match the available versions of GTK, GObject, etc which can vary widely depending on your environment. |
Most apps I do are for internal use, and we have a very limited OS versions. When I use gtk-rs I build a different version for windows, and ship the gtklibs with it. Probably the difference here is that is the linker at buildtime who finds them, not at runtime. Edit: Sorry. It really is multiplatform since Linux girs are untouched. It's working perfectly Also had to modify |
Yep. The nuget packages create the illusion that it should "just work". But they are build for certain versions of the libraries and this must be kept in mind. I hope that we could help solving your immediate problem / question? |
Would be nice to be able to import GTK libs built with gvsbuild.
Would it be possible modifying Resolve in ImportResover with something like this?
Or
The text was updated successfully, but these errors were encountered: