Overall, I think the correct action is to set aside this silent-rules wild-goose-chase.
On Mon, Jul 23, 2012 at 7:26 PM, Stefano Lattarini <stefano.lattar...@gmail.com> wrote: > On 07/23/2012 10:29 AM, Jack Kelly wrote: >> On Tue, Jul 17, 2012 at 7:04 PM, Stefano Lattarini >> <stefano.lattar...@gmail.com> wrote: >>> Maybe we could try to write to the Emacs list for help at this point... >> >> I wrote the emacs list, and they pointed me to the NOMESSAGE argument >> for (load). Unfortunately the rabbit hole goes deeper... >> >> Emacs defines a variable, site-run-file, that is meant to be the >> "first" thing loaded, before .emacs and before default.el. We can get >> at that, but not with -Q. An autoconf check seems the correct approach >> here (as part of AM_PATH_LISPDIR), running something like: >> >> $(EMACS) -batch --eval "(princ site-run-file)" 2>/dev/null >> > OK, so far sounds simple and sensible. > >> (Is the redirect to /dev/null safe for DJGPP and/or MSYS?) >> > For MSYS, yes. For DJGPP, I think so (/dev/null redirections are used > throughout the Automake codebase, and nobody has ever complained about > them), bot honestly I don't deeply care: DJGPP should be considered > obsolete anyway. > >> Because debian has to do things their own way, (I'm sure they have >> their reasons), the initialisation process on debian systems is a >> little more complicated than just running the site-run-file: >> http://stackoverflow.com/q/189291/429232 >> > Ouch. > >> >> Therefore, we can check if it's a debianised emacs with something like: >> >> $(EMACS) -batch --eval "(unless (boundp 'debian-emacs-flavor) (kill-emacs >> 1))" >> >> And we can get the actual flavour with this: >> >> $(EMACS) -batch -eval "(princ debian-emacs-flavor)" 2>/dev/null >> >> It is fairly easy to advise (load) so that it's always loading silently: >> >> (defadvice 'load ('before 'silently) (ad-set-arg 2 t)) >> (ad-activate 'load) >> >> Then the next step is to emulate the normal startup, which would be >> something like: >> >> (let ((debian-emacs-flavor (quote $flavor)) (site-run-file \"$sitefile\")) >> (when (debian-emacs-flavor) >> (load \"debian-startup\") >> (debian-startup debian-emacs-flavor)) >> (load site-run-file)) >> > > Yikes :-( > > I strongly fear this poking in Debian internals is too fragile w.r.t. > forward compatibility. I'd rather avoid further debacles like the > install-info one: > > <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=213524> > <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9773> > >> At this point, we're well beyond what's sensible for a makefile >> snippet, so we should really move it all into a .el file that lives in >> $auxdir or a shell script with the elisp embedded. Do you have a >> preference? I suppose a .el file saves an extra fork per .el file, >> > My preference thus go to a '.el' file that lives in $auxdir. But first > I'd have to be convinced that catering to the Debian setup is actually > a good move. That won't be easy ;-) > > OK, let's take a step back. > > Are we sure that Emacs doesn't offer any way to pass "early" code fragments > to be eval'd before anything else not in the Emacs core is read or executed? > That would be great, and allow us to implement a much simpler and more > portable workaround. I don't think so. before-init-hook looked promising, but you can't add to that hook until after command-line options are parsed and dealt with (too late). "The only way to change it with real effect is before dumping Emacs." ( http://www.gnu.org/software/emacs/manual/html_node/elisp/Init-File.html ). Dumping an updated emacs into $builddir seemed promising, but calling (dump-emacs "newmacs" "/usr/bin/emacs") is just causing segfaults on my machine. > Even better: maybe Emacs offers an environment variable that could be used > to control the verbosity of (load), and maybe of other functions as well? > Something akin to PYTHONVERBOSE for python: > <http://docs.python.org/release/3.1.5/using/cmdline.html#envvar-PYTHONVERBOSE> > > If this is not the case, could such a variable be added to future Emacs > version? This way, our elisp byte-compile rules would be kept simple, > with only the (IMHO minor) annoyance that silent rules wouldn't work very > well for them with "non recent" emacs versions. And this annoyance would > be automatically mitigated as the times goes by and non-very-recent Emacs > versions become first "older", then "old", and finally "ancient". I think the way to do this would be as an improvement to make batch mode more palatable in general. I think an environment variable or a change to default behaviour is the least-potentially-breaking solution. >> and >> I think there's sufficient command-line handling built into emacs that >> it shouldn't be too hard to write a compile.el or el-compile.el (do >> you have a name to suggest?). >> >> -- Jack > > Finally, an update on the status of the 'elisp-work' branch: I plan to > add support for '$(EMACSFLAGS)' and '$(AM_ELCFLAGS)' being automatically > passed to our emacs invocations, add a couple of new test cases, and > then merge the branch into 'master'. Since the lack of 'silent-rules' > support is not a regression, I don't want that to block the integration > of all the improvements done so far. This sounds sensible, apart from an apparent discrepancy: you've called one variable $(EMACSFLAGS) and the other $(AM_ELCFLAGS). Shouldn't they be either $(ELCFLAGS) and $(AM_ELCFLAGS) or $(EMACSFLAGS) and $(AM_EMACSFLAGS)? When testing, I think it needs to be tested with emacs and xemacs, and using something like autoconf (which has some .el files). -- Jack
