[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: python-files-can-appear-in-subdirs.patch
From: |
Alexandre Duret-Lutz |
Subject: |
Re: python-files-can-appear-in-subdirs.patch |
Date: |
21 Oct 2001 13:20:37 +0200 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 |
>>> "Tom" == Tom Tromey <address@hidden> writes:
>>>>>> "adl" == Alexandre Duret-Lutz <address@hidden> writes:
Tom> [ PYCFILES and PYOFILES ]
adl> Is there a need for them? To me it looks like they never
adl> worked,
(They never worked because python.am calls py-compile to compile all
python files at once, and py-compile will build .pyc and pyo files
unconditionally.)
adl> and I've no idea when they are usefull.
Tom> Me neither. I'm not a Python user; I just checked in code that other
Tom> people wrote.
After some speleology, I've found this patch from Andrew Dalke
http://sources.redhat.com/ml/automake/1999-07/msg00012.html
which does not use py-compile but takes PYCFILES and PYOFILES into
account.
The following coments of yours mention another patch which I
have not been able to discover.
http://sources.redhat.com/ml/automake/1999-07/msg00073.html
The first commit (lookup 1999-11-22 in ChangeLog.2000) uses
py-compile, but searching the archive for 'py-compile' yield
nothing.
To me, it looks like Andrew's code has been mixed with someone else's
code. Hence some confusion: the documentation comes from Andrew and
refers to PYCFILES/PYOFILES, although python.am/py-compile don't.
(BTW, Andrew is missing from THANKS.)
I'll submit a patch later today to remove the PYCFILES/PYOFILES
documentation, because presently it's just confusing.
Then, if someone needs to be able to decide whether his files
need to be byte-compiled/optimized or not, we can add some
options to py-compile, and handle a per-target _PYFLAGS variable
to specify these options; this sounds cleaner to me. But
frankly, I think this won't be needed. (Besides, someone would
have reported that PYCFILES/PYOFILES was not working if this
feature was really needed.)
adl> In fact I'm wondering whether the nobase_ feature is functional
adl> at all!
Tom> Yeah. I saw your other patches in this area. Will your Python/nobase
Tom> patch work now?
Yes.
The remaining issue in this area is that, as with other
primaries, the following will fail during 'make install'
because 'foo/bar/' does not exists:
foodir = foo
nobase_foo_PYTHON = bar/baz.py
nobase.test XFAILs for the same reason (dirpaths of nobase_
files are not created).
I've discussed this with Akim a few day ago, and he suggested
going toward implementing the -D options in install.sh.
--
Alexandre Duret-Lutz