all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* 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.