You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Brian Havard <br...@kheldar.apana.org.au> on 2001/07/25 04:43:09 UTC
make_exports.awk vs APR_DECLARE_* macros
A problem I have with the current code is that apr_file_set_inherit() isn't
included in the exports list because its declaration isn't of the usual
form. We need to either make make_exports.awk aware of the various
APR_DECLARE_* macros or ditch them altogether & declare them normally. I
vote the latter, we write the standard form in the comment above it
anyway...
--
______________________________________________________________________________
| Brian Havard | "He is not the messiah! |
| brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
------------------------------------------------------------------------------
Re: make_exports.awk vs APR_DECLARE_* macros
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
It solves our problem for today. +1.
----- Original Message -----
From: "Brian Havard" <br...@kheldar.apana.org.au>
To: <ne...@apache.org>
Sent: Wednesday, July 25, 2001 11:13 AM
Subject: Re: make_exports.awk vs APR_DECLARE_* macros
> On Wed, 25 Jul 2001 08:36:56 -0700, Ryan Bloom wrote:
>
> >On Tuesday 24 July 2001 22:45, William A. Rowe, Jr. wrote:
> >> Good point. And folks, this is a 2.0.22-dev showstopper :(
> >>
> >> Ryan, you invented both constructs. Thoughts?
> >
> >First, apr_file_set_inherit isn't in the exports file, because we explicitly don't put it there.
> >The problem is that the function only exists when a macro is evaluated, so if we use the
> >awk script, then we try to create a line like:
> >
> >void *ap_hack_apr_set_##type##_inherit = apr_set_##name##_inherit
> >
> >This is obviosly wrong. No amount of mucking with APR_DECLARE_* will resolve this.
> >
> >I guess I am having a hard time seeing any way to resolve this problem.
>
> I worked around it with the change in the patch below. There are others, of
> course, but this gets all current modules building again. The other option
> is to have make_exports.awk know how to do the same transform but to do
> that it would require full knowledge of ALL such macros.
>
> Maybe we could pass the .h files through the CPP before feeding them to
> make_exports.awk? Probably not practical but might be worth a try.
>
>
> Index: apr_file_io.h
> ===================================================================
> RCS file: /usr/local/cvs/apr/include/apr_file_io.h,v
> retrieving revision 1.105
> diff -u -r1.105 apr_file_io.h
> --- apr_file_io.h 2001/07/18 19:12:41 1.105
> +++ apr_file_io.h 2001/07/25 16:01:34
> @@ -575,14 +576,14 @@
> * @param file The file to enable inheritance.
> * @deffunc void apr_file_set_inherit(apr_file_t *file)
> */
> -APR_DECLARE_SET_INHERIT(file);
> +APR_DECLARE(void) apr_file_set_inherit(apr_file_t *file);
>
> /**
> * Unset a file from being inherited by child processes.
> * @param file The file to disable inheritance.
> * @deffunc void apr_file_unset_inherit(apr_file_t *file)
> */
> -APR_DECLARE_UNSET_INHERIT(file);
> +APR_DECLARE(void) apr_file_unset_inherit(apr_file_t *file);
>
> #ifdef __cplusplus
> }
>
>
> >> ----- Original Message -----
> >> From: "Brian Havard" <br...@kheldar.apana.org.au>
> >> To: "Apache Developers Mailing List" <ne...@apache.org>
> >> Sent: Tuesday, July 24, 2001 9:43 PM
> >> Subject: make_exports.awk vs APR_DECLARE_* macros
> >>
> >> > A problem I have with the current code is that apr_file_set_inherit()
> >> > isn't included in the exports list because its declaration isn't of the
> >> > usual form. We need to either make make_exports.awk aware of the various
> >> > APR_DECLARE_* macros or ditch them altogether & declare them normally. I
> >> > vote the latter, we write the standard form in the comment above it
> >> > anyway...
>
> --
> ______________________________________________________________________________
> | Brian Havard | "He is not the messiah! |
> | brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
> ------------------------------------------------------------------------------
>
>
Re: make_exports.awk vs APR_DECLARE_* macros
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Sander Striker" <st...@apache.org>
Sent: Wednesday, July 25, 2001 11:43 AM
> > >void *ap_hack_apr_set_##type##_inherit = apr_set_##name##_inherit
> > >
> > >This is obviosly wrong. No amount of mucking with APR_DECLARE_* will resolve this.
> >
> > I worked around it with the change in the patch below. There are
> > others, of
> > course, but this gets all current modules building again. The other option
> > is to have make_exports.awk know how to do the same transform but to do
> > that it would require full knowledge of ALL such macros.
>
> Exactly how many of those macros are there?
> If there aren't a boat load of them it might be worthwhile
> to implement them.
The idea is to provide an entire host of accessors, allowing us to easily export the
pool, lock, inherit, and other 'common' fields. I dunno if this is worth the pain.
Leaving the declarations as native is perhaps the simplest solution.
> > Maybe we could pass the .h files through the CPP before feeding them to
> > make_exports.awk? Probably not practical but might be worth a try.
That would (likely) be the only way.
RE: make_exports.awk vs APR_DECLARE_* macros
Posted by Sander Striker <st...@apache.org>.
> On Wed, 25 Jul 2001 08:36:56 -0700, Ryan Bloom wrote:
>
> >On Tuesday 24 July 2001 22:45, William A. Rowe, Jr. wrote:
> >> Good point. And folks, this is a 2.0.22-dev showstopper :(
> >>
> >> Ryan, you invented both constructs. Thoughts?
> >
> >First, apr_file_set_inherit isn't in the exports file, because
> we explicitly don't put it there.
> >The problem is that the function only exists when a macro is
> evaluated, so if we use the
> >awk script, then we try to create a line like:
> >
> >void *ap_hack_apr_set_##type##_inherit = apr_set_##name##_inherit
> >
> >This is obviosly wrong. No amount of mucking with APR_DECLARE_*
> will resolve this.
> >
> >I guess I am having a hard time seeing any way to resolve this problem.
>
> I worked around it with the change in the patch below. There are
> others, of
> course, but this gets all current modules building again. The other option
> is to have make_exports.awk know how to do the same transform but to do
> that it would require full knowledge of ALL such macros.
Exactly how many of those macros are there?
If there aren't a boat load of them it might be worthwhile
to implement them.
> Maybe we could pass the .h files through the CPP before feeding them to
> make_exports.awk? Probably not practical but might be worth a try.
Sander
RE: make_exports.awk vs APR_DECLARE_* macros
Posted by Sander Striker <st...@apache.org>.
> >On Tuesday 24 July 2001 22:45, William A. Rowe, Jr. wrote:
> >> Good point. And folks, this is a 2.0.22-dev showstopper :(
> >>
> >> Ryan, you invented both constructs. Thoughts?
> >
> >First, apr_file_set_inherit isn't in the exports file, because
> we explicitly don't put it there.
> >The problem is that the function only exists when a macro is
> evaluated, so if we use the
> >awk script, then we try to create a line like:
> >
> >void *ap_hack_apr_set_##type##_inherit = apr_set_##name##_inherit
> >
> >This is obviosly wrong. No amount of mucking with APR_DECLARE_*
> will resolve this.
> >
> >I guess I am having a hard time seeing any way to resolve this problem.
>
> I worked around it with the change in the patch below. There are
> others, of
> course, but this gets all current modules building again. The other option
> is to have make_exports.awk know how to do the same transform but to do
> that it would require full knowledge of ALL such macros.
>
> Maybe we could pass the .h files through the CPP before feeding them to
> make_exports.awk? Probably not practical but might be worth a try.
Tried that before I revised the make_exports.awk.
That will take an awfull long time.
Sander
Re: make_exports.awk vs APR_DECLARE_* macros
Posted by Brian Havard <br...@kheldar.apana.org.au>.
On Wed, 25 Jul 2001 08:36:56 -0700, Ryan Bloom wrote:
>On Tuesday 24 July 2001 22:45, William A. Rowe, Jr. wrote:
>> Good point. And folks, this is a 2.0.22-dev showstopper :(
>>
>> Ryan, you invented both constructs. Thoughts?
>
>First, apr_file_set_inherit isn't in the exports file, because we explicitly don't put it there.
>The problem is that the function only exists when a macro is evaluated, so if we use the
>awk script, then we try to create a line like:
>
>void *ap_hack_apr_set_##type##_inherit = apr_set_##name##_inherit
>
>This is obviosly wrong. No amount of mucking with APR_DECLARE_* will resolve this.
>
>I guess I am having a hard time seeing any way to resolve this problem.
I worked around it with the change in the patch below. There are others, of
course, but this gets all current modules building again. The other option
is to have make_exports.awk know how to do the same transform but to do
that it would require full knowledge of ALL such macros.
Maybe we could pass the .h files through the CPP before feeding them to
make_exports.awk? Probably not practical but might be worth a try.
Index: apr_file_io.h
===================================================================
RCS file: /usr/local/cvs/apr/include/apr_file_io.h,v
retrieving revision 1.105
diff -u -r1.105 apr_file_io.h
--- apr_file_io.h 2001/07/18 19:12:41 1.105
+++ apr_file_io.h 2001/07/25 16:01:34
@@ -575,14 +576,14 @@
* @param file The file to enable inheritance.
* @deffunc void apr_file_set_inherit(apr_file_t *file)
*/
-APR_DECLARE_SET_INHERIT(file);
+APR_DECLARE(void) apr_file_set_inherit(apr_file_t *file);
/**
* Unset a file from being inherited by child processes.
* @param file The file to disable inheritance.
* @deffunc void apr_file_unset_inherit(apr_file_t *file)
*/
-APR_DECLARE_UNSET_INHERIT(file);
+APR_DECLARE(void) apr_file_unset_inherit(apr_file_t *file);
#ifdef __cplusplus
}
>> ----- Original Message -----
>> From: "Brian Havard" <br...@kheldar.apana.org.au>
>> To: "Apache Developers Mailing List" <ne...@apache.org>
>> Sent: Tuesday, July 24, 2001 9:43 PM
>> Subject: make_exports.awk vs APR_DECLARE_* macros
>>
>> > A problem I have with the current code is that apr_file_set_inherit()
>> > isn't included in the exports list because its declaration isn't of the
>> > usual form. We need to either make make_exports.awk aware of the various
>> > APR_DECLARE_* macros or ditch them altogether & declare them normally. I
>> > vote the latter, we write the standard form in the comment above it
>> > anyway...
--
______________________________________________________________________________
| Brian Havard | "He is not the messiah! |
| brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
------------------------------------------------------------------------------
Re: make_exports.awk vs APR_DECLARE_* macros
Posted by Ryan Bloom <rb...@covalent.net>.
On Tuesday 24 July 2001 22:45, William A. Rowe, Jr. wrote:
> Good point. And folks, this is a 2.0.22-dev showstopper :(
>
> Ryan, you invented both constructs. Thoughts?
First, apr_file_set_inherit isn't in the exports file, because we explicitly don't put it there.
The problem is that the function only exists when a macro is evaluated, so if we use the
awk script, then we try to create a line like:
void *ap_hack_apr_set_##type##_inherit = apr_set_##name##_inherit
This is obviosly wrong. No amount of mucking with APR_DECLARE_* will resolve this.
I guess I am having a hard time seeing any way to resolve this problem.
Ryan
>
> Bill
>
> ----- Original Message -----
> From: "Brian Havard" <br...@kheldar.apana.org.au>
> To: "Apache Developers Mailing List" <ne...@apache.org>
> Sent: Tuesday, July 24, 2001 9:43 PM
> Subject: make_exports.awk vs APR_DECLARE_* macros
>
> > A problem I have with the current code is that apr_file_set_inherit()
> > isn't included in the exports list because its declaration isn't of the
> > usual form. We need to either make make_exports.awk aware of the various
> > APR_DECLARE_* macros or ditch them altogether & declare them normally. I
> > vote the latter, we write the standard form in the comment above it
> > anyway...
> >
> > --
> >
> > _________________________________________________________________________
> >_____
> >
> > | Brian Havard | "He is not the messiah!
> > | | brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life
> > | of Brian |
> >
> >
> > -------------------------------------------------------------------------
> >-----
--
_____________________________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
-----------------------------------------------------------------------------
RE: make_exports.awk vs APR_DECLARE_* macros
Posted by Sander Striker <st...@apache.org>.
Hi guys,
Well, I decided to do another patch. I've inlined it and
attached it.
It adds multiline support to #if, #ifdef, etc.
And it detects declared functions not declared using
the AP[RU]_DECLARE scheme. I hope this is what you
guys meant.
Furthermore I had to do some cleanup in the substitutions
because when I read them over they didn't seem ok.
Sander
--- build/make_exports.awk Wed Jul 25 16:20:24 2001
+++ build/make_exports.awk.new Wed Jul 25 16:18:52 2001
@@ -26,6 +26,7 @@
TYPE_HEADER = 1
stackptr = 0
+ multiline = 0
}
function push(line) {
@@ -76,10 +77,19 @@
}
}
+/^.*/ {
+ if (multiline) {
+ multiline = $0 ~ /[\\]$/
+ push($0)
+ next
+ }
+}
+
/^[ \t]*AP[RU]?_DECLARE[^(]*[(][^)]*[)]([^ ]* )*[^(]+[(]/ {
sub("[ \t]*AP[RU]?_DECLARE[^(]*[(][^)]*[)][ \t]*", "")
- sub("[(].*", "")
- sub("([^ ]* (^([ \t]*[(])))+", "")
+ sub("[ \t]*[(].*", "")
+ sub("([^ ]* )+", "")
+ sub("[\*]+", "")
add_symbol($0)
next
@@ -97,6 +107,19 @@
next
}
+/^[ \t]*([a-zA-Z_][a-zA-Z0-9_]*[ \t]+)+[ \t\*]*[a-zA-Z_][a-zA-Z0-9_]*[
\t]*[(][^)]*[)][ \t]*;[ \t]*$/ {
+ if (!index($0, "typedef")) {
+ sub("^[ \t]+", "")
+ sub("[ \t]*[(].*", "")
+ sub("([^ ]* )+", "")
+ sub("[\*]+", "")
+
+ add_symbol($0)
+ }
+
+ next
+}
+
/^#[ \t]*if(ndef| !defined[(])([^_]*_)*H/ {
enter_scope(TYPE_HEADER)
next
@@ -104,6 +127,7 @@
/^#[ \t]*if([n]?def)? / {
enter_scope(TYPE_NORMAL)
+ multiline = $0 ~ /[\\]$/
push($0)
next
}
@@ -122,6 +146,7 @@
}
/^#[ \t]*elif/ {
+ multiline = $0 ~ /[\\]$/
push($0)
next
}
Re: make_exports.awk vs APR_DECLARE_* macros
Posted by Cliff Woolley <cl...@yahoo.com>.
On Wed, 25 Jul 2001, William A. Rowe, Jr. wrote:
> > A problem I have with the current code is that apr_file_set_inherit() isn't
> > included in the exports list because its declaration isn't of the usual
> > form. We need to either make make_exports.awk aware of the various
> > APR_DECLARE_* macros or ditch them altogether & declare them normally. I
> > vote the latter, we write the standard form in the comment above it
> > anyway...
>
> Good point. And folks, this is a 2.0.22-dev showstopper :(
=-( Okay, holding the tag pending resolution of this issue.
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: make_exports.awk vs APR_DECLARE_* macros
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Good point. And folks, this is a 2.0.22-dev showstopper :(
Ryan, you invented both constructs. Thoughts?
Bill
----- Original Message -----
From: "Brian Havard" <br...@kheldar.apana.org.au>
To: "Apache Developers Mailing List" <ne...@apache.org>
Sent: Tuesday, July 24, 2001 9:43 PM
Subject: make_exports.awk vs APR_DECLARE_* macros
> A problem I have with the current code is that apr_file_set_inherit() isn't
> included in the exports list because its declaration isn't of the usual
> form. We need to either make make_exports.awk aware of the various
> APR_DECLARE_* macros or ditch them altogether & declare them normally. I
> vote the latter, we write the standard form in the comment above it
> anyway...
>
> --
> ______________________________________________________________________________
> | Brian Havard | "He is not the messiah! |
> | brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
> ------------------------------------------------------------------------------
>
>
RE: make_exports.awk vs APR_DECLARE_* macros
Posted by Sander Striker <st...@apache.org>.
Brian Havard wrote:
> A problem I have with the current code is that
> apr_file_set_inherit() isn't
> included in the exports list because its declaration isn't of the usual
> form. We need to either make make_exports.awk aware of the various
> APR_DECLARE_* macros
Well, I could help out with this option. Just send me the spec of
the AP[RU]?_DECLARE macros that need to be exported and I'll post
a patch to the make_exports.awk.
> or ditch them altogether & declare them normally. I
> vote the latter, we write the standard form in the comment above it
> anyway...
The standard form in the comment isn't in all places anymore. It
isn't needed by Doxygen, so actually they should be removed IMHO.
Sander