"pelzflorian (Florian Pelz)" <pelzflor...@pelzflorian.de> writes:
> Hi 宋文武. > > Help me understand. What you are inventing here is search path > configuration files as a preferred alternative to environment > variables. > [...] > Also because it does not propagate, it will not have duplicate > entries. Yes, exactlly. > When we do need to propagate to child processes, e.g. when environment > variables should apply to launching plug-ins in child processes, we > can still wrap-program as before? Not sure if such might be needed in > gnome-builder. Yes, wrap-program can still be used if needed. > Does this mean we can no longer refer to a 'glib-or-gtk-wrap phase? > Judging from Maxim’s comment <https://issues.guix.gnu.org/75688#34>, > >> In its current form, this phase should be renamed >> 'write-search-path-files' or similar; we could introduce a deprecated >> symbol for wrap-all-programs for backward compatibility. > > we would rename the phase. > Which is possible, but might impact third-party channels. No more: > > (arguments > (list #:phases > #~(modify-phases %standard-phases > (add-after 'glib-or-gtk-wrap 'wrap-binaries > […] > I think the glib-or-gtk-wrap symbol and phase can be keeped for fallback, it will do nothing when a previous write-search-path-files phase did the work, or will do what it currently does when write-search-paths-files does nothing (not ELF executables or Python scripts). Thanks.
