[Distutils] CCompiler interfaces

[Greg Ward]

On 12 September 2000, Rene Liebscher said:
> Output filenames:
> 
> * create_static_lib needs a library name, which
> becomes intern a real file name.
> (Is anyone using this method?)

Yes, this is used by the "build_clib" command.  It's important
functionality (IMHO).

> * link_shared_library is similar to 
> create_static_lib.

Right, because shared libraries and static libraries are (at least
conceptually) similar.  In implementation terms -- how they're created,
what you can do with them, how they're formatted -- they are indeed
quite different, as you observed later.

> * link_shared_object needs a real file name.
> 
> * link_executable wants the basename of its
> output file.

'link_shared_object()' is the odd man out here: the other three all want
an "abstract" name -- library or executable name -- rather than a
concrete filename.  'link_shared_object()' was mainly conceived as a
back-door to let you generate whatever filename you please, if the
high-level interface ('link_shared_library()') doesn't cut it.

> We have two methods shared_object_filename()
> and library_filename() (for static and shared
> libraries). Wouldn't it be better to add
> a method executable_filename() and use for
> all of the linker methods the real filename
> as parameter?

'shared_object_filename()' is a relic -- I just checked, and it's only
defined by CCompiler, and not used anywhere.  Fine to delete it.

I agree about 'executable_filename()' -- good idea to add this for
consistency.

> For link_executable() we also need a parameter
> export_symbols. (An executable could export
> symbols to be able to be extended by plug-ins.)

OK, I didn't know that.  Sounds like a reasonable change.

> The best way would to merge these three methods
> into one new method and remove the old ones. 
> (Or let the old ones call the new and give a warning
> the user should use the new method.)

Agreed.  The backwards compatibility is a pain because these methods
take so many parameters, but I think the 'link_this()' and 'link_that()'
interface is nice to support.  I wouldn't bother with a warning, though.

> This new method would have following parameters:
> (It is better to see a shared libray as an half-build
> executable than to compare it with static libraries.)
> 
>    def link (self,
>                   target,
[...]
> 
> target would be one of 'shared_object', 
> 'shared_library' or 'executable'.

Then it should be called 'target_desc' -- when I see "target", I think
"filename".

> The compiler classes would then be much simpler
> and smaller.

Good -- they need it.

> This saves about 70 lines of redundant code.
> For BCPPCompiler and MSVCCompiler it is similar.

Excellent!

> Are there any objections?
> If not, I would send Greg a patch for it.

OK -- I'll take a look at the patch.

> > Release 0.9 (29 June, 2000):
> > ----------------------------
> ...
> 
> >  * added the ability to compile and link in resource files with
> >    Visual C++ on Windows (Thomas Heller)
> 
> However, I can't find the place where it is done. Maybe it wasn't
> checked in ? 

I think this was a change to msvccompiler.py.  Can't remember exactly
what the change was -- was there anything in the CVS log?

        Greg