Alexei Bakharevski wrote:
> Some suggestions, although, not specific to NT:
> 1. have the following build targets: static library (debug & release),
> dynamic library (debug & release);
There's a few other issues at hand, I think. Would it be enough to just
release a "static library" build target? I know I'm personally mainly
interested in static library builds that are linked /MT & /MTd, but
somebody might conceivably prefer static libs linked /MD & /MDd, which
is after all the current OpenSSL default behaviour.
Same thing goes for dynamic libraries, only the other way around. I've
had problems I've yet to address trying to link these /MT & /MTd, so
I've had to settle for /MD & /MDd.
Then there's the issue of NT specific builds versus the "generic" win32
builds, which I haven't managed to look in to all that much either.
> 2. to have a dedicated directory for all build results, may be with separate
> sub-directories for the intermediate results for every possible build
> target, eg build\lib\debug for static debug library. The build results might
> go (ideally) into a single directory, or have four for every target (eg
> build\lib\). I think this will help to keep the source directory from being
> polluted with the build results;
Any and all suggestions here would be most welcome.
> 3. name built libraries accordingly, eg static library in debug mode:
> libeay32ds.lib;
This shouldn't be too hard to accomplish. Would we really need separate
build directories if we used a library naming convention?
My vote would be for something like (I hope I'm making at least some
sense here) "lib(eay|ssl)(32|nt)(MD|MT)[d].lib".
> I have got four ms_xx.mak files that do this, but I was not brave enough to
> dig deeper than this. The changes are primitive, but if these are of any
> help to you I can mail them.
I guess we've ended up with something similar, but please do!
Ng Pheng Siong wrote:
> Yes, please: make it work with Borland's BC++ 5.5 free compiler tools.
I'm afraid I don't have access to a Borland compiler, so I don't know if
I can be os much help here, unfortunately. :-(
> Release/debug DLL configs will be nice. Maybe standardise the
> calling convention (cdecl, fastcall, etc., whatever these are), too.
Standardisation might be nice, but aren't calling conventions mainly an
anachronism from the days before flat memory models?
//oscar
S/MIME Cryptographic Signature
