improve autoconf support
------------------------

                 Key: AXIS2C-313
                 URL: http://issues.apache.org/jira/browse/AXIS2C-313
             Project: Axis2-C
          Issue Type: Improvement
          Components: build system (Unix/Linux)
    Affects Versions: 0.93
         Environment: Unix/Linux, maybe Windows and others.
            Reporter: Chris Darroch


The autoconf system really isn't being used effectively for the axis2c package. 
 First, as noted
in another bug report, some of the code searches for libraries in 
$AXIS2C_HOME/lib regardless
of what is specified by the user when using the --libdir configure option.

Second, it would be better if include files were installed in, say, 
$includedir/axis2, the way
the APR project installs them in $includedir/apr-$majorversion and httpd 
installs them
in $includedir/apache2.  Given that 375 files are installed, this is otherwise 
a major source
of pollution in a common location.

Third, if one uses --libdir, --includedir, and --bindir, then each successive 
installation
of an axis2c sub-project (like xml_schema or woden) and the main axis2c 
installation itself
should use these locations to search for dependencies.   As it is, the util 
sub-project
installs quite neatly, but then all the others require patches to their 
Makefiles and/or specific
CFLAGS and LDFLAGS settings so that they can locate the previous sub-projects'
headers and libraries.  This really shouldn't be necessary; they should look in 
--libdir
and --includedir automatically.

Fourth, the various test suites that run when "make check" is used fail in a 
wide variety of
ways.  Many of the test suites depend on libcutest.a -- but this isn't 
something the CuTest
package provides!  Instead, you have to dig out a posting to the mailing list:

http://www.mail-archive.com/axis-c-dev@ws.apache.org/msg04697/Makefile

(An alternative would be the derived version that the APR test suite uses.)  
Other tests
depend on data files that aren't in the distribution; for example, the 
xml_schema tests
seem to require the files from 
https://svn.apache.org/repos/asf/webservices/commons/trunk/modules/XmlSchema/src/test/test-resources/
in a "resources" directory.  The woden tests require a Calculator.wsdl file 
that I found in
https://svn.apache.org/repos/asf/webservices/axis2/trunk/c/test/resources/wsdl, 
but it
required that the xmlns:wsdl="http://schemas.xmlsoap.org/wsdl"; attribute *not* 
have a
trailing slash and WODEN_WSDL10_DESC_GET_INTERFACES() be used.  The
util/test/util/test_util.c file calls run_test_string(env) after freeing the 
env variable, producing
a segfault.  And so forth.

Fifth, while I realize this would be a pain, it would be really superb if one 
could control
the layout of the $AXIS2C_HOME location using the kinds of options provided by 
the
config.layout file in the httpd package.  More, instead of requiring 
directories under
$AXIS2C_HOME named "logs", "services", "modules", and so forth, and requiring 
that
the libraries in the services and modules directories be accompanied by XML 
files,
it would be great if you could ask for a layout like this:

$prefix = $MY_INSTALL_DIR
$bindir = $prefix/bin (by default, use --bindir to change)
$includedir = $prefix/include/axis2 (by default, use --includedir to change)
$libdir = $prefix/lib/axis2 (by default, use --libdir to change)
$sysconfdir = $prefix/etc/axis2 (by default, use --sysconfdir to change)
$localstatedir = $prefix (by default, use --localstatedir to change)

$logfiledir = $localstatedir/logs (by default, use config.layout or axis2.xml 
to change)
$servicesdir = $libdir/services (by default, use config.layout or axis2.xml to 
change)
$modulesdir = $libdir/modules (by default, use config.layout or axis2.xml to 
change)

The axis2.xml file would be expected to reside in $sysconfdir.  There would be
runtime options (like httpd's -f option) that would allow the user to point to 
another
non-standard file, though.  This file would could then contain <logsDir>,
<servicesDir>, <modulesDir> to point to non-standard directories for those 
things,
if the user wanted a different layout.  Among other things, this kind of 
framework
allows for easy switching between different versions of the same services and
modules for testing purposes.

Sorry to sound negative about all this -- the axis2c package looks to be ideal 
for my
purposes (combining it with mod_dbd inside httpd); I've just had to struggle 
with the
installation process quite a bit to get things laid out the way I want them.  
Thanks for
listening!

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

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

Reply via email to