axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sanjaya Ratnaweera (JIRA)" <>
Subject [jira] Closed: (AXIS2C-313) improve autoconf support
Date Tue, 03 Apr 2007 10:03:32 GMT


Sanjaya Ratnaweera closed AXIS2C-313.

> improve autoconf support
> ------------------------
>                 Key: AXIS2C-313
>                 URL:
>             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
>         Assigned To: Sanjaya Ratnaweera
>             Fix For: 1.0.0
> 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
> 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
> 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
> 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
> ways.  Many of the test suites depend on libcutest.a -- but this isn't something the
> package provides!  Instead, you have to dig out a posting to the mailing list:
> (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
> in a "resources" directory.  The woden tests require a Calculator.wsdl file that I found
>, but it
> required that the xmlns: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,
> 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
> 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
> listening!

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:
For additional commands, e-mail:

View raw message