12:13 a.m.
Okay, I did a "make distclean" in my packages/ directory yesterday.
After this, I've been somewhat confused about the package dependencies.
Looks like one has to do at least a "make" in some package directories
before other packages can be built. "make autoloads" in packages/ after
a distclean there isn't enough.
A particularily confusing example was when I tried to build tramp
yesterday, it failed telling me it cannot load ediff-util. I added
ediff to REQUIRES, but I don't think tramp requires ediff directly, but
"through" vc. Compiling vc before tramp helps, and after doing that I
could also build tramp *without* the explicit ediff requirement.
Shouldn't this have Just Worked without doing a "make" in vc? That
doesn't seem to do anything else but byte-compiles .el files in vc/.
Possibly related; It seems that pdepends.mk isn't used at all when
building from a package directory, nor is it created when running "make
autoloads" in a package dir. Shouldn't it be? It will be created (and
used, I guess) when making autoloads from packages/ or
packages/xemacs-packages/ and it will be removed when doing a "make
clean" in these (though first created if it doesn't exist) or the
package directory.
Please advise. Because of this, I've already added possibly wrong (or
at least redundant) REQUIRES stuff to psgml and tramp.
Thanks for patience,
--
\/ille Skyttä
ville.skytta at xemacs.org
3:34 p.m.
|--==> "VS" == Ville Skytt <Ville> writes:
VS> Okay, I did a "make distclean" in my packages/ directory yesterday.
VS> After this, I've been somewhat confused about the package dependencies.
VS> Looks like one has to do at least a "make" in some package directories
VS> before other packages can be built. "make autoloads" in packages/
after
VS> a distclean there isn't enough.
I just did 'make distclean' 'make install' all went well, sorta
kinda. The only problems I saw was Semantic related (but we know
about that).
VS> A particularily confusing example was when I tried to build tramp
VS> yesterday, it failed telling me it cannot load ediff-util. I added
VS> ediff to REQUIRES, but I don't think tramp requires ediff directly, but
VS> "through" vc. Compiling vc before tramp helps, and after doing that I
VS> could also build tramp *without* the explicit ediff requirement.
VS> Shouldn't this have Just Worked without doing a "make" in vc?
That
VS> doesn't seem to do anything else but byte-compiles .el files in vc/.
Yes it should, and to be honest, I'm surprised that it didn't for you.
VS> Possibly related; It seems that pdepends.mk isn't used at all when
VS> building from a package directory, nor is it created when running "make
VS> autoloads" in a package dir. Shouldn't it be? It will be created (and
VS> used, I guess) when making autoloads from packages/ or
VS> packages/xemacs-packages/ and it will be removed when doing a "make
VS> clean" in these (though first created if it doesn't exist) or the
VS> package directory.
OK confession time... Before the advent of pdepends.mk, the packages
built fine for me, after pdepends.mk, they still built fine for me.
Because of that I never looked closely at what they were supposed to
do. I had noticed that they don't get built when building a package
from within a package directory
(./packages/xemacs-packages/pkgname/).
Sorry Jan. I really did mean to bring this up with you, but because
it didn't appear broken, I never thought about it.
VS> Please advise. Because of this, I've already added possibly wrong (or
VS> at least redundant) REQUIRES stuff to psgml and tramp.
What should happen, and did for me today...
make distclean -- cleans out any generated file
make (anything except the clean targets or html) -- should first of all do a
'make autoloads', then do whatever else.
Once all the autoloads are built, you should be able to build any
package in the tree.
I'll do a bit of investigating and see what I come up with.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
6:33 p.m.
On Wed, 2002-08-07 at 17:34, Steve Youngs wrote:
VS> Okay, I did a "make distclean" in my packages/
directory yesterday.
VS> After this, I've been somewhat confused about the package dependencies.
VS> Looks like one has to do at least a "make" in some package
directories
VS> before other packages can be built. "make autoloads" in packages/
after
VS> a distclean there isn't enough.
I just did 'make distclean' 'make install' all went well, sorta
kinda. The only problems I saw was Semantic related (but we know
about that).
Hmm, maybe I didn't make myself quite clear here, I meant doing a "make
install" in _a package_ directory, not in packages/ or
packages/xemacs-packages/, after doing a "make distclean autoloads" in
packages/. To reproduce, do the following. (Actually, this won't work
ATM because of issues with semantic, but I guess you'll get the point.)
1) Remove the "ediff" REQUIRES from tramp/Makefile
2) cd to your XEmacs/packages directory
3) Do a "make distclean autoloads" in this dir
4) cd to xemacs-packages/tramp
5) Do a "make install"
This sequence didn't work for me, for some reason unknown to me the
build failed with something like "cannot load ediff-util". cd'ing back
to xemacs-packages/vc/ and doing a make install there *before* tramp
made building tramp succeed.
I can't verify that this is the case ATM for the reasons mentioned
above, and tramp has been updated since I've last tried. But it *did*
break like outlined above (and below, quoted).
VS> A particularily confusing example was when I tried to build
tramp
VS> yesterday, it failed telling me it cannot load ediff-util. I added
VS> ediff to REQUIRES, but I don't think tramp requires ediff directly, but
VS> "through" vc. Compiling vc before tramp helps, and after doing that
I
VS> could also build tramp *without* the explicit ediff requirement.
VS> Shouldn't this have Just Worked without doing a "make" in vc?
That
VS> doesn't seem to do anything else but byte-compiles .el files in vc/.
Yes it should, and to be honest, I'm surprised that it didn't for you.
See above, hopefully that sheds some light on the issue...
VS> Possibly related; It seems that pdepends.mk isn't used
at all when
VS> building from a package directory, nor is it created when running "make
VS> autoloads" in a package dir. Shouldn't it be? It will be created
(and
VS> used, I guess) when making autoloads from packages/ or
VS> packages/xemacs-packages/ and it will be removed when doing a "make
VS> clean" in these (though first created if it doesn't exist) or the
VS> package directory.
OK confession time... Before the advent of pdepends.mk, the packages
built fine for me, after pdepends.mk, they still built fine for me.
Because of that I never looked closely at what they were supposed to
do. I had noticed that they don't get built when building a package
from within a package directory
(./packages/xemacs-packages/pkgname/).
I think the stuff in them does autoloads for and compiles all packages
that the the one with the pdepends.mk in question requires.
Sorry Jan. I really did mean to bring this up with you, but because
it didn't appear broken, I never thought about it.
Uh, please forgive my ignorance, but what part does Jan play in this?
VS> Please advise. Because of this, I've already added
possibly wrong (or
VS> at least redundant) REQUIRES stuff to psgml and tramp.
What should happen, and did for me today...
make distclean -- cleans out any generated file
make (anything except the clean targets or html) -- should first of all do a
'make autoloads', then do whatever else.
Once all the autoloads are built, you should be able to build any
package in the tree.
Yes, that's what I thought too until recently.
I'll do a bit of investigating and see what I come up with.
Thanks! I'm anxious to hear more.
--
\/ille Skyttä
ville.skytta at xemacs.org
7:22 a.m.
>>>> "Ville" == Ville Skytt <Ville>
writes:
Ville> Hmm, maybe I didn't make myself quite clear here, I meant
Ville> doing a "make install" in _a package_ directory, not in
Ville> packages/ or packages/xemacs-packages/, after doing a "make
Ville> distclean autoloads" in packages/.
I think that any time you have recursive requires across packages you
will have problems with this.
I don't know what to do about it.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
9:35 p.m.
On Thu, 2002-08-08 at 09:22, Stephen J. Turnbull wrote:
Ville> Hmm, maybe I didn't make myself quite clear here, I
meant
Ville> doing a "make install" in _a package_ directory, not in
Ville> packages/ or packages/xemacs-packages/, after doing a "make
Ville> distclean autoloads" in packages/.
I think that any time you have recursive requires across packages you
will have problems with this.
I don't know what to do about it.
Damn. But if pdepends.mk would be used when building from a package
dir, it could work?
--
\/ille Skyttä
ville.skytta at xemacs.org
2:47 a.m.
>>>> "Ville" == Ville Skytt <Ville>
writes:
Ville> On Thu, 2002-08-08 at 09:22, Stephen J. Turnbull wrote:
Ville> Hmm, maybe I didn't make myself quite clear here, I meant
Ville> doing a "make install" in _a package_ directory, not in
Ville> packages/ or packages/xemacs-packages/, after doing a "make
Ville> distclean autoloads" in packages/.
> I think that any time you have recursive requires across
> packages you will have problems with this.
>
> I don't know what to do about it.
Ville> Damn. But if pdepends.mk would be used when building from
Ville> a package dir, it could work?
You'd have to try it. Steve Y is the main resource here, as Steve
Baur seems to have dropped off the face of the earth. :-( Jan
"%%% Just Married %%%" Vroonhof <jan(a)xemacs.org> did some makefile
manipulations, but I think those were pure optimizations. I don't know
how much he knows about the dependency system. You could ask him,
although he seems extremely busy these days.
I'll let you know if and when I find Steve B.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
2:14 p.m.
>>>> "Stephen" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
>>>> "Ville" == Ville Skytt <Ville>
writes:
Ville> On Thu, 2002-08-08 at 09:22, Stephen J. Turnbull wrote:
Ville> Hmm, maybe I didn't make myself quite clear here, I meant
Ville> doing a "make install" in _a package_ directory, not in
>> I think that any time you have recursive requires across
>> packages you will have problems with this.
Ville> Damn. But if pdepends.mk would be used when building from
Ville> a package dir, it could work?
Stephen> You'd have to try it.
According to Steve B, the two problems are (1) that you could end up
calling a macro from byte-compiled code, which doesn't work (macros
are expanded and open-coded by the compiler, so there is no provision
for handling macros in the byte-code interpreter), and (2) variations
on the "APEL problem" (conditional compilation for different versions
of XEmacs/available packages from the target system).
For (1), there are two considerations. (a) The packages have become
dependent on auto-autoloads. You need to do make autoloads in all
packages in REQUIRES. (b) The package machinery doesn't take the
transitive closure, but where macros invoke macros, you need to. So
this must be done by hand in REQUIRES.
Maybe pdepends.mk could fix this, that's a Steve Y innovation so Steve
B doesn't know anything about it.
There's not much you can do about (2) except to avoid such packages.
So basically, up to the macro issue, `make install' in a package
directory should work. In other words, it should build and install,
but will fail intermittently in practice. :-/
What you seem to be getting caught on is (1)(b). What happens is that
package-compile.el deliberately clears out load-path, then adds back
in exactly the directories needed for REQUIRES. If REQUIRES is not
closed under `require', you're hosed.
Unfortunately, there's no way to find out if an eval will cause a
macro invocation without actually reading all the libraries, so you
may as well load them. Thus you really do need all those libraries
available, which in turn means putting them in REQUIRES. (And if all
you need is one stupid function from Gnus, you get all of Gnus. C'est
la vie.)
No, I can't account for why it fails for you and not for Steve Y.
The bottom line AFAICT is that those REQUIRES aren't redundant; you're
asking for trouble if you don't put them in.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
8:24 p.m.
On Fri, 2002-08-09 at 16:14, Stephen J. Turnbull wrote:
Ville> On Thu, 2002-08-08 at 09:22, Stephen J. Turnbull
wrote:
Ville> Hmm, maybe I didn't make myself quite clear here, I meant
Ville> doing a "make install" in _a package_ directory, not in
>>> I think that any time you have recursive requires across
>>> packages you will have problems with this.
Ville> Damn. But if pdepends.mk would be used when building from
Ville> a package dir, it could work?
Stephen> You'd have to try it.
[snip]
No, I can't account for why it fails for you and not for Steve Y.
I'm pretty sure that it fails for everyone, I think I just didn't make
myself clear enough and SY didn't do it exactly the same way as I did
(ie. run the first "make install" in packages/xemacs-packages/<foo>).
The bottom line AFAICT is that those REQUIRES aren't redundant;
you're
asking for trouble if you don't put them in.
Allright then, good enough for me; I'll leave them in and add new ones
if I find them. Thanks heaps for a thorough explanation, Stephen!
--
\/ille Skyttä
ville.skytta at xemacs.org
3:10 a.m.
|--==> "VS" == Ville Skytt <Ville> writes:
Ville> Damn. But if pdepends.mk would be used when building from
Ville> a package dir, it could work?
Stephen> You'd have to try it.
Definitely, and, Jan Vroonhof <jan(a)xemacs.org> is the one to yell for
help with it. :-)
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
3:07 a.m.
|--==> "SJT" == Stephen J Turnbull <stephen(a)xemacs.org> writes:
SJT> Maybe pdepends.mk could fix this, that's a Steve Y innovation
SJT> so Steve B doesn't know anything about it.
Actually, it's a Jan Vroonhof innovation.
SJT> No, I can't account for why it fails for you and not for Steve
SJT> Y.
Crossed communication wires... it does fail for me.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
3:04 a.m.
|--==> "VS" == Ville Skytt <Ville> writes:
VS> Damn. But if pdepends.mk would be used when building from a package
VS> dir, it could work?
That's where my money would be.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
3:02 a.m.
|--==> "VS" == Ville Skytt <Ville> writes:
VS> On Wed, 2002-08-07 at 17:34, Steve Youngs wrote:
VS> Hmm, maybe I didn't make myself quite clear here, I meant doing
VS> a "make install" in _a package_ directory, not in packages/ or
VS> 1) Remove the "ediff" REQUIRES from tramp/Makefile
VS> 2) cd to your XEmacs/packages directory
VS> 3) Do a "make distclean autoloads" in this dir
VS> 4) cd to xemacs-packages/tramp
VS> 5) Do a "make install"
Ah, now I am seeing the same problem you are.
VS> Possibly related; It seems that pdepends.mk isn't used at all
VS> when building from a package directory, nor is it created when
VS> running "make autoloads" in a package dir. Shouldn't it be?
I would think so, yes. And this is probably the answer to the problem.
VS> Uh, please forgive my ignorance, but what part does Jan play in
VS> this?
Jan invented 'pdepends.mk'.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
8123
days inactive
8136
days old
11 comments
3 participants
participants (3)
-
Stephen J. Turnbull -
Steve Youngs -
Ville Skyttä