Re: simple useful functions

[Tak Ota <Takaaki.Ota@am.sony.com>]

Fri, 3 Dec 2010 20:36:09 -0800: Stefan Monnier <monnier@IRO.UMontreal.CA> wrote:

> >> - I fail to see in which circumstance(s) this is useful.
> > OK, I see this may not be useful for everybody.
> 
> That's not necessarily a problem, tho.  Most packages in Emacs are not
> useful for everybody, after all.  Still, it needs to be useful to more
> than a handful; and, more importantly, it should provide a clear
> functionality in a "generic" way (this is what is likely to make it
> useful to more than a handful of users).
> 
> > The reason I wrote this command was to support embedded software
> > development.  In embedded development work we are usually required to
> > use some cross compilation tools.  Such tools often come with a setup
> > script which includes setting up necessary environment variables for
> > command paths and library paths.

I understand.

> IIUC these scripts are written for /bin/sh, right?  How do (t)csh users
> handle that?
> [ Sorry, I'm not that familiar with cross-compiling: OpenWRT is about
>   as far as I got into this, and it "takes care of things" in ways
>   I haven't tried to understand.  They don't use such setup scripts, at
>   least in a user-visible way (although the user does perform the
>   cross-compiling).  ]

Those scripts are written for the shell the tool provider intends user
to use.  The shell to use is not always our choice.

> > In order to compile software in this environment from Emacs I need to
> > start Emacs from the shell that has run the script.  But to me Emacs
> > is not a text editor but a working environment.
> 
> I partly understand the context.  But right here I think your script
> fails to serve you: it uses `setenv' which affects all inferior
> processes, so if you're working on several projects at the same time
> from the same Emacs session (likely if you're using it as a work
> environment, which is also the intended use to a large extent), you get
> pollution from one project to the other.  I think this issue is
> important, and I suspect that figuring out how it should be solved is
> necessary to figure out what is a good/generic way to provide this
> "source" feature.

This is a good point.  I am contaminating the whole emacs.  It made me
review compile.el and I learned the existence of
compilation-environment which I think is more appropriate than
`setenv' function.


(defun source (script &optional shell keep-current-directory)
  "Source the specified shell script and set `compilation-environment'.
Source the shell SCRIPT and import the environment into
`compilation-environment'.  The optional SHELL specifies the
shell other than the default `shell-file-name'.  When
KEEP-CURRENT-DIRECTORY is nil, which is the default, the current
directory is temporarily changed to the directory where the
script resides while sourcing the it."
  (interactive "fscript file: ")
  (if (null shell)
      (setq shell shell-file-name))
  (with-temp-buffer
    (unless keep-current-directory
      (setq default-directory (file-name-directory script)))
    (call-process shell nil t nil "-c" (concat ". " (shell-quote-argument script) "; printenv"))
    (setq compilation-environment
	  (split-string
	   (buffer-substring-no-properties (point-min) (point-max))
	   "\n"))))