Re: Problems starting Apache 2.2 with mod_ruby

I agree, it adds a bit of complication, but will support both  
versions quite well in transition.  "Porting Unix Software" from  
O'Reilly recommends this as a way to easily support different  
architectures easily.  If you look at a lot of Open Source projects  
which support different operating systems and hardware, you'll see  
#ifdef sprinkled liberally throughout the code.  If one is consistent  
with the conditional compiles, then the chance of error is minimal.

Also, it's easy to snip out the #ifdef directives later when you want  
to drop support for the old version of Apache.

I think writing a stub library is adding a different bit of  
complexity and may even in the long run be more difficult to  
maintain, especially when you want to completely transition the code  
over to the new API.

Both versions of Apache can be supported without starting a new code  
branch, unless that's the intention.  Then you have two code branches  
which can diverge in many different ways.  Changes to one may not  
always make it into the other.

I did also use the macro translation patch which was posted the other  
day with the same result.  (In my opinion, not the best way to do it  
either, but it works.)

Then again, perhaps it's time to quit supporting the old API and move  
forward using the new API entirely while freezing the last release  
which supports the old API.

The cleanliness of my compiles and checking each C source module and  
header along with a clean link indicates to me I didn't miss any  
functions in the translation, before moving along to the next C  
source file and its compile.

Mike - who really doesn't want to start any C programming style wars.

On Jan 10, 2006, at 21:55 , Dan Cross wrote:

> On Tue, Jan 10, 2006 at 08:37:53PM +0900, Michael Sullivan wrote:
>> #ifdef APACHE2
>> 	apr_new-function_call(....);
>> #else
>> 	ap_old_function(...);
>> #endif
>
> I don't recommend doing this.  It's a good way to introduce errors.  A
> better approach is to create an intermediate interface that you  
> program
> to, and then provide concrete implementations of that for both old and
> new APR functions, and link in the apporpriate versions at the  
> end.  E.g.,
> instead if the above, have:
>
> 	stub_apr_call(...);	/* Hopefully with a better name */
>
> And then in oldap.c:
>
> whatever *
> stub_apr_call(...)
> {
> 	return ap_old_function(...);
> }
>
> While in newapr.c:
>
> whatever *
> stub_apr_call(...)
> {
> 	return apr_new_function(...);
> }
>
> In general, conditional compilation has been a fruitful source of  
> errors,
> and something like this will be easier to debug.
>
> 	- Dan C.
>
>