On Sat, 9 Dec 2000, Dr S N Henson wrote:
> Richard Levitte - VMS Whacker wrote:
> >
> >
> > I would actually be quite positive to autoconf if it wasn't for two
> > things in it that I view as flaws:
> >
> > 1) really heavy (to the level of magic) on sh features, making it
> > really difficult to deal with when something goes wrong, and
> > making portability a royal pain.
>
> That's been my experience too. If it works its great. If it doesn't work
> then I'd generally throw the package away and try something else.
>
> I wouldn't like to try to get it going under Windows or some of the
> weirder embedded platforms OpenSSL has been used with.
I wouldn't throw the baby out with the bath-water. Sure the "Configure"
script (being Perl) is used on Windows as well as unixen, but any other
possible view of the build process on Windows would show that basically we
have a non-standard build procedure dedicated to a non-standard system. I
wouldn't have thought that should be an obstacle to the viability of using
autoconf on "normal" systems to save us having to manually maintain
hideous config strings for each and every flavour of operating system,
compiler, and level of debugging (and/or the other optional config
features). My objection to having more than one configure process was if
*two* had to be used on the *same* system or if autoconf was unable to
solve everything for all but the weirdest of systems. I'd rather know that
all future unix-like support was likely to be very straightforward and
dependant basically on autoconf portability and then maintain weird build
procedures just for weird systems, than try to maintain a weird build
process for all systems - even the ones for whom autoconf would take away
most of the pain. If weird configuration is going to be needed on *all*
systems, even if autoconf removes part of the problem for some of them,
then that is obviously a lot less interesting.
In fact, it would probably be a lot cleaner IMHO if Win32 was acknowledged
as its own beast and thus had a dedicated build procedure that was simpler
than the attempt to generalise to it in the Configure script. Even with
"Configure" supporting Win32, the build still requires loads of extra
windows-specific steps to complete. More importantly, there's still lots
of windows-specific stuff required to keep OpenSSL "ported" to win32 -
here "port" means when one of us periodically tries a build and
updates/fixes everything that gets in the way until it completes. Even
then this might only apply to VC++ or Borland-C builds - CygWin should
work through autoconf shouldn't it? Perhaps Richard could comment on this
aspect too as I suspect much of it applies to the VMS world?
My limited experience with autoconf-based packages has usually been
encountering problems where it is dependant on other packages, libraries,
etc. OpenSSL being a kind of low-level library in its own right doesn't
have the problem nearly as badly as, for example, a GUI tool that relies
on widgets, C++ cruft, network libraries, and other GUI componentry it
wishes to call upon. I don't know autoconf's internals at all - but I'd
have thought any roadblocks would be discovery problems it can't deal with
(eg. /dev/urandom? Perl? BIGNUM precompiler setup? etc) rather than
dealing with strange depencies on componentry in the host system (apart
from Perl, cc, ranlib, as, etc which is pretty standard autoconf fodder, I
can only think of perhaps "bc" as an issue?).
Cheers,
Geoff
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
