* 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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.