For what it's worth, I had an undergraduate who was working for me put
all of SSLeay 0.8.1 under GNU Autoconf/Automake. His estimate of the
time it took him is about 20 hours or so; he doesn't really remember
very well at this point, but I know that estimate has be within a
factor of two.
I've been using the result for about a year now as part of a larger
piece of software that I'll be releasing quite soon. That work, plus
a couple smallish patches to 0.8.1, have meant that I have an entire
package which can be compiled under HPUX 9.05, HPUX 10.20, Linux RH
5.1, Irix 6.2, NetBSD 1.3.2, Solaris 5.6, and Alpha OSF1 V4.0, all
merely by typing "./configure" and then "make". It probably works
transparently on other architectures, too---the set above is merely
the selection I've got available to me here. Note that this spans
various big-vs-little endian architectures -and- 64-bit ones.
I would be ecstatic if the OpenSSL people could make use of this work.
One of the reasons why I haven't bothered to upgrade to 0.9.0 or, for
that matter, OpenSSL---besides not wishing to hit a moving target
shortly before a release---is because I would have to redo a lot of
that work, even when one considers that CVS can help a lot with the
merge. Making this work a part of OpenSSL, on the other hand, would
save me from having to remerge for every single OpenSSL release.
If this was any ordinary piece of software, I'd simply offer a diff
between 0.8.1 as released, and our version, and people would then
instantly have an Autoconf/Automake version of 0.8.1, and could also
use that work to help make 0.9.0 or OpenSSL also use that. However,
it's not clear to me what the legalities are of making even the diff
available, considering that the work was done in the US. It's also
not clear whether the OpenSSL project would accept it, given recent
comments about donations of US-written code. Opinions on these
subjects are solicited. [Those in the US will be able to examine the
resulting code, and make their own diff, when I release the software.
Those outside the US, of course, cannot download it.]
Given that it only took my undergraduate ~20 hours to do this,
however, I strongly suspect that it would be faster to redo it
overseas that it would be to spend much more time discussing it...
And by the way, which do you think is more likely to be ported to
Windows or NT and will have the aid of lots of other developers to
help keep it up-to-date? A special-case bunch of #ifdef's that only
the OpenSSL people use, or GNU Autoconf/Automake? I don't happen to
know anything about the FSF's plans in this regard, or what the
development community for Autoconf/Automake is up to at the moment,
but I would be very surprised if Windows/NT support wasn't on their
list. After all, making this work in that environment could
potentially help a -lot- of other projects, not just OpenSSL---it
could help everything that uses these GNU tools. Or perhaps the
OpenSSL effort should take it upon themselves to help with making
Autoconf/Automake work in W/NT? You would be helping yourselves -and-
the rest of the open-source community.
P.S. I should note that there may already -be- such support.
Here are the first two entries in the NEWS file for Autoconf 2.13:
Major changes in release 2.13:
* Support for building on Win32 systems where the only available C or
C++ compiler is the Microsoft Visual C++ command line compiler
(`cl'). Additional support for building on Win32 systems which are
using the Cygwin or Mingw32 environments.
* Support for alternative object file and executable file extensions.
On Win32, for example, these are .obj and .exe. These are discovered
using AC_OBJEXT and AC_EXEEXT, which substitute @OBJEXT@ and
@EXEEXT@ in the output, respectively.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
