cvs-update

cvs-update

[Juri Linkov]

I see a new useful make target was added to Makefiles as:

cvs-update: recompile autoloads finder-data custom-deps

But I wonder why it doesn't use the existing target `updates'?
I mean why not to write the same new target as:

cvs-update: recompile updates

Also I think it would be good to recommend it in INSTALL.CVS,
e.g. by replacing

  $ make recompile EMACS=../src/emacs

with

  $ make cvs-update EMACS=../src/emacs

Or maybe even there should be a new top-level target `cvs-update' to perform
all necessary updates after every CVS update, e.g. something like:

make; make -C lisp EMACS=../src/emacs recompile updates; make; make tags; make info

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: cvs-update

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Date: Wed, 04 Jan 2006 08:27:44 +0200
> 
> I see a new useful make target was added to Makefiles as:
> 
> cvs-update: recompile autoloads finder-data custom-deps

I'm glad you find it useful.

> But I wonder why it doesn't use the existing target `updates'?
> I mean why not to write the same new target as:
> 
> cvs-update: recompile updates

Because "make updates" also does "make update-subdirs", which is
almost always unnecessary, and includes the mh-autoloads target, which
is already part of "make recompile".

Re: cvs-update

[Bill Wohler]

Juri Linkov <juri@jurta.org> writes:

> Also I think it would be good to recommend [the cvs-update target]
> in INSTALL.CVS, e.g. by replacing
>
>   $ make recompile EMACS=../src/emacs
>
> with
>
>   $ make cvs-update EMACS=../src/emacs
>
> Or maybe even there should be a new top-level target `cvs-update' to perform
> all necessary updates after every CVS update, e.g. something like:
>
> make; make -C lisp EMACS=../src/emacs recompile updates; make; make tags; make info

I would like that.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.

Re: cvs-update

[Stefan Monnier]

> Because "make updates" also does "make update-subdirs", which is
> almost always unnecessary, and includes the mh-autoloads target, which
> is already part of "make recompile".

mh-autoloads should simply not be in update-subdirs.
It seems it's been added a bit everywhere rather than carefully choosing the
one place where it should go.


        Stefan

Re: cvs-update

[Juri Linkov]

>> But I wonder why it doesn't use the existing target `updates'?
>> I mean why not to write the same new target as:
>>
>> cvs-update: recompile updates
>
> Because "make updates" also does "make update-subdirs", which is
> almost always unnecessary,

update-subdirs is much faster than other updates so it doesn't hurt to
call this target after every CVS update.

> and includes the mh-autoloads target, which is already part of "make
> recompile".

Then it should be removed.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: cvs-update

[Bill Wohler]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Because "make updates" also does "make update-subdirs", which is
>> almost always unnecessary, and includes the mh-autoloads target, which
>> is already part of "make recompile".
>
> mh-autoloads should simply not be in update-subdirs.
> It seems it's been added a bit everywhere rather than carefully choosing the
> one place where it should go.

Actually, I carefully chose each of those places ;-).

I started out by putting it everywhere where "autoloads" appeared
since it's an identical construct. If mh-autoloads doesn't belong in
those places, neither does autoloads. If I remember correctly, I had
to add it to compile and recompile too since it wasn't getting run
during bootstrap or during recompiles after cvs updates.

Note that unlike autoloads target, the mh-autoloads target won't
actually do anything if none of the files in the mh-e directory have
changed. And it runs a whole lot faster.

I'm definitely open to feedback or suggestions.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.

Re: cvs-update

[Eli Zaretskii]

> Cc: Juri Linkov <juri@jurta.org>, emacs-devel@gnu.org
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu, 05 Jan 2006 00:25:59 -0500
> 
> > Because "make updates" also does "make update-subdirs", which is
> > almost always unnecessary, and includes the mh-autoloads target, which
> > is already part of "make recompile".
> 
> mh-autoloads should simply not be in update-subdirs.

You misunderstood me (because my wording was ambiguous):
`mh-autoloads' is not part of `update-subdirs', it's part of
`updates'.

Re: cvs-update

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Cc: emacs-devel@gnu.org
> Date: Thu, 05 Jan 2006 08:44:34 +0200
> 
> > Because "make updates" also does "make update-subdirs", which is
> > almost always unnecessary,
> 
> update-subdirs is much faster than other updates so it doesn't hurt to
> call this target after every CVS update.

That depends on how fast is your machine and your filesystem.  I have
sometimes to work on platforms where update-subdirs is annoyingly
slow.

In any case, I always thought Make was invented precisely so
unnecessary commands would not be run, even if they don't take long
time.

> > and includes the mh-autoloads target, which is already part of "make
> > recompile".
> 
> Then it should be removed.

>From where? from "make recompile"?  I thought it was there for a
good reason.  Bill, could you please comment on this?

Re: cvs-update

[Stefan Monnier]

>> > Because "make updates" also does "make update-subdirs", which is
>> > almost always unnecessary, and includes the mh-autoloads target, which
>> > is already part of "make recompile".
>> 
>> mh-autoloads should simply not be in update-subdirs.

> You misunderstood me (because my wording was ambiguous):
> `mh-autoloads' is not part of `update-subdirs', it's part of
> `updates'.

Oh, I see.  Well, then it shouldn't be in recompile.


        Stefan

Re: cvs-update

[Stefan Monnier]

> I started out by putting it everywhere where "autoloads" appeared
> since it's an identical construct. If mh-autoloads doesn't belong in
> those places, neither does autoloads. If I remember correctly, I had
> to add it to compile and recompile too since it wasn't getting run
> during bootstrap or during recompiles after cvs updates.

As far as I know, bootstrap rebuild loaddefs.el even though `autoloads' is
not on `compile', so there must have been some other problem.

> Note that unlike autoloads target, the mh-autoloads target won't
> actually do anything if none of the files in the mh-e directory have
> changed. And it runs a whole lot faster.

Right, so maybe it should be in compile/recompile only and nowhere else.


        Stefan

Re: cvs-update

[Bill Wohler]

Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> > Note that unlike autoloads target, the mh-autoloads target won't
> > actually do anything if none of the files in the mh-e directory have
> > changed. And it runs a whole lot faster.
> 
> Right, so maybe it should be in compile/recompile only and nowhere else.

I just removed it from bootstrap since bootstrap depends on compile
which depends on mh-autoloads.

I added mh-autoloads to compile-always to be consistent with the compile
target.

I did not remove mh-autoloads from updates since none of the targets of
updates already builds mh-autoloads and because I don't fully understand
the use of updates. However, it just occurred to me updates is for those
targets which take a long time to run and don't change often and
therefore are not recompile dependencies. If that's true, specifying
mh-autoloads as an updates dependency is essentially a no-op (since the
recompile target has likely been run recently) and might as well be
removed. Right? I'll do that, so as you say, mh-autoloads will only be a
compile/compile-always/recompile dependency.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.