all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Filtering loaddefs files in lisp/Makefile
@ 2010-10-02 12:17 Eli Zaretskii
  2010-10-02 16:24 ` Chong Yidong
  0 siblings, 1 reply; 3+ messages in thread
From: Eli Zaretskii @ 2010-10-02 12:17 UTC (permalink / raw)
  To: emacs-devel

What do people think about replacing this ugliness:

	    els=`echo $(lisptagsfiles1) $(lisptagsfiles2) $(lisptagsfiles3) $(lisptagsfiles4) | sed -e "s,$(lisp)/[^ ]*loaddefs[^ ]*,," -e "s,$(lisp)/ldefs-boot[^ ]*,,"`; \
	    ${ETAGS} -o $@ $$els

with a command that uses `find', e.g.:

	find . -name "*.el" -a -\! -( -name "*loaddefs.el" -o -name "ldefs-boot.el" -) | ${ETAGS} -o $@ -

The combined length of all the Lisp files expanded from
$(lisptagsfilesN) is 32K, so I guess a few shells will choke on what
we currently have, while doing it with `find' will avoid that problem.
As a bonus, we won't need to track the depth of the `lisp' tree
hierarchy by adding more of the $(lisptagsfilesN) variables.



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Filtering loaddefs files in lisp/Makefile
  2010-10-02 12:17 Filtering loaddefs files in lisp/Makefile Eli Zaretskii
@ 2010-10-02 16:24 ` Chong Yidong
  2010-10-02 22:59   ` Francesco Potortì
  0 siblings, 1 reply; 3+ messages in thread
From: Chong Yidong @ 2010-10-02 16:24 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

> What do people think about replacing this ugliness:
>
> 	    els=`echo $(lisptagsfiles1) $(lisptagsfiles2) $(lisptagsfiles3) $(lisptagsfiles4) | sed -e "s,$(lisp)/[^ ]*loaddefs[^ ]*,," -e "s,$(lisp)/ldefs-boot[^ ]*,,"`; \
> 	    ${ETAGS} -o $@ $$els
>
> with a command that uses `find', e.g.:
>
> 	find . -name "*.el" -a -\! -( -name "*loaddefs.el" -o -name "ldefs-boot.el" -) | ${ETAGS} -o $@ -
>
> The combined length of all the Lisp files expanded from
> $(lisptagsfilesN) is 32K, so I guess a few shells will choke on what
> we currently have, while doing it with `find' will avoid that problem.
> As a bonus, we won't need to track the depth of the `lisp' tree
> hierarchy by adding more of the $(lisptagsfilesN) variables.

Seems fine.



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Filtering loaddefs files in lisp/Makefile
  2010-10-02 16:24 ` Chong Yidong
@ 2010-10-02 22:59   ` Francesco Potortì
  0 siblings, 0 replies; 3+ messages in thread
From: Francesco Potortì @ 2010-10-02 22:59 UTC (permalink / raw)
  To: Chong Yidong; +Cc: Eli Zaretskii, emacs-devel

>Eli Zaretskii <eliz@gnu.org> writes:
>
>> What do people think about replacing this ugliness:
>>
>> 	    els=`echo $(lisptagsfiles1) $(lisptagsfiles2) $(lisptagsfiles3) $(lisptagsfiles4) | sed -e "s,$(lisp)/[^ ]*loaddefs[^ ]*,," -e "s,$(lisp)/ldefs-boot[^ ]*,,"`; \
>> 	    ${ETAGS} -o $@ $$els
>>
>> with a command that uses `find', e.g.:
>>
>> 	find . -name "*.el" -a -\! -( -name "*loaddefs.el" -o -name "ldefs-boot.el" -) | ${ETAGS} -o $@ -

The find manual says it is "\!", not "-!".  The following corrects the
above and is slightly simpler:

find . -name "*.el" -a \! -name "*loaddefs.el" -a \! -name "ldefs-boot.el" | ${ETAGS} -o $@ -

I think that inside a script quoting the ! is useless, as shell history
expansion is not enabled.  This would bring to this:

find . -name "*.el" -a ! -name "*loaddefs.el" -a ! -name "ldefs-boot.el" | ${ETAGS} -o $@ -



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2010-10-02 22:59 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-10-02 12:17 Filtering loaddefs files in lisp/Makefile Eli Zaretskii
2010-10-02 16:24 ` Chong Yidong
2010-10-02 22:59   ` Francesco Potortì

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.