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[] = {
> _installdirs_env_component,
> _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[] = {
> _installdirs_config_component,
> _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
