No, you entirely miss the point.
The HEADER tells the user who compiles against it, exactly what httpd
has or doesn't have.
If it doesn't have it, the fn returns NOTIMPL. That's fine.
Your patch screws the user thusly;
mturk build says; -DAPU_HAVE_ICONV=0
user's project says nothing...
tests #if APU_HAVE_ICONV
decides to enable feature X based on ICONV being present.
User runs his program which promptly crashes.
Thanks dude :)
Whatever the ***public*** headers say is what apr[-whatever] must be.
You can play these games in internal, private headers. That doesn't matter.
Bill
Mladen Turk wrote:
William A. Rowe, Jr. wrote:
> William A. Rowe, Jr. wrote:
>>
>> Shall we set up an appropriate perl/python/awk script which accepts
>> --with-iconv and can direct it at apr-iconv, libiconv for the gnuish
>> folk or something else altogether?
>
> Of course --without-iconv is one of those legitimate somethings ;-)
>
> But that results in an absolute
>
> #define APU_HAVE_APR_ICONV 0
> #define APU_HAVE_ICONV 0
>
Right, but in that case we have:
#else /* !APR_HAS_XLATE */
APU_DECLARE(apr_status_t) apr_xlate_open(apr_xlate_t **convset,
const char *topage,
const char *frompage,
apr_pool_t *pool)
{
return APR_ENOTIMPL;
}
> with no ambiguity.
>
And that's legitimate.
In other case the apu build should fail I suppose.
Regards,
Mladen.
.
