httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralf S. Engelschall" <>
Subject Re: Suggestion: shtool
Date Tue, 27 Apr 1999 06:36:26 GMT

In article <> you wrote:
> Ralf S. Engelschall wrote:
>> In article <> you wrote:
>> > [...]
>> > At least for Apache 1.4/2.0 it sounds reasonable to use shtool, of course :)
>> Although I'm rather sure Jim will not change his general opinion on shtool ;),
>> here is the final note at least for the group that shtool 1.1.0 was released
>> today. It's a complete overhauled version for which I've spent 25 extra hours
>> over the weekend. It now even includes a complete manual page covering all
>> tools and options, it contains a small GNU autoconf environment for building
>> and installing, I've cleaned up and merged the ingredients, added a few more
>> goodies from my script archive, etc. So, at least those interested in such
>> tools (especially for other Open Source packages) should look at it and take
>> again my suggestion that for Apache 1.4/2.0 one should consider replacing most
>> of our current scripts with shtool calls.
> I still don't think that a single script is an advantage, modules exist
> for a reason. Also, I totally agree with the comment about libtool - if
> it works its great, but if it doesn't it seems to be totally impossible
> to fix (and, in my experience, it doesn't). I haven't looked at shtool,
> but the fact it is a single script does not bode well.

It's not really fair to not look at the code but to give a general mark on it
just because it's a single script. That sounds as would all single scripts be
bad which is like saying any single executable not using DSO for its parts is
bad IMHO. Hmmm... I would appreciate more closer looks at the package before
it is given a mark.

> I'm also not keen on relying on externally maintained packages, any more
> than is necessary, even if it does mean a little more work for us. That
> is, unless they are _extremely_ widely used (i.e. already installed
> nearly everywhere).

That's IMHO confusing when you talk about shell scripts: Because you always
depend on lots of _external_ and even not always portable programs when you
program shell scripts. So, when you don't want to rely on external things in
general, you've to package Perl with Apache, compile Perl yourself at the
bootstrapping phase and then program anything with this Perl interpreter and
without any Perl modules, etc. Then I can accept this argument. 

But when you really want to benefit from others work you _have_ to rely on
external things which you import and just treat as a block boxes... I do this
since years with GNU autoconf, libtool and friends. I'm also a big fan of
stand-alone self-containing packages, of course. That's why one imports
libtool, shtool, etc.  as a _copy_ to the own source tree. But nevertheless
one treats these copies as block boxes and just _use_ them.

And BTW, I think that someone who can't fix the all-in-one shtool usually is
also not able to fix the scripts itself it's assembled from. Especially
because shtools parts do not rely on each other and are cleary seperated in
the shtool script. Look at the shtool source, Ben. The resulting shtool is as
easy/complicated to understand as the parts itself. It doesn't contain such a
complicated internal structure like libtool.

                                       Ralf S. Engelschall

View raw message