On 7/20/06, David Lee <[EMAIL PROTECTED]> wrote:
On Thu, 20 Jul 2006, Andrew Beekhof wrote:
> On 7/20/06, David Lee <[EMAIL PROTECTED]> wrote:
> > [...]
> > Meanwhile, I've taken a look at the generated Makefiles and think I see
> > _why_ it failing as you described. (But that doesn't explain why it's
> > being generated like that.)
> >
> > I've attempted a local workaround. It looks functionally OK, but has the
> > feel of digging deeper into a nasty hole that I shouldn't start digging in
> > the first place.
>
> If it works, then thats the best option.
(Futher to self...)
GOT IT, I hope!
Pushing forward with _PYTHON (as I think is right) is good. But doing it
by using something that feels wrong and clunky (my "attempted a local
workaround" of my email this morning) isn't.
However, I think I've now done it cleanly. See 1.15 of "cts/Makefile.am".
A single-line addition, that also feels appropriate.
excellent - i'll take a look
>
> > The automake manual doesn't seem to provide enough detail for maintaining
> > the combination of ".py.in"-from-".py" and "_PYTHON". (And its those two
> > in combination which appear to be causing the problem you identified.)
>
> One quesiton... why is that makefile dealing with .pyc files in the
> first place? I dont believe they're used anywhere are they?
The idea of _PYTHON seems to have been written shortly after the "Goat
Book" went to press, so missed the book.
Its principle difference from _SCRIPTS (apart from the one you found!) is
in cleanly managing of ".pyo" and ".pyc" as they interact with install and
uninstall procedures.
i meant why do *we* care... i've never seen any .pyo or .pyc files
coming from cts. perhaps i just haven't been looking?
When all(*) the other stuff is installed (headers, libraries, objects,
scripts, perl files, ...) that's it, ... finished, ... done. It is all
predictable and determinate: the files on the disk are consistent with the
packaging information held by rpm, deb, etc.
(*) "var" things may be different and individual and non-systematic. I
mention them for completeness only, and move swiftly on...
But _PYTHON is different. At run-time it tries to create ".pyo" (and
perhaps also ".pyc") files alongside, in what could (by now) be a
read-only, or multi-machine nfs-mounted area. Ugh. Cold shiver. Etc.
Packaging information becomes inconsistent. To give one instance: an
attempted removal won't even know that it should remove those extra files.
The idea of "_PYTHON" seems to be to create those extra files in advance,
and then install them as part of the package. This keeps everything
consistent.
I think that is a good principle.
You uncovered a wrinkle in my earlier attempt (rev 1.14) that was
unforeseen (because _PYTHON is poorly documented). I believe I have now
just cleanly addressed that wrinkle.
>
> > I'll consider raising a query on the automake email list. But I'm shortly
> > going out of email contact for a couple of weeks.
I posted the question.
But the list seems to have died a few days ago (having hitherto had
activity of several emails per day).
Best wishes.
--
: David Lee I.T. Service :
: Senior Systems Programmer Computer Centre :
: Durham University :
: http://www.dur.ac.uk/t.d.lee/ South Road :
: Durham DH1 3LE :
: Phone: +44 191 334 2752 U.K. :
_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
