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

[Aleksej Saushev]

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 don't need and it is really better to avoid changing files during
installation.

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. While in simple cases this may work, it fails in more
complex environments. A user may be dissatisfied with default system
interpreter and deploy his own, slightly different one. One may choose
(d)ash or zsh, which slightly deviate from standard and your code may
break, or one may build newer and slightly incompatible PERL to avoid
running into annoying bug or to utilize some feature lacking in default
one.

> What I do now is:
> * write code which works out where things are itself,
> * and checks versions carefully dynamically and complains;
> * for things which are really fussy, or where I might want to select  
> versions, write "wrappers" which control the environment for things  
> based on configuration files or the environment.  The wrappers  
> themselves need to bootstrap themselves based on only minimal  
> assumptions.
>
> I actually have a whole wrapper-creation system I wrote, though I  
> don't use it very much nowadays as I cop out and write simple once-off  
> wrappers (like the one I use for CCL).

Wrappers... This may be viable approach, but I don't believe in them,
I've rarely, if ever, seen really good wrapper-based solution. You may
be quite satisfied with yours, that's your own business after all.

There exists (possible) compromise solution, when you install package
"configuration" (path to interpreters) and provide some tool to
reconfigure it in-place. I'm not sure how viable it is.


-- 
HE CE3OH...