bug#10693: guild compile --load-path value is not processed with scm_parse_path, GUILE_LOAD_PATH env variable value is parsed.

[Ian Hulin <ian@hulin.org.uk>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

(Copy of reply sent to Mark alone by mistake)
Hi Mark
On 02/02/12 05:05, Mark H Weaver wrote:
> Hi Ian,
> 
> Ian Hulin <ian@hulin.org.uk> writes:
>> ian@nanny-ogg ~/src/lilypond (T2026-1)>> guild compile 
>> --load-path="/home/ian/src/lilypond:/home/ian/src/lilypond/scm"
> 
> According to both the Guile manual and the output of "guile compile
> -h":
> 
> -L, --load-path=DIR   add DIR to the front of the module load path
> 
> In other words, it behaves as documented.  The idea is that you
> should pass multiple --load-path options, one for each DIR.
> 
> Having said this, one could reasonably argue that the long option
> name is misleading, and I tend to agree.  On the other hand, the
> current behavior has the advantage of allowing _any_ directory to
> be added, even if its name contains a colon, and thus allows the
> creation of more robust code.
> 
> We might want to change the long option name (while continuing to
> accept --load-path for backward compatibility), but I can't think
> of a good name.  Any suggestions?
> 
- --add-to-load-path, then it matches the new procedure/macro that does
the same thing?

Note too that the guile command line does not have a long option name
for -L.

Also, how about documenting somewhere the difference in behaviour
between setting the environment variable and using the long option name.

Thanks very much for pointing out the bear-traps, Mark.

Cheers,

Ian

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPKvkhAAoJEBqidDirZqAShiUIAJEy0qTxa9nfOTsidTG5DGmM
CM0rvAOUPoBii39nUNX/vkpBtTPWRLerY7QhTVPNMNbu7T7+rify12KwDxYaz/bM
8CDXYzYD7ypTiBHYlJ4ZJaGPt+CZs7PR9JobtaGT3AuRx8S4iGRGEL6x0G2hByiy
M7sEHkxU8D1FGgavTFxvWI9MLypde44xcjagv6Da3ATUD3nYO4HRDVSAMp9g1cmy
6dAGDtzEccbzlYfRtb126MtskAqD4Z9Fl/zfFIhN06CLXyJBi1xS+WL3F5EwI0lv
evAN5VXwb1xkVaHFkjM1xaM4ny2BFAJEkJeBx7KTTqQJNWrplVBPJGUyzJWM7QU=
=YiMF
-----END PGP SIGNATURE-----