Jason Tishler writes:
> 1. VPATH support: I was hoping that Distutils supports VPATH.
> Unfortunately, my research (i.e, web searching, Python doc reading,
> Distutils code grep-ing) came up empty which leads me to the
> conclude that VPATH is not (currently) supported. However, the
> setup.py that is part of the Python build *does* support configuring
> and building in a tree that is different than the source tree.
> If this is the required (VPATH) functionality, then we can steal
> this from the Python build.
That would be it. Btw., the current Makefile.pre.in approach also claims
to support VPATH, but in its own brain-dead way that makes it useless.
It would be interesting to see whether the distutils way does better here.
> 2. Installation by a non-root user: I don't know how to solve this
> with Makefiles. The only workaround I can think of is to install
> in a non-privileged directory and inform the user to set their
> PYTHONPATH appropriately. BTW, won't non-root users have problems
> installing PostgreSQL in the standard directory too?
The whole point here is not to install in the standard directories.
More issues:
4. DESTDIR support: Yet to see this happen...
5. Dependency tracking: Haha...
6. Respecting the choice of compiler in configure.
> I knew what you meant, but from my experiences enhancing Cygwin Python to
> support shared extensions, I can attest that Makefile.pre.in, makesetup,
> etc. is *not* a fun place to be.
That's why I want to rip that too.
> IMO, it makes much more sense to leverage off of the Distutils effort
> -- especially now that the standard Python extension modules are built
> this way too.
Distutils, much like MakeMaker on the Perl side, are nice for getting your
Python module out to the world without spending too much time thinking
about packaging. However, in the PostgreSQL tree they are part of a
larger system and they are supposed to act as part of that system (by
deliberate choice). And we do spend time thinking about packaging. ;-)
I wouldn't mind having a setup.py available for those who want to use it.
But as long as it doesn't go into the direction of fixing the outlined
issues 1.-6. there is still bound to be a replacement.
I have attached a makefile that illustrates what I could imagine the
replacement to be.
> I am certainly not a Python expert, but my impression is that
> $(prefix)/lib/python2.1 is reserved for Python itself. I can research
> this one too, but I still think that the PostgreSQL modules should go
> in $(prefix)/lib/python2.1/site-packages.
Seems reasonable, but if you can find some official recommendation that
would be great.
--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
