Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] Use of OPAL_PREFIX to relocate a lib
From: Sylvain Jeaugey (sylvain.jeaugey_at_[hidden])
Date: 2010-11-04 06:08:39


Hi Brian,

I finally found some time to test your patch and it solves my problem.

Thanks a lot !

Sylvain

On Wed, 27 Oct 2010, Barrett, Brian W wrote:

> I found the issue - somehow, we let the priorities used in installdirs get lost when we rewrote part of the configure system a couple months ago. I have a fix, but it involves changing the configure system, so I won't commit it until this evening.
>
> Thanks for pointing out the bug!
>
> Brian
>
> On Oct 26, 2010, at 8:36 AM, Barrett, Brian W wrote:
>
>> I'll take a look at fixing this the right way today.
>>
>> Since I wrote both the original autogen.sh that guaranteed static-components was ordered and PREFIX code, I had considered it to be a documented feature that there was strong otdering in the static-components list. So personally, I'd consider it a bug in autogen.pl, but I think we can work around it.
>>
>> Brian
>>
>> On Oct 26, 2010, at 6:01 AM, Sylvain Jeaugey wrote:
>>
>>> On Tue, 26 Oct 2010, Jeff Squyres wrote:
>>>
>>>> I don't think this is the right way to fix it. Sorry! :-(
>>> I don't think it is the right way to do it either :-)
>>>
>>>> I say this because it worked somewhat by luck before, and now it's
>>>> broken. If we put in another "it'll work because of a side effect of an
>>>> unintentional characteristic of the build system" hack, it'll just
>>>> likely break again someday if/when we change the build system.
>>> I completely agree.
>>>
>>>> I'd prefer a more robust solution that won't break as a side-effect of
>>>> the build system.
>>> I'd prefer too, but it would require adding much more logic in the
>>> framework, including component sort with priority. And since no-one except
>>> me seems to care about this functionality, I'm fine with this patch.
>>>
>>> More generally, I understand your demand for high quality patches that do
>>> things The Right Way. However, I feel it's sometimes exagerated,
>>> especially when talking about parts of the code that don't meet these high
>>> quality standards.
>>>
>>> In the end, my feeling is that we don't replace very bad (broken) code
>>> with bad (working) code because we want to wait for a perfect (never
>>> happening) code. I don't think it's beneficial to the project.
>>>
>>> Sylvain
>>> _______________________________________________
>>> devel mailing list
>>> devel_at_[hidden]
>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>
>>
>> --
>> Brian W. Barrett
>> Dept. 1423: Scalable System Software
>> Sandia National Laboratories
>>
>>
>>
>> _______________________________________________
>> devel mailing list
>> devel_at_[hidden]
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>
>
> --
> Brian W. Barrett
> Dept. 1423: Scalable System Software
> Sandia National Laboratories
>
>
>
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>