Re: RFC: drop autoconf 2.13 support on trunk
On Thu, Nov 25, 2004 at 10:44:21AM +, Joe Orton wrote: I'd like to propose also to drop autoconf 2.13 support on the trunk. +1 (across the board, actually; no reason for httpd either) -- Greg Stein, http://www.lyra.org/
Re: svn commit: r106663 - /apr/apr/trunk/CHANGES /apr/apr/trunk/include/apr_file_io.h
At 03:26 PM 11/26/2004, you wrote: Author: stas Date: Fri Nov 26 13:26:37 2004 New Revision: 106663 URL: http://svn.apache.org/viewcvs?view=revrev=106663 Log: rename the fopen defines (APR_READ, APR_WRITE, etc.) to have prefix APR_FOPEN_ (keeping the old defines) Stas, you forgot doxygen @deprecate tags! For example, with; +#define APR_FOPEN_READ 0x1 /** Open the file for reading */ we need a matching doxygen entry redirecting the user; +#define APR_READ APR_FOPEN_READ /** @deprecated @see APR_FOPEN_READ */ This provides documentation that devs *need* to track the changes. Bill
Re: svn commit: r106663 - /apr/apr/trunk/CHANGES /apr/apr/trunk/include/apr_file_io.h
At 10:50 AM 11/29/2004, Stas Bekman wrote: Also should the deprecated macros stay in this file or can those be moved to some dedicated file to reduce the noise? They stay in place. During the next major+1 bump, the RM trawls through the files looking for @deprecated, and simply strips them out. The way doxygen works, you would not want these moving out of scope to another file. Bill
Re: svn commit: r106663 - /apr/apr/trunk/CHANGES /apr/apr/trunk/include/apr_file_io.h
William A. Rowe, Jr. wrote: At 10:50 AM 11/29/2004, Stas Bekman wrote: Also should the deprecated macros stay in this file or can those be moved to some dedicated file to reduce the noise? They stay in place. During the next major+1 bump, the RM trawls through the files looking for @deprecated, and simply strips them out. That's not possible with this particular change, since everything (APR/httpd) still uses the old macros. The way doxygen works, you would not want these moving out of scope to another file. Is there a way to put them in a different file and tell doxygen that the following entries really belong to a different file? -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: apxs/apr-config/apu-config on Win32
Randy Kobes wrote: I've been testing out some perl scripts to emulate apxs/apr-config/apu-config on Win32 (under Apache/2.0.x), and was wondering if there was any interest in developing them within the appropriate httpd/apr sources. At present they can be installed via a perl script http://perl.apache.org/dist/win32-bin/install_apxs This assumes an installed Apache binary with the associated apr/aprutil libs, but it would be possible to separate out the apxs from the apr/apu config utilties. In their present form they're intended for building modules outside of the httpd sources; they've been tested out on the c-modules within the perl-framework under httpd-test, as well as those under env/ of httpd-apreq-2, and they seem to work OK. +1 Randy is a long time committer to the mod_perl project, so I'm sure that if the proposed scripts are integrated with apr/httpd, Randy will be able to maintain those, once the right karma is added. There are very few brave folks who handle the win32 world, so let's make it easier for them to help the disadventaged win32 users. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: apxs/apr-config/apu-config on Win32
At 11:51 AM 11/29/2004, Stas Bekman wrote: Randy Kobes wrote: I've been testing out some perl scripts to emulate apxs/apr-config/apu-config on Win32 (under Apache/2.0.x), and was wondering if there was any interest in developing them within the appropriate httpd/apr sources. At present they can be installed via a perl script http://perl.apache.org/dist/win32-bin/install_apxs This assumes an installed Apache binary with the associated apr/aprutil libs, but it would be possible to separate out the apxs from the apr/apu config utilties. In their present form they're intended for building modules outside of the httpd sources; they've been tested out on the c-modules within the perl-framework under httpd-test, as well as those under env/ of httpd-apreq-2, and they seem to work OK. +1 Randy is a long time committer to the mod_perl project, so I'm sure that if the proposed scripts are integrated with apr/httpd, Randy will be able to maintain those, once the right karma is added. There are very few brave folks who handle the win32 world, so let's make it easier for them to help the disadventaged win32 users. ++1 - this is a wonderful thing. One note - I'd like to see this stripped to the point where you don't have a ton of dependencies on additional modules. Would be nice to distribute without the need to use Makemaker. Is this possible? (Putting necessary .pm stubs in the same tree as apxs and letting it run out-of-the-box?) Bill
Re: svn commit: r106663 - /apr/apr/trunk/CHANGES /apr/apr/trunk/include/apr_file_io.h
At 11:45 AM 11/29/2004, Stas Bekman wrote: William A. Rowe, Jr. wrote: At 10:50 AM 11/29/2004, Stas Bekman wrote: Also should the deprecated macros stay in this file or can those be moved to some dedicated file to reduce the noise? They stay in place. During the next major+1 bump, the RM trawls through the files looking for @deprecated, and simply strips them out. That's not possible with this particular change, since everything (APR/httpd) still uses the old macros. No, it's a requirement when we push major+1. Then again, httpd may stay with 1.x, or may have a prerequisite 1.1 (meaning we assume your change is there) or it may even move to 2.x - in which case we -must- update all occurrences within httpd. There is no reason to keep using the old symbols in apr[-util/-iconv] so feel free to start migrating those. The way doxygen works, you would not want these moving out of scope to another file. Is there a way to put them in a different file and tell doxygen that the following entries really belong to a different file? 1. it isn't pretty and 2. you can't force a user to include another file from minor to minor bump. Their code should keep compiling w/o changes. Please don't worry that this seems 'polluted' - the next major bump cleans this all out. In the meantime, if they look for these symbols grep APR_FOO include/* they should find the old and new flavors in the same file, helping them with their own migration tasks. Bill
Re: svn commit: r106663 - /apr/apr/trunk/CHANGES /apr/apr/trunk/include/apr_file_io.h
William A. Rowe, Jr. wrote: At 11:45 AM 11/29/2004, Stas Bekman wrote: William A. Rowe, Jr. wrote: At 10:50 AM 11/29/2004, Stas Bekman wrote: Also should the deprecated macros stay in this file or can those be moved to some dedicated file to reduce the noise? They stay in place. During the next major+1 bump, the RM trawls through the files looking for @deprecated, and simply strips them out. That's not possible with this particular change, since everything (APR/httpd) still uses the old macros. No, it's a requirement when we push major+1. Then again, httpd may stay with 1.x, or may have a prerequisite 1.1 (meaning we assume your change is there) or it may even So when will it be possible to know whether it'll be in or not? If someone decides to remove those later, why do I waste my time? move to 2.x - in which case we -must- update all occurrences within httpd. Understood. There is no reason to keep using the old symbols in apr[-util/-iconv] so feel free to start migrating those. I'll be working on symbols that I touch, at the moment I don't have to time to work on other things. Once mod_perl 2.0 is out I may be able to spend more time on other things. The way doxygen works, you would not want these moving out of scope to another file. Is there a way to put them in a different file and tell doxygen that the following entries really belong to a different file? 1. it isn't pretty and 2. you can't force a user to include another file from minor to minor bump. Their code should keep compiling w/o changes. Please don't worry that this seems 'polluted' - the next major bump cleans this all out. In the meantime, if they look for these symbols grep APR_FOO include/* they should find the old and new flavors in the same file, helping them with their own migration tasks. Good point. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
