You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Max Bowsher <ma...@ukf.net> on 2006/01/05 13:45:51 UTC
Re: [PATCH] Fix for #699 XML parser not detected at configure time
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Kamesh Jayachandran wrote:
> Hi Garrett,
> Thanks for your feedback.
> Based on comment on this defect by maxb sometime this january to make
> use the apu-config --includes and apu-config --ldflags, modified the
> patch and tested by having two installations of expat one in the
> /usr/local and another in the /home/kamesh/expat and made the CFLAGS to
> have -I/home/kamesh/expat/include to influence the neon to take the
> expat from /home/kamesh/expat while apr-util take it from /usr/local/lib.
> With this patch apr-util always dictates what version of expat neon says.
> Ran make check which went through fine.
>
> [[[
> Fix issue #699, XML parser not detected at configure time
> * build/ac-macros/neon.m4
> Configure neon block
> There is a difference in the way expat(actually expat.h) is
> identified in the build system between the apr-util and neon.
> The apr-util explicitly identifies the expat in /usr, /usr/local.
> The neon hands off the task to AC_CHECK_HEADER autoconf macro
> which just relies on the default behaviour of
> $(CC), $(CFLAGS) $(CPPFLAGS) which seems to be fine in my gcc
> version 3.4.3 20041212 (Red Hat 3.4.3-9.EL4).
> Because of this difference possibly both might find a different
> versions of expat.
> The fix feeds the findings of apr-util to neon.
> ]]]
>
> Index: build/ac-macros/neon.m4
> ===================================================================
> --- build/ac-macros/neon.m4 (revision 17664)
> +++ build/ac-macros/neon.m4 (working copy)
> @@ -79,6 +79,17 @@
> # there, otherwise, neon is on its own to find expat.
> if test -f "$abs_builddir/apr-util/xml/expat/lib/expat.h" ; then
> args="$args --with-expat='$abs_builddir/apr-util/xml/expat/lib/libexpat.la'"
> + else
> + #There is a difference in the way expat(actually expat.h) is identified in the build system between the apr-util and neon.
> + #apr-util explicitly identifies the expat in /usr, /usr/local
> + #neon hands off the task to AC_CHECK_HEADER autoconf macro which just relies on the default behaviour of $(CC), $(CFLAGS) $(CPPFLAGS) which seems to be fine in my gcc version 3.4.3 20041212 (Red Hat 3.4.3-9.EL4).
> + #Because of this difference possibly both might find a different versions of expat.
> + #The below solution feeds the findings of apr-util to neon.
> + if test -f /usr/local/include/expat.h; then
> + apr_utils_includes=`$abs_builddir/apr-util/apu-config --includes`
> + apr_utils_ldflags=`$abs_builddir/apr-util/apu-config --ldflags`
> + args="$args CFLAGS='$apr_utils_includes $CFLAGS' LDFLAGS='$apr_utils_ldflags $LDFLAGS'"
> + fi
> fi
> SVN_SUBDIR_CONFIG(neon, $args)
Why all this weird special-casing instead of following the suggested
course of action I described in issuezilla?
Max.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
iD8DBQFDvSMPfFNSmcDyxYARAm21AJ9hp7bRH9AUsZP5IUvB7anayImCgACguYkI
VsrX9YHUYgqy9voHHmjrmLA=
=YIPE
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Fix for #699 XML parser not detected at configure time
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 1/6/06, Garrett Rooney <ro...@electricjellyfish.net> wrote:
> On 1/6/06, Kamesh Jayachandran <ka...@collab.net> wrote:
> > Hi Max,
> > Sorry misunderstood your point.
> > Please look at my new patch.
> >
> > With regards
> > Kamesh Jayachandran
> > [[[
> > Fix for #699 XML parser not detected at configure time.
> >
> > * build/ac-macros/neon.m4
> > (SVN_LIB_NEON): Feeds the findings of apr-util to neon.
> >
> > ]]]
>
> This looks good to me. Committed (with some rewriting of the comment)
> in revision 18005.
Oops, it turns out I missinterpreted maxb's plan for solving this
issue. What he was really going for is in aprutil.m4 pulling
apr-util's cflags, cppflags, and includes into our own CPPFLAGS/CFLAGS
variables, so we can be sure we're always using them when they're
needed.
I've reverted the change in the meantime, because it has some other
issues Max pointed out (hardcoded apu-config is a bad thing, for
example, since we could be using apr-util 1.x which uses
apr-1-config), and unfortunately I've timed out on the amount of
effort I can put in to this now, since a low level build change like
that will likely have unforseen consequences and there are a lot of
combinations to test...
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Fix for #699 XML parser not detected at configure time
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 1/6/06, Kamesh Jayachandran <ka...@collab.net> wrote:
> Hi Max,
> Sorry misunderstood your point.
> Please look at my new patch.
>
> With regards
> Kamesh Jayachandran
> [[[
> Fix for #699 XML parser not detected at configure time.
>
> * build/ac-macros/neon.m4
> (SVN_LIB_NEON): Feeds the findings of apr-util to neon.
>
> ]]]
This looks good to me. Committed (with some rewriting of the comment)
in revision 18005.
Thanks!
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Fix for #699 XML parser not detected at configure time
Posted by Kamesh Jayachandran <ka...@collab.net>.
Hi Max,
Sorry misunderstood your point.
Please look at my new patch.
With regards
Kamesh Jayachandran
[[[
Fix for #699 XML parser not detected at configure time.
* build/ac-macros/neon.m4
(SVN_LIB_NEON): Feeds the findings of apr-util to neon.
]]]
Kamesh Jayachandran wrote:
> Hi Max,
> How will setting CPPFLAGS or LDFLAGS from the svn build programs will
> affect the neon configure routine?
> My patch calls the neon's configure with the LDFLAGS/CFLAGS values as
> seen by svn build programs from apr-util.
>
> Unfortunately I could not reproduce the same issue now as I did
> sometime back. Yes I could reproduce now but my very restrictive
> '-nostdinc' to CFLAGS and CPPFLAGS causes someother compile issue
> which it did not in the past. Will try and get back.
>
> With regards
> Kamesh Jayachandran
>
> Max Bowsher wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Kamesh Jayachandran wrote:
>>
>>> Hi Garrett,
>>> Thanks for your feedback.
>>> Based on comment on this defect by maxb sometime this january to make
>>> use the apu-config --includes and apu-config --ldflags, modified the
>>> patch and tested by having two installations of expat one in the
>>> /usr/local and another in the /home/kamesh/expat and made the CFLAGS to
>>> have -I/home/kamesh/expat/include to influence the neon to take the
>>> expat from /home/kamesh/expat while apr-util take it from /usr/local/lib.
>>> With this patch apr-util always dictates what version of expat neon says.
>>> Ran make check which went through fine.
>>>
>>> [[[
>>> Fix issue #699, XML parser not detected at configure time
>>> * build/ac-macros/neon.m4
>>> Configure neon block
>>> There is a difference in the way expat(actually expat.h) is
>>> identified in the build system between the apr-util and neon.
>>> The apr-util explicitly identifies the expat in /usr, /usr/local.
>>> The neon hands off the task to AC_CHECK_HEADER autoconf macro
>>> which just relies on the default behaviour of
>>> $(CC), $(CFLAGS) $(CPPFLAGS) which seems to be fine in my gcc
>>> version 3.4.3 20041212 (Red Hat 3.4.3-9.EL4).
>>> Because of this difference possibly both might find a different
>>> versions of expat.
>>> The fix feeds the findings of apr-util to neon.
>>> ]]]
>>>
>>> Index: build/ac-macros/neon.m4
>>> ===================================================================
>>> --- build/ac-macros/neon.m4 (revision 17664)
>>> +++ build/ac-macros/neon.m4 (working copy)
>>> @@ -79,6 +79,17 @@
>>> # there, otherwise, neon is on its own to find expat.
>>> if test -f "$abs_builddir/apr-util/xml/expat/lib/expat.h" ; then
>>> args="$args --with-expat='$abs_builddir/apr-util/xml/expat/lib/libexpat.la'"
>>> + else
>>> + #There is a difference in the way expat(actually expat.h) is identified in the build system between the apr-util and neon.
>>> + #apr-util explicitly identifies the expat in /usr, /usr/local
>>> + #neon hands off the task to AC_CHECK_HEADER autoconf macro which just relies on the default behaviour of $(CC), $(CFLAGS) $(CPPFLAGS) which seems to be fine in my gcc version 3.4.3 20041212 (Red Hat 3.4.3-9.EL4).
>>> + #Because of this difference possibly both might find a different versions of expat.
>>> + #The below solution feeds the findings of apr-util to neon.
>>> + if test -f /usr/local/include/expat.h; then
>>> + apr_utils_includes=`$abs_builddir/apr-util/apu-config --includes`
>>> + apr_utils_ldflags=`$abs_builddir/apr-util/apu-config --ldflags`
>>> + args="$args CFLAGS='$apr_utils_includes $CFLAGS' LDFLAGS='$apr_utils_ldflags $LDFLAGS'"
>>> + fi
>>> fi
>>> SVN_SUBDIR_CONFIG(neon, $args)
>>>
>>
>> Why all this weird special-casing instead of following the suggested
>> course of action I described in issuezilla?
>>
>> Max.
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.1 (Cygwin)
>>
>> iD8DBQFDvSMPfFNSmcDyxYARAm21AJ9hp7bRH9AUsZP5IUvB7anayImCgACguYkI
>> VsrX9YHUYgqy9voHHmjrmLA=
>> =YIPE
>> -----END PGP SIGNATURE-----
>>
>>
>
Re: [PATCH] Fix for #699 XML parser not detected at configure time
Posted by Kamesh Jayachandran <ka...@collab.net>.
Hi Max,
How will setting CPPFLAGS or LDFLAGS from the svn build programs will
affect the neon configure routine?
My patch calls the neon's configure with the LDFLAGS/CFLAGS values as
seen by svn build programs from apr-util.
Unfortunately I could not reproduce the same issue now as I did sometime
back. Yes I could reproduce now but my very restrictive '-nostdinc' to
CFLAGS and CPPFLAGS causes someother compile issue which it did not in
the past. Will try and get back.
With regards
Kamesh Jayachandran
Max Bowsher wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Kamesh Jayachandran wrote:
>
>> Hi Garrett,
>> Thanks for your feedback.
>> Based on comment on this defect by maxb sometime this january to make
>> use the apu-config --includes and apu-config --ldflags, modified the
>> patch and tested by having two installations of expat one in the
>> /usr/local and another in the /home/kamesh/expat and made the CFLAGS to
>> have -I/home/kamesh/expat/include to influence the neon to take the
>> expat from /home/kamesh/expat while apr-util take it from /usr/local/lib.
>> With this patch apr-util always dictates what version of expat neon says.
>> Ran make check which went through fine.
>>
>> [[[
>> Fix issue #699, XML parser not detected at configure time
>> * build/ac-macros/neon.m4
>> Configure neon block
>> There is a difference in the way expat(actually expat.h) is
>> identified in the build system between the apr-util and neon.
>> The apr-util explicitly identifies the expat in /usr, /usr/local.
>> The neon hands off the task to AC_CHECK_HEADER autoconf macro
>> which just relies on the default behaviour of
>> $(CC), $(CFLAGS) $(CPPFLAGS) which seems to be fine in my gcc
>> version 3.4.3 20041212 (Red Hat 3.4.3-9.EL4).
>> Because of this difference possibly both might find a different
>> versions of expat.
>> The fix feeds the findings of apr-util to neon.
>> ]]]
>>
>> Index: build/ac-macros/neon.m4
>> ===================================================================
>> --- build/ac-macros/neon.m4 (revision 17664)
>> +++ build/ac-macros/neon.m4 (working copy)
>> @@ -79,6 +79,17 @@
>> # there, otherwise, neon is on its own to find expat.
>> if test -f "$abs_builddir/apr-util/xml/expat/lib/expat.h" ; then
>> args="$args --with-expat='$abs_builddir/apr-util/xml/expat/lib/libexpat.la'"
>> + else
>> + #There is a difference in the way expat(actually expat.h) is identified in the build system between the apr-util and neon.
>> + #apr-util explicitly identifies the expat in /usr, /usr/local
>> + #neon hands off the task to AC_CHECK_HEADER autoconf macro which just relies on the default behaviour of $(CC), $(CFLAGS) $(CPPFLAGS) which seems to be fine in my gcc version 3.4.3 20041212 (Red Hat 3.4.3-9.EL4).
>> + #Because of this difference possibly both might find a different versions of expat.
>> + #The below solution feeds the findings of apr-util to neon.
>> + if test -f /usr/local/include/expat.h; then
>> + apr_utils_includes=`$abs_builddir/apr-util/apu-config --includes`
>> + apr_utils_ldflags=`$abs_builddir/apr-util/apu-config --ldflags`
>> + args="$args CFLAGS='$apr_utils_includes $CFLAGS' LDFLAGS='$apr_utils_ldflags $LDFLAGS'"
>> + fi
>> fi
>> SVN_SUBDIR_CONFIG(neon, $args)
>>
>
> Why all this weird special-casing instead of following the suggested
> course of action I described in issuezilla?
>
> Max.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (Cygwin)
>
> iD8DBQFDvSMPfFNSmcDyxYARAm21AJ9hp7bRH9AUsZP5IUvB7anayImCgACguYkI
> VsrX9YHUYgqy9voHHmjrmLA=
> =YIPE
> -----END PGP SIGNATURE-----
>
>