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. > > > 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. 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/
