[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Quick divert() 2.13/2.6x portability macro

From: Rasmus Lerdorf
Subject: Re: Quick divert() 2.13/2.6x portability macro
Date: Sat, 28 Nov 2009 05:42:38 -0800
User-agent: Thunderbird (X11/20090817)

Eric Blake wrote:
> What exactly are you trying to accomplish?  Without knowing your end goal,
> I can't properly suggest a better alternative (and note that the better
> alternative might mean using a different interface altogether).  It may be
> better off to use the documented interface of m4_divert_text or a proper
> use of AC_REQUIRE to cause the topological sorting necessary to achieve
> your desired output order, without having to rely on raw diversions.

Basically the diversions are there to organize the phases of the checks.

## Diversion 1 is the autoconf + automake setup phase. We also
## set the PHP version, deal with platform-specific compile
## options and check for the basic compile tools.

## Diversion 2 is the initial checking of OS features, programs,
## libraries and so on.

## In diversion 3 we check for compile-time options to the PHP
## core and how to deal with different system dependencies.
## This includes whether debugging or short tags are enabled
## and the default behaviour of php.ini options.
## This is also where a SAPI interface is selected (choosing between
## Apache module, CGI etc.)

## In diversion 4 we check user-configurable general settings.

## In diversion 5 we check which extensions should be compiled.
## All of these are normally in the extension directories.
## Diversion 5 is the last one.  Here we generate files and clean up.

I changed these from 1-5 to 1001-1005, but that breaks the build under
2.13 and even under 2.65 it messes up the output of configure --help

I would love to get off of 2.13, but it would be easier to do if I had a
migration phase where things worked in both.  As it is there is a strong
faction that is of the opinion that everything works fine in 2.13, and
it all breaks in 2.65, so we'll just stick to 2.13 forever since
fiddling with m4 scripts isn't a whole lot of fun.

As far as my little naiive attempt at replacing my divert() calls with a
little macro that will use different diversions in 2.65 go, changing it
to use m4_divert() didn't make a difference.  And I don't really
understand how I messed up the diversion stack.  All I am doing is
replacing a direct call to divert(1) with a call to PHP_DIVERT(1) where
PHP_DIVERT is now:


Why does that change the stack?  Shouldn't it still be pushing those
diversions onto the stack in exactly the same order or is there some m4
scoping thing going on?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]