[Distutils] Proposal: C/C++ compiler identification

[John Skaller]

At 16:33 15/12/98 -0500, Greg Ward wrote:
>Quoth John Skaller, on 16 December 1998:

>>         I want the build process to put that
>> information into a standard module. So I can get it out,
>> and call up the compiler to make a C extension FROM PYTHON.
>
>A-ha!  Thank you -- now it comes clear.  If I were more weasely, I could
>squirm out of it by saying "Well, this just follows from the requirement 
>to easily build extension modules from source" or, "That's not a
>requirement, it's an implementation detail".

        You could, you'd be right in both cases, and you cannot
be expected to do everything: which is why I wrote the article. :-)

>But I'm not a weasel, 

        You're not god. You started this list to get help
from others. 

>and I think at some point I meant to mention this
>in the requirements document.  So I've added it.  

        Great! Thanks! 

>I'm managing to keep implementation details out of the requirements
>list, though.  In particular, my proposal is for a new 'sys.config'
>module which would contain everything you might need to know about how
>Python was configured.  

        YES!!!! I agree!

>The most important items are the compiler,
>compiler flags, platform, and library installation directories.

        Can I recommend you look at the interscript compilers module again?
Instead of storing compiler flags, etc, you need an actual
command that does the compilation. I.e. a python function
that builds a command string and os.system's it.

        I don't think that 'data' can store this information,
there are too many options. (Store the data as well!)

>For an example of the degree of flaming overkill possible in this sort
>of module, try this

>   perl -MConfig -e 'map { print "$_: $Config{$_}\n" } sort keys %Config;'

>You'll note that Perl's Config module stores *every* piece of
>information, gleaned, gathered, or queried from the user while running
>Perl's 'Configure' script.  I don't think Python's sys.config need be
>*quite* so exhaustive, 

        I agree. After all, we can upgrade it later.
The important thing is to get the module into the
distribution. That way people can try it, and we'll find
out what is missing. Anyone on this list have a Next machine??

>Here's a very rough start
>(loosely based on my long experience with building Perl and my very
>brief experience with building Python, and a bit of poking through
>Python's makefiles):

        This is too Unixy.

>  cc              C compiler used to build Python
>  cppflags        C preprocessor flags used to build Python (-I, -D, -U)
>  optimize        optimization/debugging flags used to build Python
>  ccsharedflags   C compiler flags required to build shared objects
>  extra_ccflags   any other C compiler flags used to build Python
>  ccflags         all compiler flags used to build Python:
>                  cppflags + optimize + extra_ccflags
>  ccextflags      all compiler flags used to build Python extensions:
>                  cppflags + optimize + ccsharedflags + extra_ccflags
>
>  ldlibdirs       -L flags used to build Python
>  ldlibs          -l flags used to build Python
>  extra_ldflags   any other needed linker flags
>  ldsharedflags   linker flags required to build shared objects
>  ldflags         all linker flags used to build Python:
>                  ldlibdirs + ldlibs + extra_ldflags
>  ldextflags      linker flags used to build Python extensions:
>                  ldlibdirs + ldlibs + ldsharedflags + extra_ldflags


        I do not think _any_ of these flags, etc, are required
individually. Nor do I see how they can possibly be enough.
You are making assumptions about how an arbitrary compiler is invoked.

        What you need is a _function_ which compiles a c file
for a shared library, and another which links them.

        In other words, you just need a string with some
'slots' in it for the filenames, and which has all the flags
already set in the right places. The function is a generalisation
of that. Have a look at the compilers module I posted here.

>  platform        hardware/os/vendor (or something along those lines)

        Yes. Something like that. This is necessarily
crude information.

>  install_bindir       directory to install binary executables
>  install_scriptdir    directory to install non-binary executables
>  install_includedir   directory to install C header files
>  install_confincludedir  directory to install platform- and
>                          build-specific C header files
>  install_libdir       main Python library directory
>  install_sitelibdir   directory for site-specific modules


        Each of these things is what i call an 'install point'.
It isn't clear that the list is enough: clients may want to organise
things differently for different modules.

        For example, the place PYTHON puts scripts is definitely
NOT where I want extension packages: I want them in the
site-packages directory.

        This is tough. I think your list is a good start.
Please add:

        install_htmldir  directory to put HTML doco
        install_mandir   directory for man pages (does anyone provide them?)

>Obviously this is very sketchy.  

        An excellent sketch though. Why? because it is concrete
enough to be argued about! 
-------------------------------------------------------
John Skaller    email: skaller@maxtal.com.au
		http://www.maxtal.com.au/~skaller
		phone: 61-2-96600850
		snail: 10/1 Toxteth Rd, Glebe NSW 2037, Australia