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/09/29 23:53:21 UTC
[jira] Created: (AXIS2C-312) remove fixed paths from code
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
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
[jira] Updated: (AXIS2C-312) remove fixed paths from code
Posted by "Chris Darroch (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2C-312?page=all ]
Chris Darroch updated AXIS2C-312:
---------------------------------
Attachment: axis2.xml.in
> 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
> 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Resolved: (AXIS2C-312) remove fixed paths from code
Posted by "Sanjaya Ratnaweera (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2C-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sanjaya Ratnaweera resolved AXIS2C-312.
---------------------------------------
Resolution: Fixed
> remove fixed paths from code
> ----------------------------
>
> Key: AXIS2C-312
> URL: https://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.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Commented: (AXIS2C-312) remove fixed paths from code
Posted by "Chris Darroch (JIRA)" <ji...@apache.org>.
[ 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
[jira] Updated: (AXIS2C-312) remove fixed paths from code
Posted by "Sanjaya Ratnaweera (JIRA)" <ji...@apache.org>.
[ 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Assigned: (AXIS2C-312) remove fixed paths from code
Posted by "Samisa Abeysinghe (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2C-312?page=all ]
Samisa Abeysinghe reassigned AXIS2C-312:
----------------------------------------
Assignee: Sanjaya Ratnaweera
> 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
>
> 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
[jira] Closed: (AXIS2C-312) remove fixed paths from code
Posted by "Sanjaya Ratnaweera (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2C-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sanjaya Ratnaweera closed AXIS2C-312.
-------------------------------------
> remove fixed paths from code
> ----------------------------
>
> Key: AXIS2C-312
> URL: https://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.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Updated: (AXIS2C-312) remove fixed paths from code
Posted by "Samisa Abeysinghe (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2C-312?page=all ]
Samisa Abeysinghe updated AXIS2C-312:
-------------------------------------
Fix Version/s: 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: core/deployment, build system (Unix/Linux)
> Affects Versions: 0.93
> Environment: Unix/Linux, maybe Windows and others.
> Reporter: Chris Darroch
> Assigned To: Sanjaya Ratnaweera
> Fix For: 0.96
>
> 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Updated: (AXIS2C-312) remove fixed paths from code
Posted by "Chris Darroch (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2C-312?page=all ]
Chris Darroch updated AXIS2C-312:
---------------------------------
Attachment: axis2c-312.patch
> 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
> 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org