automake-patches
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]