* Re: Emacs-diffs Digest, Vol 49, Issue 33 [not found] <E1GsTlR-0003Kq-GG@monty-python.gnu.org> @ 2006-12-08 7:51 ` Eli Zaretskii 2006-12-08 11:33 ` Juanma Barranquero 0 siblings, 1 reply; 5+ messages in thread From: Eli Zaretskii @ 2006-12-08 7:51 UTC (permalink / raw) Cc: emacs-devel > Date: Thu, 07 Dec 2006 18:09:41 +0000 > From: Juanma Barranquero <lekktu@gmail.com> > Subject: [Emacs-diffs] Changes to emacs/lispref/makefile.w32-in,v > To: emacs-diffs@gnu.org > Message-ID: <E1GsNgj-0006Es-NG@savannah.gnu.org> > > CVSROOT: /cvsroot/emacs > Module name: emacs > Changes by: Juanma Barranquero <lektu> 06/12/07 18:09:41 > > Index: makefile.w32-in > =================================================================== > RCS file: /cvsroot/emacs/emacs/lispref/makefile.w32-in,v > retrieving revision 1.17 > retrieving revision 1.18 > diff -u -b -r1.17 -r1.18 > --- makefile.w32-in 30 Oct 2006 14:15:57 -0000 1.17 > +++ makefile.w32-in 7 Dec 2006 18:09:41 -0000 1.18 > @@ -119,5 +119,5 @@ > > distclean: clean > > -maintainer-clean: clean > - - $(DEL) elisp elisp-* elisp.dvi elisp.oaux > +maintainer-clean: distclean > + - $(DEL) elisp.dvi elisp.oaux > Why did you make this change? lispref/Makefile.in still removes the results of makeinfo, evidently to support a separate lispref packaging. Why shouldn't makefile.w32-in follow suit? ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Emacs-diffs Digest, Vol 49, Issue 33 2006-12-08 7:51 ` Emacs-diffs Digest, Vol 49, Issue 33 Eli Zaretskii @ 2006-12-08 11:33 ` Juanma Barranquero 2006-12-08 15:56 ` Eli Zaretskii 0 siblings, 1 reply; 5+ messages in thread From: Juanma Barranquero @ 2006-12-08 11:33 UTC (permalink / raw) Cc: emacs-devel On 12/8/06, Eli Zaretskii <eliz@gnu.org> wrote: > > -maintainer-clean: clean > > - - $(DEL) elisp elisp-* elisp.dvi elisp.oaux > > +maintainer-clean: distclean > > + - $(DEL) elisp.dvi elisp.oaux > Why did you make this change? lispref/Makefile.in still removes the > results of makeinfo, evidently to support a separate lispref > packaging. Why shouldn't makefile.w32-in follow suit? Maybe I've misunderstood lispref/Makefile.in. The motivation for my change is that, in my in-place installation, maintainer-clean (from lispref/Makefile.w32-in) was deleting elisp and elisp-* from lispref/, not info/, so it nuked elisp-cover.texi. maintainer-clean has clean as precondition, and clean already does: - $(DEL) $(infodir)/elisp* so, what's the difference? It is an issue for non-inplace installations? I can revert my patch, but then maintainer-clean will have to be changed to maintainer-clean: clean - $(DEL) $(infodir)/elisp $(infodir)/elisp-* elisp.dvi elisp.oaux unless I'm mistaken. /L/e/k/t/u ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Emacs-diffs Digest, Vol 49, Issue 33 2006-12-08 11:33 ` Juanma Barranquero @ 2006-12-08 15:56 ` Eli Zaretskii 2006-12-08 18:43 ` Stefan Monnier 2006-12-08 18:57 ` Juanma Barranquero 0 siblings, 2 replies; 5+ messages in thread From: Eli Zaretskii @ 2006-12-08 15:56 UTC (permalink / raw) Cc: emacs-devel > Date: Fri, 8 Dec 2006 12:33:04 +0100 > From: "Juanma Barranquero" <lekktu@gmail.com> > Cc: emacs-devel@gnu.org > > The motivation for my change is that, in my in-place installation, > maintainer-clean (from lispref/Makefile.w32-in) was deleting elisp > and elisp-* from lispref/, not info/, so it nuked elisp-cover.texi. To avoid nuking more than we want, we could replace elisp-* with something like "elisp-? elisp-??". > maintainer-clean has clean as precondition, and clean already does: > - $(DEL) $(infodir)/elisp* > > so, what's the difference? It is an issue for non-inplace installations? It is an issue for building the ELisp manual as a separate package, the way it was before we bundled it with Emacs. Then the Info files were generated in place, so maintainer-clean deleted them. > I can revert my patch, but then maintainer-clean will have to be changed to > > maintainer-clean: clean > - $(DEL) $(infodir)/elisp $(infodir)/elisp-* elisp.dvi elisp.oaux No, there's no need to remove $(infodir)/elisp-* more than once. Instead, I suggest to replace elisp-* with "elisp-? elisp-??". ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Emacs-diffs Digest, Vol 49, Issue 33 2006-12-08 15:56 ` Eli Zaretskii @ 2006-12-08 18:43 ` Stefan Monnier 2006-12-08 18:57 ` Juanma Barranquero 1 sibling, 0 replies; 5+ messages in thread From: Stefan Monnier @ 2006-12-08 18:43 UTC (permalink / raw) Cc: Juanma Barranquero, emacs-devel >> The motivation for my change is that, in my in-place installation, >> maintainer-clean (from lispref/Makefile.w32-in) was deleting elisp >> and elisp-* from lispref/, not info/, so it nuked elisp-cover.texi. > To avoid nuking more than we want, we could replace elisp-* with > something like "elisp-? elisp-??". This is not directly related, but I wish we could use the ".info" postfix on our Info files: it always comes in handy. Stefan ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Emacs-diffs Digest, Vol 49, Issue 33 2006-12-08 15:56 ` Eli Zaretskii 2006-12-08 18:43 ` Stefan Monnier @ 2006-12-08 18:57 ` Juanma Barranquero 1 sibling, 0 replies; 5+ messages in thread From: Juanma Barranquero @ 2006-12-08 18:57 UTC (permalink / raw) Cc: emacs-devel On 12/8/06, Eli Zaretskii <eliz@gnu.org> wrote: > It is an issue for building the ELisp manual as a separate package, > the way it was before we bundled it with Emacs. Then the Info files > were generated in place, so maintainer-clean deleted them. Ah, I see. > Instead, I suggest to replace elisp-* with "elisp-? elisp-??". OK, I'll fix it as you suggest. Thanks, /L/e/k/t/u ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2006-12-08 18:57 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <E1GsTlR-0003Kq-GG@monty-python.gnu.org>
2006-12-08 7:51 ` Emacs-diffs Digest, Vol 49, Issue 33 Eli Zaretskii
2006-12-08 11:33 ` Juanma Barranquero
2006-12-08 15:56 ` Eli Zaretskii
2006-12-08 18:43 ` Stefan Monnier
2006-12-08 18:57 ` Juanma Barranquero
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).