You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by "Chris Darroch (JIRA)" <ji...@apache.org> on 2006/10/26 01:31:17 UTC

[jira] Commented: (AXIS2C-312) remove fixed paths from code

    [ http://issues.apache.org/jira/browse/AXIS2C-312?page=comments#action_12444754 ] 
            
Chris Darroch commented on AXIS2C-312:
--------------------------------------

I'm attaching one possible set of changes to fix the $AXIS2C_HOME/lib
requirement.  A configuration file <parameter> named "libraryDir"
contains the path to the libraries.  The configure.ac build script is
changed slightly so that samples/server/axis2.xml.in is parsed by
configure and the @libdir@ value interpolated into place, so that the
axis2.xml file is then ready for installation.

This is just one possible patch, of course; one could also interpolate
@libdir@ right into the modules/core/deployment C files; or do something
fancier so that the library loading code in util/src/class_loader.c didn't
require an input path but instead looked in the locations specified
by the ld system (e.g., LD_LIBRARY_PATH).  That might be best of all,
really.

> remove fixed paths from code
> ----------------------------
>
>                 Key: AXIS2C-312
>                 URL: http://issues.apache.org/jira/browse/AXIS2C-312
>             Project: Axis2-C
>          Issue Type: Bug
>          Components: core/deployment, build system (Unix/Linux)
>    Affects Versions: 0.93
>         Environment: Unix/Linux, maybe Windows and others.
>            Reporter: Chris Darroch
>         Assigned To: Sanjaya Ratnaweera
>
> 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:
> http://marc.theaimsgroup.com/?l=axis-c-user&m=115956538314942&w=2
> 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, services,
> 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: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org