From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Thu, 25 Jul 2002 04:33:26 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 283 ************************************************** Wednesday 24 July 2002 Number 283 ************************************************** Subjects for today 1 Re: wxWindows : Lord Spigol" 2 Re: Clearing the environment? : Maynard" 3 RE: wxWindows : Dave Webster 4 RE: wxWindows : Dave Webster 5 RE: wxWindows : Dave Webster 6 Re: Clearing the environment? : John Poltorak 7 RE: wxWindows : Dave Webster 8 Unixos2 bootstrap and Perl build result : Csaba" 9 Re: Using YACC when building FLEX : Csaba" 10 Re: wxWindows : John Poltorak 11 RE: wxWindows : Dave Webster 12 Re: wxWindows : John Poltorak 13 Re: Building emacs : John Poltorak 14 Re: Unixos2 bootstrap and Perl build result : John Poltorak 15 Re: wxWindows : Stefan Neis 16 RE: wxWindows : Stefan Neis 17 Re: Perl Building : Stefan Neis 18 Re: Building emacs : Stefan Neis 19 Re: ln.cmd : John Drabik" 20 Re: Using YACC when building FLEX : John Poltorak 21 Re: Building emacs : Christian Hennecke" 22 New Flex : John Poltorak 23 Re: wxWindows : John Poltorak 24 Re: wxWindows : Stefan Neis 25 Building GZIP : John Poltorak 26 RE: wxWindows : Dave Webster 27 RE: wxWindows : Andrea Venturoli 28 RE: wxWindows : Dave Webster 29 Re: Using YACC when building FLEX : Stefan Neis 30 Re: Using YACC when building FLEX : John Poltorak 31 ln.cmd : John Poltorak 32 Re: UnixOS/2 bootstrap : Dave Saville" 33 Re: UnixOS/2 bootstrap : John Poltorak 34 Re: Building GZIP : xyzyx" 35 RE: wxWindows : Csaba" 36 Re: Using YACC when building FLEX : Csaba" **= Email 1 ==========================** Date: Thu, 25 Jul 2002 07:13:37 -0300 (ADT) From: "Lord Spigol" Subject: Re: wxWindows John, you have my admiration! Sometimes I wondered about what the Unix folks have did to ease the software instalation on Unix/Linux. This & WPS for Linux are a great step for the Unix world. []s Rod On Thu, 25 Jul 2002 09:01:36 +0100, John Poltorak wrote: >One of the things I'm trying to come up with is a 'build system' for OS/2 >which will allow apps to install just as easily on OS/2 as Linux. **= Email 2 ==========================** Date: Thu, 25 Jul 2002 07:24:37 -0500 (CDT) From: "Maynard" Subject: Re: Clearing the environment? On Wed, 24 Jul 2002 22:18:39 -0500 (CDT), xyzyx wrote: >Does anyone have a script to clear out the environment variables? I've >got a ton of settings from my "normal" EMX setup which I'm pretty sure >are interfering with UnixOS2. Here's what I'm using to date; would appreciate incorporating any enhancements. --Maynard rem save the required elements of current environment: rem I stopped short of creating a for %%f in (OSRT) ...... method if exist save_env.cmd del save_env.cmd echo %OSRT% | sed "s/^/set OSRT=/" >>save_env.cmd echo %UXRT% | sed "s/^/set UXRT=/" >>save_env.cmd echo %BLDRT% | sed "s/^/set BLDRT=/" >>save_env.cmd echo %BLD_HOME% | sed "s/^/set BLD_HOME=/" >>save_env.cmd REM echo %REPOSITORY% | sed "s/^/set REPOSITORY=/" >>save_env.cmd echo %ETC% | sed "s/^/set ETC=/" >>save_env.cmd echo %HOSTNAME% | sed "s/^/set HOSTNAME=/" >>save_env.cmd echo %OS2_SHELL% | sed "s/^/set OS2_SHELL=/" >>save_env.cmd echo %PROMPT% | sed "s/^/set PROMPT=/" >>save_env.cmd echo %TEMP% | sed "s/^/set TEMP=/" >>save_env.cmd echo %TZ% | sed "s/^/set TZ=/" >>save_env.cmd echo %USE_HOSTS_FIRST% | sed "s/^/set USE_HOSTS_FIRST=/" >>save_env.cmd rem clear the entire current environment: env | sed "s/^/set /;s/=.*$/=/" >clearenv.cmd call clearenv.cmd rem then restore the required elements call save_env.cmd **= Email 3 ==========================** Date: Thu, 25 Jul 2002 07:39:04 -0500 From: Dave Webster Subject: RE: wxWindows THat would certainly help. -----Original Message----- From: John Poltorak [mailto:jp at eyup.org] Sent: Thursday, July 25, 2002 3:02 AM To: os2-unix at eyup.org Subject: Re: wxWindows On Wed, Jul 24, 2002 at 03:54:10PM -0500, Dave Webster wrote: > Typically all wxWindows Open Source projects use the > Linux/Unix model of distribution where you untar/zip the tarball and then > "make" it. Some of us are trying hard to get them to adopt a more > Windows/MAC/OS2 method of allowing users to download a setup that simply > installs the exe and any needed dlls, but that is very slow to catch on. One of the things I'm trying to come up with is a 'build system' for OS/2 which will allow apps to install just as easily on OS/2 as Linux. It seems to work reasonably well with Perl and I'm testing it with quite a number of apps, so that by the time wxWindows is released, its installation may not be as burdensome as it would normally be... -- John **= Email 4 ==========================** Date: Thu, 25 Jul 2002 07:47:30 -0500 From: Dave Webster Subject: RE: wxWindows wx.lib, debug, statically linked with VisualAge C++ V3.0 FP8 is 53,153,996 bytes in size. That includes sources from common, generic, html, os2, png, jpeg, tiff, regex and zlib. Statically linked minimal under VA is still over 14MB. Release is quite a bit smaller but still quite large. wx.dll is also large with the debug version being right at 50MB in size. The exe's however are very small running less than 500K in size. Have never tried to zip them up, though. Good to hear the lib is still being built with EMX. -----Original Message----- From: Stefan Neis [mailto:neis at cdc.informatik.tu-darmstadt.de] Sent: Thursday, July 25, 2002 5:24 AM To: 'os2-unix at eyup.org' Subject: RE: wxWindows On Wed, 24 Jul 2002, Dave Webster wrote: > build/link it, then run it. The dll and static lib are both over 50MB in > size and many of the statically linked samples exceed 20MB so giving them to > you as an e-mail attachment is impossible. Really? Is that the debug version? February's EMX compiled static debug library had something like 35MB (non-debug less than 10), typical statically linked samples (minimal, menu) were about 1.4MB in size... Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 5 ==========================** Date: Thu, 25 Jul 2002 07:53:39 -0500 From: Dave Webster Subject: RE: wxWindows Frankly, I have not spent any time at all with all the autoconf stuff. I just choose to keep my VisualAge makefile up to date mannually which has been no problem at all. It has been a long time since I had to add or delete contents from it. What wxWindows based apps really need for the Windows (and OS/2) environment is a properly prepared InstallShield/Window Installer type installation (and a corresponding installation package under OS/2, perhaps something like what VisualAge 4.0 and the latest TCPIP package have). You are NEVER going to get Windows and OS/2 users to do the Unix "make" installation thing, not ever. -----Original Message----- From: Stefan Neis [mailto:neis at cdc.informatik.tu-darmstadt.de] Sent: Thursday, July 25, 2002 5:19 AM To: os2-unix at eyup.org Subject: Re: wxWindows On Thu, 25 Jul 2002, John Poltorak wrote: > One of the things I'm trying to come up with is a 'build system' for OS/2 > which will allow apps to install just as easily on OS/2 as Linux. Well, wxWindows is onw of the cases where the "autoconf && configure && make" business does work (provided you have the right versions of everything needed and after setting some environment variables). I'm interested in seeing what needs to be done to get rid of the autoconf step after the recent switch to current autoconf with its better OS/2 support, but had no time to do it so far. And right now, wxWindows CVS got updated to cvs-1.11.2 which seems to be incompatible with all older clients, so I'm out of it for the moment... Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 6 ==========================** Date: Thu, 25 Jul 2002 08:10:03 +0100 From: John Poltorak Subject: Re: Clearing the environment? On Wed, Jul 24, 2002 at 10:18:39PM -0500, xyzyx wrote: > Does anyone have a script to clear out the environment variables? I've > got a ton of settings from my "normal" EMX setup which I'm pretty sure > are interfering with UnixOS2. Try something like:- env | sed "s/^/set /;s/=.*$/=/" >clearenv.cmd clearenv.cmd > thanks, > paul -- John **= Email 7 ==========================** Date: Thu, 25 Jul 2002 08:23:38 -0500 From: Dave Webster Subject: RE: wxWindows Depends on what you expect out of a toolkit whose main purpose is to provide a stable cross platform, code once, compile anywhere, type facility. It also depends on what type of application you are developing. As I stated in my article, wxWindows, as it sits today, is NOT suitable for a lot of mainstream business use where app developers are primarily providing front end system's management for mission critical back end processing systems. It is gross overkill for that. But if you are developing the next office suite, CAD/CAM, photo processing, genetic sequencing, or any GUI app that requires a full set of modern, exotic GUI feature, then wxWindows may be your only viable choice in a C++ environment, especially if you are targeting it at Windows, MAC, Linux and/or OS2 users. Also not sure about what you would expect to see from a wx release. The best you are ever going to get for OS/2 is: 1) For use as purely a development toolkit (not to update the lib itself): a static lib, debug and release, a dll, debug and release, for each compiler env supported and a series of headers and an html reference document, and sample set of makefiles. 2) If you want to modify/fix the library itself you'd get the source and a library makefile for each compiler. In both cases the samples and demos would NEVER come in executable format. It's that way with V, IOCL and most other toolkits out there. Basically, you'd get something akin to a Rogue Wave CD, a series libs, dlls, and header files and perhaps some sample makefiles for each supported compiler. Not sure what else a C++ development toolkit would ever be expected to deliver? And remember, once again, wxOS2 has never been released and there has never been an application written using it, other than the internal samples and demos, which of course, you have to build for yourself. -----Original Message----- From: Hakan [mailto:agents at meddatainc.com] Sent: Wednesday, July 24, 2002 4:17 PM To: os2-unix at eyup.org Subject: RE: wxWindows I do not want to be too discouraging, however, in my opinion, this project will not have any impact on OS/2 application development. Hakan On Wed, 24 Jul 2002 15:54:10 -0500, Dave Webster wrote: >wxOS2 is available only via CVS from wxWindows.org. To even get to a demo, >you'd have to check out the distribution from the CVS tree via anonymous, >read-only access, build the library, then go to a particular sample, and >build/link it, then run it. The dll and static lib are both over 50MB in >size and many of the statically linked samples exceed 20MB so giving them to >you as an e-mail attachment is impossible. > >Hopefully by late August, the next formal release of wxWindows will be >available, and for the first time, wxOS2 with it. But even then, you'd have >to download it from the site or buy the CD, install it, build the library, >and link the demos yourself to get them. > >Understand the state of the project. It has never been released in any form >and is still incomplete. To get any kind of wxWindows app or demo you have >to download the source, and build it. That is how they do it over there. >The don't even put executable binaries on the CD. There are a few apps that >are available for wxWindows in executable form, like wxDesigner, but you >have to pay for them. Typically all wxWindows Open Source projects use the >Linux/Unix model of distribution where you untar/zip the tarball and then >"make" it. Some of us are trying hard to get them to adopt a more >Windows/MAC/OS2 method of allowing users to download a setup that simply >installs the exe and any needed dlls, but that is very slow to catch on. >They are a bit slow to realize that typical Windows/OS2 users do not have >any ability to "make" anything. But the core group is dominated nowadays by >a very Linux oriented crowd so get used to the tarball/make routine if you >want to use this library for any development, or even a lot of apps >developed under it. > > >-----Original Message----- >From: Hakan [mailto:agents at meddatainc.com] >Sent: Wednesday, July 24, 2002 2:41 PM >To: os2-unix at eyup.org >Subject: RE: wxWindows > > >I was hoping you would point me to some demos of vxWindows for OS/2... >Alas, no. Can you point me to some demo programs running under OS/2? > >Thank you. > >Hakan > >On Wed, 24 Jul 2002 13:53:37 -0500, Dave Webster wrote: > >>Yes, there are plenty of demos via the wxWindows samples, some of which are >>pretty exotic. >> >>As for the lowest common denominator as it pertains to features, I can >>attest, after over 3 years of working on the project OS/2 is by far and >wide >>the most primitive GUI wxWindows supports (at least until they hit the >>embedded OS's) and I actually have to add a great deal of capability to >OS/2 >>from scratch (areas such as guages, progress bars, statusbars, toolbars, >>tooltips, over a dozen dialogs common to most GUI's at the API level not in >>OS/2 PM and so on). However, things unique to a particular OS, if that >>feature is truly unique to a particular OS, are justifiable ignored as that >>defeats the purpose of a cross-platform toolkit in the first place. >> >>Philosophically speaking, we live in a Windows-centric universe now. The >>realities of cross platform development, especially in a commercial sense, >>are that the Windows product ships first. If successful, other ports may >>happen. The easier the porting effort the better the chance a major app >>will make it to other platforms. With wxWindows, that effort is nearly >>trivial, and that is why it was originally developed over 10 years >>ago....the desire to create something in Windows, prove its viability on >the >>dominant OS, and then, if a hit, port it to Linux Gtk, Motif and the MAC >>(and now OS/2) and execute it using native widgets (unlike Java and most >>other cross-platform GUI toolkits). The dominant OS dictates the GUI >>feature set. The reality is that OS/2 is long in the tooth as GUI's go and >>really quite primitive. WPS is about the only thing it has going for it >>that most others do not. >> >>I have looked at almost every cross platform GUI toolkit out there, >>including IOCL, V, Fox, and at least two dozen others. Nothing is nearly >as >>complete and all encompassing as wxWindows, not even close (auto grids, >auto >>sizers, auto layout controls, wizard controls and such as well as fully >>implemented Unicode support). But therein lies wxWindows biggest weakness, >>it is like trying to take a drink from a fire hydrant. >> >>-----Original Message----- >>From: Hakan [mailto:agents at meddatainc.com] >>Sent: Wednesday, July 24, 2002 12:44 PM >>To: os2-unix at eyup.org >>Subject: RE: wxWindows >> >> >>Well, I am curious because, as already pointed out, the business case >>as to why a software developer should use vxWindows in order to reach >>the OS/2 market is very weak. The Linux market may offer a stronger >>case. Compiliing an application is just part of the equation. >> >>Furthermore, cross-platform libraries tend to be written to the lowest >>common denominator, thereby excluding features exclusive to OS/2 (or >>other operating systems), e.g., the WPS. >> >>What about demos of vxWindows compiled for OS/2? Surely there must be >>some? >> >>Hakan >> >>On Wed, 24 Jul 2002 12:06:07 -0500, Dave Webster wrote: >> >>>There are no shipping apps for OS/2 as wxOS2 is not a released port. Most >>>of the wxWindows samples work, tough. For examples of current wxWindows >>>apps go to www.wxWindows.org. There are an ever growing number of them >>>readily available, but most are vertical market apps and apps developed >for >>>internal use at this point. And that will likely be where the bulk of >>>wxWindows development happens, inside corporations for internal use, >>>especially for those needing cross-platform capabilities. However, there >>is >>>no reason why something like wxDesigner could not simply be compiled under >>>VisualAge C++ V3.0 FP 8 and shipped as an OS/2 product. >>> >>>Prior to the release I hope to at least put up some screen shots on the wx >>>web site. >>> >>>-----Original Message----- >>>From: Hakan [mailto:agents at meddatainc.com] >>>Sent: Wednesday, July 24, 2002 11:32 AM >>>To: os2-unix at eyup.org >>>Subject: RE: wxWindows >>> >>> >>>Dave, >>> >>>Can you give us examples of applications using vxWindows (preferably >>>OS/2 applications although I do understand that the OS/2 port is not >>>complete)? >>> >>>Hakan >>> >>>On Wed, 24 Jul 2002 10:51:30 -0500, Dave Webster wrote: >>> >>>>I've heard that there is a reasonable chance Open Office very well might. >>>>As for Mozilla, there are supposedly competing products underway using >>>>wxWindows that may make that moot. WxWindows has been around for 10 >>years, >>>>but only in the last year or so is library beginning to get a big >>>following. >>>>One of the reasons is that some of the principals have moved out of the >>>>world of Academia and into the European business community and are really >>>>preaching the wx gospel to a much wider audience now, and folks are >>finally >>>>starting to listen. >>>> >>>>The thing is, it is important to get wxOS2 out there in a reasonably >>useful >>>>state to take advantage of the potential explosion of wxWindows based >mass >>>>market apps that should start appearing in the next two years. Wx also >>>>needs a replacement for SciTech. SciTech was slated to be a corporate >>>>support wrapper around wxWindows in much the same fashion that IBM and HP >>>>are corporate support wrappers around Linux. Large, commercial shops and >>>>Fortune 1000 type companies are simply not comfortable with any Open >>Source >>>>software unless there is this corporate wrapper around it. SciTech folks >>>>apparently had some major falling out with the principals over how the wx >>>>product is managed and pretty much abandoned their wxMGL effort as a >>>result. >>>>Too bad. It really needs a significant corporate sponsor so if you or >>>>anyone knows of one, that would be a great boon to the wxWindows effort. >>>> >>>>-----Original Message----- >>>>From: John Poltorak [mailto:jp at eyup.org] >>>>Sent: Wednesday, July 24, 2002 10:18 AM >>>>To: os2-unix at eyup.org >>>>Subject: Re: wxWindows >>>> >>>> >>>>On Wed, Jul 24, 2002 at 09:23:33AM -0500, Dave Webster wrote: >>>>> Most of the development with wxWindows today is in vertical market >>>>software >>>>> and not in the mass market area at all. Companies like using wx to >>build >>>>> cross platform (and just single platform as it is a wonderful toolkit >on >>>>any >>>>> platform) apps with very narrowly focused purpose. There have been >some >>>>> recent announcements that have yet to make the wxWindows web site of >>some >>>>> fairly significant Windows based software companies switching to >>>wxWindows >>>>> from MFC. IBM currently uses it. >>>>> >>>>> If wxWindows ever makes a serious splash in the Window's world and >wxOS2 >>>>can >>>>> get to reasonably solid state, I can see it pretty much ending the >>>>> OPEN32/Odin effort as cross-compiling wxMSW source to wxOS2 is trivial >>to >>>>> converting a WIN32 app today using those. (remember wxWindows does not >>>>> typically rely on resource files at all so there is not a .rc file >>>>migration >>>>> ever needed). >>>> >>>> >>>>Is there any chance of Open Office being converted to use wxWindows? >Maybe >> >>>>Mozilla too... >>>> >>>> >>>>What compilers can be used with it? >>>> >>>>-- >>>>John >>>> >>>> >>>> >>> >>> >>> >>> >> >> >> >> > > > > **= Email 8 ==========================** Date: Thu, 25 Jul 2002 09:00:20 +0100 From: "Csaba" Subject: Unixos2 bootstrap and Perl build result 0100,0100,0100CourierFailed 6/726 test scripts, 99.17% okay. 19/68650 subtests failed, 99.97% okay. Failed Test Stat Wstat Total Fail Failed List of Failed ------------------------------------------------------------------------------- ../lib/ExtUtils/t/basic.t 1 256 17 1 5.88% 14 ../lib/Net/t/hostname.t 2 1 50.00% 1 lib/os2_process.t 8 2048 227 8 3.52% 13 19 37 80 85 94 174 209 lib/os2_process_kid.t 227 5 2.20% 80 85 94 174 209 lib/rx_cmprt.t 255 65280 18 3 16.67% 16-18 op/stat.t 73 1 1.37% 44 64 tests and 557 subtests skipped. Ceci n'est pas un .signature **= Email 9 ==========================** Date: Thu, 25 Jul 2002 09:00:20 +0100 From: "Csaba" Subject: Re: Using YACC when building FLEX 0100,0100,0100On 24 Jul 2002, at 21:24, John Poltorak wrote: [snip] 7F00,0000,0000> > So how would I incorporate that into this Makefile if I wanted to use yacc > instead of bison? :- > > # make file for "flex" tool, emx+gcc > > release: > $(MAKE) -f Makefile.os2 flex.exe \ > CC="gcc -Zomf -O" O=".obj" A=".lib" AR="emxomfar" \ > LDFLAGS="-s -Zcrtdll -Zstack 512" > debug: > $(MAKE) -f Makefile.os2 flex.exe \ > CC="gcc -g" O=".o" A=".a" AR="ar" > > CFLAGS = -DOS2 -DSHORT_FILE_NAMES > > YACC = bison YACC = yacc # #YACC = bison -y #This uses bison's yacc compatibility mode; #the same rule (below) could be used with both # 7F00,0000,0000> FLEX = flex > FLEX_FLAGS = -ist > > .SUFFIXES: .c $O > > .c$O: > $(CC) $(CFLAGS) -c $<< > > FLEXLIB = fl$A > FLEXOBJS = ccl$O dfa$O ecs$O gen$O main$O misc$O nfa$O parse$O \ > scan$O skel$O sym$O tblcmp$O yylex$O > LIBOBJS = libmain$O libyywrap$O > > flex.exe : $(FLEXOBJS) $(FLEXLIB) > $(CC) $(LDFLAGS) -o $ at $(FLEXOBJS) $(FLEXLIB) > > first_flex: > cp initscan.c scan.c > $(MAKE) $(MFLAGS) flex > > $(FLEXLIB): $(LIBOBJS) > $(AR) cru $(FLEXLIB) $(LIBOBJS) > $(AR) s $(FLEXLIB) > > parse.h parse.c: parse.y > $(YACC) -d -o parse.c parse.y Courierparse.h parse.c : parse.y $(YACC) -d parse.y mv y.tab.c parse.c mv y.tab.h parse.hArial 7F00,0000,0000> > scan.c : scan.l > $(FLEX) $(FLEX_FLAGS) $(COMPRESSION) scan.l >scan.c > [snip] Ceci n'est pas un .signature **= Email 10 ==========================** Date: Thu, 25 Jul 2002 09:01:36 +0100 From: John Poltorak Subject: Re: wxWindows On Wed, Jul 24, 2002 at 03:54:10PM -0500, Dave Webster wrote: > Typically all wxWindows Open Source projects use the > Linux/Unix model of distribution where you untar/zip the tarball and then > "make" it. Some of us are trying hard to get them to adopt a more > Windows/MAC/OS2 method of allowing users to download a setup that simply > installs the exe and any needed dlls, but that is very slow to catch on. One of the things I'm trying to come up with is a 'build system' for OS/2 which will allow apps to install just as easily on OS/2 as Linux. It seems to work reasonably well with Perl and I'm testing it with quite a number of apps, so that by the time wxWindows is released, its installation may not be as burdensome as it would normally be... -- John **= Email 11 ==========================** Date: Thu, 25 Jul 2002 10:27:26 -0500 From: Dave Webster Subject: RE: wxWindows Yes. I was referring to consumer-like apps that are developed using wxWindows. Far too often guys spend so much time in Open Source doing Linux stuff that when they try and do something in Windows or OS/2 they forget that for most users, Windows and OS/2do not come with any capability to build or "make" anything. They expect to click on a setup.exe, answer a few installation questions, let the installation do its thing and then run it. For the library itself, yes I would always recommend that users download the entire source, and then compile it using their own options (those that are not mandated by the library to build properly) so as to be compatible with the rest of their environment. I would not expect a toolkit to come with a "Windows Installer" type installation, although that is certainly doable if you are willing to live the makefiles and environment as they come. -----Original Message----- From: Andrea Venturoli [mailto:ml.ventu at flashnet.it] Sent: Thursday, July 25, 2002 3:32 PM To: os2-unix at eyup.org Subject: RE: wxWindows ** Reply to note from Dave Webster Thu, 25 Jul 2002 07:53:39 -0500 > What wxWindows based apps really need for the Windows (and OS/2) environment > is a properly prepared InstallShield/Window Installer type installation (and > a corresponding installation package under OS/2, perhaps something like what > VisualAge 4.0 and the latest TCPIP package have). You are NEVER going to > get Windows and OS/2 users to do the Unix "make" installation thing, not > ever. I don't see this as practical. The point is that you should compile it yourself for several reasons: you might have different compilers, different library versions, and different requirement on wxWindows itself; you might want a debug or a release version, you might want onyl wxBase or the full-featured wxGUI (wheter wxMSW, wxOS2, wxGTK, ...), you might need ODBC or might want to leave it out because you don't have the lower level packages (be that iODBC, MDAC, ...) and you don't feel keen on installing something you don't need. Practically there are hundred of ways to build that library, and probably a build made on a different system won't work on yours (unless you get, install and set up in a particular way the correct version of a lot of dependencies). Even the SETUP package, which do exists for Windows, only extract the sources as you can do from the zipfile. Of course end-user application are a different story... bye av. **= Email 12 ==========================** Date: Thu, 25 Jul 2002 11:39:49 +0100 From: John Poltorak Subject: Re: wxWindows On Thu, Jul 25, 2002 at 12:19:08PM +0200, Stefan Neis wrote: > On Thu, 25 Jul 2002, John Poltorak wrote: > > > One of the things I'm trying to come up with is a 'build system' for OS/2 > > which will allow apps to install just as easily on OS/2 as Linux. > > Well, wxWindows is onw of the cases where the "autoconf && > configure && make" business does work (provided you have the right > versions of everything needed and after setting some environment > variables). That's good to hear. I guess I should give it a try with my build system to see my baseline toolset is sufficient to get wxWindows built. > I'm interested in seeing what needs to be done to get > rid of the autoconf step after the recent switch to current autoconf > with its better OS/2 support, but had no time to do it so far. Although the current autoconf does has good OS/2 support, there are still a few patches which make that support better, so I would be inclined to retain the autoconf step for the time being. I wouldn't expect it to take long. Maybe you could compare the original supplied configure script with the new one produced after running autoconf. > And right now, wxWindows CVS got updated to cvs-1.11.2 which seems > to be incompatible with all older clients, so I'm out of it for the > moment... Is anyone looking at updating the OS/2 version of CVS? Maybe it will build anyway with the addition of the current OS/2 patches... > Regards, > Stefan > -- > Micro$oft is not an answer. It is a question. The answer is 'no'. > -- John **= Email 13 ==========================** Date: Thu, 25 Jul 2002 11:48:16 +0100 From: John Poltorak Subject: Re: Building emacs On Thu, Jul 25, 2002 at 12:36:17PM +0200, Stefan Neis wrote: > On Wed, 24 Jul 2002, Christian Hennecke wrote: > > > On Wed, 24 Jul 2002 13:09:25 +0100, John Poltorak wrote: > > > > >I managed to build emacs v20.7 recently with some considerable help from > > > > John, could you assemble a binary distribution? I guess there are quite > > some people who would like to use the latest Emacs, > ^^^^^^^^^^^^ ;-) > Aren't they at 21.something by now? :-( OK so *they* are at 21.*, but the latest one for us is 20.7. Unfortunately it's a 'flat pack' version where you bring it home and have to assemble it yourself so if you don't have the right tools it stays packed. Maybe our Japanese friends could create something which came pre-assembled... > Regards, > Stefan > -- > Micro$oft is not an answer. It is a question. The answer is 'no'. > -- John **= Email 14 ==========================** Date: Thu, 25 Jul 2002 12:16:21 +0100 From: John Poltorak Subject: Re: Unixos2 bootstrap and Perl build result On Thu, Jul 25, 2002 at 09:00:20AM +0100, Csaba wrote: > Failed 6/726 test scripts, 99.17% okay. 19/68650 subtests > failed, 99.97% okay. Failed Test Stat Wstat Total Fail > Failed List of Failed > ------------------------------------------------------------------------------- > ../lib/ExtUtils/t/basic.t 1 256 17 1 5.88% 14 > ../lib/Net/t/hostname.t 2 1 50.00% 1 > lib/os2_process.t 8 2048 227 8 3.52% 13 19 37 80 85 94 174 209 > lib/os2_process_kid.t 227 5 2.20% 80 85 94 174 209 > lib/rx_cmprt.t 255 65280 18 3 16.67% 16-18 > op/stat.t 73 1 1.37% 44 > 64 tests and 557 subtests skipped. This is looking like a familiar pattern... The rx_cmprt is some problem with REXX handling Unix line termination which has been pinpointed, but a fix hasn't been agreed yet. hostname is related to host name resolution and probably depends on various settings in %ETC% or having %HOSTNAME% set. I get the same error. op/stat is something I get, but not always. Most people seem to get the other three although the failing tests differ. Maybe it's hardware related... It would be nice to get the basic.t failure cracked as it appears to fail on a single test... -- John **= Email 15 ==========================** Date: Thu, 25 Jul 2002 12:19:08 +0200 (CEST) From: Stefan Neis Subject: Re: wxWindows On Thu, 25 Jul 2002, John Poltorak wrote: > One of the things I'm trying to come up with is a 'build system' for OS/2 > which will allow apps to install just as easily on OS/2 as Linux. Well, wxWindows is onw of the cases where the "autoconf && configure && make" business does work (provided you have the right versions of everything needed and after setting some environment variables). I'm interested in seeing what needs to be done to get rid of the autoconf step after the recent switch to current autoconf with its better OS/2 support, but had no time to do it so far. And right now, wxWindows CVS got updated to cvs-1.11.2 which seems to be incompatible with all older clients, so I'm out of it for the moment... Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 16 ==========================** Date: Thu, 25 Jul 2002 12:23:47 +0200 (CEST) From: Stefan Neis Subject: RE: wxWindows On Wed, 24 Jul 2002, Dave Webster wrote: > build/link it, then run it. The dll and static lib are both over 50MB in > size and many of the statically linked samples exceed 20MB so giving them to > you as an e-mail attachment is impossible. Really? Is that the debug version? February's EMX compiled static debug library had something like 35MB (non-debug less than 10), typical statically linked samples (minimal, menu) were about 1.4MB in size... Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 17 ==========================** Date: Thu, 25 Jul 2002 12:32:51 +0200 (CEST) From: Stefan Neis Subject: Re: Perl Building Hi, > [1] my fresh build completed with an unusual number of test failures; > so I compared the log file with an earlier log from a successful build. > The new log contained entries referencing a drive (p:) which is not > relevant to the current build at all; P: was from yesterday's Yes, that's something you can expect with all kind of open source software. If you take a build tree containing some compiled/configured stuff to a different box (which is not an exact clone of the existing one) you're lost. However, for almost all packages 'make distclean' should regenerate a clean source tree.. Regards, Stefan **= Email 18 ==========================** Date: Thu, 25 Jul 2002 12:36:17 +0200 (CEST) From: Stefan Neis Subject: Re: Building emacs On Wed, 24 Jul 2002, Christian Hennecke wrote: > On Wed, 24 Jul 2002 13:09:25 +0100, John Poltorak wrote: > > >I managed to build emacs v20.7 recently with some considerable help from > > John, could you assemble a binary distribution? I guess there are quite > some people who would like to use the latest Emacs, ^^^^^^^^^^^^ ;-) Aren't they at 21.something by now? :-( Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 19 ==========================** Date: Thu, 25 Jul 2002 12:55:06 -0600 (MDT) From: "John Drabik" Subject: Re: ln.cmd On Thu, 25 Jul 2002 17:14:46 +0100, John Poltorak wrote: >Does anyone have ln.cmd? :- >It's a simple cmd file:- > > at echo off >cp %1 %2 Automake tries to setup a symbolic link, using ln. The OS/2 equivalent must make a copy of the file, since there are no symbolic links available. That's all it does. You might also want to replace "cp" with "copy", since automake might be run early in the build process, or without cp on the path. Also, copy won't change the time stamp (the new file matches the old), so -p isn't needed. In fact, if you *want* the file to have a new timestamp, you'll need the old "+ ,," at the end. It (ln) probably *should* be in the baseline tools. No idea about if it needs a specific timestamp (but, I doubt it, if it doesn't even exist). John **= Email 20 ==========================** Date: Thu, 25 Jul 2002 13:19:32 +0100 From: John Poltorak Subject: Re: Using YACC when building FLEX On Thu, Jul 25, 2002 at 09:00:20AM +0100, Csaba wrote: > On 24 Jul 2002, at 21:24, John Poltorak wrote: [snip] > > > So how would I incorporate that into this Makefile if I wanted to use > yacc > instead of bison? :- > > # make file for "flex" tool, I'm not sure what mail client you're using but it doesn't half mess things up for mutt... Here is how I interpreted your suggestion for a YACC version of the Makefile for FLEX:- # make file for "flex" tool, emx+gcc release: $(MAKE) -f Makefile.os2 flex.exe \ CC="gcc -Zomf -O" O=".obj" A=".lib" AR="emxomfar" \ LDFLAGS="-s -Zcrtdll -Zstack 512" debug: $(MAKE) -f Makefile.os2 flex.exe \ CC="gcc -g" O=".o" A=".a" AR="ar" CFLAGS = -DOS2 -DSHORT_FILE_NAMES #YACC = bison YACC = yacc # #YACC = bison -y #This uses bison's yacc compatibility mode; #the same rule (below) could be used with both # FLEX = flex FLEX_FLAGS = -ist .SUFFIXES: .c $O .c$O: $(CC) $(CFLAGS) -c $<< FLEXLIB = fl$A FLEXOBJS = ccl$O dfa$O ecs$O gen$O main$O misc$O nfa$O parse$O \ scan$O skel$O sym$O tblcmp$O yylex$O LIBOBJS = libmain$O libyywrap$O flex.exe : $(FLEXOBJS) $(FLEXLIB) $(CC) $(LDFLAGS) -o $ at $(FLEXOBJS) $(FLEXLIB) first_flex: cp initscan.c scan.c $(MAKE) $(MFLAGS) flex $(FLEXLIB): $(LIBOBJS) $(AR) cru $(FLEXLIB) $(LIBOBJS) $(AR) s $(FLEXLIB) parse.h parse.c: parse.y $(YACC) -d -o parse.c parse.y parse.h parse.c : parse.y $(YACC) -d parse.y mv y.tab.c parse.c mv y.tab.h parse.h $(FLEX) $(FLEX_FLAGS) $(COMPRESSION) scan.l >scan.c scan.c : scan.l $(FLEX) $(FLEX_FLAGS) $(COMPRESSION) scan.l >scan.c Here's what I got when I used it:- [C:\unixos2\workdir\flex-2.5.4]make -f makefile.os2 makefile.os2:48: warning: overriding commands for target `parse.h' makefile.os2:45: warning: ignoring old commands for target `parse.h' makefile.os2:48: warning: overriding commands for target `parse.c' makefile.os2:45: warning: ignoring old commands for target `parse.c' make -f Makefile.os2 flex.exe \ CC="gcc -Zomf -O" O=".obj" A=".lib" AR="emxomfar" \ LDFLAGS="-s -Zcrtdll -Zstack 512" make[1]: Entering directory `C:/unixos2/workdir/flex-2.5.4' Makefile.os2:48: warning: overriding commands for target `parse.h' Makefile.os2:45: warning: ignoring old commands for target `parse.h' Makefile.os2:48: warning: overriding commands for target `parse.c' Makefile.os2:45: warning: ignoring old commands for target `parse.c' gcc -Zomf -O -DOS2 -DSHORT_FILE_NAMES -c ccl.c< SYS1003: The syntax of the command is incorrect. make[1]: *** [ccl.obj] Error 1 make[1]: Leaving directory `C:/unixos2/workdir/flex-2.5.4' make: *** [release] Error 2 Please correct me, if I got something wrong. Or should I have selected a specific target in the Makfile? -- John **= Email 21 ==========================** Date: Thu, 25 Jul 2002 13:36:55 +0200 (CEST) From: "Christian Hennecke" Subject: Re: Building emacs On Thu, 25 Jul 2002 11:48:16 +0100, John Poltorak wrote: >OK so *they* are at 21.*, but the latest one for us is 20.7. Unfortunately >it's a 'flat pack' version where you bring it home and have to assemble it >yourself so if you don't have the right tools it stays packed. Well, I guess a "compiling and setting up Emacs in 1000 easy steps" guide would be sufficient, too. :-) Christian Hennecke **= Email 22 ==========================** Date: Thu, 25 Jul 2002 13:43:00 +0100 From: John Poltorak Subject: New Flex It looks as though a new maintainer has taken over Flex and there is currently a new release, the first one in six years, being put together here:- ftp://ftp.uncg.edu/people/wlestes/ It would be nice to get this usable on OS/2 as soon as it gets released. -- John **= Email 23 ==========================** Date: Thu, 25 Jul 2002 14:04:35 +0100 From: John Poltorak Subject: Re: wxWindows On Thu, Jul 25, 2002 at 02:48:22PM +0200, Stefan Neis wrote: > On Thu, 25 Jul 2002, John Poltorak wrote: > > > Although the current autoconf does has good OS/2 support, there are still > > a few patches which make that support better, so I would be inclined to > > retain the autoconf step for the time being. I wouldn't expect it to take > > long. > > It doesn't, if you do have autoconf installed. But I fully expect packages > to be compilable without autoconf installed. > I'd rather tweak the wxWindows' configure.in to cope with remaining > problems than to tell everyone to get autoconf (which version anyway?) The latest, of course :-)... Maybe insist on them having a standard UnixOS/2 development system ;-). They would have autoconf installed in that case. > > Maybe you could compare the original supplied configure script with > > the new one produced after running autoconf. > > The problem is, that all the line numbers in the configure script will > probably be different, so it's hard to find any critical differences > within all the output generated by diff... This no longer occurs when using autoconf v2.53. You should only see the actual line numbers reported in config.log. Configure itself doesn't contain them any more AFAICS. > Regards, > Stefan -- John **= Email 24 ==========================** Date: Thu, 25 Jul 2002 14:48:22 +0200 (CEST) From: Stefan Neis Subject: Re: wxWindows On Thu, 25 Jul 2002, John Poltorak wrote: > Although the current autoconf does has good OS/2 support, there are still > a few patches which make that support better, so I would be inclined to > retain the autoconf step for the time being. I wouldn't expect it to take > long. It doesn't, if you do have autoconf installed. But I fully expect packages to be compilable without autoconf installed. I'd rather tweak the wxWindows' configure.in to cope with remaining problems than to tell everyone to get autoconf (which version anyway?) > Maybe you could compare the original supplied configure script with > the new one produced after running autoconf. The problem is, that all the line numbers in the configure script will probably be different, so it's hard to find any critical differences within all the output generated by diff... > Is anyone looking at updating the OS/2 version of CVS? Maybe it will build > anyway with the addition of the current OS/2 patches... Good question. ;-) Regards, Stefan **= Email 25 ==========================** Date: Thu, 25 Jul 2002 15:14:24 +0100 From: John Poltorak Subject: Building GZIP I've just built GZIP v1.2.4 from the original source using the supplied Makefile.os2. The only problem is that the one I built is 112kB in size but the one I already have which is included with GTAR258 is only 84kB. What would account for the difference in size? I built mine with the gccdyn target. Is there any way to tell how the original was built? -- John **= Email 26 ==========================** Date: Thu, 25 Jul 2002 15:22:34 -0500 From: Dave Webster Subject: RE: wxWindows Well for an app you have no sources, just an executable and a dll or two and maybe some data files. I've done a lot of InstallShield work on Windows before and it's really fairly simple unless your app has a lot of ActiveX controls and such to put in the Registry. As for getting an install package to install say wxOS2, it would not be hard at all really. Prompt the user for their OS2 Toolkit path, TCPIP lib path and UPM path or read it from the users environment, ask for the installation disk/path, unzip the thing to the path, execute a cd to /src then do a nmake all -f makefile.va or nmake -f makefile.va WXMAKINGDLL=1, then cd to ..//samples and do an nmake all -f makefile.va or nmake all 0f makefile.va WXUSINGDLL=1, repeat each for a "release" build, and you've got it, the lib and dll, and all the samples built, ready to go. wxOS2 for VisualAge doesn't use all the autoconf/configure nonsense.... just a simple makefile. -----Original Message----- From: Csaba [mailto:adwx88 at uk.uumail.com] Sent: Thursday, July 25, 2002 2:39 PM To: os2-unix at eyup.org Subject: RE: wxWindows On 25 Jul 2002, at 7:53, Dave Webster wrote: [snip] > > What wxWindows based apps really need for the Windows (and OS/2) environment > is a properly prepared InstallShield/Window Installer type installation (and > a corresponding installation package under OS/2, perhaps something like what > VisualAge 4.0 and the latest TCPIP package have). You are NEVER going to > get Windows and OS/2 users to do the Unix "make" installation thing, not > ever. > Heh, that'll be the day when some installer would unpack the sources in the temp directory and run autoconf configure make make install :-) Ceci n'est pas un .signature **= Email 27 ==========================** Date: Thu, 25 Jul 2002 15:32:10 EST From: Andrea Venturoli Subject: RE: wxWindows ** Reply to note from Dave Webster Thu, 25 Jul 2002 07:53:39 -0500 > What wxWindows based apps really need for the Windows (and OS/2) environment > is a properly prepared InstallShield/Window Installer type installation (and > a corresponding installation package under OS/2, perhaps something like what > VisualAge 4.0 and the latest TCPIP package have). You are NEVER going to > get Windows and OS/2 users to do the Unix "make" installation thing, not > ever. I don't see this as practical. The point is that you should compile it yourself for several reasons: you might have different compilers, different library versions, and different requirement on wxWindows itself; you might want a debug or a release version, you might want onyl wxBase or the full-featured wxGUI (wheter wxMSW, wxOS2, wxGTK, ...), you might need ODBC or might want to leave it out because you don't have the lower level packages (be that iODBC, MDAC, ...) and you don't feel keen on installing something you don't need. Practically there are hundred of ways to build that library, and probably a build made on a different system won't work on yours (unless you get, install and set up in a particular way the correct version of a lot of dependencies). Even the SETUP package, which do exists for Windows, only extract the sources as you can do from the zipfile. Of course end-user application are a different story... bye av. **= Email 28 ==========================** Date: Thu, 25 Jul 2002 15:33:11 -0500 From: Dave Webster Subject: RE: wxWindows And not to be condescending, but this where Unix/Linux folks just don't get it when dealing with OS/2 and Windows. There is no autoconf, configure, make, make install for Windows or OS/2 software, at least not in the traditional sense. Windows and OS/2 users (not developers) mostly have never heard of "make". They pop a CD in the CD drive, the auto start brings up the setup.exe applet which is usually Windows installer or OS/2 equivalent, they fill in a few prompts and click "Next" and when done they are ready to run. You NEVER "make" anything in Windows or OS/2 from the standpoint of application installs. In fact compilers do NOT even ship with the OS. Same for commercial toolkits. When you install Rogue Wave on OS/2 or Windows you run the same kind of installer as you do for app. You tell it where you want it, it puts it there, libs, dlls, headers, source and all. No configure, no make, not make install, no Unix-like crappola at all. That is how wxOS2 will install, hopefully. You can build the library if you want to, but it will have the static lib and dll already built on the CD if I have any say so in the matter. I have no plans to even mess with this autoconf/configure stuff, hell I don't even know what it is! -----Original Message----- From: Csaba [mailto:adwx88 at uk.uumail.com] Sent: Thursday, July 25, 2002 2:39 PM To: os2-unix at eyup.org Subject: RE: wxWindows On 25 Jul 2002, at 7:53, Dave Webster wrote: [snip] > > What wxWindows based apps really need for the Windows (and OS/2) environment > is a properly prepared InstallShield/Window Installer type installation (and > a corresponding installation package under OS/2, perhaps something like what > VisualAge 4.0 and the latest TCPIP package have). You are NEVER going to > get Windows and OS/2 users to do the Unix "make" installation thing, not > ever. > Heh, that'll be the day when some installer would unpack the sources in the temp directory and run autoconf configure make make install :-) Ceci n'est pas un .signature **= Email 29 ==========================** Date: Thu, 25 Jul 2002 16:17:28 +0200 (CEST) From: Stefan Neis Subject: Re: Using YACC when building FLEX On Thu, 25 Jul 2002, John Poltorak wrote: > .c$O: > $(CC) $(CFLAGS) -c $<< That certainly should have been "$<", not "$<<" > parse.h parse.c : parse.y > $(YACC) -d parse.y > mv y.tab.c parse.c > mv y.tab.h parse.h > $(FLEX) $(FLEX_FLAGS) $(COMPRESSION) scan.l >scan.c I don't think you want the last line. HTH, Stefan **= Email 30 ==========================** Date: Thu, 25 Jul 2002 16:31:49 +0100 From: John Poltorak Subject: Re: Using YACC when building FLEX On Thu, Jul 25, 2002 at 04:17:28PM +0200, Stefan Neis wrote: > On Thu, 25 Jul 2002, John Poltorak wrote: > > .c$O: > > $(CC) $(CFLAGS) -c $<< > > That certainly should have been "$<", not "$<<" There were a lot of spurious '<'s. Guess I missed one. > > parse.h parse.c : parse.y > > $(YACC) -d parse.y > > mv y.tab.c parse.c > > mv y.tab.h parse.h > > $(FLEX) $(FLEX_FLAGS) $(COMPRESSION) scan.l >scan.c > > I don't think you want the last line. OK that makes it better. Just if the lines above could be improved using something like:- $(YACC) -d -b $* parse.y but that ends up creating parse.tab.{c,h}. Maybe there is a way preventing 'tab.' being inserted in the middle... However it still didn't work since it seems to require flex to exist before the makefile can build flex.exe... [C:\unixos2\workdir\flex-2.5.4]make -f makefile.os2 makefile.os2:48: warning: overriding commands for target `parse.h' makefile.os2:45: warning: ignoring old commands for target `parse.h' makefile.os2:48: warning: overriding commands for target `parse.c' makefile.os2:45: warning: ignoring old commands for target `parse.c' make -f Makefile.os2 flex.exe \ CC="gcc -Zomf -O" O=".obj" A=".lib" AR="emxomfar" \ LDFLAGS="-s -Zcrtdll -Zstack 512" make[1]: Entering directory `C:/unixos2/workdir/flex-2.5.4' Makefile.os2:48: warning: overriding commands for target `parse.h' Makefile.os2:45: warning: ignoring old commands for target `parse.h' Makefile.os2:48: warning: overriding commands for target `parse.c' Makefile.os2:45: warning: ignoring old commands for target `parse.c' gcc -Zomf -O -DOS2 -DSHORT_FILE_NAMES -c ccl.c gcc -Zomf -O -DOS2 -DSHORT_FILE_NAMES -c dfa.c gcc -Zomf -O -DOS2 -DSHORT_FILE_NAMES -c ecs.c gcc -Zomf -O -DOS2 -DSHORT_FILE_NAMES -c gen.c gcc -Zomf -O -DOS2 -DSHORT_FILE_NAMES -c main.c gcc -Zomf -O -DOS2 -DSHORT_FILE_NAMES -c misc.c gcc -Zomf -O -DOS2 -DSHORT_FILE_NAMES -c nfa.c yacc -d parse.y mv y.tab.c parse.c mv y.tab.h parse.h gcc -Zomf -O -DOS2 -DSHORT_FILE_NAMES -c parse.c flex -ist scan.l >scan.c SYS1041: The name flex is not recognized as an internal or external command, operable program or batch file. make[1]: *** [scan.c] Error 255 make[1]: Leaving directory `C:/unixos2/workdir/flex-2.5.4' make: *** [release] Error 2 > HTH, > Stefan > -- John **= Email 31 ==========================** Date: Thu, 25 Jul 2002 17:14:46 +0100 From: John Poltorak Subject: ln.cmd Does anyone have ln.cmd? :- 10-07-95 3:58p 21 0 ln.cmd It's a simple cmd file:- at echo off cp %1 %2 but I'd like to know where it came from. It looks as though automake barfs when I try to install it with this file missing, so I ought to include ln.cmd in the baseline toolset. I realise that creating the file is simple enough, but I would like it to have a specific timestamp, so that it isn't highlighted as a file differing between different locations if a comparison is ever made. BTW is 'cp' OK, or should it be 'cp -p'? -- John **= Email 32 ==========================** Date: Thu, 25 Jul 2002 17:56:29 +0100 (BST) From: "Dave Saville" Subject: Re: UnixOS/2 bootstrap John Just downloaded and tried your script. I used a drive that only had /tmp on it unixwise. first thing was the script ends up going to cd \%bld_home%\lib ux2_inst but there is no \lib everything is in the base. Took the /lib off and tried again. Got bored watching and went for a cuppa. Came back to: E:\usr\dll\gnuregex.dll E:\usr\dll\gnurx.dll E:\usr\dll\gnushu.dll E:\usr\dll\gnutu.dll 14 file(s) moved. OS/2 Command Interpreter version 4.5 [E:\unixos2]ARCHIVE CFLAGS LDFLAGS PARMS MAKEPARM SRC perl-5.8.0 . ARCHIVE perl-5.8.0 CFLAGS LDFLAGS PARMS MAKEPARM . SRC /unixos2/workdir /unixos2/workdir/perl-5.8.0 build.sh[126]: autoconf: not found ./configure (I see you are using the Korn shell. Some ksh's blow up on configure, mainly on older exotic systems. If yours does, try the Bourne shell instead.) Say 'sh Configure', not 'sh Subject: Re: UnixOS/2 bootstrap On Thu, Jul 25, 2002 at 05:56:29PM +0100, Dave Saville wrote: > John > > Just downloaded and tried your script. The script is work-in-progress and is liable to change every day. Without knowing what you actually ran I can't say what may have happened. > I used a drive that only had > /tmp on it unixwise. > > first thing was the script ends up going to > > cd \%bld_home%\lib > ux2_inst > but there is no \lib everything is in the base. There shouldn't be a \lib, there should be \%bld_home%\lib. If there isn't then WGET has not retrieved everything properly. > -- > Regards > > Dave Saville > Please note new email address dave.saville at ntlworld.com > -- John **= Email 34 ==========================** Date: Thu, 25 Jul 2002 19:37:35 -0500 (CDT) From: "xyzyx" Subject: Re: Building GZIP On Thu, 25 Jul 2002 15:14:24 +0100, John Poltorak wrote: > >I've just built GZIP v1.2.4 from the original source using the supplied >Makefile.os2. The only problem is that the one I built is 112kB in size >but the one I already have which is included with GTAR258 is only 84kB. > > >What would account for the difference in size? > > >I built mine with the gccdyn target. Is there any way to tell how the >original was built? Maybe the original had it's symbols stripped off? Try 'emxbind -s gzip.exe' and see what's left over. Paul **= Email 35 ==========================** Date: Thu, 25 Jul 2002 20:39:06 +0100 From: "Csaba" Subject: RE: wxWindows On 25 Jul 2002, at 7:53, Dave Webster wrote: [snip] > > What wxWindows based apps really need for the Windows (and OS/2) environment > is a properly prepared InstallShield/Window Installer type installation (and > a corresponding installation package under OS/2, perhaps something like what > VisualAge 4.0 and the latest TCPIP package have). You are NEVER going to > get Windows and OS/2 users to do the Unix "make" installation thing, not > ever. > Heh, that'll be the day when some installer would unpack the sources in the temp directory and run autoconf configure make make install :-) Ceci n'est pas un .signature **= Email 36 ==========================** Date: Thu, 25 Jul 2002 20:39:06 +0100 From: "Csaba" Subject: Re: Using YACC when building FLEX On 25 Jul 2002, at 13:19, John Poltorak wrote: > On Thu, Jul 25, 2002 at 09:00:20AM +0100, Csaba wrote: > > On 24 Jul 2002, at 21:24, John Poltorak wrote: [snip] > > > > So how would I incorporate that into this Makefile if I wanted to use > > yacc > instead of bison? :- > > # make file for "flex" tool, > > I'm not sure what mail client you're using but it doesn't half mess things > up for mutt... Pegasus 3.12 > > # make file for "flex" tool, emx+gcc > > release: > $(MAKE) -f Makefile.os2 flex.exe \ > CC="gcc -Zomf -O" O=".obj" A=".lib" AR="emxomfar" \ > LDFLAGS="-s -Zcrtdll -Zstack 512" > debug: > $(MAKE) -f Makefile.os2 flex.exe \ > CC="gcc -g" O=".o" A=".a" AR="ar" > > CFLAGS = -DOS2 -DSHORT_FILE_NAMES > > #YACC = bison > YACC = yacc > # > #YACC = bison -y > #This uses bison's yacc compatibility mode; > #the same rule (below) could be used with both > # > FLEX = flex > FLEX_FLAGS = -ist > > .SUFFIXES: .c $O > > .c$O: > $(CC) $(CFLAGS) -c $<< > > FLEXLIB = fl$A > FLEXOBJS = ccl$O dfa$O ecs$O gen$O main$O misc$O nfa$O parse$O \ > scan$O skel$O sym$O tblcmp$O yylex$O > LIBOBJS = libmain$O libyywrap$O > > flex.exe : $(FLEXOBJS) $(FLEXLIB) > $(CC) $(LDFLAGS) -o $ at $(FLEXOBJS) $(FLEXLIB) > > first_flex: > cp initscan.c scan.c > $(MAKE) $(MFLAGS) flex > > $(FLEXLIB): $(LIBOBJS) > $(AR) cru $(FLEXLIB) $(LIBOBJS) > $(AR) s $(FLEXLIB) > > parse.h parse.c: parse.y > $(YACC) -d -o parse.c parse.y > The above (two lines) needs to go, replaced with the rule below > parse.h parse.c : parse.y > $(YACC) -d parse.y > mv y.tab.c parse.c > mv y.tab.h parse.h The above is the new and improved yacc rule: run yacc, then rename the output files The follwoing line has nothing to do with the yacc rule ! Ditch it > $(FLEX) $(FLEX_FLAGS) $(COMPRESSION) scan.l >scan.c > > scan.c : scan.l > $(FLEX) $(FLEX_FLAGS) $(COMPRESSION) scan.l >scan.c > > [snip] Ceci n'est pas un .signature