You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@apr.apache.org by mt...@apache.org on 2006/05/31 15:38:55 UTC
svn commit: r410522 - /apr/apr-util/trunk/include/apu.hw
Author: mturk
Date: Wed May 31 06:38:54 2006
New Revision: 410522
URL: http://svn.apache.org/viewvc?rev=410522&view=rev
Log:
Allow external override for XLATE support.
The XLATE can be disabled by setting the
APR_HAS_XLATE=0 on build time.
Modified:
apr/apr-util/trunk/include/apu.hw
Modified: apr/apr-util/trunk/include/apu.hw
URL: http://svn.apache.org/viewvc/apr/apr-util/trunk/include/apu.hw?rev=410522&r1=410521&r2=410522&view=diff
==============================================================================
--- apr/apr-util/trunk/include/apu.hw (original)
+++ apr/apr-util/trunk/include/apu.hw Wed May 31 06:38:54 2006
@@ -1,4 +1,4 @@
-/* Copyright 2000-2005 The Apache Software Foundation or its licensors, as
+/* Copyright 2000-2006 The Apache Software Foundation or its licensors, as
* applicable.
*
* Licensed under the Apache License, Version 2.0 (the "License");
@@ -94,10 +94,12 @@
#define APU_HAVE_DB 0
#endif
-
+/* Allow external override */
+#if !defined(APU_HAS_XLATE)
#define APU_HAVE_APR_ICONV 1
#define APU_HAVE_ICONV 0
#define APR_HAS_XLATE (APU_HAVE_APR_ICONV || APU_HAVE_ICONV)
+#endif
#if !defined(APU_HAVE_PGSQL)
#define APU_HAVE_PGSQL 0
Re: svn commit: r410522 - /apr/apr-util/trunk/include/apu.hw
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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.
>
> .
>
Re: svn commit: r410522 - /apr/apr-util/trunk/include/apu.hw
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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.
>
> .
>
Re: svn commit: r410522 - /apr/apr-util/trunk/include/apu.hw
Posted by Mladen Turk <mt...@apache.org>.
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.
Re: svn commit: r410522 - /apr/apr-util/trunk/include/apu.hw
Posted by Mladen Turk <mt...@apache.org>.
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.
Re: svn commit: r410522 - /apr/apr-util/trunk/include/apu.hw
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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
with no ambiguity.
Re: svn commit: r410522 - /apr/apr-util/trunk/include/apu.hw
Posted by Mladen Turk <mt...@apache.org>.
William A. Rowe, Jr. wrote:
>> I think we can have a simple .vbs or .js script.
>> Using other languages is additional tool dependency thought.
>
> I know :(
>
> I'm almost resigned to saying something like, users who build APR have
> .NET 1.0 or bigger installed, so just write the danged things in C#.
>
I think we can learn something from the PHP community.
They have a neat configure.js that is used to mimic the
unixoid build system. Further more, the cscript comes with
almost any windows version (think it's part of IE5+).
I think we should seek in that direction instead depending on
many versatile scripting technologies.
OTOH, if the httpd will be bound with OpenSSL, then I think
that even the Perl can be used, because it is already required
by the OpenSSL build.
Regards,
Mladen.
Re: svn commit: r410522 - /apr/apr-util/trunk/include/apu.hw
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Mladen Turk wrote:
> Correct if you need to have installed headers files with binary
> distribution. In case you don't, its irrelevant.
> OTOH it's the same like APR_DECLARE_STATIC/APU_DECLARE_STATIC
> etc..
Different case, although I don't entirely disagree. We set up this
convention so we could install both static and dynamic flavors; win32
is a little unique in having different compile bits thrown. Presuming
you want the dynamic lib (almost always a good idea) then you have to
do nothing whatsoever. If you really really want to tweak things to
build the library into your program (that's a stretch on unix too!)
then you have to throw these flags, and link to apr.lib instead of
libapr.lib, which already proves that this small discrepancy isn't
a huge deal. You can't -lapr on windows in the first place.
> That's why we have apu/apr.hw at the first place.
> Having a perl, or a notepad is the same thing.
> I think we can have a simple .vbs or .js script.
> Using other languages is additional tool dependency thought.
I know :(
I'm almost resigned to saying something like, users who build APR have
.NET 1.0 or bigger installed, so just write the danged things in C#.
/shrug
Bill
Re: svn commit: r410522 - /apr/apr-util/trunk/include/apu.hw
Posted by Mladen Turk <mt...@apache.org>.
William A. Rowe, Jr. wrote:
> -1 veto. Please revert.
>
Reverted.
> Installed (finalized) c language headers cannot be volitile based on
> environmental factors. It's the #1 source of my wasted time (not in ASF
> projects, specificially).
>
Correct if you need to have installed headers files with binary
distribution. In case you don't, its irrelevant.
OTOH it's the same like APR_DECLARE_STATIC/APU_DECLARE_STATIC
etc..
> Shall we set up an appropriate perl/python/awk script which accepts
> --with-iconv
That's why we have apu/apr.hw at the first place.
Having a perl, or a notepad is the same thing.
I think we can have a simple .vbs or .js script.
Using other languages is additional tool dependency thought.
Regards,
Mladen.
Re: svn commit: r410522 - /apr/apr-util/trunk/include/apu.hw
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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
with no ambiguity.
Re: svn commit: r410522 - /apr/apr-util/trunk/include/apu.hw
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
mturk@apache.org wrote:
> -
> +/* Allow external override */
> +#if !defined(APU_HAS_XLATE)
> #define APU_HAVE_APR_ICONV 1
> #define APU_HAVE_ICONV 0
> #define APR_HAS_XLATE (APU_HAVE_APR_ICONV || APU_HAVE_ICONV)
> +#endif
-1 veto. Please revert.
Installed (finalized) c language headers cannot be volitile based on
environmental factors. It's the #1 source of my wasted time (not in ASF
projects, specificially).
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?
Bill
Re: svn commit: r410522 - /apr/apr-util/trunk/include/apu.hw
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
mturk@apache.org wrote:
> -
> +/* Allow external override */
> +#if !defined(APU_HAS_XLATE)
> #define APU_HAVE_APR_ICONV 1
> #define APU_HAVE_ICONV 0
> #define APR_HAS_XLATE (APU_HAVE_APR_ICONV || APU_HAVE_ICONV)
> +#endif
-1 veto. Please revert.
Installed (finalized) c language headers cannot be volitile based on
environmental factors. It's the #1 source of my wasted time (not in ASF
projects, specificially).
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?
Bill