Re: cvs commit: apr buildconf
On Wednesday, February 7, 2001, at 04:54 PM, Jeff Trawick wrote: -ltpath=`helpers/PrintPath libtoolize` -ltpath=`dirname $ltpath` +libtoolize=`helpers/PrintPath glibtoolize libtoolize` +ltpath=`dirname $libtool` I think you meant "ltpath=`dirname $libtoolize`" Yup. And I looked that over three times and it didn't set off a bell. Ah. I see that you just fixed it. -Fitz
Re: cvs commit: apr buildconf
[EMAIL PROTECTED] writes: > wsanchez01/02/07 12:42:16 > > Modified:.buildconf > Log: > Check for glibtoolize as well as libtoolize. ... > Index: buildconf > === > RCS file: /home/cvs/apr/buildconf,v > retrieving revision 1.6 > retrieving revision 1.7 > diff -u -r1.6 -r1.7 > --- buildconf 2001/01/09 11:05:34 1.6 > +++ buildconf 2001/02/07 20:42:16 1.7 > @@ -3,8 +3,8 @@ ># ># Build aclocal.m4 from libtool's libtool.m4 and our own M4 files. ># > -ltpath=`helpers/PrintPath libtoolize` > -ltpath=`dirname $ltpath` > +libtoolize=`helpers/PrintPath glibtoolize libtoolize` > +ltpath=`dirname $libtool` I think you meant "ltpath=`dirname $libtoolize`" buildconf ain't working right for me and configure isn't either :) -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: [PATCH] iconv tweak
Mo DeJong <[EMAIL PROTECTED]> writes: >> Is it reasonable to test for a compile *warning* via autoconf? > I am not sure why that matters. The point is that apr does not > compile on some systems, this iconv #define code will fix that. Warnings do matter, hence my questions. I certainly agree that it is important to get all systems compiling even if we have to have warnings; I'm just wondering about a better solution. Thanks, Jeff -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: [PATCH] iconv tweak
On Wed, Feb 07, 2001 at 11:58:42AM -0800, Mo DeJong wrote: > On 7 Feb 2001, Jeff Trawick wrote: > > > Here is the bit of code from the Jikes java compiler > > > that deals with this issue. > > > > > > size_t n = iconv(_converter, > > > #ifdef HAVE_ERROR_CALL_ICONV_CONST > > > (char **) > > > #endif > > > &source_ptr, &srcl, > > > (char **)&chp, &chl > > > ); > > > > The code would be nicer if we define ICONV_INBUF_TYPE to "char **" or > > "const char **" and then do > > Well, that would just be casting a const char** to a const char ** > in the normal case, why put an extra cast in for no reason? > I tend to like knowing about the exceptions and why they are in the > code instead of having unexplained casts all over the place. > Just for reference, in AbiWord this is dealt with in the following way iconv(arg_1, (ICONV_CONST char **) arg_2, etc ...) where ICONV_CONST is either defined to const or not depending on the platform. I have to say that this is ugly and horrible, and really wish there was a better solution. sam th [EMAIL PROTECTED] http://www.abisource.com/~sam/ GnuPG Key: http://www.abisource.com/~sam/key pgpsZpPLDDXMp.pgp Description: PGP signature
Re: [PATCH] iconv tweak
On 7 Feb 2001, Jeff Trawick wrote: > Doesn't AC_TRY_COMPILE() succeed if there is a warning? I think your > patch only helps on rare systems where the compiler won't compile it > at all if the const-ness doesn't match the iconv() prototype. Yeah, > that is an improvement over the current situation but it would be nice > to get rid of the problem -- warning or error -- altogether. We are testing for the error condition, that is why the #define is called HAVE_ERROR_CALL_ICONV_CONST. The error shows up on systems with the combo of a non const header file and a gcc newer than 2.95 (like Red Hat 7.0). > Mo DeJong <[EMAIL PROTECTED]> writes: > > > On Sun, 4 Feb 2001, Greg Stein wrote: > > > > > There was some discussion about iconv prototyes here recently, but I kind > > > of > > > missed it. > > > > > > Do we always need to live with a warning about a type mismatch, or is the > > > cast below appropriate? > > > > > > IOW, do some headers have "const" on them, and others not? > > > > Yup, you cannot just use a cast, you need to use a HAVE... > > test because headers differ and newer versions of > > gcc will generate an error on a plain cast. > > What does "plain cast" in this sense mean? A cast that does not happen using the ifdef HAVE_ERROR_CALL_ICONV_CONST conditional logic. The point was that just casting to char ** would fail on some systems. > > Here is the bit of code from the Jikes java compiler > > that deals with this issue. > > > > size_t n = iconv(_converter, > > #ifdef HAVE_ERROR_CALL_ICONV_CONST > > (char **) > > #endif > > &source_ptr, &srcl, > > (char **)&chp, &chl > > ); > > The code would be nicer if we define ICONV_INBUF_TYPE to "char **" or > "const char **" and then do Well, that would just be casting a const char** to a const char ** in the normal case, why put an extra cast in for no reason? I tend to like knowing about the exceptions and why they are in the code instead of having unexplained casts all over the place. > n = iconv(_converter, > (ICONV_INBUF_TYPE)&source_ptr, &srcl, > (char **)&chp, &chl); > > but that is a minor detail (particularly since we have so few calls to > iconv). > > Is it reasonable to test for a compile *warning* via autoconf? I am not sure why that matters. The point is that apr does not compile on some systems, this iconv #define code will fix that. Mo DeJong Red Hat Inc
Re: [PATCH] iconv tweak
On Wed, Feb 07, 2001 at 01:14:59PM -0500, Jeff Trawick wrote: > > Is it reasonable to test for a compile *warning* via autoconf? > The easiest way would probably be to use c++ to test this, since in c++ cast from a char ** to a const char ** is illegal, and generates and error. sam th [EMAIL PROTECTED] http://www.abisource.com/~sam/ GnuPG Key: http://www.abisource.com/~sam/key pgpzktqdLBGiz.pgp Description: PGP signature
Re: [PATCH] iconv tweak
Doesn't AC_TRY_COMPILE() succeed if there is a warning? I think your patch only helps on rare systems where the compiler won't compile it at all if the const-ness doesn't match the iconv() prototype. Yeah, that is an improvement over the current situation but it would be nice to get rid of the problem -- warning or error -- altogether. Mo DeJong <[EMAIL PROTECTED]> writes: > On Sun, 4 Feb 2001, Greg Stein wrote: > > > There was some discussion about iconv prototyes here recently, but I kind of > > missed it. > > > > Do we always need to live with a warning about a type mismatch, or is the > > cast below appropriate? > > > > IOW, do some headers have "const" on them, and others not? > > Yup, you cannot just use a cast, you need to use a HAVE... > test because headers differ and newer versions of > gcc will generate an error on a plain cast. What does "plain cast" in this sense mean? > Here is the bit of code from the Jikes java compiler > that deals with this issue. > > size_t n = iconv(_converter, > #ifdef HAVE_ERROR_CALL_ICONV_CONST > (char **) > #endif > &source_ptr, &srcl, > (char **)&chp, &chl > ); The code would be nicer if we define ICONV_INBUF_TYPE to "char **" or "const char **" and then do n = iconv(_converter, (ICONV_INBUF_TYPE)&source_ptr, &srcl, (char **)&chp, &chl); but that is a minor detail (particularly since we have so few calls to iconv). Is it reasonable to test for a compile *warning* via autoconf? -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: apr_ function prefixes
On Wed, Feb 07, 2001 at 06:50:09AM -0500, Kevin Pilch-Bisson wrote: > On Tue, Feb 06, 2001 at 03:05:30PM -0800, Greg Stein wrote: > > On Tue, Feb 06, 2001 at 09:38:16AM -0500, Kevin Pilch-Bisson wrote: > > >... > > > +1 for this, but only if it is done soon. As Ryan said recently, APR is > > > approaching the Beta stage, so API's shouldn't change much. However, I > > > think this is a useful change. > > > > A little process comment here: Ryan is a single voice out of all of us here. > > I want to see a "beta" also, but just because Ryan or I say so doesn't make > > it true. > > > > Basically, we release it as a beta when we (the group) think it is a beta. > > > My apologies if I stepped on any toes. I didn't mean to say that Ryan > had the final say or anything like that. I was just referring to the > fact that Ryan recently suggested not changing API's much, because APR > was approaching Beta. All I meant to say was that I thought this change > was important, even though it _DOES_ in fact change those API's, but > that it should be done soon if it is done, because the API should be > stable once APR is `Beta'd. > > If you interpreted it differently, please rest assured that this was all > I meant to imply. Hehe... have no fear of my toes. Around mailing lists, I wear asbestos pajamas and steel-toed boots. :-) It is only what I said: a "comment". You did say you were lurking for a while and relatively new, so I simply filled in a bit of info on how the process works. No big whoop. I think we'll be changing APIs until we release. After that, then it will be trickier. Trying to freeze APIs at any point before a release just means that you release with sucky APIs. Fix them first, then release. After you release, you have to deal with the crap you built, but that is a different story for a different time :-) Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: apr_ function prefixes
On Tue, Feb 06, 2001 at 03:05:30PM -0800, Greg Stein wrote: > On Tue, Feb 06, 2001 at 09:38:16AM -0500, Kevin Pilch-Bisson wrote: > >... > > +1 for this, but only if it is done soon. As Ryan said recently, APR is > > approaching the Beta stage, so API's shouldn't change much. However, I > > think this is a useful change. > > A little process comment here: Ryan is a single voice out of all of us here. > I want to see a "beta" also, but just because Ryan or I say so doesn't make > it true. > > Basically, we release it as a beta when we (the group) think it is a beta. > My apologies if I stepped on any toes. I didn't mean to say that Ryan had the final say or anything like that. I was just referring to the fact that Ryan recently suggested not changing API's much, because APR was approaching Beta. All I meant to say was that I thought this change was important, even though it _DOES_ in fact change those API's, but that it should be done soon if it is done, because the API should be stable once APR is `Beta'd. If you interpreted it differently, please rest assured that this was all I meant to imply. -- > Kevin Pilch-Bisson [EMAIL PROTECTED] http://www.pilch-bisson.net PGP Public Key At http://pgp.pilch-bisson.net pgptqEvaU4ZLR.pgp Description: PGP signature
[fielding@ebuilt.com: Re: FreeBSD 4.2 breakage (?)]
[ assuming a misfire ] - Forwarded message from "Roy T. Fielding" <[EMAIL PROTECTED]> - From: "Roy T. Fielding" <[EMAIL PROTECTED]> Subject: Re: FreeBSD 4.2 breakage (?) To: Greg Stein <[EMAIL PROTECTED]> Date: Mon, 5 Feb 2001 18:29:31 -0500 > I don't have a ready solution for strings.h, however. Because we *do* use > strcasecmp, I don't know a better way to pick it up. I don't want to rely on > /not/ including strings.h if string.h is present. Who knows if string.h will > define strcasecmp? GNU's happens to do so, but what about elsewhere? From > that point, I said "gotta include both. now how do I prevent the extra > definition of strcasecmp?" Isn't this the reason we are using autoconf? Just write a test case like the iconv one that Mo posted. > Even if we ultimately back out the POSIX_SOURCE thing, cleaning out the > BSDisms from internal and public APR will assist with portability. > [ I'm presuming that POSIX is more portable than BSDisms ] Not really... most of the platforms that Apache 1.3 runs on predate POSIX. BSDisms tend to work because many other real code bases have been ported to multiple platforms, whereas POSIX was simply a standard based on what was believed to be the lowest common denominator. Roy - End forwarded message - -- Greg Stein, http://www.lyra.org/
