From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Sat, 29 Mar 2003 05:00:44 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 85 ************************************************** Friday 28 March 2003 Number 85 ************************************************** Subjects for today 1 Re: Building Python : Andrew MacIntyre 2 Re: Building Python : John Poltorak 3 Re: conflicting types for `_getcwd2' : Stefan Neis 4 Re: conflicting types for `_getcwd2' : Stefan Neis 5 Re: Building Python : Steve Wendt" 6 Re: Making PKGs : John Poltorak 7 Re: Making PKGs : Andreas Buening 8 Re: Making PKGs : John Poltorak 9 Re: Building Python : Dave and Natalie" 10 Re: Making PKGs : Andreas Buening **= Email 1 ==========================** Date: Sat, 29 Mar 2003 09:55:49 +1000 (est) From: Andrew MacIntyre Subject: Re: Building Python On Thu, 27 Mar 2003, Dave and Natalie wrote: > On Thu, 27 Mar 2003 21:31:05 +0000, John Poltorak wrote: > > >I'd like to build and install Python into a more Unix-like directory > >structure. Can anyone tell me where it is usually installed? > > On my Debian partition it is installed \usr\lib eg > Directory of L:\usr\lib Debian is an exception. The vast majority, and Python's default, install in /usr/local/... You can in fact, as I've previously stated, install my binary distribution into such a structure by:- - put the .exe's in /usr/local/bin - put python22.dll wherever you put DLLs in /usr/local - move the Lib directory structure to /usr/local/python2.2 - move the Include directory to /usr/local/python2.2/include - set PYTHONHOME to /usr/local/python2.2 - set PYTHONPATH appropriately In building this yourself, you'll need to doctor PC/os2emx/pyconfig.h to change the #defines for: PREFIX (default if $PYTHONHOME not set) PYTHONPATH (default if $PYTHONPATH not set) I just noticed that my 2.2.2 distribution has PREFIX set to /usr - as my docs state that PYTHONHOME should be set, this never comes into play. I don't plan to support any of my work through the python configure script, but if you send me your makefile+pyconfig.h, I'll add build support for UnixOS2 as a target environment (ie "make UnixOS2"). There are some things that won't work if built with the standard configure script (most of the OS/2 specific support, including multithreading AFAIK). The optional extensions will end up being supported via a setup.py script in the os2emx directory (I haven't been able to use the standard one for my work because it assumes a genuine Unix platform), but the standard setup.py script may work for UnixOS2. -- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac at bullseye.apana.org.au | Snail: PO Box 370 andymac at pcug.org.au | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia **= Email 2 ==========================** Date: Sat, 29 Mar 2003 10:01:15 +0000 From: John Poltorak Subject: Re: Building Python On Sat, Mar 29, 2003 at 09:55:49AM +1000, Andrew MacIntyre wrote: > On Thu, 27 Mar 2003, Dave and Natalie wrote: > > > On Thu, 27 Mar 2003 21:31:05 +0000, John Poltorak wrote: > > > > >I'd like to build and install Python into a more Unix-like directory > > >structure. Can anyone tell me where it is usually installed? > > > > On my Debian partition it is installed \usr\lib eg > > Directory of L:\usr\lib > > Debian is an exception. > > The vast majority, and Python's default, install in /usr/local/... > > You can in fact, as I've previously stated, install my binary distribution > into such a structure by:- > - put the .exe's in /usr/local/bin > - put python22.dll wherever you put DLLs in /usr/local > - move the Lib directory structure to /usr/local/python2.2 > - move the Include directory to /usr/local/python2.2/include > - set PYTHONHOME to /usr/local/python2.2 > - set PYTHONPATH appropriately > > In building this yourself, you'll need to doctor PC/os2emx/pyconfig.h > to change the #defines for: > PREFIX (default if $PYTHONHOME not set) > PYTHONPATH (default if $PYTHONPATH not set) > > I just noticed that my 2.2.2 distribution has PREFIX set to /usr - as my > docs state that PYTHONHOME should be set, this never comes into play. > > I don't plan to support any of my work through the python configure > script, but if you send me your makefile+pyconfig.h, I'll add build > support for UnixOS2 as a target environment (ie "make UnixOS2"). There > are some things that won't work if built with the standard configure > script (most of the OS/2 specific support, including multithreading AFAIK). Is there any way that your stuff could be made to work through the normal build process? ie by changes to configure.in or Makefile.in for instance... I've been putting together a UnixOS/2 Build System which attempts to use a standard procedure of:- autoconf configure make make install and it it works very well in many cases > The optional extensions will end up being supported via a setup.py script > in the os2emx directory (I haven't been able to use the standard one > for my work because it assumes a genuine Unix platform), but the standard > setup.py script may work for UnixOS2. Can you provide more details... I'm not sure if you are aware of the UnixOS/2 Build System mailing list... Further details are available here:- http://os2ports.com/mailman/listinfo/ux2bs The main focus is testing the building of apps under UX2BS. UX2BS will actually bootstrap a build environment from a simple script and create a system in which you ought to be able to build and install any app automatically just by running:- build APPNAME It already builds newer versions of some of the apps required by Python such as READLINE and GDBM. It would be good to get your comments on what it has to offer and how it could be improved. I was actually surprised that:- build python created a runnable OS/2 binary. > -- > Andrew I MacIntyre "These thoughts are mine alone..." > E-mail: andymac at bullseye.apana.org.au | Snail: PO Box 370 > andymac at pcug.org.au | Belconnen ACT 2616 > Web: http://www.andymac.org/ | Australia > -- John **= Email 3 ==========================** Date: Sat, 29 Mar 2003 11:01:46 +0100 (CET) From: Stefan Neis Subject: Re: conflicting types for `_getcwd2' On Fri, 28 Mar 2003, John Poltorak wrote: > In file included from assert.c:20: > u:\unixos2\emx\include\stdlib.h:229: conflicting types for `_getcwd2' > u:\unixos2\emx\include\stdlib.h:163: previous declaration of `_getcwd2' > In file included from assert.c:21: > u:\unixos2\emx\include\unistd.h:99: conflicting types for `_getcwd2' > u:\unixos2\emx\include\stdlib.h:229: previous declaration of `_getcwd2' > > Is there anything I can do about this? Looking at the headers, line 163 of stdlib.h and line 99 of unistd.h really do decalre "getcwd", so there presumably is something like #define getcwd _getcwd2 or #define getcwd(a,b) _getcwd2(a,b) Move that define somewhere _after_ including stdlib.h and unistd.h... Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 4 ==========================** Date: Sat, 29 Mar 2003 11:01:46 +0100 (CET) From: Stefan Neis Subject: Re: conflicting types for `_getcwd2' On Fri, 28 Mar 2003, John Poltorak wrote: > In file included from assert.c:20: > u:\unixos2\emx\include\stdlib.h:229: conflicting types for `_getcwd2' > u:\unixos2\emx\include\stdlib.h:163: previous declaration of `_getcwd2' > In file included from assert.c:21: > u:\unixos2\emx\include\unistd.h:99: conflicting types for `_getcwd2' > u:\unixos2\emx\include\stdlib.h:229: previous declaration of `_getcwd2' > > Is there anything I can do about this? Looking at the headers, line 163 of stdlib.h and line 99 of unistd.h really do decalre "getcwd", so there presumably is something like #define getcwd _getcwd2 or #define getcwd(a,b) _getcwd2(a,b) Move that define somewhere _after_ including stdlib.h and unistd.h... Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 5 ==========================** Date: Sat, 29 Mar 2003 19:05:20 -0800 (PST) From: "Steve Wendt" Subject: Re: Building Python On Sun, 30 Mar 2003 09:45:50 +1000 (est), Andrew MacIntyre wrote: >I personally find that the Linux distro approach sucks, because without >delving into the package database you can't easily separate whats optional >and what's not. ??? Everything is optional, if you don't break dependencies for something you really want. ;) ----------- "Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws." - Plato (427-347 B.C.) **= Email 6 ==========================** Date: Sat, 29 Mar 2003 21:12:39 +0000 From: John Poltorak Subject: Re: Making PKGs On Sat, Mar 29, 2003 at 09:14:13PM +0100, Andreas Buening wrote: > John Poltorak wrote: > > > > The UnixOS/2 Build System seems to be working pretty well now for quite a > > number of apps. What I would like to do in the future is to create PKGs > > for installation via PKGTOOL. What I would like to have is some program > > which build PKGs. > > With "PKGTOOL" you mean installpkg? AIUI installpkg is based on a PKGTOOL set of utils as provided by Slackware for Software installation and management. > > Does anyone knoe if such a program exists? > > Another question: Does the installation tool work for you > as expected? I don't use it and don't think we are yet in a position make PKGs properly. > Bye, > Andreas > > -- > One OS to rule them all, One OS to find them, > One OS to bring them all and in the darkness bind them > In the Land of Mordor where the Shadows lie. -- John **= Email 7 ==========================** Date: Sat, 29 Mar 2003 21:14:13 +0100 From: Andreas Buening Subject: Re: Making PKGs John Poltorak wrote: > > The UnixOS/2 Build System seems to be working pretty well now for quite a > number of apps. What I would like to do in the future is to create PKGs > for installation via PKGTOOL. What I would like to have is some program > which build PKGs. With "PKGTOOL" you mean installpkg? > Does anyone knoe if such a program exists? Another question: Does the installation tool work for you as expected? Bye, Andreas -- One OS to rule them all, One OS to find them, One OS to bring them all and in the darkness bind them In the Land of Mordor where the Shadows lie. **= Email 8 ==========================** Date: Sat, 29 Mar 2003 23:06:34 +0000 From: John Poltorak Subject: Re: Making PKGs On Sat, Mar 29, 2003 at 11:41:44PM +0100, Andreas Buening wrote: > John Poltorak wrote: > > > > On Sat, Mar 29, 2003 at 09:14:13PM +0100, Andreas Buening wrote: > > > John Poltorak wrote: > > > > > > > > The UnixOS/2 Build System seems to be working pretty well now for quite a > > > > number of apps. What I would like to do in the future is to create PKGs > > > > for installation via PKGTOOL. What I would like to have is some program > > > > which build PKGs. > > > > > > With "PKGTOOL" you mean installpkg? > > > > AIUI installpkg is based on a PKGTOOL set of utils as provided by > > Slackware for Software installation and management. > > I have no idea what you're talking about. The installpkg > I have doesn't use any other tools (except unzip). I'm talking about the _principles_ behind software management, not the current state of installpkg. installpkg is based on the Slackware program in terms of functionality, although it isn't a port but a re-write in REXX. > Bye, > Andreas > > -- > One OS to rule them all, One OS to find them, > One OS to bring them all and in the darkness bind them > In the Land of Mordor where the Shadows lie. -- John **= Email 9 ==========================** Date: Sat, 29 Mar 2003 23:22:35 -0800 From: "Dave and Natalie" Subject: Re: Building Python On Sun, 30 Mar 2003 09:45:50 +1000 (est), Andrew MacIntyre wrote: > >I have to say I've not used any recent Linux distro (the last I used was >Debian), so my comments concerning Linux would appear out of date. Well the oldest distro I have here is slackware 2.2 (kernel 1.3) and it doesn't even have python. The only mention of python is in the sendmail src. It does have /usr/lib/perl4 (and perl5 .01 as an option). So even back then ('95) they were considering that you might have 2 incompatible packages installed. >In general, the Linux distros would appear to be taking the view that if >its packaged by the distro it goes into /usr. Sounds logical, distro supplied files go into /usr and packages from elsewhere go into /usr/local. That way if I want to install the newest I can. Especially important with Debian as they're very conservative in releases. > >The BSDs certainly don't - ports packages in *BSD aren't part of the base >OS so go in /usr/local. Solaris had a similar approach, except packages >went in /opt (though this is now more for commercial packages, OSS is now >largely using /usr/local last time I looked). Don't know much about the BSDs but I think the next thing I install will be one. Any recommendations? With Solaris I'd guess that any OSS software that is installed didn't come from Sun so should go into /usr/local. > >I personally find that the Linux distro approach sucks, because without >delving into the package database you can't easily separate whats optional >and what's not. With Debian its quite easy, just fire up dselect and the first catagory is required packages, eg bash, gzip, libc5, etc. The rest are optional Dave ps I have a redhat 5.0 install which has python in /usr/lib/python1.5 **= Email 10 ==========================** Date: Sat, 29 Mar 2003 23:41:44 +0100 From: Andreas Buening Subject: Re: Making PKGs John Poltorak wrote: > > On Sat, Mar 29, 2003 at 09:14:13PM +0100, Andreas Buening wrote: > > John Poltorak wrote: > > > > > > The UnixOS/2 Build System seems to be working pretty well now for quite a > > > number of apps. What I would like to do in the future is to create PKGs > > > for installation via PKGTOOL. What I would like to have is some program > > > which build PKGs. > > > > With "PKGTOOL" you mean installpkg? > > AIUI installpkg is based on a PKGTOOL set of utils as provided by > Slackware for Software installation and management. I have no idea what you're talking about. The installpkg I have doesn't use any other tools (except unzip). > > > Does anyone knoe if such a program exists? > > > > Another question: Does the installation tool work for you > > as expected? > > I don't use it and don't think we are yet in a position make PKGs > properly. Bye, Andreas -- One OS to rule them all, One OS to find them, One OS to bring them all and in the darkness bind them In the Land of Mordor where the Shadows lie.