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