[Distutils] CCompiler interfaces

Rene Liebscher R.Liebscher@gmx.de
Tue Sep 12 07:55:01 2000


Last weekend I tried to use Distutils' compiler
classes to build an executable on Win32.
Beside some problems with the compilers,
I found that parameters of some methods of 
CCompiler are a little bit confusing.

Output filenames:

* create_static_lib needs a library name, which
becomes intern a real file name.
(Is anyone using this method?)

* link_shared_library is similar to 
create_static_lib.

* link_shared_object needs a real file name.

* link_executable wants the basename of its
output file.

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?


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


If we would make both changes I mentioned above,
the interfaces of the three link_* methods would 
be the same. Also the implementation is almost
the same. ( link_shared_library() calls 
link_shared_object(), and link_executable() differs
only in one line in UnixCCompiler. The other compilers
are similar, they only change some options to
compile an executable instead a shared library.)

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.)


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,
                         objects,
                         output_libname,
                         output_dir=None,
                         libraries=None,
                         library_dirs=None,
                         runtime_library_dirs=None,
                         export_symbols=None,
                         debug=0,
                         extra_preargs=None,
                         extra_postargs=None,
                         build_temp=None):

target would be one of 'shared_object', 
'shared_library' or 'executable'.

The compiler classes would then be much simpler
and smaller.

For example UnixCCompiler.
* Remove link_shared_library() and link_executable()
* Rename link_shared_object() to link() and add
target to the parameter list. 

* Change the spawn() call in it to the following
piece of code.

   try:
     if target == 'executable':
        self.spawn (self.linker_exe + ld_args)
     else:     
        self.spawn (self.linker_so + ld_args)
   except DistutilsExecError, msg:
     raise LinkError, msg
  
This saves about 70 lines of redundant code.
For BCPPCompiler and MSVCCompiler it is similar.

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


###########################################################
And now a short piece of Changes.txt:
> 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 can do the same using BCPPCompiler and CygwinCCompiler,
and will send a patch after reorganizing the compiler
classes.  



Kind regards

Rene Liebscher