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
>> de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> 
> 
> -- 
>  Brian W. Barrett
>  Dept. 1423: Scalable System Software
>  Sandia National Laboratories
> 
> 
> 
> _______________________________________________
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
> 

-- 
  Brian W. Barrett
  Dept. 1423: Scalable System Software
  Sandia National Laboratories



Reply via email to