mh-e/mh-loaddefs.el removed from CVS

mh-e/mh-loaddefs.el removed from CVS

[Bill Wohler]

It is now regenerated automatically in lisp/Makefile.

Those of you using MH-E in CVS Emacs will need to run ./configure in
order to rebuild lisp/Makefile from lisp/Makefile.in.

Please let me know if you hit any problems with my changes.

-- 
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: mh-e/mh-loaddefs.el removed from CVS

[Stefan Monnier]

> It is now regenerated automatically in lisp/Makefile.
> Those of you using MH-E in CVS Emacs will need to run ./configure in
> order to rebuild lisp/Makefile from lisp/Makefile.in.

Reminds me that I think it'd be neat if autoloads.el accepted
a "autoload-destination" file-local variable, so that a file could say "my
autoloads should go to mh-loaddefs.el rather than the default loaddefs.el".

Another related "todo item" if mine in this area is to make an
(require-autoload 'feature), which would work more or less like require,
except that the byte compiler would replace it with a list of autoloads for
all the functions used in the file and provided by `feature'.


        Stefan

Re: mh-e/mh-loaddefs.el removed from CVS

[Richard M. Stallman]

Did you make sure mh-loaddefs.el is regenerated for releases?
It should be included in the release.

Re: mh-e/mh-loaddefs.el removed from CVS

[Bill Wohler]

"Richard M. Stallman" <rms@gnu.org> writes:

> Did you make sure mh-loaddefs.el is regenerated for releases?
> It should be included in the release.

I was wondering about that.

mh-loaddefs.el is regenerated any time mh-e/*.el is touched and the
bootstrap, compile, or recompile targets in lisp/Makefile are run. If
this is not sufficient, please let me know what I need to do.

In any case, I ran make dist from the top and found that
lists/mh-e/mh-loaddefs.el was in the emacs-22.0.50 directory that was
created.

I also saw the following output

    The following .el file names are too long:
    ...
    lisp/mh-e/mh-customize.el
    lisp/mh-e/mh-identity.el
    lisp/mh-e/mh-loaddefs.el

Should I be concerned?

-- 
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: mh-e/mh-loaddefs.el removed from CVS

[Richard M. Stallman]

    In any case, I ran make dist from the top and found that
    lists/mh-e/mh-loaddefs.el was in the emacs-22.0.50 directory that was
    created.

Did you do this starting from a state with no mh-loaddefs.el file?
If so, then you have proved that `make dist' creates the file
meaning that there the problem  I was worried about does not exist.

    I also saw the following output

	The following .el file names are too long:
	...
	lisp/mh-e/mh-customize.el
	lisp/mh-e/mh-identity.el
	lisp/mh-e/mh-loaddefs.el

We used to try to support systems with 14-char file name limits.
I don't think they exist any more.  So I deleted that warning check.
Thanks.

Re: mh-e/mh-loaddefs.el removed from CVS

[Bill Wohler]

"Richard M. Stallman" <rms@gnu.org> writes:

>     In any case, I ran make dist from the top and found that
>     lists/mh-e/mh-loaddefs.el was in the emacs-22.0.50 directory that was
>     created.
>
> Did you do this starting from a state with no mh-loaddefs.el file?
> If so, then you have proved that `make dist' creates the file
> meaning that there the problem  I was worried about does not exist.

Thanks for making me look again. I took a second look and found I
needed to add mh-autoloads to the updates target in lisp/Makefile in
order to build mh-loaddefs.el in the case that someone removed that
file manually before running make dist.

If someone finds other circumstances in which make dist fails to
create lisp/mh-e/mh-loaddefs.el, please let me know.

-- 
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: mh-e/mh-loaddefs.el removed from CVS

[Zhang Wei]

The lisp/Makefile.in has been changed to regenerate
mh-e/mh-loaddefs.el, but the corresponding lisp/makefile.w32-in remain
unchanged. Is that ok?

Re: mh-e/mh-loaddefs.el removed from CVS

[Bill Wohler]

Zhang Wei <id.brep@gmail.com> writes:

> The lisp/Makefile.in has been changed to regenerate
> mh-e/mh-loaddefs.el, but the corresponding lisp/makefile.w32-in remain
> unchanged. Is that ok?

I was unaware of this file, sorry.

I'll patch the file and check it in. Since I do not have a Windows
system to test this change on, can someone please verify the patch and
make any adjustments as necessary? If others would prefer that I mail
the patch to a Windows user, please let me know now.

-- 
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: mh-e/mh-loaddefs.el removed from CVS

[Juanma Barranquero]

On 10/13/05, Bill Wohler <wohler@newt.com> wrote:

> I'll patch the file and check it in. Since I do not have a Windows
> system to test this change on, can someone please verify the patch and
> make any adjustments as necessary?

Makefile.w32-in must support both sh and cmd.exe shells; getting the
CMD shell to do some things (like echo'ing a ^L in a line by itself)
can prove tricky.

--
                    /L/e/k/t/u

Re: mh-e/mh-loaddefs.el removed from CVS

[Bill Wohler]

Bill Wohler <wohler@newt.com> writes:

> Zhang Wei <id.brep@gmail.com> writes:
>
>> The lisp/Makefile.in has been changed to regenerate
>> mh-e/mh-loaddefs.el, but the corresponding lisp/makefile.w32-in remain
>> unchanged. Is that ok?
>
> I was unaware of this file, sorry.
>
> I'll patch the file and check it in.

Done. Can someone please take care of verifying the change and
implementing any "tricky bits" that Juanma mentioned?

By the way, MH-E is known to run on Windows so this is a worthwhile
exercise.

I noticed a few discrepancies between Makefile.in and
makefile.w32-in which may or may not be problems:

1. AUTOGENEL does not exist in makefile.w23-in, nor a maintainer-clean
   target which uses it.

2. compile depends on $(lisp)/subdirs.el in Makefile.in, subdirs.el in
   makefile.w32-in.

3. bootstrap in makefile.w32-in depends on "finder-data custom-deps"
   while boostrap in Makefile.in does not.

-- 
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: mh-e/mh-loaddefs.el removed from CVS

[Bill Wohler]

Bill Wohler <wohler@newt.com> writes:

> Those of you using MH-E in CVS Emacs will need to run ./configure in
> order to rebuild lisp/Makefile from lisp/Makefile.in.

Just a friendly reminder that you MUST do this (or "./config.status")
since I checked in my Makefile.in changes a few days ago. You'll know
you'll have to do this if you get a compile error that mh-loaddefs.el
can't be found.

-- 
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: mh-e/mh-loaddefs.el removed from CVS

[Bill Wohler]

Bill Wohler <wohler@newt.com> writes:

> Bill Wohler <wohler@newt.com> writes:
>
>> Those of you using MH-E in CVS Emacs will need to run ./configure in
>> order to rebuild lisp/Makefile from lisp/Makefile.in.
>
> Just a friendly reminder that you MUST do this (or "./config.status")
> since I checked in my Makefile.in changes a few days ago. You'll know
> you'll have to do this if you get a compile error that mh-loaddefs.el
> can't be found.

One small correction: you must do this even if you're not using MH-E.

-- 
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: mh-e/mh-loaddefs.el removed from CVS

[Jason Rumney]

Bill Wohler <wohler@newt.com> writes:

>>> The lisp/Makefile.in has been changed to regenerate
>>> mh-e/mh-loaddefs.el, but the corresponding lisp/makefile.w32-in remain
>>> unchanged. Is that ok?
>
> Done. Can someone please take care of verifying the change and
> implementing any "tricky bits" that Juanma mentioned?

I have implemented the "tricky bits" and tested them on
CMD.EXE.

> I noticed a few discrepancies between Makefile.in and
> makefile.w32-in which may or may not be problems:
>
> 1. AUTOGENEL does not exist in makefile.w23-in, nor a maintainer-clean
>    target which uses it.

As you say, there is no maintainer-clean target in the w32 makefiles.
I'm not sure how important it is to be able to start from a clean CVS
tree without checking it out fresh. If it is important, someone can
add the necessary targets to the w32 makefiles.

> 2. compile depends on $(lisp)/subdirs.el in Makefile.in, subdirs.el in
>    makefile.w32-in.

I have changed all references to .el files to use $(lisp).

> 3. bootstrap in makefile.w32-in depends on "finder-data custom-deps"
>    while boostrap in Makefile.in does not.

But bootstrap-after does depend on those files. I have seen reports of
Windows reporting no documentation for built-in commands, so this may
be the reason.

Re: mh-e/mh-loaddefs.el removed from CVS

[Bill Wohler]

Jason Rumney <jasonr@gnu.org> wrote:

> Bill Wohler <wohler@newt.com> writes:
> 
> >>> The lisp/Makefile.in has been changed to regenerate
> >>> mh-e/mh-loaddefs.el, but the corresponding lisp/makefile.w32-in remain
> >>> unchanged. Is that ok?
> >
> > Done. Can someone please take care of verifying the change and
> > implementing any "tricky bits" that Juanma mentioned?
> 
> I have implemented the "tricky bits" and tested them on
> CMD.EXE.

Thank you. Much appreciated.

-- 
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: mh-e/mh-loaddefs.el removed from CVS

[Stefan Monnier]

> I'm not sure how important it is to be able to start from a clean CVS
> tree without checking it out fresh.

For some people, checking out the whole CVS tree takes a long time.
For subversions.gnu.org it also adds unnecessary load.

Admittedly, this is not specific to Emacs, and arguably CVS should come with
a tool to delete non-CVS-managed files to revert to the "fresh checkout"
state.  I use a littel Perl script `cvsclean' to do that.


        Stefan


#!/usr/bin/perl

sub cvsclean {
    my($path) = @_;
    my(%files) = ();
    my(@subdirs);

    print STDOUT "Cleaning $path\n";
    opendir (DIR, "$path/") || die "No directory $path";
    open (ENTRIES, "$path/CVS/Entries") || die "No $path/CVS/Entries file";
    while (<ENTRIES>) {
        if (m[^D/([^/]+)]) {
            push (@subdirs, "$path/$1");
        } elsif (m[^/([^/]+)/[^/-]]) {
            $files{$1} = "managed";
        }
    }

    foreach $entry (readdir(DIR)) {
        if (!exists ($files{$entry})) {
            $entry = "$path/$entry";
            if (-f $entry) {
                print STDOUT "unlink $entry\n";
                unlink $entry;
            }
        }
    }
    
    foreach $subdir (@subdirs) {
        &cvsclean ($subdir);
    }
}

&cvsclean (".");

Re: mh-e/mh-loaddefs.el removed from CVS

[Eli Zaretskii]

> From: Jason Rumney <jasonr@gnu.org>
> Date: Mon, 17 Oct 2005 22:23:04 +0100
> Cc: emacs-devel@gnu.org
> 
> Bill Wohler <wohler@newt.com> writes:
> 
> >>> The lisp/Makefile.in has been changed to regenerate
> >>> mh-e/mh-loaddefs.el, but the corresponding lisp/makefile.w32-in remain
> >>> unchanged. Is that ok?
> >
> > Done. Can someone please take care of verifying the change and
> > implementing any "tricky bits" that Juanma mentioned?
> 
> I have implemented the "tricky bits" and tested them on
> CMD.EXE.

And I tested them with a Unixy shell, and it works.  (Needed to make a
small change to avoid same-file warnings, though.)

Thanks!

Re: mh-e/mh-loaddefs.el removed from CVS

[Bill Wohler]

Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Jason Rumney <jasonr@gnu.org>
> > Date: Mon, 17 Oct 2005 22:23:04 +0100
> > Cc: emacs-devel@gnu.org
> > 
> > Bill Wohler <wohler@newt.com> writes:
> > 
> > >>> The lisp/Makefile.in has been changed to regenerate
> > >>> mh-e/mh-loaddefs.el, but the corresponding lisp/makefile.w32-in remain
> > >>> unchanged. Is that ok?
> > >
> > > Done. Can someone please take care of verifying the change and
> > > implementing any "tricky bits" that Juanma mentioned?
> > 
> > I have implemented the "tricky bits" and tested them on
> > CMD.EXE.
> 
> And I tested them with a Unixy shell, and it works.  (Needed to make a
> small change to avoid same-file warnings, though.)

Thank you both!

-- 
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: mh-e/mh-loaddefs.el removed from CVS

[Emilio Lopes]

Stefan Monnier writes:

> Admittedly, this is not specific to Emacs, and arguably CVS should come with
> a tool to delete non-CVS-managed files to revert to the "fresh checkout"
> state.

Just for the records, there's a set of CVS utilities called `cvsutils'.
It provides, among others, the following programs:

   CVSCO
          cvsco is a "cruel checkout". In other words, it removes
          results of compilation and discards local changes.  It
          deletes all the files except listed unmodified ones and
          checks out everything which seems to be missing.  Please
          note, that cvsco doesn't update files which haven't been
          modified locally. It only reloads missing files and files
          which it erases.

   CVSDISCARD
          cvsdiscard is "discard my changes". In other words, it
          discards local changes but keeps results of compilation. It
          works like cvsco, but it only deletes files which are likely
          to cause merge conflicts.

   CVSPURGE
          cvspurge leaves all files known to CVS, but removes the
          rest.  Unlike cvsco, it doesn't remove local changes.  It is
          useful to test local changes in the otherwise clean source
          tree.

   CVSTRIM
          cvstrim removes files and directories unknown to CVS. Files
          listed in .cvsignore are not removed. The idea is to remove
          the files that are not resulted from the normal build process
          - backups, coredumps etc.  cvstrim relies on .cvsignore files
          being correct. Note that the backups for modified files are
          removed.

-- 
Emílio C. Lopes
Munich, Germany