[Openmcl-devel] CCL startup script (ccl & ccl64) is not Bourne Shell compatible

[Ron Garret]

On Oct 17, 2009, at 2:51 PM, Aleksej Saushev wrote:

> Tim Bradshaw <tfb at tfeb.org> writes:
>
>> On 17 Oct 2009, at 14:57, Aleksej Saushev wrote:
>>
>>> Replace it at build time. PATH changes across system, and this  
>>> breaks
>>> spontaneously when someone uses another interpreter version or PERL
>>> suddenly becomes out of PATH.
>>
>> This is off-topic now so I'll shut up after this, but that's what I
>> used to do in the old days (I think you mean "install time" not  
>> "build
>> time"), and it sucks.  It's particularly not amusing if you need to
>> run something across a thousand-odd variously-configured systems
>> running maybe one of 5 versions of one of 4 OSs, which is what I do
>> for my living.
>> * You need an installation step, which is bad in itself, and then you
>> have several further problems.
>> * What does the installer do?  Chances are it does things like "type
>> x" to find the path to x.  In other words it just does at install  
>> time
>> what the env trick does at run time, and it's pretty hard to see that
>> as being better.
>> * You might think you can ask the user, but (a) they don't know, (b)
>> they don't like being asked, (c) they give the wrong answer.
>> * The main drag of your code is now *not what you distributed*, so
>> every time you upgrade it you need to have yet more stuff which  
>> checks
>> that all the changes are the ones you put in at installation time,
>> because if you clobber changes the user made they will come after you
>> with a pitchfork at some point.
>> * This installer you've now written, how does it find the right
>> versions of things?  Maybe you need an installer for it.
>
> No, when I write "build time" I mean exactly build time. At build time
> you know target system configuration already, thus you know standard
> place of your interpreter, either system one or the one you deploy  
> there.

You know the system configuration *at build time*.  There's no  
guarantee that the configuration won't change after that.  All else  
being equal, it is better to be able to make changes without having to  
rebuild everything in order to make it work again.

> You don't need and it is really better to avoid changing files during
> installation.

That's true.  But sometimes moving things around after installation is  
desirable or even unavoidable.

> The problem with interpreter is the same as the one with dynamic  
> libraries.
> When you use "/usr/bin/env" interpreter, you make subtle  
> assumpltions on
> generally unpredictable variables, as PATH, like you some of  
> developers
> like to make assumptions on correct LD_LIBRARY_PATH because they don't
> know how to handle libraries outside default system directories in a
> correct way.

Maybe I need to be enlightened.  What is this "correct way"?

rg