[Tutor] Python with readline

[dman]

On Tue, Apr 23, 2002 at 07:41:46AM -0400, Erik Price wrote:
| 
| On Wednesday, April 17, 2002, at 11:53  PM, dman wrote:
| 
| >No .so files?  They are always named libfoo.so, where 'foo' is the name
| >of the library.
| 
| Not any that I could see.
| 
| >| And I believe my readline library is /sw/include/readline (if the /sw/
| >| dir looks unfamiliar, it's the equivalent of /usr/local/ used by Fink,
| >| the Unix ported package management app for Mac OS X).
| >
| >The .h is the "include" file.  It is C source that is required for
| >compiling anything that uses the library.  The .so file is the "shared
| >library" file.  It is the already-compiled implementation of the
| >library.  The app (python in your case) will be dynamically linked
| >against that .so when it runs.
| 
| Useful knowledge.  Why does it need to be source code -- couldn't this 
| information just be placed into the shared library (.so) file?

It is probably at least partly due to historical reasons.  The source
is not just C itself, but also preprocessor directives.  The C
compilation model is :
    1)  preprocessor (cpp) reads files and generates intermediary source.
        it removes comments, handles all #include and #define and
        other # commands, and "normalizes" the tokens

    2)  compiler reads preprocessor output and generates object (.o) file
        (but I think there are more intermediary steps here)

    3)  linker links all object files (.o) together to create one of
        a.out binary, ELF binary, shared library (.so) or static
        library (.a)

        (static libraries are actually 'ar' archives of the binary
        library files themselves)

The include files contain important information such as function
prototypes, structure declarations, and global constants.  Due to the
way the preprocessor handles #include, this must be source code.  If
it was in the .so (or .a) then the preprocessor would have to
understand the binary format as well, and the binaries would be much
larger.  For example, compile something non-trivial with and without
a -g option and compare the size.  (or compile with -g and then run
'strip' on the binary afterwards)
        
| >Stuff in /usr/share is typically just arbitrary data the app/lib uses
| >as it runs.
| 
| Someone told me that the "setup.py" script automatically checks for the 
| presence of GNU Readline.  I didn't even know about this script, I 
| assumed that all you do is ./configure; make; make install.  So I looked 
| at it, and then I looked at the ./configure script.  Nope, setup.py does 
| not appear to be called by ./configure (although I would have assumed it 
| was).  So I need to run setup.py myself.  This is interesting for two 
| reasons --
| 
| 1) setup.py is not an executable.  No reason it should be, but then, 
| doesn't that assume that I have a working version of Python on my 
| system?  Otherwise this "setup" script wouldn't work.  Fortunately I do, 
| but if this was my first time building Python... well, it just seems 
| strange.
| 
| 2) the interface is not readily apparent.  Although running "python 
| setup.py --help" does display a list of options, it does not display a 
| list of COMMANDS that need to be given (as arguments?) with the setup.py 
| script.  I didn't actually get a chance to look at the source code yet, 
| to see if I can figure out what I'm supposed to do, but perhaps someone 
| on this list is more familiar with setup.py and can tell me what I 
| should be doing.

setup.py is a distutils thing.  (search for the distutils SIG on
python.org)  I've never used one myself because everything I need is
already packaged for my distro.  Yes, setup.py does require a working
python, but how (or why) would you install python modules if you don't
have python itself?  The dependency isn't as crazy as it first sounds.

The only time I've built python was on Solaris.  Then I followed the
instructions and edited Modules/Setup (I think it is named) and
uncommented the readline line and had no problems.

I've never used OSX so I'm not familiar with the quirks of its build
system.

-D

-- 

The remote desktop feature of Windows XP is really nice (and *novel*!).
As a Microsoft consultant can *remotely* disable the personal firewall
and control the system.  We'll ignore the fact that this tampering with
the firewall is not logged, and more importantly, that the firewall
isn't restored when the clowns from Redmond are done with their job.
                                                            -- bugtraq