From just@letterror.com Mon Jul 1 05:31:02 2002 From: just@letterror.com (Just van Rossum) Date: Mon Jul 1 04:31:02 2002 Subject: [Distutils] test for compiler on Windows? Message-ID: On Windows, how can I detect in my setup.py whether there is a compiler available? I have one C extension in my package which is entirely optional, and I would like "python setup.py install" to skip building the extension if there's no compiler available. Just From mal@lemburg.com Mon Jul 1 05:35:01 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon Jul 1 04:35:01 2002 Subject: [Distutils] test for compiler on Windows? References: Message-ID: <3D201452.4040900@lemburg.com> Just van Rossum wrote: > On Windows, how can I detect in my setup.py whether there is a compiler > available? I have one C extension in my package which is entirely optional, and > I would like "python setup.py install" to skip building the extension if there's > no compiler available. The best way to do this is to subclass the build_ext command and make compiling the extension optional. See mxSetup.py in the latest egenix-mx-base beta for an example. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From just@letterror.com Mon Jul 1 05:50:01 2002 From: just@letterror.com (Just van Rossum) Date: Mon Jul 1 04:50:01 2002 Subject: [Distutils] test for compiler on Windows? In-Reply-To: <3D201452.4040900@lemburg.com> Message-ID: M.-A. Lemburg wrote: > Just van Rossum wrote: > > On Windows, how can I detect in my setup.py whether there is a > > compiler available? I have one C extension in my package which is > > entirely optional, and I would like "python setup.py install" to > > skip building the extension if there's no compiler available. > > The best way to do this is to subclass the build_ext command > and make compiling the extension optional. > > See mxSetup.py in the latest egenix-mx-base beta for an example. Wow, that is one mean setup script... Thanks! Just From dubois1@llnl.gov Fri Jul 5 14:42:01 2002 From: dubois1@llnl.gov (Paul Dubois) Date: Fri Jul 5 13:42:01 2002 Subject: [Distutils] executable? Message-ID: <1025890877.19472.2.camel@ldorritt> Has anyone used distutils to build an executable? I have it building a C library and then I need to build an executable based on that library using the same macro and library definitions and one new .c file containing the main. From thomas.heller@ion-tof.com Fri Jul 5 15:04:02 2002 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Fri Jul 5 14:04:02 2002 Subject: [Distutils] executable? References: <1025890877.19472.2.camel@ldorritt> Message-ID: <04fd01c2244e$5253d530$e000a8c0@thomasnotebook> > Has anyone used distutils to build an executable? I have it building a > C library and then I need to build an executable based on that library > using the same macro and library definitions and one new .c file > containing the main. py2exe's setup-script builds some exe-files (but it's windows only). Thomas From hinsen@cnrs-orleans.fr Sat Jul 6 05:09:28 2002 From: hinsen@cnrs-orleans.fr (Konrad Hinsen) Date: Sat Jul 6 04:09:28 2002 Subject: [Distutils] executable? Message-ID: <200207060810.g668AJx01887@localhost.localdomain> Paul Dubois writes: > Has anyone used distutils to build an executable? I have it building a > C library and then I need to build an executable based on that library > using the same macro and library definitions and one new .c file > containing the main. I have a script that builds a new Python executable (with additional builtin modules) and which gets all system information from distutils, but it then makes explicit system calls to run the compilation. I couldn't find any helper functions for this within distutils. Here is the script: --------------------------------------------------------------------------- # Compile the mpipython executable containing # the Scientific.MPI extension module # Normally nothing needs to be changed below import distutils import distutils.sysconfig import os cfgDict = distutils.sysconfig.get_config_vars() # Name of the MPI compilation script. mpicompiler = 'mpicc' sources='mpipython.c Scientific_mpi.c' cmd = '%s %s -o mpipython -I%s %s -L%s -lpython%s %s %s' % \ (mpicompiler, cfgDict['LINKFORSHARED'], cfgDict['INCLUDEPY'], sources, cfgDict['LIBPL'], cfgDict['VERSION'], cfgDict['LIBS'], cfgDict['LIBM']) print 'cmd = ', cmd os.system(cmd) --------------------------------------------------------------------------- Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From hoel@germanlloyd.org Mon Jul 8 04:30:01 2002 From: hoel@germanlloyd.org (=?iso-8859-15?Q?Berthold_H=F6llmann?=) Date: Mon Jul 8 03:30:01 2002 Subject: [Distutils] Re: executable? In-Reply-To: <1025890877.19472.2.camel@ldorritt> References: <1025890877.19472.2.camel@ldorritt> Message-ID: Paul Dubois writes: > Has anyone used distutils to build an executable? I have it building a > C library and then I need to build an executable based on that library > using the same macro and library definitions and one new .c file > containing the main. In the early days of distutils I wrote: from distutils.core import setup from distutils.ccompiler import new_compiler from distutils.command.build import build opt_src =3D ["qp/qpalloc.c", "qp/qpmatrx.c", "qp/qpproc.c", = "qp/qpvect.c", "qp/qpchol.c", "qp/qporder.c", "qp/qpshut.c", "qp/qpxlist.c", "qp/qpdata.c", "qp/qpprepr.c", "qp/qpsolv.c", "qp/qpmain.c", "qp/qpprint.c", "qp/qpsymbo.c"] def build_opt(self): CC =3D new_compiler() if sys.platform !=3D 'win32': CC.add_library('m') import os.path opt_obj =3D CC.compile(opt_src) CC.link_executable(opt_obj, os.path.join("build/lib/", sys.platform, 'opt')) class my_build(build): def run(self): build_opt() build.run(self) setup (cmdclass =3D {'build': my_build}, name =3D "PyQP", version =3D "0.0.0", description =3D "qp access for Python", author =3D 'Berthold H"ollmann', author_email =3D "hoel@germanlloyd.org", packages =3D [''], ) which might be a starting point for your own code Greetings Berthold --=20 Dipl.-Ing. Berthold H=F6llmann __ Address: hoel@germanlloyd.org G / \ L Germanischer Lloyd phone: +49-40-36149-7374 -+----+- Vorsetzen 32/35 P.O.Box 111606 fax : +49-40-36149-7320 \__/ D-20459 Hamburg D-20416 Hamburg This email contains confidential information for the exclusive attention of the intended addressee. Any access of third parties to this email is unauthorized. Any use of this email by not intended recipients like copying, distribution, disclosure etc. is prohibited and may be unlawful. When addressed to our clients the content of this email is subject to the General Terms and Conditions of GL's Group of Companies applicable at the date of this email.=20 GL's Group of Companies does not warrant and/or guarantee that this message at the moment of receipt is authentic, correct and its communication free of errors, interruption etc.=20 From ville.vainio@swisslog.com Mon Jul 8 09:53:03 2002 From: ville.vainio@swisslog.com (Ville Vainio) Date: Mon Jul 8 08:53:03 2002 Subject: [Distutils] Erasing *.py after install Message-ID: <3D298B07.4070403@swisslog.com> Occasionally there is a need to delete the *.py files (but leave *.pyc and *.pyo) after installation, in order to protect some proprietary stuff (not just embarrassing hacks ;-). It would be quite nice to have this option in distutils. Or is it there already? -- Ville From Jack.Jansen@cwi.nl Mon Jul 8 10:25:30 2002 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Mon Jul 8 09:25:30 2002 Subject: [Distutils] Erasing *.py after install In-Reply-To: <3D298B07.4070403@swisslog.com> Message-ID: <145AE313-9276-11D6-9516-0030655234CE@cwi.nl> On Monday, July 8, 2002, at 02:52 , Ville Vainio wrote: > Occasionally there is a need to delete the *.py files (but leave *.pyc > and *.pyo) after installation, in order to protect some proprietary > stuff (not just embarrassing hacks ;-). It would be quite nice to have > this option in distutils. Or is it there already? If you want this shouldn't you just distribute the .pyc or .pyo files? It's false security to think that people won't be able to get at your sources if the .py files are part of the distribution... -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From ville.vainio@swisslog.com Mon Jul 8 10:33:01 2002 From: ville.vainio@swisslog.com (Ville Vainio) Date: Mon Jul 8 09:33:01 2002 Subject: [Distutils] Erasing *.py after install References: <145AE313-9276-11D6-9516-0030655234CE@cwi.nl> Message-ID: <3D29947B.1040302@swisslog.com> Jack Jansen wrote > > If you want this shouldn't you just distribute the .pyc or .pyo files? > It's false security to think that people won't be able to get at your > sources if the .py files are part of the distribution... The idea is that installation will be done at our company (or at least by someone from our company), automatically, and the distribution will be removed afterwards. I guess the upcoming import-from-zipfile feature could be used to facilitate this? -- Ville From mwh@python.net Mon Jul 8 10:34:01 2002 From: mwh@python.net (Michael Hudson) Date: Mon Jul 8 09:34:01 2002 Subject: [Distutils] Erasing *.py after install In-Reply-To: Jack Jansen's message of "Mon, 8 Jul 2002 15:24:49 +0200" References: <145AE313-9276-11D6-9516-0030655234CE@cwi.nl> Message-ID: <2mu1nany3m.fsf@starship.python.net> Jack Jansen writes: > On Monday, July 8, 2002, at 02:52 , Ville Vainio wrote: > > > Occasionally there is a need to delete the *.py files (but leave *.pyc > > and *.pyo) after installation, in order to protect some proprietary > > stuff (not just embarrassing hacks ;-). It would be quite nice to have > > this option in distutils. Or is it there already? > > If you want this shouldn't you just distribute the .pyc or .pyo files? > It's false security to think that people won't be able to get at your > sources if the .py files are part of the distribution... It's arguably false security to think that sufficiently determined people won't be able to get at your .pys if you distribute only your .pycs... Cheers, M. -- Strangely enough I saw just such a beast at the grocery store last night. Starbucks sells Javachip. (It's ice cream, but that shouldn't be an obstacle for the Java marketing people.) -- Jeremy Hylton, 29 Apr 1997 From mal@lemburg.com Mon Jul 8 10:46:15 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon Jul 8 09:46:15 2002 Subject: [Distutils] Erasing *.py after install References: <145AE313-9276-11D6-9516-0030655234CE@cwi.nl> <2mu1nany3m.fsf@starship.python.net> Message-ID: <3D2997C5.3040908@lemburg.com> Michael Hudson wrote: > Jack Jansen writes: > > >>On Monday, July 8, 2002, at 02:52 , Ville Vainio wrote: >> >> >>>Occasionally there is a need to delete the *.py files (but leave *.pyc >>>and *.pyo) after installation, in order to protect some proprietary >>>stuff (not just embarrassing hacks ;-). It would be quite nice to have >>>this option in distutils. Or is it there already? >> >>If you want this shouldn't you just distribute the .pyc or .pyo files? >>It's false security to think that people won't be able to get at your >>sources if the .py files are part of the distribution... > > > It's arguably false security to think that sufficiently determined > people won't be able to get at your .pys if you distribute only your > .pycs... Indeed, decompyle does wonders here. The resulting code is sometimes even better formatted than the original ;-) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From l.widdershoven@fz-juelich.de Mon Jul 15 08:46:02 2002 From: l.widdershoven@fz-juelich.de (Leon Widdershoven) Date: Mon Jul 15 07:46:02 2002 Subject: [Distutils] Python extenstion pyo instead of pyc Message-ID: <200207151345.32544.l.widdershoven@fz-juelich.de> Hi, I have a problem installing modules using setup.py bdist_rpm due to the fact that I have PYTHONOPTIMIZE=3D2 defined in my profile. This causes the build to fail as rpm expects a .pyc file, not a pyo file. This can be easily solved in an automatic way, just create the expected extension based on the PYTHONOPTIMIZE variable, or unset this variable=20 during the build. The distutils I use are revision v. 1.53 (taken from dist.py). Best regards, Leon Widdershoven From mhammond@skippinet.com.au Thu Jul 18 15:21:46 2002 From: mhammond@skippinet.com.au (Mark Hammond) Date: Thu Jul 18 14:21:46 2002 Subject: [Distutils] distutils parsing Makefile? Message-ID: Hi all, I have a patch at source-forge I would like some distutils related input on. www.python.org/sf/566100 - Patch [ 566100 ] Rationalize DL_IMPORT and DL_EXPORT In particular, Makefile.pre.in has been modified thus: RCS file: /cvsroot/python/python/dist/src/Makefile.pre.in,v retrieving revision 1.86 diff -u -r1.86 Makefile.pre.in --- Makefile.pre.in 21 Jun 2002 14:48:36 -0000 1.86 +++ Makefile.pre.in 5 Jul 2002 06:41:28 -0000 @@ -65,7 +65,7 @@ # Extra C flags added for building the interpreter object files. CFLAGSFORSHARED=@CFLAGSFORSHARED@ # C flags used for building the interpreter object files -PY_CFLAGS= $(CFLAGS) $(CPPFLAGS) $(CFLAGSFORSHARED) +PY_CFLAGS= $(CFLAGS) $(CPPFLAGS) $(CFLAGSFORSHARED) -DPy_BUILD_CORE # Machine-dependent subdirectories The idea is that Py_BUILD_CORE is defined *only* when building Python itself and builtin modules, but not for extension modules. On python-dev, Guido raised the following concern: My only concern would be that tools which parse the Makefile (I believe distutils does this?) should not accidentally pick up the "-DPy_BUILD_CORE" flag. Can anyone here tell me if this will be an issue for distutils? Does distutils do any parsing of the Makefile, and if so, is my change likely to work as intended? Thanks, Mark. From akuchlin@mems-exchange.org Thu Jul 18 16:02:03 2002 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Thu Jul 18 15:02:03 2002 Subject: [Distutils] distutils parsing Makefile? In-Reply-To: References: Message-ID: <20020718190122.GC30446@ute.mems-exchange.org> On Thu, Jul 18, 2002 at 04:24:40PM +1000, Mark Hammond wrote: >-PY_CFLAGS= $(CFLAGS) $(CPPFLAGS) $(CFLAGSFORSHARED) >+PY_CFLAGS= $(CFLAGS) $(CPPFLAGS) $(CFLAGSFORSHARED) -DPy_BUILD_CORE > >Can anyone here tell me if this will be an issue for distutils? Does >distutils do any parsing of the Makefile, and if so, is my change likely to >work as intended? distutils.sysconfig.parse_makefile() handles parsing of Makefiles. extension.py uses it to parse the Setup file, and sysconfig.py parses the main Makefile and then looks for a few settings such as LDSHARED. It doesn't look for PY_CFLAGS, so this change should be safe. --amk From gotcha@swing.be Wed Jul 24 13:47:03 2002 From: gotcha@swing.be (Godefroid Chapelle) Date: Wed Jul 24 12:47:03 2002 Subject: [Distutils] Trying to build extensions with Borland compiler Message-ID: <5.1.0.14.2.20020724184341.00abca00@pop.swing.be> Hi, When running the Zope3 C extensions building script, I get the following message generated by distutils.spawn module : Building extensions in C:\Projects\Zope3\lib\python\Zope\Security running build_ext building '_Proxy' extension skipping _Proxy.c (build\temp.win32-2.2\Release\_proxy.obj up-to-date) writing build\temp.win32-2.2\Release\_Proxy.def c:\Program Files\Borland\Bcc55\bin\ilink32.exe /Tpd /Gn /q /x /LC:\Python22\libs /L. "/Lc:\Program Files\Borland\Bcc55\lib" c0d32 build\temp.win32-2.2\Release\_ proxy.obj , _Proxy.pyd ,, C:\Python22\libs\python22_bcpp.lib import32 cw32mt , b uild\temp.win32-2.2\Release\_Proxy.def , Fatal: Unable to open file 'LIB.OBJ' error: command 'ilink32.exe' failed with exit status 2 I have not been able to find out where this LIB.OBJ file should be found. I wonder if it comes from the Borland side or from the Python library side. I must say that the _proxy.obj was built on my machine with the compiler. Any help appreciated. -- Godefroid Chapelle BubbleNet sprl rue Victor Horta, 18 / 202 1348 Louvain-la-Neuve Belgium Tel + 32 (10) 459901 Mob + 32 (477) 363942 TVA 467 093 008 RC Niv 49849 From R.Liebscher@gmx.de Thu Jul 25 05:35:01 2002 From: R.Liebscher@gmx.de (Rene Liebscher) Date: Thu Jul 25 04:35:01 2002 Subject: [Distutils] Trying to build extensions with Borland compiler References: <5.1.0.14.2.20020724184341.00abca00@pop.swing.be> Message-ID: <3D3FB8CC.8014C288@gmx.de> Godefroid Chapelle wrote: > > Hi, > > When running the Zope3 C extensions building script, I get the following > message generated by distutils.spawn module : > > Building extensions in C:\Projects\Zope3\lib\python\Zope\Security > running build_ext > building '_Proxy' extension > skipping _Proxy.c (build\temp.win32-2.2\Release\_proxy.obj up-to-date) > writing build\temp.win32-2.2\Release\_Proxy.def > c:\Program Files\Borland\Bcc55\bin\ilink32.exe /Tpd /Gn /q /x > /LC:\Python22\libs > /L. "/Lc:\Program Files\Borland\Bcc55\lib" c0d32 > build\temp.win32-2.2\Release\_ > proxy.obj , _Proxy.pyd ,, C:\Python22\libs\python22_bcpp.lib import32 > cw32mt , b > uild\temp.win32-2.2\Release\_Proxy.def , > Fatal: Unable to open file 'LIB.OBJ' > error: command 'ilink32.exe' failed with exit status 2 > > I have not been able to find out where this LIB.OBJ file should be found. I > wonder if it comes from the Borland side or from the Python library side. I think this is a problem with the quoting in the command line. "/Lc:\Program Files\Borland\Bcc55\lib" probably is interpreted as /Lc:\Program Files\Borland\Bcc55\lib You could try to fix the command line quoting in distutils (file bcppcompiler.py in method link. I would do, but I don't have a Windows machine available now.) or you install bcc55 in a path with spaces in it. > > I must say that the _proxy.obj was built on my machine with the compiler. > > Any help appreciated. > -- > > Godefroid Chapelle > Kind regards Rene Liebscher From gotcha@swing.be Thu Jul 25 06:05:02 2002 From: gotcha@swing.be (Godefroid Chapelle) Date: Thu Jul 25 05:05:02 2002 Subject: [Distutils] Trying to build extensions with Borland compiler In-Reply-To: <3D3FB8CC.8014C288@gmx.de> References: <5.1.0.14.2.20020724184341.00abca00@pop.swing.be> Message-ID: <5.1.0.14.2.20020725110014.00abcc80@pop.swing.be> At 10:37 25/07/2002, Rene Liebscher wrote: >I think this is a problem with the quoting in the command line. > >"/Lc:\Program Files\Borland\Bcc55\lib" > >probably is interpreted as > >/Lc:\Program Files\Borland\Bcc55\lib > >You could try to fix the command line quoting in distutils >(file bcppcompiler.py in method link. >I would do, but I don't have a Windows machine available now.) >or you install bcc55 in a path with spaces in it. Thanks. I moved bcc55 to a path without spaces and it did work... I'll try to understand where the problem lies -ie on Borland linker side or on distutils side- and come back later about it. -- Godefroid Chapelle BubbleNet sprl rue Victor Horta, 18 / 202 1348 Louvain-la-Neuve Belgium Tel + 32 (10) 459901 Mob + 32 (477) 363942 TVA 467 093 008 RC Niv 49849 From barry@python.org Thu Jul 25 10:24:02 2002 From: barry@python.org (Barry A. Warsaw) Date: Thu Jul 25 09:24:02 2002 Subject: [Distutils] Re: [I18n-sig] JapaneseCodecs 1.4.7 released References: <200207121650.g6CGo4N15961@grad.sccs.chukyo-u.ac.jp> <15679.37981.879403.546544@anthem.wooz.org> Message-ID: <15679.64403.935865.272438@anthem.wooz.org> [Adding distutils-sig@python.org >>>>> "MvL" == Martin v Loewis writes: >> I just realized we still have a problem with this distutils >> package. It still insists on installing japanese.pth in >> /usr/local/lib/python-2.2/site-packages even if I include >> --install-lib and --install-purelib switches to the "python >> setup.py install" command. MvL> Since japanese.pth is processed as a 'data' file, you have MvL> two options: 1. Only invoke the install_lib command, not the MvL> install command. This will then avoid the install_headers, MvL> install_scripts, and install_data commands (the first two not MvL> being used here, anyway). MvL> 2. Provide the --install-data= argument to the install MvL> command, to specify an alternative prefix for data files. I think I'm going to go with your second suggestion, since it fits in better with what I've already got. ObDistutils: the install command has a --root option and a --home option, both of which would seem to do what I want, but neither quite do. E.g. invoking install with --root=/tmp/foo leaves me with /tmp/foo/usr/local/lib/python2.1/site-packages/ and invoking with --home=/tmp/foo leaves me with /tmp/foo/lib/python/ What I really want is an option to leave me with /tmp/foo/ so that I can put /tmp/foo on sys.path and be done with it, yet still guarantee that distutils will only install files under /tmp/foo and no where else. It seems that I'm left with this as my best option: % python setup.py install --install-lib /tmp/foo --install-purelib \ /tmp/foo --install-data /tmp/foo That still leaves me with /tmp/foo/lib/pythonX.Y/site-packages/japanese.pth but I'll ignore that for now . Am I whacked not to want those extra directories in what I have to set my PYTHONPATH to? Maybe I'm just bucking the natural order of things, but I still think I'd like an install command option that collapses those three options into one. If distutils is going to be used to install stuff in a site-packages override directory, or in a user-specific search-first directory, I think we need to make this simpler. but-maybe-I'm-insane-ly y'rs, -Barry From robin@jessikat.fsnet.co.uk Sat Jul 27 11:43:02 2002 From: robin@jessikat.fsnet.co.uk (Robin Becker) Date: Sat Jul 27 10:43:02 2002 Subject: [Distutils] setting string macros Message-ID: I'm having a problem win32 vs freeBSD/unices under win32 the executed command string appears like this -DLIBART_VERSION=\"2.3.10\" so the setup.py code looks like define_macros=[('LIBART_VERSION','\\"2.3.10\\"')] but this causes problems with unices (unterminated string constant errors) and I have to use define_macros=[('LIBART_VERSION','"2.3.10"')] I guess this relates to problems in system under win32, but is there a 'correct' way to get string macros defined. -- Robin Becker