After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 572916 - Make the gnome-shell script work without needing "jhbuild run"
Make the gnome-shell script work without needing "jhbuild run"
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
: 573024 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-02-23 22:26 UTC by Dan Winship
Modified: 2009-02-25 19:39 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Make the gnome-shell script work without needing "jhbuild run" (19.91 KB, patch)
2009-02-23 22:26 UTC, Dan Winship
committed Details | Review

Description Dan Winship 2009-02-23 22:26:12 UTC
This makes the gnome-shell script set up the things it currently needs
jhbuild to set up for it: the PATH, so it can find the right metacity
binary, and the gjs load path, so it can find the builtin gjs modules.

(It also fixes the fact that we look for Meta-2.25.gir in gnome-shell's
own libdir rather than in metacity-clutter's libdir. We should have
metacity-clutter export the exact location of its gir file; that will be
fixed later.)

Not totally sure about the hack to make src/gnome-shell executable...

I seem to have thwarted git's rename detection (possibly due to changing
the permission bits on the files?), but the only change between the old
gnome-shell and the new gnome-shell.in is in the env.update() call in
start_shell().
Comment 1 Dan Winship 2009-02-23 22:26:16 UTC
Created attachment 129374 [details] [review]
Make the gnome-shell script work without needing "jhbuild run"
Comment 2 Dan Winship 2009-02-24 20:59:42 UTC
*** Bug 573024 has been marked as a duplicate of this bug. ***
Comment 3 Owen Taylor 2009-02-24 22:34:42 UTC
What about all the other envvars that jhbuild sets up. Grepping my environment. 

Most relevant:
LD_LIBRARY_PATH=/home/otaylor/gnome-shell/install/lib
XDG_CONFIG_DIRS=/home/otaylor/gnome-shell/install/etc/xdg:/etc/xdg
XDG_DATA_DIRS=/home/otaylor/gnome-shell/install/share:/usr/share

Compile time only:
CPLUS_INCLUDE_PATH=/home/otaylor/gnome-shell/install/include
LDFLAGS=-L/home/otaylor/gnome-shell/install/lib 
C_INCLUDE_PATH=/home/otaylor/gnome-shell/install/include
ACLOCAL_FLAGS=-I /home/otaylor/gnome-shell/install/share/aclocal
PKG_CONFIG_PATH=/home/otaylor/gnome-shell/install/lib/pkgconfig:/home/otaylor/gnome-shell/install/share/pkgconfig:/usr/share/pkgconfig:/usr/lib/pkgconfig
INSTALL=/home/otaylor/bin/install-check

Just annoying:
MANPATH=/home/otaylor/gnome-shell/install/share/man

Not really relevant:
PERL5LIB=/home/otaylor/gnome-shell/install/lib/perl5
MONO_GAC_PREFIX=/home/otaylor/gnome-shell/install
MONO_PREFIX=/home/otaylor/gnome-shell/install
PYTHONPATH=/home/otaylor/gnome-shell/install/lib/python2.5/site-packages

???:
DYLD_FALLBACK_LIBRARY_PATH=/home/otaylor/gnome-shell/install/lib
Comment 4 Dan Winship 2009-02-24 22:53:53 UTC
(In reply to comment #3)
> What about all the other envvars that jhbuild sets up.

gnome-shell doesn't need any of them, so...

(If LD_LIBRARY_PATH matters, that's a bug. The compile-time-only stuff doesn't matter. (If the user wants to compile from within gnome-shell, they can use jhbuild, just like they would when compiling from outside gnome-shell.) MANPATH is, as you say, annoying, because it overrides rather than appending (and we're not installing any interesting non-compile-time man pages anyway). The not really relevant stuff is not really relevant. DYLD_FALLBACK_LIBRARY_PATH is an OS X thing.)

That leaves the XDG vars as the only ones we might plausibly need, but we don't appear to need them either (as long as we set the gjs search path by hand, which we do).

Comment 5 Owen Taylor 2009-02-24 22:58:00 UTC
Are you asssuming that libtool is going to do magic so we end up with a rpath to libclutter, etc?
Comment 6 Dan Winship 2009-02-25 13:55:29 UTC
(In reply to comment #5)
> Are you asssuming that libtool is going to do magic so we end up with a rpath
> to libclutter, etc?

Yes. (It does on Fedora anyway.) But I could add LD_LIBRARY_PATH back if you're worried. Or we could see if people complain. It would basically completely fail if the rpath wasn't set, so it would be pretty obvious.
Comment 7 Owen Taylor 2009-02-25 18:32:54 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > Are you asssuming that libtool is going to do magic so we end up with a rpath
> > to libclutter, etc?
> 
> Yes. (It does on Fedora anyway.) But I could add LD_LIBRARY_PATH back if you're
> worried. Or we could see if people complain. It would basically completely fail
> if the rpath wasn't set, so it would be pretty obvious.

Well, someone *could* have system gjs/girepository/clutter-0.9, but probably unlikely for now.

We can certainly wait until problems show up.

Patch looks good to me.


Comment 8 Dan Winship 2009-02-25 19:39:43 UTC
committed. (will update wiki again)