4:59 a.m.
Steve Youngs <youngs(a)xemacs.org> writes:
APPROVE COMMIT
With this patch...
make distclean
make bindist (or install)
...works as expected, ie, the 'bindist' and 'install' targets will
build the packages if required.
I've tested this with Mule and non-Mule 21.[145] from an individual
package directory. But not from the top level directory yet because
doing a complete packages build takes literally hours on my system
(still using the borrowed hardware).
Maybe someone with decent hardware could let me know if 'make bindist'
'make install' works from the top level.
BTW, Vin, I can't reproduce your Dired build failure with this patch,
but I must confess that I didn't before this patch. Does this fix it
for you?
NOTE: This patch has been committed.
Thanks, Steve. Now we're making some progress. I can successfully
build the packages again, with one small problem. I have to run make
in the vm directory before I can run make in the bbdb directory.
Let me explain...
I used to run 'make bindist' from the toplevel directory, but a few
months ago it became possible to run make bindist in only the
directories of interest. For instance, I now installed on my machine
only the following packages:
ls /usr/local/xemacs-packages/pkginfo
MANIFEST.apel MANIFEST.eshell MANIFEST.psgml
MANIFEST.bbdb MANIFEST.eterm MANIFEST.semantic
MANIFEST.c-support MANIFEST.footnote MANIFEST.sgml
MANIFEST.calc MANIFEST.hm--html-menus MANIFEST.sh-script
MANIFEST.cc-mode MANIFEST.ibuffer MANIFEST.speedbar
MANIFEST.debug MANIFEST.igrep MANIFEST.supercite
MANIFEST.dired MANIFEST.ispell MANIFEST.texinfo
MANIFEST.ecb MANIFEST.mail-lib MANIFEST.text-modes
MANIFEST.ecrypto MANIFEST.net-utils MANIFEST.time
MANIFEST.edebug MANIFEST.os-utils MANIFEST.tramp
MANIFEST.ediff MANIFEST.pc MANIFEST.vc
MANIFEST.edit-utils MANIFEST.pcl-cvs MANIFEST.view-process
MANIFEST.efs MANIFEST.pcomplete MANIFEST.w3
MANIFEST.eieio MANIFEST.perl-modes MANIFEST.xemacs-base
MANIFEST.elib MANIFEST.prog-modes MANIFEST.xemacs-devel
I save considerable time by only building the packages I want to
install. I was very grateful for this change, thank you to whoever
made it (props to Ben?).
(I still run 'make autoloads' from the top directory - this makes sure
that all the autoload files exist when I run make in the individual
package directories.)
Currently, when I try to run make in bbdb, I get the following error:
xemacs -no-autoloads -vanilla -batch -eval '(setq stack-trace-on-error t
load-always-display-messages t load-ignore-out-of-date-elc-files t
load-show-full-path-in-messages t)' -l
/opt/build/xemacs-packages-2003-03-26/package-compile.el -- bbdb edit-utils gnus mh-e
rmail supercite vm tm apel mail-lib xemacs-base w3 fsf-compat eterm sh-script -- -l
vm-version -f batch-byte-compile lisp/bbdb-vm.el
Loading /usr/local/xemacs-21.1.14/lib/xemacs-21.1.14/lisp/auto-autoloads...
Loading /opt/build/xemacs-packages-2003-03-26/xemacs-packages/sh-script/auto-autoloads...
Loading /opt/build/xemacs-packages-2003-03-26/xemacs-packages/eterm/auto-autoloads...
Loading
/opt/build/xemacs-packages-2003-03-26/xemacs-packages/fsf-compat/auto-autoloads...
Loading /opt/build/xemacs-packages-2003-03-26/xemacs-packages/w3/lisp/auto-autoloads...
Loading
/opt/build/xemacs-packages-2003-03-26/xemacs-packages/xemacs-base/auto-autoloads...
Loading /opt/build/xemacs-packages-2003-03-26/xemacs-packages/mail-lib/auto-autoloads...
Loading /opt/build/xemacs-packages-2003-03-26/xemacs-packages/apel/auto-autoloads...
Loading /opt/build/xemacs-packages-2003-03-26/xemacs-packages/tm/auto-autoloads...
Loading /opt/build/xemacs-packages-2003-03-26/xemacs-packages/vm/auto-autoloads...
Loading /opt/build/xemacs-packages-2003-03-26/xemacs-packages/supercite/auto-autoloads...
Loading /opt/build/xemacs-packages-2003-03-26/xemacs-packages/rmail/auto-autoloads...
Loading /opt/build/xemacs-packages-2003-03-26/xemacs-packages/mh-e/auto-autoloads...
Loading
/opt/build/xemacs-packages-2003-03-26/xemacs-packages/gnus/gnus/lisp/auto-autoloads...
Loading
/opt/build/xemacs-packages-2003-03-26/xemacs-packages/edit-utils/auto-autoloads...
Loading /opt/build/xemacs-packages-2003-03-26/xemacs-packages/bbdb/lisp/auto-autoloads...
Compiling /opt/build/xemacs-packages-2003-03-26/xemacs-packages/bbdb/lisp/bbdb-vm.el...
While compiling toplevel forms in file
/opt/build/xemacs-packages-2003-03-26/xemacs-packages/bbdb/lisp/bbdb-vm.el:
!! File error (("Cannot open load file" "vm-autoload"))
Done
For the moment, I'm getting around this problem by inserting the
following hack into my script by doing the following:
pushd ./xemacs-packages/vm
make vm-autoload.el
popd
after running 'make autoloads' and before running 'make' in the bbdb
directory. Shouldn't 'make autoloads' in vm create the vm-autoload.el
file? Was this broken by the latest vm updates?
Thanks,
Vin
11:28 a.m.
New subject: [AC] [PACKAGES] More package build fixing.
|--==> "VS" == Vin Shelton <acs(a)xemacs.org> writes:
VS> Thanks, Steve. Now we're making some progress. I can successfully
VS> build the packages again, with one small problem. I have to run make
VS> in the vm directory before I can run make in the bbdb directory.
This should be fixed now.
VS> Let me explain...
VS> I used to run 'make bindist' from the toplevel directory, but a few
VS> months ago it became possible to run make bindist in only the
VS> directories of interest.
It should be possible to do the same thing from toplevel, just set
NONMULE_PACKAGES and MULE_PACKAGES to the packages you wish to build.
VS> I save considerable time by only building the packages I want to
VS> install. I was very grateful for this change, thank you to whoever
VS> made it (props to Ben?).
I've _always_ been able to build packages in this way, but I do
remember you having problems with this.
VS> (I still run 'make autoloads' from the top directory - this makes sure
VS> that all the autoload files exist when I run make in the individual
VS> package directories.)
A good idea.
VS> after running 'make autoloads' and before running 'make' in the
bbdb
VS> directory. Shouldn't 'make autoloads' in vm create the
vm-autoload.el
VS> file? Was this broken by the latest vm updates?
Yep, sorry.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
9:26 p.m.
New subject: [AC] [PACKAGES] More package build fixing.
Steve Youngs <youngs(a)xemacs.org> writes:
|--==> "VS" == Vin Shelton <acs(a)xemacs.org>
writes:
VS> I used to run 'make bindist' from the toplevel directory, but a few
VS> months ago it became possible to run make bindist in only the
VS> directories of interest.
It should be possible to do the same thing from toplevel, just set
NONMULE_PACKAGES and MULE_PACKAGES to the packages you wish to build.
This does not work for me. As you know, I don't build MULE_PACKAGES,
so I have
BUILD_WITHOUT_MULE = t
If I set
NONMULE_PACKAGES = xemacs-packages/xemacs-base xemacs-packages/xemacs-devel
and run 'make bytecompile', the make still descends into all the
subdirectories in xemacs-packages. I don't have sufficient time at
work to figure out how this is supposed to work. I noticed this
because I'm currently getting a failure when I try to build auctex,
'cause I don't have tex installed.
- Vin
7911
days inactive
7911
days old
2 comments
2 participants
participants (2)
-
Steve Youngs -
Vin Shelton