Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
From: "William A. Rowe, Jr." <wrowe@lnd.com>
To: <new-httpd@apache.org>
Subject: RE: Win32 Link libs
Date: Thu, 30 Mar 2000 12:38:36 -0600
Message-ID: <000a01bf9a77$2bbc9c30$345985d0@corecomm.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Importance: Normal

FW sidebar on Win32 Link Libs
...back to the group for a moment, with Greg's permission...

Greg's and my ongoing discussion of how this could all work led to some
interesting questions, answers and issues.  Forgive the quoting.  If you
aren't Win32 please excuse the post, but those who are might like to throw
in thoughts or at least see what I am trying to accomplish with [patch] APR
2.0 linkage mechanisms.

> > > Once the build changes are done, and assuming that the build from the
DSW
> > > is approved, then all Makefile.win will do is provide shortcuts, i.e.
> > > nmake /f Makfile.win installr instead of msdev Apache.dsw /make
> > >"InstallApp - Win32 Debug" /recurse=1
> >
> >Disagree, we want something more explicit.  Although _you_ will be able
to
> >simply build ApacheApp, command line folks CANNOT STAND wasted cpu cycles
> >to iterate apr.dsp for EVERY exe/dll.  Won't do it - makefile.win will
use
> >RECURSE=0 to avoid this.

> I don't follow.  If you have a single project that builds everything, then
> apr.dsp is only built once, because all the dependency stuff is done up
front.

If you explicitly nmake through a list of Module files, each dependent on
another, each will waste the time confirming the apr/apachecore targets are
up to date.  Unacceptable.  Oh - blasting the buildmark on each one, so
apachecore will be rebuilt each time.

I'm trying to attain something IDE users will find 100% functional, and that
command line folks continue to find productive and clear.

> Why not use dependencies for this?  That way if the path where the library
> is built changes, or the name of the library changes, then you don't have
> to change every DSP that uses that library.

Because, in an open source project, paths and library simply -don't- change
names without explicit intent by the committer.  If a patcher can break
something without knowing it, we've created a problem, not a solution.

> > I did goof.  The target of library builds for dll generation should be
> > src/build/debug/apr/dll/link - since the dll will also have a lib in
> > src/build/debug/apr/dll - but no harm yet.  Fix in the next patch.

> I've read this sentence over several times, but I can't quite follow
> it.  Are you saying that the lib file should be put in a different
> directory than the DLL?

No, remember a .dll has it's own small .lib file that binds the code to the
.dll runtime.  The source .lib object library that the .dll will be
generated from can't (well, at least shouldn't) sit in the same folder, so
I'll park it one folder away in link/, next to obj/.

> Just curious, why are you putting build in src instead of at the same
level
> as src?

Mostly because, if you blow away src you have nothing but the runtime.  Plus
one less set of ../'s to proliferate.  Any further thoughts one way or the
other?

> Okay, let me see if I get all these configurations right:

> APR.dsp: Win32 Debug and Release create a lib version of APR that use the
> DLL version of the C runtime library, while Win32 Standalone Debug and
> Release create a lib version of APR that use the static version of the C
> runtime library.

More importantly, Debug and Release will carry _declspec(export) tags.
APR.lib is built to target an exe or dll that will expose the library.
Note the APR_EXPORT_DLL define to the compiler, that's a future trigger!

Standalone will NOT carry _declspec(export) tags!  It cannot be used to
generate a dynamically linked library.  It sits there, as a lib, for the
apps that need just a few functions and don't want the baggage.

> APRLIB.dsp: creates a DLL version of APR that uses the DLL version of the
C
> runtime library.

And - MOST IMPORTANT, it exports all the objects from the Win32 APR build!
Note that anyone linking to the .DLL _MUST_ define APR_IMPORT_DLL for the
compiler to assure the right linkage.

Linking to plain old apr.lib (in build/win32/debug/apr/lib) requires the
user to _NOT_ define either APR_IMPORT_DLL _nor_ APR_EXPORT_DLL.  Not a
single _declspec() tag will remain anywhere!

Now... if you wanted to bind apr and apachecore together and export from
a single .dll, your compile settings declare APR_EXPORT_DLL and
CORE_EXPORT_DLL
and you link to the build/win32/debug/apr/dll/link/apr.lib target as well as
build/win32/debug/apache/dll/link/apache.lib.  Or something like that.
Right now only _ONE_ module will do so with .apr, that's aprlib.dll itself.

> If I have those correct, then changing the names to APRDLL and APRLib
would
> probably be prudent.  As it is now, APRLIB sounds like it should create
the
> lib version, and that leaves APR for the DLL version.

I agree, but the dll is aprlib.dll.  Now since there was no 1.3 apr file in
production, and 2.0 will break any compatbility to the core dll, we should
either shorten ApacheCore.dll, or expand apr to ApacheLib.dll (or something
like that).  Name ideas?

> In the APR workspace, why is APR.dsp dependant on APRLIB.dsp?

obvious by now, I'm sure, but apr has a library of _declspec(export) objs
that must be bound into a dll by aprlib.

What is ApacheCore going to have for configurations and how will they match
up with APR?

CORE_EXPORT_DLL, CORE_IMPORT_DLL define the direction.  I don't expect any
change to the ApacheCore beyond correctly identifing what libraries it's
bound to, if they are import or export, etc...  ApacheCore will build with
Win32 Debug and Win32 Release.  We might want to try ApacheCore Standalone,
since dropping all import/export fixups would speed it up for benchmarks,
but you will NOT be able to link in Modules in that case.  (Or, perhaps
you still could, let me think on this.  No matter what, they could never
peek inside the ApacheCore to play with anything.  This could be a good
thing :-)


> Did you come up with any libs other than for those two
> projects?  I built a
> full apache with nothing other than those five libraries, and libs
> specified through dependencies.

Guess I've wasted just too many hours of my life to trust Microsoft's
assumptions when I can avoid them.  Ever pulled your teeth out over
the combination of USE_MIN_CRT and just about any simple str or mem
functions?  (Works to libcmt, not to msvcmt.dll) Frankly, it's simpler
stating what you want and having it.

All I've added are the appropriate MSVCMT(d)/LIBCMT(d) libraries and
oldnames, based on the build.

REMEMBER - the project will NOT be built by many of us using the
dependencies.  This is a convience thing for today while working in IDE.