Greg Stein wrote:
>
> On Tue, Feb 27, 2001 at 02:44:50PM -0500, Jim Jagielski wrote:
> > What's patsubst ? I don't see it in any m4 docs?
>
> Info m4
> - Text Handling
> - Patsubst
>
> Dunno if it has always been around, or whether it is relatively new.
> Considering the glacial pace of m4 dev
Greg Stein <[EMAIL PROTECTED]> writes:
> Not entirely true. It worked splendidly on my Linux box (otherwise, I
> wouldn't have committed :-).
I should have said "the build was broken on at least some BSD and some
Linux systems". :-)
-K
On Tue, Feb 27, 2001 at 08:48:22PM -, [EMAIL PROTECTED] wrote:
>...
> However, since the build was broken on at least BSD and Linux, and
> Jim's patch makes things work again, it seemed better to apply it and
> *then* figure out if it's the Right Thing. :-)
Not entirely true. It worked s
On Tue, Feb 27, 2001 at 02:44:50PM -0500, Jim Jagielski wrote:
> What's patsubst ? I don't see it in any m4 docs?
Info m4
- Text Handling
- Patsubst
Dunno if it has always been around, or whether it is relatively new.
Considering the glacial pace of m4 development, I'd tend towards long
time...
Please add one.
Ryan
On Tue, 27 Feb 2001, Cliff Woolley wrote:
>
> Is there any particular reason that APR-util doesn't have a CHANGES file
> yet? I assume it's just because nobody's gotten around to it. If that's
> the case, I'll go ahead and add one.
>
> --Cliff
>
>
__
Greg Stein <[EMAIL PROTECTED]> writes:
> I'd rather we find out what is wrong with BSD m4.
News flash: it's not just BSD m4 -- my Debian Linux box also cannot
build APR now, with exactly the same errors as Ben reported from BSD.
galois$ m4 --version
GNU m4 1.4
galois$
I have not been f
Is there any particular reason that APR-util doesn't have a CHANGES file
yet? I assume it's just because nobody's gotten around to it. If that's
the case, I'll go ahead and add one.
--Cliff
[EMAIL PROTECTED] writes:
> jim 01/02/27 08:58:33
>
> Modified:.configure.in
> Log:
> Back to using APR_FLAG_HEADERS... note that
> this may require GNUm4 on FreeBSD systems
>
> +dnl work around unexplained problem on Tru64 where
> +dnl the above invocation says
What's patsubst ? I don't see it in any m4 docs?
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
"Hell is hot, that's never been disputed by anybody."
More weirdness... If I change the below to:
APR_FOREACH([
[if test "$ac_cv_header_]translit(eachval,[/+-.],[_p__])" = "yes"; then
dnl note: this translit() maps "/" to "_" and omits ".". the third arg
(note the rearrangements in the translit strings), configure looks
like:
for ac_hdr i
Greg Stein wrote:
>
> I'd rather we find out what is wrong with BSD m4.
>
I do see the strip-off-last-h-occasionally problem with Gnu m4.
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
It solves it, but it is much less effective than the approach that is
currently in there. Specifically, it invokes a bunch of subshells and seds
for each and every header. My change last night totally avoids that by
moving the effort into m4 rather than runtime.
I'd rather we find out what is wron
[EMAIL PROTECTED] wrote:
>
> Jim just posted a patch which should solve the problem without using
> GNUm4.
>
Here it is again... I'd appreciate feedback on it, because it
looks like it solves the problem. At the least, you'll
see no diff in your apr.h and apr_private.h files, at best,
you'll see
On Tue, Feb 27, 2001 at 11:43:06AM -0600, Ben Collins-Sussman wrote:
>
> Sorry, I'm confused here; my FreeBSD 4.2 system has /usr/bin/m4 and
> /usr/local/bin/gm4. Do I need to do some icky softlinking to make APR
> use gm4? Or is there a better solution?
I believe you should be able to say:
M4
Jim just posted a patch which should solve the problem without using
GNUm4.
Ryan
On 27 Feb 2001, Ben Collins-Sussman wrote:
>
> Sorry, I'm confused here; my FreeBSD 4.2 system has /usr/bin/m4 and
> /usr/local/bin/gm4. Do I need to do some icky softlinking to make APR
> use gm4? Or is there a
On Tue, 27 Feb 2001, Greg Stein wrote:
> Euh... I don't think we want another ring.
>
> A simpler idea is to have the apr_bucket_pool structure contain a pointer to
> an apr_bucket_heap structure. At cleanup time, you do the following:
Ahh, (he says as the little light over his head comes on). T
On Tue, 27 Feb 2001, Greg Stein wrote:
> On Tue, Feb 27, 2001 at 09:16:36AM -0800, [EMAIL PROTECTED] wrote:
> > On Tue, 27 Feb 2001, Greg Stein wrote:
> > > On Tue, Feb 27, 2001 at 08:47:01AM -0800, [EMAIL PROTECTED] wrote:
> > > > On Tue, 27 Feb 2001, Jim Jagielski wrote:
> > > > > Using GNUm4 un
Sorry, I'm confused here; my FreeBSD 4.2 system has /usr/bin/m4 and
/usr/local/bin/gm4. Do I need to do some icky softlinking to make APR
use gm4? Or is there a better solution?
I've no real issue with requiring developers to use Gm4... As much as
autoconf depends on m4, it's almost a requirement :)
I'd like to avoid it, but I'm not fanatical about it.
--
===
Jim Jagielski [|] [EMAIL PROTECTED
Here's a diff which works around the m4 weirdness. It also avoids
the problem which causes that nasty dropping 'h' buglet which
would cause incorrect entries in apr.h. As you can see, I move
some stuff back into shell land, rather than m4 land.
It also results in a slightly smaller configure:
On Tue, Feb 27, 2001 at 09:16:36AM -0800, [EMAIL PROTECTED] wrote:
> On Tue, 27 Feb 2001, Greg Stein wrote:
> > On Tue, Feb 27, 2001 at 08:47:01AM -0800, [EMAIL PROTECTED] wrote:
> > > On Tue, 27 Feb 2001, Jim Jagielski wrote:
> > > > Using GNUm4 under FreeBSD makes everything work...
> > >
> > > T
<[EMAIL PROTECTED]> writes:
> > This simply means a developer needs:
> >
> > autoconf, libtool, GNU m4
> >
> > Not a biggy in my book.
> >
> > It would be nice to find the discrepancy with *BSD m4 and submit bugs back
> > to their M4 team.
>
> IMO, this is the exact same as requiring gmake to
On Tue, 27 Feb 2001, Greg Stein wrote:
> On Tue, Feb 27, 2001 at 08:47:01AM -0800, [EMAIL PROTECTED] wrote:
> > On Tue, 27 Feb 2001, Jim Jagielski wrote:
> >
> > > Using GNUm4 under FreeBSD makes everything work...
> >
> > That is not a restriction we want to add if at all possible.
>
> Note that
On Tue, Feb 27, 2001 at 08:47:01AM -0800, [EMAIL PROTECTED] wrote:
> On Tue, 27 Feb 2001, Jim Jagielski wrote:
>
> > Using GNUm4 under FreeBSD makes everything work...
>
> That is not a restriction we want to add if at all possible.
Note that this is for developers only. Users never use/need M4.
[EMAIL PROTECTED] wrote:
>
> On Tue, 27 Feb 2001, Jim Jagielski wrote:
>
> > Using GNUm4 under FreeBSD makes everything work...
>
> That is not a restriction we want to add if at all possible.
>
Well, at least now I can build... I'll restore configure.in
to use APR_FLAG_HEADERS to see if we ca
On Tue, 27 Feb 2001, Jim Jagielski wrote:
> Using GNUm4 under FreeBSD makes everything work...
That is not a restriction we want to add if at all possible.
Ryan
___
Ryan Bloom [EMAIL PROTECT
Using GNUm4 under FreeBSD makes everything work...
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
"Hell is hot, that's never been disputed by anybody."
Greg Stein wrote:
>
> I'll ask again: WHAT are you seeing? Do you have a log? A snippet from
> apr_private.h.in? How can we diagnose the problem if you just keep saying
> "it's broken, so I'm reverting."
When apr_private.h.in is being built by autoheader, the lines
such as:
/* Define if you ha
On Tue, Feb 27, 2001 at 11:11:14AM -0500, Jim Jagielski wrote:
>...
> Yes, but we are doing:
>
> AC_CHECK_HEADERS($1)
>
> where $1 is what's passed to APR_FLAG_HEADERS, which autoheader isn't
> parsing correctly... What I've been seeing on all my test machines is that
> the HAVE_CTYPES_H, f
On Tue, 27 Feb 2001, Jim Jagielski wrote:
> Jim Jagielski wrote:
> >
> > Do a ./buildconf so that autoheader is called. You'll see that
> > apr_private.h.in isn't being correctly built.
> >
>
> Now this is weird... it builds fine under Linux, but not under
> FreeBSD.
Probably differences in M4.
On Tue, Feb 27, 2001 at 11:14:36AM -0500, Jim Jagielski wrote:
> Greg Stein wrote:
> >
> > No...
> >
> > We *are* using AC_CHECK_HEADERS right now. Look at the first line in
> > APR_FLAG_HEADERS(). My apr_private.h.in is populating quite fine. What are
> > you seeing?
> >
>
> Do a ./buildconf s
Jim Jagielski wrote:
>
> Do a ./buildconf so that autoheader is called. You'll see that
> apr_private.h.in isn't being correctly built.
>
Now this is weird... it builds fine under Linux, but not under
FreeBSD.
--
===
Ji
Greg Stein wrote:
>
> No...
>
> We *are* using AC_CHECK_HEADERS right now. Look at the first line in
> APR_FLAG_HEADERS(). My apr_private.h.in is populating quite fine. What are
> you seeing?
>
Do a ./buildconf so that autoheader is called. You'll see that
apr_private.h.in isn't being correctly
On Tue, 27 Feb 2001, Cliff Woolley wrote:
> On Mon, 26 Feb 2001 [EMAIL PROTECTED] wrote:
>
> > > 3) pool_bucket_cleanup() is completely bogus AFAICT. I've added this
> > > comment to the code, which describes the problems pretty well:
> > > 4) The same problem applies to file buckets that have be
Greg Stein wrote:
>
> On Tue, Feb 27, 2001 at 03:24:29PM -, [EMAIL PROTECTED] wrote:
> > jim 01/02/27 07:24:28
> >
> > Modified:.configure.in
> > Log:
> > revert back to old way until we figure out
> > an autoheader work-around. Allow building again
>
> What the h
On Tue, Feb 27, 2001 at 03:24:29PM -, [EMAIL PROTECTED] wrote:
> jim 01/02/27 07:24:28
>
> Modified:.configure.in
> Log:
> revert back to old way until we figure out
> an autoheader work-around. Allow building again
What the hell?!!!
I spent something like six hou
On Tue, 27 Feb 2001, William A. Rowe, Jr. wrote:
> From: <[EMAIL PROTECTED]>
> Sent: Tuesday, February 27, 2001 8:39 AM
>
>
> > I agree that lighting a fire is a good thing, but I would personally
> > rather see one or two APR patches from him first. I haven't really been
> > paying any attention
On Tue, Feb 27, 2001 at 10:09:39AM -0500, Jim Jagielski wrote:
> Argf I *think* that autoheader requires that we do
> AC_CHECK_HEADERS to check for header files in order to
> populate apr_private.h.in. Is that right??
>
> If so, unless we can think of something else, we need to
> go back to us
On Tue, Feb 27, 2001 at 09:54:25AM -0500, Cliff Woolley wrote:
> On Mon, 26 Feb 2001 [EMAIL PROTECTED] wrote:
> > > 3) pool_bucket_cleanup() is completely bogus AFAICT. I've added this
> > > comment to the code, which describes the problems pretty well:
> > > 4) The same problem applies to file bu
Sorry to bother the list with administrative bs ... really not for comment
on this list. Fat fingers.
Bill
From: <[EMAIL PROTECTED]>
Sent: Tuesday, February 27, 2001 8:39 AM
> I agree that lighting a fire is a good thing, but I would personally
> rather see one or two APR patches from him first. I haven't really been
> paying any attention to his 1.3 patches, and I'm not comfortable giving
> out comm
> Argf I *think* that autoheader requires that we do
> AC_CHECK_HEADERS to check for header files in order to
> populate apr_private.h.in. Is that right??
This is exactly freakin' right. It explains why John saw the
problem with the file in the first place. I didn't do a buildconf.
--
==
Argf I *think* that autoheader requires that we do
AC_CHECK_HEADERS to check for header files in order to
populate apr_private.h.in. Is that right??
If so, unless we can think of something else, we need to
go back to using AC_CHECK_HEADERS :<
--
===
On Mon, 26 Feb 2001 [EMAIL PROTECTED] wrote:
> > 3) pool_bucket_cleanup() is completely bogus AFAICT. I've added this
> > comment to the code, which describes the problems pretty well:
> > 4) The same problem applies to file buckets that have been split/copied
> > when APR_HAS_MMAP: when one of t
Greg Stein wrote:
>
> What platform? This kind of behavior may be what Jeff is seeing on Tru64.
>
> These things look fine on Linux (or I wouldn't have checked in :-).
>
> The variable to check *is* constructed by the line you're referencing, but
> I'm not sure how could mess up the line. It's p
Greg Stein wrote:
>
> No way. There is zero advantage to doing that. We *are* using
> AC_CHECK_HEADERS' for-loop, so I'm not sure what you're talking about.
That was before I saw the current rev... Agreed it doesn't make sense now :)
> The M4 thing is an unrolled recursion over
> a list, basical
What platform? This kind of behavior may be what Jeff is seeing on Tru64.
These things look fine on Linux (or I wouldn't have checked in :-).
The variable to check *is* constructed by the line you're referencing, but
I'm not sure how could mess up the line. It's possible that "eachval" is not
get
Greg Stein wrote:
>
> >
> > I'm not seeing that, since we're reducing down to AC_CHECK_HEADERS.
> > Let me double check... I'm seeing correct stuff under FreeBSD and A/UX.
>
> Well, yah. I fixed it :-)
>
I meant before :) Basically we were just doing:
for i in $stuff
do
AC_CHECK_HE
On Tue, Feb 27, 2001 at 07:45:18AM -0500, Jim Jagielski wrote:
> [EMAIL PROTECTED] wrote:
>...
> > * configure.in: just call APR_FLAG_HEADERS once. This allows autoconf to
> > loop over the values *once* rather than substituting N loops for header
> > checking. This drops configure's size
On Tue, Feb 27, 2001 at 08:00:15AM -0500, Jim Jagielski wrote:
> Jeff Trawick wrote:
> > [EMAIL PROTECTED] writes:
> > > jim 01/02/26 11:56:14
> > >
> > > Modified:.configure.in
> > > Log:
> > > Use APR_CHECK_HEADERS instead
> >
> > One of these commits seems to have bro
Looks like something weird is going on... From a newly built
configure, note the below. Sometimes the final 'h' is being
stripped away (eg: dirent_). I've no idea what the current
mojo in apr_common.m4 is doing, so I haven't a clue :)
I'm guessing it's this line:
[if test "$ac_cv_header_]tran
Jeff Trawick wrote:
>
> now APR on Tru64 doesn't think it has stdio.h (sort of; configure
> output says we found it; APR_HAVE_STDIO_H is set to zero); a few other
> header files aren't substituted properly either... work-around
> forthcoming...
>
> yes, this is with a virgin configure.in with no
[EMAIL PROTECTED] writes:
> gstein 01/02/27 03:34:50
>
> Modified:.configure.in
>buildapr_common.m4
> Log:
> * configure.in: just call APR_FLAG_HEADERS once. This allows autoconf to
> loop over the values *once* rather than substituting N loops for h
Jeff Trawick wrote:
>
> [EMAIL PROTECTED] writes:
>
> > jim 01/02/26 11:56:14
> >
> > Modified:.configure.in
> > Log:
> > Use APR_CHECK_HEADERS instead
>
> One of these commits seems to have broken every case where we
> previously checked for the header but didn't set
Jeff Trawick wrote:
>
> [EMAIL PROTECTED] writes:
>
> > jim 01/02/26 11:56:14
> >
> > Modified:.configure.in
> > Log:
> > Use APR_CHECK_HEADERS instead
>
> One of these commits seems to have broken every case where we
> previously checked for the header but didn't set
[EMAIL PROTECTED] wrote:
>
> gstein 01/02/27 03:34:50
>
> Modified:.configure.in
>buildapr_common.m4
> Log:
> * configure.in: just call APR_FLAG_HEADERS once. This allows autoconf to
> loop over the values *once* rather than substituting N loops for
> 1) The apr_bucket_shared and apr_bucket_simple structs are completely
> useless, and a needless time/resource drain. If we just add an apr_off_t
> start into the apr_bucket struct, apr_bucket_shared and apr_bucket_simple
> can go away completely, saving massive amounts of work in all of the
> b
Okay, I've got a series of pretty major bucket API cleanups I'd like to do
(most of which are mostly transparent outside apr-util, BTW). Before I
go off and commit, though, this was major enough to warrant seeking group
consent. Here are the issues I'm addressing, in roughly descending order
of
On Mon, Feb 26, 2001 at 07:22:06PM -0800, Greg Stein wrote:
> On Mon, Feb 26, 2001 at 09:20:46PM -0500, Jeff Trawick wrote:
> > Jim Jagielski <[EMAIL PROTECTED]> writes:
> >
> > > I've got a real cool idea about how to make everyone happy...
> > > Heading out right now, but will commit something l
On Mon, Feb 26, 2001 at 09:20:46PM -0500, Jeff Trawick wrote:
> Jim Jagielski <[EMAIL PROTECTED]> writes:
>
> > I've got a real cool idea about how to make everyone happy...
> > Heading out right now, but will commit something later
> > today :)
>
> Just for my curiosity, can you tell me which sy
Jeff Trawick <[EMAIL PROTECTED]> writes:
> watch out non-Linux-ers...
>
> Since the signal handling was moved around in the threaded MPM, on
> Tru64 and AIX the child processes are looping somewhere and they don't
> respond to SIGTERM.
It seems that the problems started when we went from
sige
Jim Jagielski <[EMAIL PROTECTED]> writes:
> I've got a real cool idea about how to make everyone happy...
> Heading out right now, but will commit something later
> today :)
Just for my curiosity, can you tell me which system actually can build
APR after these cool ideas were implemented?
--
Je
[EMAIL PROTECTED] writes:
> jim 01/02/26 11:56:14
>
> Modified:.configure.in
> Log:
> Use APR_CHECK_HEADERS instead
One of these commits seems to have broken every case where we
previously checked for the header but didn't set a flag.
In those cases, we had symbols def
63 matches
Mail list logo
