Error when using multiple gi-crystal shards
wildeyedskies opened this issue · 13 comments
When requiring both libadwaita and gtk4 this happens:
In lib/libshumate/lib/gi-crystal/src/auto/g_lib-2.0/lib_g_lib.cr:5:8
5 | type AsciiType = UInt32
^
Error: AsciiType is already defined
This also happened when I tried to generate my own bindings for libshumate. I'm not sure if this is a bug or if I'm just using the generator wrong. Is there something I need to do to make sure I'm not importing 2 copies of the base gobject stuff?
gtk4 is automatically required when you require libadwaita, you don't need to do it manually.
Is the repository for your binding public? so I can try it and see if something is wrong?
Sorry for the delay to answer, end of year, you know :-)
So what seems to happen is that if you require multiple libraries that require gi-crystal, you get conflicts.
What ended up working was generating the additional bindings within the main application and requiring the generated bindings from within the lib/libadwaita directory.
This technically works, but I'd ideally like to have seperate shards for my other bindings.
The project is here
https://gitlab.gnome.org/wildeyedskies/wince/-/blob/main/src/wince.cr
Happy new year!
I tried to reproduce this issue in the here: 465d330 but without success. I created another lib and did run the generator twice, one for each library... but the error didn't happen.
If you could modify this branch to reproduce the issue would be great.
The issue isn't caused by having GICrystal build to libraries, it's caused by having multiple dependencies that make use of GICrystal. The error is reproduced in my project on the broken-gi-crystal
https://gitlab.gnome.org/wildeyedskies/wince/-/blob/broken-gi-crystal/src/wince.cr
Here you can see I try to import libadwaita and then geoclue and libshumate directly from gi-crystal. This fails with the error shown above.
The main branch shows the fix I have which is to import everything via the libadwaita directory. While it does work, it makes it difficult to package and import multiple bindings into one project.
https://gitlab.gnome.org/wildeyedskies/wince/-/blob/main/src/wince.cr
I'm able to reproduce the bug, could you please keep this branch broken-gi-crystal alive in the repository until I have time to fix this bug?
BTW, the right way to require modules is by using GICrystal.require, e.g.
GICrystal.require("Geoclue", "2.0")
GICrystal.require("Shumate", "1.0")However the bug persists even using it on your code.
The issue is caused by the lib symbolic link created by shards.
So when libadwaita requires the generated bindings it requires the file:
lib/libadwaita/lib/src/gi-crystal/src/auto/... since the GICrystal.require macro expands in a file in lib/libadwaita/ directory.
When you require your bindings in your project it require the files in the right place... so for the compiler there are two bindings for g-lib:
lib/gi-crystal/src/auto/g_liblib/libadwaita/lib/gi-crystal/src/auto/g_lib
Even they being the same file in the OS.
Ok, we know what causes the issue, now we need to think about how to fix it 😅
The first solution that comes to my mind is to just check if the ../lib is a symlink, if so, use ../../ instead of ../lib. However there's no macro method to check if a file is a symlink, so this would need to be made by a run macro.
I'll wait a bit before fix using this solution to see if something better comes to my mind.
The fix was way easier than I expected... could you double check if it worked? (I tested here with your repository and it worked) Maybe using a shard.override.yml file pointing gi-crystal to issue-70 branch.
Woah sweet, thank you for fixing this. I'll test it soon
i tried the fix for an identical problem with gtk3 + atspi, and it worked great with this change :)
Confirmed that the fix works for my project!