In the message I sent to Tom Tromey, I mentioned that my current macros
install relative to python. This was done for convinience, but isn't
really the GNU way of doing things.
The other option is to install all scripts to $(prefix)/lib/site-python
and all extension modules to $(exec_prefix)/lib/site-python, and let the
user override those values with either a switch to configure or setting
some variables before calling make. This could be made smoother for a
user by installing a .pth file relative to python in order to fix the
python path for them. Once again, this isn't quite correct automake
behaviour.
This is probably the behaviour that will be put into automake, though. I
wrote the macros the way I did in order to make installation as painless
as possible.
James Henstridge.
--
Email: [EMAIL PROTECTED]
WWW: http://www.daa.com.au/~james/
On Thu, 17 Dec 1998, Philip Dawes wrote:
>
>
> > -----Original Message-----
> > From: James Henstridge [mailto:[EMAIL PROTECTED]]
> > Sent: 16 December 1998 02:53
> > To: '[EMAIL PROTECTED]'
> > Subject: Re: [pygtk] Python-Automake
> >
> >
> > I got a reply from Tom Tromey about my patches. He said the changes
> > won't make it into automake 1.4 (which will be released
> > soon), but will
> > probably be in the version after that. I have no idea when
> > that comes out
> > though.
>
> That's good news though - Cheers.
>
> Ooooh - one extra thing. I've noticed that the autoconf macros for
> gnome-python look for the main python site-packages folder
> (/usr/lib/python1.5/site-packages in my debian distro) and install stuff in
> there.
>
> In my objIDL package, make install puts them in
> $(PREFIX)/python$(PYVERSION)/site-packages,
> creating the folders if necessary, and then tells the user that they may
> need to set their PYTHONPATH environment variable. I did this because I put
> all my gnome stuff in prefix=/opt/gnome, and like to know that I can remove
> it all by deleting the prefix directory.
> I'm relatively new to python (a few months) so I might be missing something
> - is the reason that your script hunts for the default site-packages to save
> the user having to add the extra environment variable, or are there any
> other side effects to my approach?
>
> BTW, Debian installs python in /usr, but I think also creates a
> /usr/local/lib/python1.5/site-packages directory for extra stuff, from which
> python modules are found by python without having to set PYTHONPATH. It
> might be worth the generic autoconf script searching for already created
> site-packages folders in the prefix directory and use them if they exist.
> Just a thought; I don't mind doing the code if you think this is a good
> idea.
>
> > As for the ORBit bindings for python, have you looked at
> > doing stubless
> > bindings like Owen Taylors MICO perl bindings? I am not sure
> > if ORBit has
> > been developed far enough for this yet though.
>
> I'm afraid that I haven't turned my attention to python bindings yet. I'm
> currently working on C++ bindings (but I'm using python to write the idl
> compiler since this will make things a lot simpler and quicker).
> Martin von Loewis from fnORB and python-corba mapping fame thought that it
> would be worth exposing the CDR representation from ORBit to the python
> bindings and let it do it's own marshalling so I don't see any reason why we
> couldn't attempt stubless bindings given that you can deduce type
> information in python relatively easily.
>
> Cheers,
>
> Phil.
> To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
>
To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]