axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sanjaya Ratnaweera (JIRA)" <>
Subject [jira] Updated: (AXIS2C-312) remove fixed paths from code
Date Tue, 19 Dec 2006 05:22:23 GMT
     [ ]

Sanjaya Ratnaweera updated AXIS2C-312:

    Fix Version/s: 1.0.0
                       (was: 0.96)

> remove fixed paths from code
> ----------------------------
>                 Key: AXIS2C-312
>                 URL:
>             Project: Axis2-C
>          Issue Type: Bug
>          Components: build system (Unix/Linux), core/deployment
>    Affects Versions: 0.93
>         Environment: Unix/Linux, maybe Windows and others.
>            Reporter: Chris Darroch
>         Assigned To: Sanjaya Ratnaweera
>             Fix For: 1.0.0
>         Attachments:, axis2c-312.patch
> As per this thread on the user mailing list, I've found that one can't actually use
> the --libdir, --includedir, etc. options to the autoconf configure program:
> Here's the crux of the problem: hard-coded paths.  While I appreciate that these are
> easier to write than a fully-configurable package, the documentation in the INSTALL file
> and the use of autoconf implies that one can customize the installation.  For
> example, the INSTALL file says:
>    Please run './configure --help' in samples folder for more information on
>    configure options.
> As it happens, when I discovered that the package was going to install
> about 15 libraries and 375 header files, I purposefully used the
> standard autoconf configure options to put these in subdirectories:
>         ./configure --prefix=$(INSTALL_PATH) --enable-tests \
>                 --bindir=$(INSTALL_PATH)/bin/axis2 \
>                 --includedir=$(INSTALL_PATH)/include/axis2 \
>                 --libdir=$(INSTALL_PATH)/lib/axis2 \
> With the appropriate CFLAGS and LDFLAGS and a little Makefile tuning, this all
> compiles OK and installs OK.  It's also a fairly standard Apache way of doing
> things -- the APR and httpd projects use the apr-<majorversion> and apache2
> subdirectories, for example, to keep their headers and libraries from polluting
> the user's --includedir location.
> Alas, in axis2_conf_builder_process_transport_senders(), we have this code:
> repos_name = AXIS2_DEP_ENGINE_GET_REPOS_PATH(conf_builder->
>                                              desc_builder->engine, env);
> temp_path = AXIS2_STRACAT(repos_name, AXIS2_PATH_SEP_STR, env);
> temp_path2 = AXIS2_STRACAT(temp_path, AXIS2_LIB_FOLDER, env);
> temp_path3 = AXIS2_STRACAT(temp_path2, AXIS2_PATH_SEP_STR, env);
> path_qualified_dll_name = AXIS2_STRACAT(temp_path3, dll_name, env);
> This means that, in effect, the --libdir option to configure is useless, because the
> code is going to ignore whatever the specified installation locations were and go
> looking in the $AXIS2C_HOME/lib location regardless.
> What I'll do for now, I guess, is creating a symlink from $AXIS2C_HOME/lib to my
> $INSTALL_PATH/lib/axis2 location, and this does indeed work OK.  However, it's
> a workaround caused by what I'd suggest is a pair of bugs.
> First, I'd suggest that there should be no hard-coded paths like the ones I see
> in modules/core/deployment/conf_builder.c, desc_builder.c, and arch_reader.c.
> These are just the ones using AXIS2_DEP_ENGINE_GET_REPOS_PATH();
> there may well be other similar functions I'm not aware of, though.  Such paths
> should be determined from configuration parameters.  For example, programs
> could look for axis2.xml $AXIS2C_HOME, then in a directory specified at compile
> time using an option to ./configure, and finally in the current directory.  The axis2.xml
> file would then, in turn, include the paths to the directories used for logs, libraries,
> modules, etc.  It would also be nice if at compile time and run time one could specify
> a different name for the axis2.xml file -- for example, Apache httpd accepts an -f
> run-time option to use a non-standard configuration file.
> Second, whole autoconf system for axis2c needs some work.  I'll put details into a
> second enhancement request, but as far as this particular bug is concerned, I'd suggest
> that since --libdir does correctly install the libraries into a given location, it's
wrong to then
> go looking in $AXIS2C_HOME/lib despite what the user requested.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message