Message ID | cover.1706558199.git.vivien@planete-kraus.eu |
---|---|
Headers | show |
Series | Wrap gnome-shell-extensions with gobject-introspection in native-inputs | expand |
Am Montag, dem 29.01.2024 um 20:56 +0100 schrieb Vivien Kraus: > Dear guix, > > I think I made a mistake. gobject-introspection should probably be in > native-inputs. We only use this package so that GI_TYPELIB_PATH is > set up at build time. Gjs probably has all the girepository > infrastructure it needs already. > > What do you think? Note: if you set GI_TYPELIB_PATH at build time, you could get confusions between build/host libs. It's unlikely, but you might want to make sure that your paths are sound. Anyhow, this series mostly LGTM on first glance. Does this issue also affect the extensions already pushed? Cheers
Le lundi 29 janvier 2024 à 21:53 +0100, Liliana Marie Prikler a écrit : > Am Montag, dem 29.01.2024 um 20:56 +0100 schrieb Vivien Kraus: > > Dear guix, > > > > I think I made a mistake. gobject-introspection should probably be > > in native-inputs. We only use this package so that GI_TYPELIB_PATH > > is set up at build time. Gjs probably has all the girepository > > infrastructure it needs already. > > > > What do you think? > Note: if you set GI_TYPELIB_PATH at build time, you could get > confusions between build/host libs. It's unlikely, but you might > want > to make sure that your paths are sound. Is there a solution for this? As far as I understand, GI_TYPELIB_PATH at build time has a mix of native inputs and inputs + propagated inputs, and we only want the latter. If I understand correctly, we can’t use search-input-directory because it would be from only 1 package. > Does this issue also affect the extensions already pushed? Other shell extension wrap their code for GI_TYPELIB_PATH, by getting the environment variable value at build time. Vivien