%% Richard Levitte - VMS Whacker <[EMAIL PROTECTED]> writes:

  rl> Oh?  Let's see, for Windows, there's CygWin, Ming something,
  rl> Borland and Microsoft as compiler environments.

Yes, but these are build issues (makefile stuff) moreso than compile
issues.

Anyway, in GNU make (which is probably much simpler than openssl in some
respects) we haven't needed to make much differentiation in the code
based on the compiler.

We do ship separate makefiles for building with nmake vs. GNU make,
etc. and there are some changes you need to make by hand, I supposed,
based on your compiler.

Since relatively few people on Windows will compile the code themselves
anyway (in my experience) it seems reasonable to allow the bar to be
higher for Windows.

  rl> On VMS, you have DEC C and GNU C, and the contents of the C RTL is
  rl> very much depending on the operating system version.

Well, I'm not too familiar with VMS.  In GNU make, again, we haven't had
to make much differentiation between RTLs.

  rl> I'd love to have autoconf on VMS generating a DCL script.  I did that
  rl> kind of port for the stuff I could understand in autoconf 1, and it
  rl> was complete hell, trust me on that.  Autoconf is no better.

Yes, autoconf is not at all interested in or built towards being used to
generate anything except shell scripts, there's no doubt of that.

I'm not sure the new version is any better, but at least they've
addressed some major cleanup issues like quoting, etc.

  pausmith> The downside to autoconf/automake is that you have to either
  pausmith> (a) check in the generated files (configure, Makefile.in,
  pausmith> etc.), which is a drag since these things change all the
  pausmith> time, or (b) require everyone wanting to build from CVS to
  pausmith> install the toolset (you need perl, GNU make, autoconf,
  pausmith> automake, and GNU m4--and currently-released versions
  pausmith> require GCC as well; I think the coming-soon versions
  pausmith> don't.)

  rl> ... or (c) require that the developpers and the release manager have
  rl> those tools, and the release manager will simply generate the
  rl> appropriate files when building the distribution...

Well, I was talking solely abut developers/release managers in the above
paragraph: in an open source project like openssl (esp. one not already
tied to GNU toolkits) with a diverse development group, requiring all
the developers to install a complete set of autoconf tools can be a
cause of friction.

Certainly one of the fundamental goals of autoconf is that the generated
distribution tarballs don't require anything except standard UNIX tools
to do a build (as long as you're not changing code, or at least not
autoconf-related code).

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[EMAIL PROTECTED]>    HASMAT--HA Software Methods & Tools
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to