[Distutils] Re: CygwinCCompiler, msvc hack, BCPPCompiler

[Greg Ward]

[my suggestion]
>     initfunc_name = "init" + string.split(ext.name,'.')[-1]
>     if initfunc_name not in ext.export_symbols:
         ext.export_symbols.append(initfunc_name)

[Rene agrees]
> OK, I think you are right, if one wants to build none Python dll's
> he will not use build_ext to do this.

OK, can you make this change and include it in your next patch?

> I used 'extend' to be able to write "
> ld_args.extend([',','some_other_param']) ",
> but I never needed it in some places and simply forgot to replace it
> with 
> 'append' in the final patch.
[...]
> It is not necessary to have these commas as separate words, but they
> don't really 
> belong to a output filename or a library name, this is the other reason 
> why I made them in separate words.

OK.  I'd really like to see that code cleaned up: can you take care of
that too?  If it doesn't matter how things are broken up into words, how 
about just economizing on the amount of Python code?  The current
implementation seems rather bloated to me.

> 'mypylib' is not a Borland standard library. It is a Borland-like
> python.lib.  MSVC and Borland use different formats for their object
> files (COFF and OMF.) Now there comes also a 'python??' library from
> build_ext it should be also called 'python??.lib'. So you had to
> replace the standard 'python??.lib' by a Borland-like one. But what
> happens if you installed Python on a network drive and some users want
> to use MSVC and other BORLAND C++?  Then you have to give one of these
> libraries another name. I would suggest 'bcpp_python??.lib'.

OK, that seems like a sensible convention to me.  Congratulations, you
have just converted a "Liebscher convention" to a "Distutils
convention".  Next thing you know it'll be a "Python convention", and
then it'll be unstoppable!  ;-)

I've added the 'debug' flag to the official 'find_library_file()'
signature specified by CCompiler.  I've also rewritten the
implementation in both MSVCCompiler and BCPPCompiler.  Here's the MSVC
one (it's a bit simpler -- no prefix):

    def find_library_file (self, dirs, lib, debug=0):
        # Prefer a debugging library if found (and requested), but deal
        # with it if we don't have one.
        if debug:
            try_names = [lib + "_d", lib]
        else:
            try_names = [lib]
        for dir in dirs:
            for name in try_names:
                libfile = os.path.join(dir, self.library_filename (name))
                if os.path.exists(libfile):
                    return libfile
        else:
            # Oops, didn't find it in *any* of 'dirs'
            return None

and here's the BCPP version:

    def find_library_file (self, dirs, lib, debug=0):
        # List of effective library names to try, in order of preference:
        # bcpp_xxx.lib is better than xxx.lib
        # and xxx_d.lib is better than xxx.lib if debug is set
        #
        # The "bcpp_" prefix is to handle a Python installation for people
        # with multiple compilers (primarily Distutils hackers, I suspect
        # ;-).  The idea is they'd have one static library for each
        # compiler they care about, since (almost?) every Windows compiler
        # seems to have a different format for static libraries.
        if debug:
            dlib = (lib + "_d")
            try_names = ("bcpp_" + dlib, "bcpp_" + lib, dlib, lib)
        else:
            try_names = ("bcpp_" + lib, lib)

        for dir in dirs:
            for name in try_names:
                libfile = os.path.join(dir, self.library_filename (name))
                if os.path.exists(libfile):
                    return libfile
        else:
            # Oops, didn't find it in *any* of 'dirs'
            return None

Do those look right to you?  Obviously this is completely untested, but
I think both are a huge improvement so I'll check 'em in anyways.  Make
sure you "cvs up" if you have any patches for msvccompiler.py or
bcppcompiler.py!

Also in the "obvious" category: these should be combined, presumably
when someone (probably me, sigh) sits down and factors WindowsCCompiler
out of MSVCCompiler and BCPPCompiler.

> * About the 'pragma' in config.h:
> In PC/config.h of the Python source there are following lines:
> -------------------------------------------
> #ifndef USE_DL_EXPORT
> /* So nobody needs to specify the .lib in their Makefile any more */
> #ifdef _DEBUG
> #pragma comment(lib,"python20_d.lib")
> #else
> #pragma comment(lib,"python20.lib")
> #endif
> #endif /* USE_DL_EXPORT */
> -------------------------------------------
> If we want to use bcpp_python20.lib instead of python20.lib, we
> had to change the first line to:
> ------------------------------------------
> #if !defined(USE_DL_EXPORT) && defined(_MSC_VER)
> ------------------------------------------ 
> So the Borland C++ compiler wouldn't try to load this
> incompatible library 'python20.lib' .

Looks good to me.  I just posted to python-dev about this: let's see
what they say; I can make this change to PC/config.h if it's accepted.

> (We can't change the config.h file in existing installations 
> this is why I put the comment in there. So if a user got problems
> he finds a hint where this could come from.)

Sorry, which comment?  Do you mean the warning that's printed if
'check_config_h()' doesn't like what it finds?

> >   * you shouldn't write to stdout or stderr in a compiler class -- use
> >     the 'announce()' method.  I should really add a 'debug_print()'
> >     method; that would be handy.
> If you add 'debug_print()' I will use it.

Added it.  Please change your prints or writes or whatever they are.

Thanks!

        Greg
-- 
Greg Ward - just another Python hacker                  gward@python.net
http://starship.python.net/~gward/
Eschew obfuscation!