It appears that in addition to the "worker" functions like compile(),
link_shared_object(), etc. there are four functions which *must* be
implemented by subclasses of CCompiler:
library_dir_option()
runtime_library_dir_option()
library_option()
find_library_file()
I submit the following patch (against the current CVS version of
ccompiler.py) to make future compiler implementors aware of this
requirement.
Lyle
Index: distutils/ccompiler.py
===================================================================
RCS file: /projects/cvsroot/distutils/distutils/ccompiler.py,v
retrieving revision 1.17
diff -a -u -r1.17 ccompiler.py
--- ccompiler.py 2000/03/26 21:37:09 1.17
+++ ccompiler.py 2000/05/11 20:59:16
@@ -566,7 +566,38 @@
pass
+ # -- Miscellaneous methods -----------------------------------------
+ # These are all used by the 'gen_lib_options() function; there is
+ # no appropriate default implementation so subclasses should
+ # implement all of these.
+
+
+ def library_dir_option (self, dir):
+ """Return the compiler option to add 'dir' to the list of
directories
+ searched for libraries."""
+ raise NotImplementedError
+
+
+ def runtime_library_dir_option (self, dir):
+ """Return the compiler option to add 'dir' to the list of
directories
+ searched for runtime libraries."""
+ raise NotImplementedError
+
+
+ def library_option (self, lib):
+ """Return the compiler option to add 'dir' to the list of libraries
+ linked into the shared library or executable."""
+ raise NotImplementedError
+
+
+ def find_library_file (self, dirs, lib):
+ """Search the specified list of directories for a static or shared
+ library file 'lib' and return the full path to that file. Return
+ None if it wasn't found in any of the specified directories."""
+ raise NotImplementedError
+
+
# -- Filename generation methods -----------------------------------
# The default implementation of the filename generating methods are
Hi,
I wrote a patch for the above commands.
Both commands derive from install_misc, which copies some files to a
given directory and is defined in cmd.py.
With the attached patch you can now have "scripts=[...]" and
"data=[...]" attributes in setup.py.
By the way: I was not able to TeX the documentation because I found
no howto.cls file (the files are using \documentclass{howto}). There
should be a make file to compile all the various .tex files.
Bastian
--
Bastian Kleineidam -- Just do it. Use Linux. .~.
http://fsinfo.cs.uni-sb.de/~calvin/official/ /V\
// \\
/( )\
^`~'^
> Thanks -- I'll check it in shortly. One problem:
>
> > extra_args.append ('/IMPLIB:' + implib_dir)
> > + self.mkpath (os.path.dirname(implib_dir))
> > # if MSVC
>
> I fixed this bug just before seeing your patch with
>
> self.mkpath(implib_dir)
>
> One of us misunderstands what 'implib_dir' is, and since you're the one
> using Windows, it could well be me. Can you test to see which fix is
> the right one?
The /IMPLIB:name switch to the linker is used to specify the name of an
import library. The variable name "implib_dir" should probably be changed to
"implib_file" because it is the file name of the import library and not a
directory name. Having said that, the correct code snippet is:
implib_file = os.path.join (self.build_temp, \
self.get_ext_libname (extension_name))
extra_args.append ('/IMPLIB:' + implib_file)
self.mkpath (os.path.dirname (implib_file))
I just tested this on two of my projects plus PyXML-0.5.4 and it works
properly.
Lyle
Tony J Ibbs (Tibs) wrote:
> I'm only following this with half a mind at best (sorry), but Bastian had an
> email that contained:
>
> > >But I don't think we should rely on everyone using the
> > >"#!/usr/bin/env" hack, either: the first python on the path isn't
> > >necessarily the right one.
> > The "first python on the path" is the correct thing for the user,
> > otherwise the path is wrong. So "/usr/bin/env pyton" yields the correct
> > interpreter to execute.
>
> Do please remember the problem on Dec Unixes (which appears to be) that if
> the environment is large (i.e., many environment variables) then
> /usr/bin/env falls back to *printing* the environment variables, instead of
> executing the given program (gods know why, but this is Dec).
[snip]
That's not the only problem, apparently different systems are undecided as
to whether "env" belongs in "/usr/bin" or in "/bin". Also, considering that
other operating systems have their own ways of implementing the spirit of
the "#!" hack (and they're usually pretty bad at it), I think the final
script really needs to be generated during installation.
See this URL for the complete discussion on #!/bin/env:
http://x29.deja.com/dnquery.xp?search=next&DBS=1&IS=%22/bin/env%20python%22…
=============================================================================
michaelMuller = mmuller(a)enduden.com | http://www.cloud9.net/~proteus
-----------------------------------------------------------------------------
The natural progress of things is for liberty to yield and government to
gain control. - Thomas Jefferson
=============================================================================
All,
In trying to implement the compiler class for Borland's C++ compiler I've
run up against a minor snag or two.
First, some background. For extension modules on Windows, we want to support
the specification of an optional module definition file (a.k.a. a .DEF
file). On Unix I believe it's true that all of the symbols in a shared
library are "exported" so this is a non-issue. On Windows, however, you must
specify in one way or another which symbols in a DLL are to be exported. One
way to do this is to provide the exported symbols' names in a .DEF file
which you must write (it's a specially-formatted ASCII text file). Another
way to do this is list each of the exported symbols' names on the linker
command line using a linker-specific switch.
Currently, a module developer can tell the Distutils which DEF file to use
for each extension module with the "def_file" key, e.g.:
setup (...,
ext_modules = [
('module1',
{ 'sources' : ['module1.c'],
'def_file' : ['module1.def']
}
),
('module2',
{ 'sources' : ['module2.c'],
'def_file' : ['module2.def']
}
),
]
)
If the "def_file" information for an extension module is not explicitly
specified, there is code in the build_ext command which guesses a likely
name for the .DEF file (basically module_name + ".def") and sees if that
file exists. If so, it uses that file. Otherwise, we adopt a reasonable
fallback position and guess the initialization function's name to be "init"
+ module_name and ask the linker to export that symbol for us.
OK, we have now arrived at the problem part ;)
The way to specify either the .DEF file name or the exported symbol name(s)
is linker-specific. For Microsoft's linker they are passed along as
straightforward arguments, either:
/DEF:module1.def
or
/EXPORTS:initmodule1
but for Borland's linker this information comes in very differently -- not
as simple arguments which you can just append to the linker's argument list.
Since only the compiler class knows for sure how to specify the .DEF file
name (or alternatively the exported symbols list) it seems that we should
pass this information directly to the compiler through the
link_shared_object() function's argument list, instead of cooking up those
arguments in the build_ext command. I'd propose adding an additional
argument to the function's signature (its default could be None and could be
ignored by non-Windows compilers).
Changing the subject, it might also be appropriate to pass down the
temporary files directory for the current extension's build, unless this
kind of code:
build_ext = self.find_peer ('build_ext')
build_temp = build_ext.build_temp
is considered safe. If this doesn't violate encapsulation (for the compiler
object to know that the build_ext object has an attribute named
"build_temp") then I'll just do this and sleep soundly ;)
Sorry for the rambling e-mail!
Lyle
Hi all --
I've just released a new code snapshot, available at
http://www.python.org/sigs/distutils-sig/download.html#snapshot
The major change is the addition of Bastian Kleineidam's
"install_scripts" and "install_data" commands. I'll let you figure out
what type of files these two install. ;-)
I also fixed a little bug in the "install" command that appeared when
testing Bastian's two commands.
Also, there an initial stab at finding and parsing config files has been
added. It doesn't have any actual effect yet, though.
Oh yeah, Lyle Johnson's --compiler switch went in tonight too.
Thanks to Bastian and Lyle for the patches! (And also to Harry Gebel,
whose bdist_rpm did *not* make it in tonight ... that was the original
plan, but I got distracted by Bastian's stuff. Ahh well, one patch at a
time...)
Greg
PS. there's some CVS reshuffling going on at python.org, the upshot of
which is that these changes are *not* available by CVS (unless you
happen to have a login on my home PC, which you do not unless you are
me). I'm afraid everyone will have to use code snapshots for the next
couple of days. ;-(
--
Greg Ward - Linux nerd gward(a)python.net
http://starship.python.net/~gward/
Be wary of strong drink. It can make you shoot at tax collectors--and miss.
On 11 May 2000, F. Oliver Gathmann said:
> I was trying to get the new PyXML (v. 0.5.4) compiled with distutils v.
> 0.8.1, and besides some tweaking of pyexpat.c I had to make sure the
> directory path for the
> temporary import library was generated, as shown in the attached patch
> to build_ext.py (BTW, this was on a Win98 machine).
Hmmm, I thought someone else had reported this, and I thought it had
been fixed. Can you try Distutils 0.8.2 and see if if it works any
better?
