Use `gsr` without `make install`

[Christoph Dorn]

Is it possible to link the built `gsr` into the $PATH without running
`make install`?

`make install` generates the following:

* Creating target directories
cp -f /pinf/platforms/gpsee/gpsee/spidermonkey/builds/release/jsapi/
lib/libmozjs.dylib /opt/local/gpsee/lib/libmozjs.dylib
install_name_tool -id /opt/local/gpsee/lib/libmozjs.dylib /opt/local/
gpsee/lib/libmozjs.dylib
cp -f -rp /pinf/platforms/gpsee/gpsee/spidermonkey/builds/release/
jsapi/include /opt/local/gpsee
cp -f -rp /pinf/platforms/gpsee/gpsee/libffi/builds/release/install/
lib /opt/local/gpsee
gcc -dynamiclib -undefined dynamic_lookup -L/pinf/platforms/gpsee/
gpsee -L/pinf/platforms/gpsee/gpsee/spidermonkey/builds/release/jsapi/
lib -L/opt/local/gpsee/lib /opt/local/gpsee/lib/libmozjs.dylib -
lplds4 -lplc4 -lnspr4 -lm -L/opt/local/gpsee/lib -L/opt/local/lib/nspr
-L/opt/local/lib -o /opt/local/gpsee/lib/libgpsee.dylib gpsee.o
gpsee_unix.o gpsee_lock.o gpsee_flock.o gpsee_util.o gpsee_modules.o
gpsee_compile.o gpsee_context_private.o gpsee_xdrfile.o
gpsee_hookable_io.o gpsee_datastores.o gpsee_monitors.o gpsee_realms.o
gpsee_gccallbacks.o gpsee_bytethings.o gpsee_p2open.o modules/gpsee/
gpsee.a modules/system/system.a modules/vm/vm.a version.o
gcc -L/pinf/platforms/gpsee/gpsee -L/pinf/platforms/gpsee/gpsee/
spidermonkey/builds/release/jsapi/lib -L/opt/local/gpsee/lib /opt/
local/gpsee/lib/libmozjs.dylib -lplds4 -lplc4 -lnspr4 -lm -L/opt/local/
gpsee/lib -L/opt/local/lib/nspr -L/opt/local/lib gsr.o version.o -
lgpsee -o /opt/local/gpsee/bin/gsr
gcc -L/pinf/platforms/gpsee/gpsee -L/pinf/platforms/gpsee/gpsee/
spidermonkey/builds/release/jsapi/lib -L/opt/local/gpsee/lib /opt/
local/gpsee/lib/libmozjs.dylib -lplds4 -lplc4 -lnspr4 -lm -L/opt/local/
gpsee/lib -L/opt/local/lib/nspr -L/opt/local/lib gpsee_precompiler.o -
lgpsee -o /opt/local/gpsee/bin/gpsee_precompiler
* Generating gpsee.pc
cp -f gpsee.pc /opt/local/gpsee/lib/pkgconfig/gpsee.pc
* Installing JavaScript module components
cp -f modules/binary/binary.js modules/fs-base/fs-base.js modules/gffi/
gffi.js modules/net/net.js modules/shellalike/shellalike.js modules/
syslog/syslog.js modules/util/util.js modules/xhr/xhr.js /opt/local/
gpsee/libexec
* Precompiling /opt/local/gpsee/libexec/binary.js
* Precompiling /opt/local/gpsee/libexec/fs-base.js
* Precompiling /opt/local/gpsee/libexec/gffi.js
* Precompiling /opt/local/gpsee/libexec/net.js
* Precompiling /opt/local/gpsee/libexec/shellalike.js
* Precompiling /opt/local/gpsee/libexec/syslog.js
* Precompiling /opt/local/gpsee/libexec/util.js
* Precompiling /opt/local/gpsee/libexec/xhr.js
[ -h "/usr/bin/gsr" ] || ln -s "/opt/local/gpsee/bin/gsr" "/usr/bin/
gsr"
cp -f gpsee-config /opt/local/gpsee/bin
cp -f modules/binary/binary.dylib modules/cgi/cgi.dylib modules/curses/
curses.dylib modules/gffi/gffi.dylib modules/shellalike/
shellalike.dylib modules/signal/signal.dylib modules/thread/
thread.dylib /opt/local/gpsee/libexec
cp -f gpsee.h gpsee-jsapi.h gpsee_config.h gpsee_lock.c gpsee_flock.h
gpsee_formats.h gpsee-iconv.h gpsee_version.h gpsee_unix.h /opt/local/
gpsee/include


Looks like a lot is done during the install process.

What I am seeking to do is build gsr and link it into $PATH without
installing anything anywhere else.

Should I be using --prefix to isolate the install into a sandbox
directory (if I cannot get around running `make install`)?

Thanks!
Christoph

[Wes Garland]

> What I am seeking to do is build gsr and link it into $PATH without
> installing anything anywhere else.

It would be possible to do this -- but I'm not sure the resultant binary would do you any good.

Reviewing quickly your post, what was installed was
 - SpiderMonkey
 - libgpsee.so
 - gsr
 - gpsee.pc  (package config info)
 - Modules that ship with GPSEE

Without SpiderMonkey we have no JavaScript, without libgpsee we have no GPSEE, without modules we can't require() anything that is not pure JS  (so, no fs-base, no binary/b, no system.stdout, etc).  

You could remove gpsee.pc from the build, but then any other programs (besides GSR) needing to use GPSEE would not be able to. It's only a couple hundred bytes anyhow.

I'm thinking that the gpsee_precompiler should be in your list, I'm not sure why I didn't see it in there.  You could eliminate that, but anybody building programs out of GSR is likely to miss it: ideally, gpsee_precompiler is used in the 3rd party apps "install phase" to compile JS->Bytecode.  Without this, it means that users executing scripts have to have permission to write to the scripts' directory in order to take advantage of pre-compiled bytecode, which would be a security problem in many types of installation.

Was there anything in particular you wanted to eliminate that I didn't address?

Wes

--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102

[Christoph Dorn]

> Was there anything in particular you wanted to eliminate that I didn't
> address?

I need multiple versions of gpsee on the same system and not have it
mess with the OS at all. So I presume using --prefix during configure
is the best solution to sandbox the install? Does that put everything
somewhere else or only the binary? I am not too familiar with --
prefix.

Christoph

[Jeff Johnson]

FYI: There's a flag in the AutoFu version of gpsee that will append a version
so that no paths collide.

"works" in RPM: not looked yet at gpsee but its easy fixing in the
top-level Makefile.

I'm distracted atm cross-compiling MeeGo for a panda board … will
eventually cycle back to gpsee+AutoFu.

73 de Jeff

[Christoph Dorn]

On Oct 3, 5:57 pm, Jeff Johnson <n3...@mac.com> wrote:
> FYI: There's a flag in the AutoFu version of gpsee that will append a version
> so that no paths collide.
>
> "works" in RPM: not looked yet at gpsee but its easy fixing in the
> top-level Makefile.

I can wait a bit, but would be nice to have eventually.

> I'm distracted atm cross-compiling MeeGo for a panda board … will
> eventually cycle back to gpsee+AutoFu.

Bug filed: http://code.google.com/p/gpsee/issues/detail?id=92

Christoph