[ 
https://issues.apache.org/jira/browse/AXIS2C-1130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Nairn updated AXIS2C-1130:
--------------------------------

    Attachment: libxml2.patch

The attached patch (against r654079 of SVN) cleans up the use of libxml2 
(though there is still some cleanup remaining).

The configure scripts in tools and samples are changed to not check which 
parser to use (as they don't care).

The toplevel configure script is changed so that the NAME argument to 
PKG_CHECK_MODULES is changed to LIBXML2 from PARSER (so that it matches the 
NAME used in the axiom configure script). This is basically a cosmetic change 
that affects the output of "configure --help" so that it says you can override 
what pkg-config finds out about libxml2 with the environment variables 
LIBXML2_CFLAGS and LIBXML2_LIBS. Since these are the variables that are used by 
the configure script in axiom then it makes sense for the help of the higher 
level configure script to tell you about them.

The axiom configure script is changed to remove $LIBXML2_CFLAGS from CFLAGS 
(they are used as required in axiom/src/parser/libxml2/Makefile.am)

axiom/src/parser/libxml2/Makefile.am is changed to not build 
libaxis2_libxml2.la (since it doesn't seem to be needed). It's also changed to 
use the CFLAGS and LIBS required to compile/link with libxml2 that the axiom 
configure script found out from pkg-config.

Loads of other Makefile.am's are changed to remove reference to the libxml2 
libraries (as the reference is not required). The references to guththila could 
also be removed but I've not done that (as this change is about libxml2).

With the patch applied Axis2/C configures (both with --enable-libxml2 and 
without), builds and runs the same as unpatched trunk.


> Build system's use of libxml2 needs cleaning up
> -----------------------------------------------
>
>                 Key: AXIS2C-1130
>                 URL: https://issues.apache.org/jira/browse/AXIS2C-1130
>             Project: Axis2-C
>          Issue Type: Improvement
>          Components: build system
>    Affects Versions: 1.4.0
>         Environment: CentOS 4.6 (linux), GCC 4.2.3
>            Reporter: Steve Nairn
>            Priority: Minor
>         Attachments: libxml2.patch
>
>
> Now that 1.4.0 is out of the way.... I'm in the process of getting Axis2/C to 
> build on Solaris, AIX, HP/UX, Tru64 and Windows (with MinGW) so am modifying 
> the "configure.ac"s and "Makefile.am"s. Rather than try and submit huge 
> patches that achieve this I thought I'd have more luck getting patches 
> accepted if they're smaller and more manageable.
> One problem I've come across is the way libxml2 is used in the build system 
> (if "--enable-libxml2" is supplied).
> The first problem is that it's difficult to use libxml2 if it is installed in 
> a non-standard place so extra CFLAGS and LDFLAGS must be supplied for the 
> build. This should not be the case as the configure script(s) use the 
> PKG_CHECK_MODULES macro to check for libxml2. This uses pkg-config to find 
> out if the libxml2 package is installed and if so, what CFLAGS and LDFLAGS 
> are required to use the package. Unfortunately this information is not then 
> used in the Makefile(s).
> The second problem is the samples and tools configure scripts check whether 
> to use guththila or libxml2 when they don't need to. The axiom configure 
> script needs to know so that it can build the correct wrapper library and the 
> top level configure script needs to know so it can pass the option to the 
> axiom configure script and so it can configure in guththila (if guththila is 
> enabled). The samples and tools shouldn't care which parser is being used so 
> don't need to check (the check just adds unnecessary complexity).
> The third problem is that the Makefile in axiom/src/parser/libxml2 builds 
> libaxis2_libxml2.la as well as libaxis2_parser.la which appears to be a bit 
> pointless. The libraries are identical and nothing uses libaxis2_libxml2,la. 
> This can be removed.
> The final problem is that lots of Makefiles explicitly mention the libxml2 or 
> guththila libraries when they don't need to. The build system uses libtool 
> which maintains the dependency information required to use a library. When 
> libaxis2_parser (either the guththila or libxml2 version) is built libtool 
> adds the dependent libraries (either guththila or libxml2) to the 
> libaxis2_parser.la file. When anything else is linked with libaxis2_parser.la 
> by libtool then libtool will automatically include the right dependent 
> libraries to the link (In fact, for the same reason very little needs to 
> explicitly link with libaxis2_parser.la since if things link to 
> libaxis2_axiom.la libtool makes sure they get the right libaxis2_parser as it 
> is required to build libaxis2_axiom.la).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to