[ http://issues.apache.org/jira/browse/AXIS2C-312?page=all ]
Sanjaya Ratnaweera updated AXIS2C-312: -------------------------------------- Fix Version/s: 1.0.0 (was: 0.96) > remove fixed paths from code > ---------------------------- > > Key: AXIS2C-312 > URL: http://issues.apache.org/jira/browse/AXIS2C-312 > 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: axis2.xml.in, 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: > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]