Hi all,
This problem may be a detail, but it bugs me a lot, so I'd like to have it
fixed. Here is a patch that changes the path setting algorithm to "last
component wins" instead of "first component wins".
This is as wrong as was the original code, except that it is
consistent with the way autogen.pl generates static-components.h.
If nobody objects, I'll commit it tomorrow.
Sylvain
diff -r c9746f7a683a opal/mca/installdirs/base/installdirs_base_components.c
--- a/opal/mca/installdirs/base/installdirs_base_components.c Tue Oct 26
10:56:53 2010 +0200
+++ b/opal/mca/installdirs/base/installdirs_base_components.c Tue Oct 26
12:48:41 2010 +0200
@@ -25,7 +25,7 @@
#define CONDITIONAL_COPY(target, origin, field) \
do { \
- if (origin.field != NULL && target.field == NULL) { \
+ if (origin.field != NULL) { \
target.field = origin.field; \
} \
} while (0)
On Thu, 7 Oct 2010, Ralph Castain wrote:
What you are seeing is just the difference in how the build system (old vs new
vs RPM script) travels across the directory tree. The new build system and RPM
do it in alphabetical order, so config comes before env. The old autogen.sh did
it in reverse alpha order, so env came before config. I don't think anyone
thought it made a difference, though you correctly point to one place where it
does.
Modifying the build system to have one place do it differently would be a
mistake, IMO. The better solution would be to use priorities to order the
processing, though that means two passes through the components (one to get the
priorities, and then another to execute) and additional API functions in the
various modules.
On Oct 7, 2010, at 6:25 AM, Sylvain Jeaugey wrote:
Hi list,
Remember this old bug ? I think I finally found out what was going wrong.
The opal "installdirs" framework has two static components : config and env.
These components are automatically detected by the MCA system and they are listed in
opal/mca/installdirs/base/static-components.h.
The problem is that no priority is given, while the order matters : the first
opened component sets the value.
When I build the v1.5 branch, I get 1.env 2.config :
const mca_base_component_t *mca_installdirs_base_static_components[] = {
&mca_installdirs_env_component,
&mca_installdirs_config_component,
NULL
};
When I build an RPM *or* the new default branch, I get 1.config 2.env :
const mca_base_component_t *mca_installdirs_base_static_components[] = {
&mca_installdirs_config_component,
&mca_installdirs_env_component,
NULL
};
I don't know why the generated file is not consistent. It may be related to the
order in which directories are created.
Anyway, the first case seems to be what was intended in the first place. Since
config sets all the values, having it in first position makes env useless.
Besides, in the first configuration, env only needs to sets OPAL_PREFIX and
since config sets all other pathes relatively to ${prefix}, it works.
So, how could we solve this ?
1. Make autogen/configure/whatever generate a consistent static-components.h
with env THEN config ;
2. Add priorities to these components so that env is opened first regardless of
its position in the static components array ;
3. Any other idea ?
Sylvain
On Fri, 19 Jun 2009, Sylvain Jeaugey wrote:
On Thu, 18 Jun 2009, Jeff Squyres wrote:
On Jun 18, 2009, at 11:25 AM, Sylvain Jeaugey wrote:
My problem seems related to library generation through RPM, not with
1.3.2, nor the patch.
I'm not sure I understand -- is there something we need to fix in our SRPM?
I need to dig a bit, but here is the thing : I generated an RPM from the
official openmpi-1.3.2-1.src.rpm (with some defines like install-in-opt, ...)
and the OPAL_PREFIX trick doesn't seem to work with it.
But don't take too much time on this, I'll find out why and maybe this is just
me building it the wrong way.
Sylvain
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
