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-----
>>
>>
>
Index: build/ac-macros/neon.m4
===================================================================
--- build/ac-macros/neon.m4 (revision 17993)
+++ build/ac-macros/neon.m4 (working copy)
@@ -80,6 +80,20 @@
# 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.
+ apr_utils_includes=`$abs_builddir/apr-util/apu-config --includes`
+ apr_utils_ldflags=`$abs_builddir/apr-util/apu-config --ldflags`
+ args="$args CPPFLAGS='$apr_utils_includes $CPPFLAGS' LDFLAGS='$apr_utils_ldflags $LDFLAGS'"
fi
SVN_EXTERNAL_PROJECT([neon], [$args])
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 6 19:48:03 2006