Hi,
On Fri, 23 Feb 2001, Ulf Moeller wrote:
> On Thu, Feb 22, 2001, Lenny Foner wrote:
>
> > It just boggles my mind that OpenSSL is somehow so special that it
> > can't use the same system used by hundreds of other packages.
>
> The OpenSSL readme explains quite clearly that patches are welcome and
> how they are best submitted. What are you all whining about, really?
:-)
Actually, I would like to add something to that. Rather than leaping in at the
finish line, I think a more worthwhile place to conduct conversation would be
back at some issues that are related, more fundamental, and make the final goal
a lot easier if they're considered first.
Namely, the source code itself - rather than the building, linking, and tweaking
of it.
Richard has been embarking on a bit of a preprocessor clean-up, and some good
feedback on this sort of thing could direct developments in a direction that
would help any future autoconf-related activities, and a lack of considered
feedback might just as easily allow things to progress towards solving one set
of requirements but in the process make autoconf-ing harder as a result.
One of the things about an autoconf (or autoconf-like) system, is that ideally
the source code should be entirely abstracted and should refer, where necessary,
to its own defined scheme of preprocessor symbols when preprocessor magic is
required in source. In short, *regular* source code should probably not do
things like;
#if defined(__FreeBSD__)
# define USE_TOD
#elif !defined(OPENSSL_SYS_MSDOS) && (!defined(OPENSSL_SYS_VMS) || defined(__DECC))
# define TIMES
#endif
#if !defined(_UNICOS) && !defined(__OpenBSD__) && !defined(sgi) &&
!defined(__FreeBSD__) && .....
# define TIMEB
#endif
(that 3rd to last line is clipped - it's over 200 characters long)
this is part of speed.c. Look at that same file (and many others like it) for an
indication of where the normal source code, whose job it is to perform logic, is
instead mostly jumping through thousands of portability and configuration hoops
manually - rather than letting the portability/configuration magic get handled
once and for all elsewhere so the code can be better insulated.
A little time spent on this sort of thing will make questions like "to autoconf
or not to autoconf" far less one of viability and a lot more about style and
preference. The regular source code deals *far* too much with bits'n'pieces of
preprocessor garbage right now that is way down at the per-platform,
per-compiler level - so autoconf-ing the library (or anything else, such as
building project files for other compilers, systems, and GUI enviroments) is
currently much more trouble than deducing system characteristics and build
tools, etc. It also requires an intimate understanding of the spaghetti of
defines and symbol twisted riddled throughout the code.
Just a few thoughts for what they're worth, which granted may not be that much.
Cheers,
Geoff
PS: I too would love to see autoconf used - not because I'm a fan of autoconf,
but because doing portability is a PITA and I'd love to see it abstracted off
into an SEP, and autoconf is the most convenient victim to hand the problem to.
But overriding that, I'd love to see the source code do easy-to-follow
easy-to-audit transparent programmatic logic - and *not* have it cluttered by
streams of preprocessor garbage everywhere. (Actually, a few less "#if 0"s, "/*
huh? */"s, and "XXX"/"FIXME"/"TODO"s would also be nice.) Volunteers welcome.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
