Re: make_export.awk
> What makes you think the awk solution is any more portable than the Perl > solution? awk is a standard Unix tool and has a specification in my copy of the CAE X/OPEN docco. Perl is not. Add to that the fact that awk is a much simpler program, can be had under a BSD license, and much is easier to port to non-Unix platforms, and I think it's a clear winner. That Apache required Perl is no excuse to bloat up APR with that requirement. Apache is not APR's only client. I prefer coding perl to awk, but it's not the more portable tool. I -1 your -1. :) BWK awk, by the way, is a fine awk. We tossed gawk for it in Mac OS X, and all (even GNU autoconf, which, by the way, uses awk) works just ducky. -Fred Wilfredo Sánchez, [EMAIL PROTECTED] Open Source Engineering Lead Apple Computer, Inc., Core Operating System Group 1 Infinite Loop, Cupertino, CA 94086, 408.974-5174
RE: [wrowe@rowe-clan.net: RE: *.exports in distro bundle, use of , Perl on Windows (was: Re: make_export.awk)]
> From: Cliff Woolley [mailto:[EMAIL PROTECTED] > Sent: Saturday, December 16, 2000 7:48 PM > > --- [EMAIL PROTECTED] wrote: > > The Apache Group has looked at Cygwin before. We do not > plan to include > > support for Cygwin right now. That may change in the future, but we > > dislike the license. > > Just as an FYI-aside: Apache 2.0 and APR actually *do* build > and run correctly almost out > of the box under Cygwin... (the last time I checked, there > were just two or three little > buglets that break the build but which are easily fixed... > I've tried submitting patches > for them before but they got ignored). > > (I know that's not exactly what you all are talking about at > the moment, I just thought I'd mention it.) And this is very cool (no sarcasm here!) I'm all for folks who can build and run under cygwin! The point is, Apache/APR on Cygwin isn't native NT, but Cygwin compatibility upon APR compatibility. The NT version, unfortunately, only builds with the VC++ products. I personally hope that grows to include bcc (another non-unix and now free compiler), as well as folks building gcc/semi-win32 ports. To Mo's comment; The -open- Apache projects are heavily supported by firms that will ultimately release custom, tweaked, or other binary-only builds. Once we are touched by GNU, those companies have no financial incentive to help grow this open community. Go figure. That we allow cygwin users to build is great. To rely on tools to distribute, that sucks. We don't want to ask Unix users, NT users, OS2 users, or MacOSX users to go chasing down fourty tools to work with Apache, and that's a very platform independent philosopy. Footnote, I don't see that relying on the Awk from Lucient poses any significant license problems... I'll ping upstairs and test the waters.
Re: cvs commit: apr CHANGES aclocal.m4
[EMAIL PROTECTED] writes: > trawick 00/12/17 05:12:12 > > Modified:.CHANGES aclocal.m4 > Log: > Tighten up the check for getaddrinfo(). If it can't figure out > the appropriate address family for 127.0.0.1, it fails. > Unfortunately, Tru64 fails this test so we won't do IPv6 on > Tru64. Note that it is easy enough to handle numeric address strings properly and portably in apr_getaddrinfo() by writing the code ourselves. Unfortunately, the Tru64 getaddrinfo() won't handle AF_UNSPEC with hosts either, so writing explicit code to handle numeric address strings is a false solution. Yuck! -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Beta reminder
This message is meant to serve as a reminder to everybody and as a STATUS message. I will be updating STATUS immediately after sending this message. The current plan is to release the first Apache beta on Friday December 22. That also means that APR is basically hitting beta status, at least it has in the past. The APR developers will need to decide if we want to divorce APR releases from Apache. This will be decided separately from new-httpd. In order to do that, we need to actually roll the release on Wednesday, and we all need to test it. We have been releasing alpha's on the day they roll, IMHO that is not a valid way to roll a beta. Currently, I am planning to roll the beta release on Wednesday, and make it available for testing. That will coincide with a Friday release date, hopefully. This requires a few things first. Each of these will go into the STATUS file. 1) The installed layout needs to be fixed. This means that the header files need to be installed in the correct location. Expect a message in a few minutes with my opinion for how this should look. 2) The instructions for rolling a release need to be updated for 2.0. Expect this to happen in the next few days. I will take care of doing this. 3) binbuild.sh may need to be updated. I haven't looked into this, but I would be surprised if it works. 4) Source code layout needs to be decided for apr and apr-util. There has been some discussion about adding a src/ directory to apr or removing it from apr-util/. Either way, this needs to be decided. 5) Apache.org needs to start running Apache 2.0 if at all possible. Would other people please look through the release show-stoppers, and either remove them if they are solved, or decide if they are really show-stoppers. If they aren't, then lets get rid of them. If they are, then lets fix them. I am not convinced that all of those showstoppers need to be solved before we release the beta. Some of them are issues for configuration, we are trying to figure out the best way to configure Apache 2.0, but nobody has ever really tried setting this stuff up. Until somebody does that, stating that we need a certain configuration option is a bit pre-mature IMHO. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
RE: [wrowe@rowe-clan.net: RE: *.exports in distro bundle, use of , Perl on Windows (was: Re: make_export.awk)]
--- [EMAIL PROTECTED] wrote: > The Apache Group has looked at Cygwin before. We do not plan to include > support for Cygwin right now. That may change in the future, but we > dislike the license. Just as an FYI-aside: Apache 2.0 and APR actually *do* build and run correctly almost out of the box under Cygwin... (the last time I checked, there were just two or three little buglets that break the build but which are easily fixed... I've tried submitting patches for them before but they got ignored). (I know that's not exactly what you all are talking about at the moment, I just thought I'd mention it.) --Cliff __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/
RE: [wrowe@rowe-clan.net: RE: *.exports in distro bundle, use of , Perl on Windows (was: Re: make_export.awk)]
> > Nak, no, you cannot incorporate cygwin on win32 for apr/apache, > > and, no, Win32 doesn't run ./configure, and no, we don't expect > > anyone on win32 to handle installation of anything beyond the > > easy-to-install activestate perl, or we incoroporate the Lucient > > licensed awk. Apr itself is not built on cygwin porting. > > I am not talking about building APR on top of Cygwin, I am > only talking about building APR with the utils (like /bin/sh) > provided by Cygwin. I assumed that this was how you all got > ./configure running under Windows, but it sounds like > nobody has done that, so my mistake. Does this mean that > the Windows version of APR only builds with VC++? Yes, currently the Windows version of APR only works with VC++. Most Windows developers use VC++, so that is who we are programming for. Most Windows developers use Windows tools, so there isn't really a good reason to force them to install a new set of tools to be able to use APR. > Gosh, you are right. We have better halt that port to Linux > too, since it is also GPLed. If you link your program to > cygwin1.dll, then it needs to be GPLed. But, there is an > exception in the license for projects that fit the OSD > definition of "open source" software. None of that matters > since you do not need to link to cygwin1.dll if you are > just using the tools to build your code. If you had actually > read the license, you might already know that (no, I > am not trying to flame here). The Apache Group has looked at Cygwin before. We do not plan to include support for Cygwin right now. That may change in the future, but we dislike the license. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
RE: [wrowe@rowe-clan.net: RE: *.exports in distro bundle, use of , Perl on Windows (was: Re: make_export.awk)]
On Sat, 16 Dec 2000, William A. Rowe, Jr. wrote: > > I guess I don't follow the logic there. How exactly would Windows > > developers run the configure script if they did not have Cygwin > > installed? Last I checked, perl did not read sh files, so you > > would need to have a version of /bin/sh on the Windows box > > to be able to run configure. I was not aware that there was > > a pure Win32 version of /bin/sh, I had always assumed people > > would be using Cygwin to run the ./configure script. Since > > Cygwin does not come with perl and it does come with gnu > > utils like sed and awk, we should use the utils and not > > perl. Does that sound reasonable to everyone? > > Nak, no, you cannot incorporate cygwin on win32 for apr/apache, > and, no, Win32 doesn't run ./configure, and no, we don't expect > anyone on win32 to handle installation of anything beyond the > easy-to-install activestate perl, or we incoroporate the Lucient > licensed awk. Apr itself is not built on cygwin porting. I am not talking about building APR on top of Cygwin, I am only talking about building APR with the utils (like /bin/sh) provided by Cygwin. I assumed that this was how you all got ./configure running under Windows, but it sounds like nobody has done that, so my mistake. Does this mean that the Windows version of APR only builds with VC++? > This is a copy of CYGWIN_LICENSE from the cygwin sources... > This program is free software; you can redistribute it and/or modify > it under the terms of the GNU General Public License (GPL) as > published by the Free Software Foundation; either version 2 of the > License, or (at your option) any later version. > > and that, for an Apache project, is the kiss of death. Gosh, you are right. We have better halt that port to Linux too, since it is also GPLed. If you link your program to cygwin1.dll, then it needs to be GPLed. But, there is an exception in the license for projects that fit the OSD definition of "open source" software. None of that matters since you do not need to link to cygwin1.dll if you are just using the tools to build your code. If you had actually read the license, you might already know that (no, I am not trying to flame here). Mo DeJong Red Hat Inc
