Re: cvs commit: httpd-2.0/include ap_mmn.h
On Thu, May 30, 2002 at 05:57:33AM -, [EMAIL PROTECTED] wrote: > jwoolley02/05/29 22:57:33 > > Modified:include ap_mmn.h > Log: > Imagine the horror. I go to try compiling PHP4, and it bombs out on > r->boundary. BUT WAIT, I say, we have a test in there for that: > #if !MODULE_MAGIC_AT_LEAST(20020506,0). The test doesn't seem to be > working. That's odd, I think. So I go look at the ap_mmn.h. Egad, > the tests are totally backwards. How on earth are we going to handle this? > Surely it's wrong in 1.3.x as well. So I go look. Nope, turns out it > got fixed TWO YEARS AGO in that repository. Sigh. Anyway, thanks Greg. > :) > > Submitted by: Greg Stein, circa Apache 1.3.13 hehe... :-) I had no idea it never made it to 2.0... woah. Thanks for the port! :-) Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: cvs commit: httpd-2.0/include ap_mmn.h
On 6 May 2002 [EMAIL PROTECTED] wrote: > jerenkrantz02/05/06 01:21:10 > > Modified:include ap_mmn.h > Log: > Removing a field in a core structure (r->boundary) merits a MMN bump, > unfortunately. They got 2 GAs out of the old MMN. > > Reviewed by:Cliff Woolley If people end up objecting to this (I'm sure they will :-P), we *could* just leave a dummy field in the middle of the request_rec. It seems awfully silly to me to start leaving cruft in the structures this early in the 2.0 cycle, though. I suggest that we leave this bump in there for now, and if other changes come about that also could take advantage of an MMN bump, we won't feel too bad about it. If we get to release time and this was the only change, we can consider sticking in a dummy var as a *temporary* measure at that time. --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
RE: cvs commit: httpd-2.0/include ap_mmn.h
This is the way to go, so please go with the minor MMN bump. Ryan -- Ryan Bloom [EMAIL PROTECTED] 645 Howard St. [EMAIL PROTECTED] San Francisco, CA > -Original Message- > From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]] > Sent: Monday, April 29, 2002 9:26 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: cvs commit: httpd-2.0/include ap_mmn.h > > T-1200 > > If I don't see any agreement that this is the way to go, I'll be happy to > revert > to the original mmn bump. > > Please comment. This should be a group decision. > > Bill > > At 07:59 AM 4/29/2002, William A. Rowe, Jr. wrote: > >Since a number of folks have complained about the major bump, I've > >reconsidered > >the impact on those testing 3rd party add-ons, and it would be good to > >avoid this > >bump due to internal changes for ssl, proxy and cgi. > > > >But the APR changes are a little more troublesome. On win32 we can live > with > >a minor bump, since the module will simply fail to load (file/entry point > >not found > >error attempting to load a module or mismatched libhttpd.dll + > libapr.dll). > > > >I'm suggesting we demote to a minor bump and ask Sander to roll this > commit > >into .36. Please comment. > > > >Bill > > > >At 07:51 AM 4/29/2002, [EMAIL PROTECTED] wrote: > >>wrowe 02/04/29 05:51:31 > >> > >> Modified:include ap_mmn.h > >> Log: > >> Demote to a minor bump for .36 - those affected by API changes > should > >> be a very small subset of modules. Here are the afflicted types & > fns; > >> > >> apr_explode_time -> apr_time_exp_tz > >> apr_explode_localtime -> apr_time_exp_lt > >> apr_get_groupname -> apr_group_name_get > >> > >> deprecated apr_lock_t, apr_os_lock_t and fns, but the warnings > >> have been there a while so no sympathy. > >> > >> added dav_hooks_search_t and DASL Search functions. > >> > >> added apr_cmdtype_e *type arg to mod_cgi opt fn ap_cgi_build_command. > >> > >> added proxy_fixups hook and ap_proxy_ssl_disable, and > >> optional fn ssl_engine_disable. > >> > >> Revision ChangesPath > >> 1.43 +3 -3 httpd-2.0/include/ap_mmn.h > >> > >> Index: ap_mmn.h > >> === > >> RCS file: /home/cvs/httpd-2.0/include/ap_mmn.h,v > >> retrieving revision 1.42 > >> retrieving revision 1.43 > >> diff -u -r1.42 -r1.43 > >> --- ap_mmn.h 13 Apr 2002 19:58:04 - 1.42 > >> +++ ap_mmn.h 29 Apr 2002 12:51:31 - 1.43 > >> @@ -103,15 +103,15 @@ > >> * 20020319 (2.0.34-dev) M_INVALID changed, plus new M_* methods for > >> RFC 3253 > >> * 20020327 (2.0.35-dev) Add parameter to quick_handler hook > >> * 20020329 (2.0.35-dev) bump for addition of freelists to bucket > API > >> - * 20020413 (2.0.36-dev) bump for new arg to opt fn > ap_cgi_build_command > >> + * 20020329.1 (2.0.36) minor bump for new arg to opt fn > >> ap_cgi_build_command > >> */ > >> > >>#define MODULE_MAGIC_COOKIE 0x41503230UL /* "AP20" */ > >> > >>#ifndef MODULE_MAGIC_NUMBER_MAJOR > >> -#define MODULE_MAGIC_NUMBER_MAJOR 20020413 > >> +#define MODULE_MAGIC_NUMBER_MAJOR 20020329 > >>#endif > >> -#define MODULE_MAGIC_NUMBER_MINOR 0 /* 0...n */ > >> +#define MODULE_MAGIC_NUMBER_MINOR 1 /* 0...n */ > >>#define MODULE_MAGIC_NUMBER MODULE_MAGIC_NUMBER_MAJOR/* > >> backward compat */ > >> > >>/** > >> > > >
Re: cvs commit: httpd-2.0/include ap_mmn.h
Cliff Woolley wrote: >On Mon, 29 Apr 2002, William A. Rowe, Jr. wrote: > >>T-1200 >>If I don't see any agreement that this is the way to go, I'll be happy >>to revert to the original mmn bump. >> > > >Bump the major. For the first couple of releases I don't see a big >problem with that. Note that with 1.3.x, the major was bumped many times >between the alphas and the final major that we still use today, which >didn't come about until 1.3.5. 1.3.1, 1.3.2, and 1.3.4 all changes in the >major. > I'm not comfortable with bumping the major number. We shouldn't be inflicting a major number change (and the consequent need to rebuild one's modules) on third party module suppliers without a damn good reason, and I just don't see anything in 2.0.36 that qualifies. --Brian
Re: cvs commit: httpd-2.0/include ap_mmn.h
On Mon, 29 Apr 2002, William A. Rowe, Jr. wrote: > T-1200 > If I don't see any agreement that this is the way to go, I'll be happy > to revert to the original mmn bump. Bump the major. For the first couple of releases I don't see a big problem with that. Note that with 1.3.x, the major was bumped many times between the alphas and the final major that we still use today, which didn't come about until 1.3.5. 1.3.1, 1.3.2, and 1.3.4 all changes in the major. --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: cvs commit: httpd-2.0/include ap_mmn.h
T-1200 If I don't see any agreement that this is the way to go, I'll be happy to revert to the original mmn bump. Please comment. This should be a group decision. Bill At 07:59 AM 4/29/2002, William A. Rowe, Jr. wrote: >Since a number of folks have complained about the major bump, I've >reconsidered >the impact on those testing 3rd party add-ons, and it would be good to >avoid this >bump due to internal changes for ssl, proxy and cgi. > >But the APR changes are a little more troublesome. On win32 we can live with >a minor bump, since the module will simply fail to load (file/entry point >not found >error attempting to load a module or mismatched libhttpd.dll + libapr.dll). > >I'm suggesting we demote to a minor bump and ask Sander to roll this commit >into .36. Please comment. > >Bill > >At 07:51 AM 4/29/2002, [EMAIL PROTECTED] wrote: >>wrowe 02/04/29 05:51:31 >> >> Modified:include ap_mmn.h >> Log: >> Demote to a minor bump for .36 - those affected by API changes should >> be a very small subset of modules. Here are the afflicted types & fns; >> >> apr_explode_time -> apr_time_exp_tz >> apr_explode_localtime -> apr_time_exp_lt >> apr_get_groupname -> apr_group_name_get >> >> deprecated apr_lock_t, apr_os_lock_t and fns, but the warnings >> have been there a while so no sympathy. >> >> added dav_hooks_search_t and DASL Search functions. >> >> added apr_cmdtype_e *type arg to mod_cgi opt fn ap_cgi_build_command. >> >> added proxy_fixups hook and ap_proxy_ssl_disable, and >> optional fn ssl_engine_disable. >> >> Revision ChangesPath >> 1.43 +3 -3 httpd-2.0/include/ap_mmn.h >> >> Index: ap_mmn.h >> === >> RCS file: /home/cvs/httpd-2.0/include/ap_mmn.h,v >> retrieving revision 1.42 >> retrieving revision 1.43 >> diff -u -r1.42 -r1.43 >> --- ap_mmn.h 13 Apr 2002 19:58:04 - 1.42 >> +++ ap_mmn.h 29 Apr 2002 12:51:31 - 1.43 >> @@ -103,15 +103,15 @@ >> * 20020319 (2.0.34-dev) M_INVALID changed, plus new M_* methods for >> RFC 3253 >> * 20020327 (2.0.35-dev) Add parameter to quick_handler hook >> * 20020329 (2.0.35-dev) bump for addition of freelists to bucket API >> - * 20020413 (2.0.36-dev) bump for new arg to opt fn ap_cgi_build_command >> + * 20020329.1 (2.0.36) minor bump for new arg to opt fn >> ap_cgi_build_command >> */ >> >>#define MODULE_MAGIC_COOKIE 0x41503230UL /* "AP20" */ >> >>#ifndef MODULE_MAGIC_NUMBER_MAJOR >> -#define MODULE_MAGIC_NUMBER_MAJOR 20020413 >> +#define MODULE_MAGIC_NUMBER_MAJOR 20020329 >>#endif >> -#define MODULE_MAGIC_NUMBER_MINOR 0 /* 0...n */ >> +#define MODULE_MAGIC_NUMBER_MINOR 1 /* 0...n */ >>#define MODULE_MAGIC_NUMBER MODULE_MAGIC_NUMBER_MAJOR/* >> backward compat */ >> >>/** >> >
Re: cvs commit: httpd-2.0/include ap_mmn.h
Since a number of folks have complained about the major bump, I've reconsidered the impact on those testing 3rd party add-ons, and it would be good to avoid this bump due to internal changes for ssl, proxy and cgi. But the APR changes are a little more troublesome. On win32 we can live with a minor bump, since the module will simply fail to load (file/entry point not found error attempting to load a module or mismatched libhttpd.dll + libapr.dll). I'm suggesting we demote to a minor bump and ask Sander to roll this commit into .36. Please comment. Bill At 07:51 AM 4/29/2002, [EMAIL PROTECTED] wrote: >wrowe 02/04/29 05:51:31 > > Modified:include ap_mmn.h > Log: > Demote to a minor bump for .36 - those affected by API changes should > be a very small subset of modules. Here are the afflicted types & fns; > > apr_explode_time -> apr_time_exp_tz > apr_explode_localtime -> apr_time_exp_lt > apr_get_groupname -> apr_group_name_get > > deprecated apr_lock_t, apr_os_lock_t and fns, but the warnings > have been there a while so no sympathy. > > added dav_hooks_search_t and DASL Search functions. > > added apr_cmdtype_e *type arg to mod_cgi opt fn ap_cgi_build_command. > > added proxy_fixups hook and ap_proxy_ssl_disable, and > optional fn ssl_engine_disable. > > Revision ChangesPath > 1.43 +3 -3 httpd-2.0/include/ap_mmn.h > > Index: ap_mmn.h > === > RCS file: /home/cvs/httpd-2.0/include/ap_mmn.h,v > retrieving revision 1.42 > retrieving revision 1.43 > diff -u -r1.42 -r1.43 > --- ap_mmn.h 13 Apr 2002 19:58:04 - 1.42 > +++ ap_mmn.h 29 Apr 2002 12:51:31 - 1.43 > @@ -103,15 +103,15 @@ > * 20020319 (2.0.34-dev) M_INVALID changed, plus new M_* methods for > RFC 3253 > * 20020327 (2.0.35-dev) Add parameter to quick_handler hook > * 20020329 (2.0.35-dev) bump for addition of freelists to bucket API > - * 20020413 (2.0.36-dev) bump for new arg to opt fn ap_cgi_build_command > + * 20020329.1 (2.0.36) minor bump for new arg to opt fn > ap_cgi_build_command > */ > >#define MODULE_MAGIC_COOKIE 0x41503230UL /* "AP20" */ > >#ifndef MODULE_MAGIC_NUMBER_MAJOR > -#define MODULE_MAGIC_NUMBER_MAJOR 20020413 > +#define MODULE_MAGIC_NUMBER_MAJOR 20020329 >#endif > -#define MODULE_MAGIC_NUMBER_MINOR 0 /* 0...n */ > +#define MODULE_MAGIC_NUMBER_MINOR 1 /* 0...n */ >#define MODULE_MAGIC_NUMBER MODULE_MAGIC_NUMBER_MAJOR/* > backward compat */ > >/** > > >
Re: cvs commit: httpd-2.0/include ap_mmn.h
At 04:26 PM 4/17/2002, William A. Rowe, Jr. wrote: >At 04:05 PM 4/17/2002, Greg Stein wrote: >>Why is this change required? > >So we had to add the apr_progtype_e * so that it could be updated to reflect >the new choice of interpreter. Doug and I were just chatting about this. Perhaps if we change the optional_fn and registered hooks schema to accept the -entire- arglist in the declaration and stringify it, we could break optional functions, registered hooks and other 'dynamic' function pointers away from the entire mmn schema. This would mean that the arglist would be checked at registration time (at startup - so the overhead is insignificant) and the hook/optional function registration can return a new status, such as APR_EWRONGVERSION, if they mismatch. Thoughts? Bill
Re: cvs commit: httpd-2.0/include ap_mmn.h
At 04:05 PM 4/17/2002, Greg Stein wrote: >Why is this change required? Sorry... pulled in 30 directions at once. Here's the short answer. This bugfix is required. If you study the entire code path of CGI creation for Win32... you will discover that -most- exec's are by explicit full path names (APR_PROGRAM). But we discovered that the logic precluded our invoking "perl "c:\full\path\to\script.pl" since perl wasn't decoded to c:\perl\bin\perl.exe. The same change is appropriate for interpretersource Registry execution as well. The difference is in the -source- of the command. The script requested by the client is untrusted. The program or path given by a shebang line or registry entry is trusted. So it's entirely appropriate to invoke the shebang-specified interpreter, or the interpretersource registry command, as APR_PROGRAM_PATH. But it's never appropriate to do so for the user-provided script. So we had to add the apr_progtype_e * so that it could be updated to reflect the new choice of interpreter. In the meantime, folks are renaming APR functions, and other goodness progresses. Please refer back to ap_mmn.h from Apache 1.3 - we rarely went two versions before we bumped the mmn. Later, since 1.3.14, the code has really stabilized. But we can't expect that tens of thousands of testers won't uncover deficiencies in the API, and the right answer is to fix them. Sure, the 2.1 tree might not bump as often, after we've gotten the API near-perfect in 2.0 :-) Finally, was this bump necessary? You could argue that the registered function I modified was principally internal. But because this function is now passed a pointer that is dereferenced, I felt the consequences of missing that API change outweighed the value of "Binary Compatibility" and changing the mmn bumping rules as we go. I won't argue if you want to keep the change but revert the mmn since it's 'internal'. In fact, it's really meant for MPM or platform-port authors only, I never anticipate that registered fn to be used by typical module authors. Bill >On Tue, Apr 16, 2002 at 02:46:25AM -0700, Greg Stein wrote: > > Woah... this just blew away all modules built for 2.0.35. This is an API > > change, which thus means a very careful review of WHY this change was > > required. Specifically, is there any way to avoid the change? > > > > For example, we could introduce a new function, and call that one instead > > from our code, leaving the old API untouched for third party modules. > > > > IOW, please justify the necessity of bumping the MMN. > > > > Cheers, > > -g > > > > On Sat, Apr 13, 2002 at 07:58:04PM -, [EMAIL PROTECTED] wrote: > > > wrowe 02/04/13 12:58:04 > > > > > > Modified:.CHANGES > > >include ap_mmn.h > > > Log: > > > The fix requires a bump > > > > > > Revision ChangesPath > > > 1.704 +5 -0 httpd-2.0/CHANGES > > > > > > Index: CHANGES > > > === > > > RCS file: /home/cvs/httpd-2.0/CHANGES,v > > > retrieving revision 1.703 > > > retrieving revision 1.704 > > > diff -u -r1.703 -r1.704 > > > --- CHANGES 12 Apr 2002 19:58:51 - 1.703 > > > +++ CHANGES 13 Apr 2002 19:58:04 - 1.704 > > > @@ -1,5 +1,10 @@ > > >Changes with Apache 2.0.36 > > > > > > + *) Allow Win32 shebang scripts to follow the path (or omit the .exe > > > + suffix from the shebang command), and allow > ScriptInterpreterSource > > > + Registry or RegistryStrict to override shebang lines, as 1.3 did. > > > + [William Rowe] > > > + > > > *) worker MPM: Fix a situation where a child exited without > releasing > > > the accept mutex. Depending on the OS and mutex mechanism this > > > could result in a hang. [Jeff Trawick] > > > > > > > > > > > > 1.42 +2 -1 httpd-2.0/include/ap_mmn.h > > > > > > Index: ap_mmn.h > > > === > > > RCS file: /home/cvs/httpd-2.0/include/ap_mmn.h,v > > > retrieving revision 1.41 > > > retrieving revision 1.42 > > > diff -u -r1.41 -r1.42 > > > --- ap_mmn.h 29 Mar 2002 08:17:19 - 1.41 > > > +++ ap_mmn.h 13 Apr 2002 19:58:04 - 1.42 > > > @@ -103,12 +103,13 @@ > > > * 20020319 (2.0.34-dev) M_INVALID changed, plus new M_* methods > for RFC 3253 > > > * 20020327 (2.0.35-dev) Add parameter to quick_handler hook > > > * 20020329 (2.0.35-dev) bump for addition of freelists to bucket API > > > + * 20020413 (2.0.36-dev) bump for new arg to opt fn > ap_cgi_build_command > > > */ > > > > > >#define MODULE_MAGIC_COOKIE 0x41503230UL /* "AP20" */ > > > > > >#ifndef MODULE_MAGIC_NUMBER_MAJOR > > > -#define MODULE_MAGIC_NUMBER_MAJOR 20020329 > > > +#define MODULE_MAGIC_NUMBER_MAJOR 20020413 > > >#endif > > >#define MODULE_MAGIC_NUMBER_MINOR 0 /* 0
Re: cvs commit: httpd-2.0/include ap_mmn.h
Bill? Comments? Why is this change required? -g On Tue, Apr 16, 2002 at 02:46:25AM -0700, Greg Stein wrote: > Woah... this just blew away all modules built for 2.0.35. This is an API > change, which thus means a very careful review of WHY this change was > required. Specifically, is there any way to avoid the change? > > For example, we could introduce a new function, and call that one instead > from our code, leaving the old API untouched for third party modules. > > IOW, please justify the necessity of bumping the MMN. > > Cheers, > -g > > On Sat, Apr 13, 2002 at 07:58:04PM -, [EMAIL PROTECTED] wrote: > > wrowe 02/04/13 12:58:04 > > > > Modified:.CHANGES > >include ap_mmn.h > > Log: > > The fix requires a bump > > > > Revision ChangesPath > > 1.704 +5 -0 httpd-2.0/CHANGES > > > > Index: CHANGES > > === > > RCS file: /home/cvs/httpd-2.0/CHANGES,v > > retrieving revision 1.703 > > retrieving revision 1.704 > > diff -u -r1.703 -r1.704 > > --- CHANGES 12 Apr 2002 19:58:51 - 1.703 > > +++ CHANGES 13 Apr 2002 19:58:04 - 1.704 > > @@ -1,5 +1,10 @@ > >Changes with Apache 2.0.36 > > > > + *) Allow Win32 shebang scripts to follow the path (or omit the .exe > > + suffix from the shebang command), and allow ScriptInterpreterSource > > + Registry or RegistryStrict to override shebang lines, as 1.3 did. > > + [William Rowe] > > + > > *) worker MPM: Fix a situation where a child exited without releasing > > the accept mutex. Depending on the OS and mutex mechanism this > > could result in a hang. [Jeff Trawick] > > > > > > > > 1.42 +2 -1 httpd-2.0/include/ap_mmn.h > > > > Index: ap_mmn.h > > === > > RCS file: /home/cvs/httpd-2.0/include/ap_mmn.h,v > > retrieving revision 1.41 > > retrieving revision 1.42 > > diff -u -r1.41 -r1.42 > > --- ap_mmn.h 29 Mar 2002 08:17:19 - 1.41 > > +++ ap_mmn.h 13 Apr 2002 19:58:04 - 1.42 > > @@ -103,12 +103,13 @@ > > * 20020319 (2.0.34-dev) M_INVALID changed, plus new M_* methods for RFC 3253 > > * 20020327 (2.0.35-dev) Add parameter to quick_handler hook > > * 20020329 (2.0.35-dev) bump for addition of freelists to bucket API > > + * 20020413 (2.0.36-dev) bump for new arg to opt fn ap_cgi_build_command > > */ > > > >#define MODULE_MAGIC_COOKIE 0x41503230UL /* "AP20" */ > > > >#ifndef MODULE_MAGIC_NUMBER_MAJOR > > -#define MODULE_MAGIC_NUMBER_MAJOR 20020329 > > +#define MODULE_MAGIC_NUMBER_MAJOR 20020413 > >#endif > >#define MODULE_MAGIC_NUMBER_MINOR 0 /* 0...n */ > >#define MODULE_MAGIC_NUMBER MODULE_MAGIC_NUMBER_MAJOR/* backward compat */ > > > > > > > > -- > Greg Stein, http://www.lyra.org/ -- Greg Stein, http://www.lyra.org/
Re: cvs commit: httpd-2.0/include ap_mmn.h
Woah... this just blew away all modules built for 2.0.35. This is an API change, which thus means a very careful review of WHY this change was required. Specifically, is there any way to avoid the change? For example, we could introduce a new function, and call that one instead from our code, leaving the old API untouched for third party modules. IOW, please justify the necessity of bumping the MMN. Cheers, -g On Sat, Apr 13, 2002 at 07:58:04PM -, [EMAIL PROTECTED] wrote: > wrowe 02/04/13 12:58:04 > > Modified:.CHANGES >include ap_mmn.h > Log: > The fix requires a bump > > Revision ChangesPath > 1.704 +5 -0 httpd-2.0/CHANGES > > Index: CHANGES > === > RCS file: /home/cvs/httpd-2.0/CHANGES,v > retrieving revision 1.703 > retrieving revision 1.704 > diff -u -r1.703 -r1.704 > --- CHANGES 12 Apr 2002 19:58:51 - 1.703 > +++ CHANGES 13 Apr 2002 19:58:04 - 1.704 > @@ -1,5 +1,10 @@ >Changes with Apache 2.0.36 > > + *) Allow Win32 shebang scripts to follow the path (or omit the .exe > + suffix from the shebang command), and allow ScriptInterpreterSource > + Registry or RegistryStrict to override shebang lines, as 1.3 did. > + [William Rowe] > + > *) worker MPM: Fix a situation where a child exited without releasing > the accept mutex. Depending on the OS and mutex mechanism this > could result in a hang. [Jeff Trawick] > > > > 1.42 +2 -1 httpd-2.0/include/ap_mmn.h > > Index: ap_mmn.h > === > RCS file: /home/cvs/httpd-2.0/include/ap_mmn.h,v > retrieving revision 1.41 > retrieving revision 1.42 > diff -u -r1.41 -r1.42 > --- ap_mmn.h29 Mar 2002 08:17:19 - 1.41 > +++ ap_mmn.h13 Apr 2002 19:58:04 - 1.42 > @@ -103,12 +103,13 @@ > * 20020319 (2.0.34-dev) M_INVALID changed, plus new M_* methods for RFC 3253 > * 20020327 (2.0.35-dev) Add parameter to quick_handler hook > * 20020329 (2.0.35-dev) bump for addition of freelists to bucket API > + * 20020413 (2.0.36-dev) bump for new arg to opt fn ap_cgi_build_command > */ > >#define MODULE_MAGIC_COOKIE 0x41503230UL /* "AP20" */ > >#ifndef MODULE_MAGIC_NUMBER_MAJOR > -#define MODULE_MAGIC_NUMBER_MAJOR 20020329 > +#define MODULE_MAGIC_NUMBER_MAJOR 20020413 >#endif >#define MODULE_MAGIC_NUMBER_MINOR 0 /* 0...n */ >#define MODULE_MAGIC_NUMBER MODULE_MAGIC_NUMBER_MAJOR /* backward compat */ > > > -- Greg Stein, http://www.lyra.org/
Re: cvs commit: httpd-2.0/include ap_mmn.h
On Tue, Jan 29, 2002 at 12:00:39AM -, [EMAIL PROTECTED] wrote: > aaron 02/01/28 16:00:39 > > Modified:include ap_mmn.h > Log: > I think this was supposed to have been bumped a couple times since > the 14th, and was perhaps forgotten about? In any case, it needs to > be bumped now -- pre_config hook return type has changed. Yeah, I screwed the pooch. I only changed the comment not the actual value when I bumped it. Oops. -- justin
Re: dependencies (was: Re: cvs commit: httpd-2.0/include ap_mmn.h)
On Sunday 26 August 2001 17:16, Greg Stein wrote: > On Sun, Aug 26, 2001 at 11:06:55AM -0700, Marc Slemko wrote: > > On 26 Aug 2001 [EMAIL PROTECTED] wrote: > > > wrowe 01/08/25 22:15:09 > > > > > > Modified:include ap_mmn.h > > > Log: > > > That last round calls for a bump. > > > > > > bump. > > > > > > Revision ChangesPath > > > 1.19 +2 -1 httpd-2.0/include/ap_mmn.h > > > > In 1.3, dependencies were generated periodically and then included in the > > makefiles... in 2.0, you have no dependencies unless you manually run > > "make depend" is the checked out tree... is it practical to have that > > automatically done somewhere? (buildconf?) > > The (apparent) consensus around dependencies focused around two points: I don't believe there was ever consensus around this. I believe half the developers wanted to see dependancies in the tree, and the other half didn't. > 1) some developers may/may not want them, so we should accomodate that [by >not forcing dependency generation] > > 2) end users do not require dependencies since they simply unpack and >compile the server. > > > Given the above two points, a developer (or a user!) that wants > dependencies can do a "make depend". Leaving it out of buildconf and > configure means that the others users are also satisfied. I have also never seen those two points before. The only argument I have ever seen around not having dependancies in CVS, is that we shouldn't have generated information stored in CVS. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: cvs commit: httpd-2.0/include ap_mmn.h
On 26 Aug 2001 [EMAIL PROTECTED] wrote: > wrowe 01/08/25 22:15:09 > > Modified:include ap_mmn.h > Log: > That last round calls for a bump. > > bump. > > Revision ChangesPath > 1.19 +2 -1 httpd-2.0/include/ap_mmn.h In 1.3, dependencies were generated periodically and then included in the makefiles... in 2.0, you have no dependencies unless you manually run "make depend" is the checked out tree... is it practical to have that automatically done somewhere? (buildconf?)
