[Distutils] Re: CygwinCCompiler, msvc hack, BCPPCompiler

Rene Liebscher R.Liebscher@gmx.de
Tue, 08 Aug 2000 14:20:48 +0200


Greg Ward wrote:
> 
> [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.

It is not as easy as you may think, I just spotted a potential problem
before it could arise.
If I would write ...append(",,%s," % filename) and filename would
contain
a blank ("/a b/file") then spawn would quote it as whole ",,/a b/file,".
And this is probably wrong. So we should insert file names as single
words in the list. 
(Don't say blanks in file names are not allowed in python module names,
THIS is a generic compiler class which could also be used for
other purposes.)
  
 
> 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):
> ... 
> and here's the BCPP version:
> ...
> 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.
 

> > (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?

I meant this one:
> >     # either exchange python15.lib in the python libs directory against
> >     # a Borland-like one, or create one with name bcpp_python15.lib
> >     # there and remove the pragmas from config.h
> >     #libraries.append ('mypylib')
> >     libraries.append ('import32')
> >     libraries.append ('cw32mt')


> > >   * 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.
Already done.