* Re: mh-e/mh-loaddefs.el removed from CVS
@ 2005-10-12 15:05 Zhang Wei
2005-10-12 22:07 ` Bill Wohler
0 siblings, 1 reply; 18+ messages in thread
From: Zhang Wei @ 2005-10-12 15:05 UTC (permalink / raw)
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?
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: mh-e/mh-loaddefs.el removed from CVS
2005-10-12 15:05 mh-e/mh-loaddefs.el removed from CVS Zhang Wei
@ 2005-10-12 22:07 ` Bill Wohler
2005-10-12 22:50 ` Juanma Barranquero
2005-10-12 23:08 ` Bill Wohler
0 siblings, 2 replies; 18+ messages in thread
From: Bill Wohler @ 2005-10-12 22:07 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: mh-e/mh-loaddefs.el removed from CVS
2005-10-12 22:07 ` Bill Wohler
@ 2005-10-12 22:50 ` Juanma Barranquero
2005-10-12 23:08 ` Bill Wohler
1 sibling, 0 replies; 18+ messages in thread
From: Juanma Barranquero @ 2005-10-12 22:50 UTC (permalink / raw)
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: mh-e/mh-loaddefs.el removed from CVS
2005-10-12 22:07 ` Bill Wohler
2005-10-12 22:50 ` Juanma Barranquero
@ 2005-10-12 23:08 ` Bill Wohler
2005-10-17 21:23 ` Jason Rumney
1 sibling, 1 reply; 18+ messages in thread
From: Bill Wohler @ 2005-10-12 23:08 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: mh-e/mh-loaddefs.el removed from CVS
2005-10-12 23:08 ` Bill Wohler
@ 2005-10-17 21:23 ` Jason Rumney
2005-10-17 21:27 ` Bill Wohler
` (2 more replies)
0 siblings, 3 replies; 18+ messages in thread
From: Jason Rumney @ 2005-10-17 21:23 UTC (permalink / raw)
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: mh-e/mh-loaddefs.el removed from CVS
2005-10-17 21:23 ` Jason Rumney
@ 2005-10-17 21:27 ` Bill Wohler
2005-10-18 14:27 ` Stefan Monnier
2005-10-20 12:10 ` Eli Zaretskii
2 siblings, 0 replies; 18+ messages in thread
From: Bill Wohler @ 2005-10-17 21:27 UTC (permalink / raw)
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: mh-e/mh-loaddefs.el removed from CVS
2005-10-17 21:23 ` Jason Rumney
2005-10-17 21:27 ` Bill Wohler
@ 2005-10-18 14:27 ` Stefan Monnier
2005-11-10 18:56 ` Emilio Lopes
2005-10-20 12:10 ` Eli Zaretskii
2 siblings, 1 reply; 18+ messages in thread
From: Stefan Monnier @ 2005-10-18 14:27 UTC (permalink / raw)
Cc: info-cvs, Bill Wohler, emacs-devel
> 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 (".");
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: mh-e/mh-loaddefs.el removed from CVS
2005-10-18 14:27 ` Stefan Monnier
@ 2005-11-10 18:56 ` Emilio Lopes
0 siblings, 0 replies; 18+ messages in thread
From: Emilio Lopes @ 2005-11-10 18:56 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: mh-e/mh-loaddefs.el removed from CVS
2005-10-17 21:23 ` Jason Rumney
2005-10-17 21:27 ` Bill Wohler
2005-10-18 14:27 ` Stefan Monnier
@ 2005-10-20 12:10 ` Eli Zaretskii
2005-10-20 14:23 ` Bill Wohler
2 siblings, 1 reply; 18+ messages in thread
From: Eli Zaretskii @ 2005-10-20 12:10 UTC (permalink / raw)
Cc: wohler, emacs-devel
> 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!
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: mh-e/mh-loaddefs.el removed from CVS
2005-10-20 12:10 ` Eli Zaretskii
@ 2005-10-20 14:23 ` Bill Wohler
0 siblings, 0 replies; 18+ messages in thread
From: Bill Wohler @ 2005-10-20 14:23 UTC (permalink / raw)
Cc: emacs-devel, Jason Rumney
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* mh-e/mh-loaddefs.el removed from CVS
@ 2005-10-07 5:00 Bill Wohler
2005-10-07 14:19 ` Stefan Monnier
` (2 more replies)
0 siblings, 3 replies; 18+ messages in thread
From: Bill Wohler @ 2005-10-07 5:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: mh-e/mh-loaddefs.el removed from CVS
2005-10-07 5:00 Bill Wohler
@ 2005-10-07 14:19 ` Stefan Monnier
2005-10-07 19:09 ` Richard M. Stallman
2005-10-15 5:51 ` Bill Wohler
2 siblings, 0 replies; 18+ messages in thread
From: Stefan Monnier @ 2005-10-07 14:19 UTC (permalink / raw)
Cc: emacs-devel
> 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: mh-e/mh-loaddefs.el removed from CVS
2005-10-07 5:00 Bill Wohler
2005-10-07 14:19 ` Stefan Monnier
@ 2005-10-07 19:09 ` Richard M. Stallman
2005-10-08 20:03 ` Bill Wohler
2005-10-15 5:51 ` Bill Wohler
2 siblings, 1 reply; 18+ messages in thread
From: Richard M. Stallman @ 2005-10-07 19:09 UTC (permalink / raw)
Cc: emacs-devel
Did you make sure mh-loaddefs.el is regenerated for releases?
It should be included in the release.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: mh-e/mh-loaddefs.el removed from CVS
2005-10-07 19:09 ` Richard M. Stallman
@ 2005-10-08 20:03 ` Bill Wohler
2005-10-09 18:16 ` Richard M. Stallman
0 siblings, 1 reply; 18+ messages in thread
From: Bill Wohler @ 2005-10-08 20:03 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: mh-e/mh-loaddefs.el removed from CVS
2005-10-08 20:03 ` Bill Wohler
@ 2005-10-09 18:16 ` Richard M. Stallman
2005-10-09 19:36 ` Bill Wohler
0 siblings, 1 reply; 18+ messages in thread
From: Richard M. Stallman @ 2005-10-09 18:16 UTC (permalink / raw)
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: mh-e/mh-loaddefs.el removed from CVS
2005-10-09 18:16 ` Richard M. Stallman
@ 2005-10-09 19:36 ` Bill Wohler
0 siblings, 0 replies; 18+ messages in thread
From: Bill Wohler @ 2005-10-09 19:36 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: mh-e/mh-loaddefs.el removed from CVS
2005-10-07 5:00 Bill Wohler
2005-10-07 14:19 ` Stefan Monnier
2005-10-07 19:09 ` Richard M. Stallman
@ 2005-10-15 5:51 ` Bill Wohler
2005-10-15 16:40 ` Bill Wohler
2 siblings, 1 reply; 18+ messages in thread
From: Bill Wohler @ 2005-10-15 5:51 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: mh-e/mh-loaddefs.el removed from CVS
2005-10-15 5:51 ` Bill Wohler
@ 2005-10-15 16:40 ` Bill Wohler
0 siblings, 0 replies; 18+ messages in thread
From: Bill Wohler @ 2005-10-15 16:40 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2005-11-10 18:56 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-10-12 15:05 mh-e/mh-loaddefs.el removed from CVS Zhang Wei
2005-10-12 22:07 ` Bill Wohler
2005-10-12 22:50 ` Juanma Barranquero
2005-10-12 23:08 ` Bill Wohler
2005-10-17 21:23 ` Jason Rumney
2005-10-17 21:27 ` Bill Wohler
2005-10-18 14:27 ` Stefan Monnier
2005-11-10 18:56 ` Emilio Lopes
2005-10-20 12:10 ` Eli Zaretskii
2005-10-20 14:23 ` Bill Wohler
-- strict thread matches above, loose matches on Subject: below --
2005-10-07 5:00 Bill Wohler
2005-10-07 14:19 ` Stefan Monnier
2005-10-07 19:09 ` Richard M. Stallman
2005-10-08 20:03 ` Bill Wohler
2005-10-09 18:16 ` Richard M. Stallman
2005-10-09 19:36 ` Bill Wohler
2005-10-15 5:51 ` Bill Wohler
2005-10-15 16:40 ` Bill Wohler
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.