httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@lnd.com>
Subject RE: Draft proposal: Win32 Compilation Environment Step 1
Date Mon, 17 Apr 2000 15:10:06 GMT
> To: new-httpd@apache.org
> Subject: Re: Draft proposal: Win32 Compilation Environment Step 1
> 
> +1 on blasting the makefiles, provided it is very easy to 
> regen them when using VC++ 5.

It is, once I've posted the Apache.dsw.

> I am ambivilant about whether APR is a dll or is statically 
> linked into Apache.  

I'm not... I believe you will hear from rbb if we tried :-)
This really is a seperate support package, IMHO.  Why
bleed through the symbols for ApacheCore?

> We definitely should -not- attempt to support multiple 
> applications each accessing the same dll (with perhaps 
> one exception, the support routines that ship with 
> Apache could/should use the common APR dll).

OK ... if we are committed to this, then we have an issue,
read my notes below.

> The one requirement we do have is that the exported symbol 
> ordinals do not change when a new function or variable is 
> added to then exported from APR.  We don't
> want to require Apache module authors to recompile their 
> modules because someone adds new
> functions to APR, but does not change the interface of any of 
> the existing functions the
> module depends on.

Back to binary compatibility <LOL>.  I agree with ordinals
and suggest we resort right before the 2.0b release.
Agreed on compatibility within version 2.0.any.

> > Step 2 will build an apr.lib from the apr.dsp/apr.mak project files
> > which mirrors the aprlib.  But it will become a STATIC library,
> > for those applications that call for it. Namely, support 
> applications.
> >
> > Here's where I am absolutely jammed.  Now I know why I created
> > that apr.dsp 4 project library...
> >
> > We don't want aprlib.dll in winnt/system32 since it's a moving
> > target.
> 
> Agreed.
> 
> > So what do we want?
> > ??? A second copy of aprlib.dll in support?
> >     That's rather sad.

I'm guessing you agreed.  However, if we link to aprlib.dll, and
don't put it in support, we are sort of screwed.

> > ??? Have both apr and aprlib declare all the sources?  This
> >     looks like a headache.

Project apr lists all the sources and builds a lib, aprlib lists
all the sources and builds a dll.  This sucks.

> > ??? Have apr build a lib with the export symbols defined,
> >     have aprlib turn that lib into a dll, and continue
> >     to use the apr.lib with symbols to link to static exe's?
> >     Just some wasted space, if I am correct, or perhaps I
> >     can throw away the export table from the linker.
> >
> 
> I think this would be perfectly acceptable.

I'm ready to go with this solution myself.  If it needs to be
reworked, then we will rework it after the fixups of APR_EXPORT_X.
Let's try this for today.
 
> > ??? Go to the idea of "Win32 Static" projects, as I've
> >     proposed once before?
> 
> Never quite had a handle on this.
 
Dynamic link project configs  This Proj - Win32 Release (/Debug)
Static  link project configs  This Proj - Win32 Static Release (/Debug)

Apr configs
apr - Win32 Standalone Release (/Debug) -> library without dllexport'ed
apr - Win32 Release (/Debug) -> library with all __declspec'ed dllexport's

Aprlib config
aprlib - Win32 Release (/Debug) <- library with all __declspec's -> dll


The build path ends up looking like

(Dynamic)
apr - Win32 Release -> lib (only a source to aprlib)
  aprlib - Win32 Release -> dll + dll's export lib
    ApacheCore - Win32 Release -> dll + dll's export lib
      Apache - Win32 Release <- aprlib + ApacheCore dll's export libs

(Static)
apr - Win32 Static Release -> static lib (no exports whatsoever)
  htdigest - Win32 Static Release <- apr static library


Dynamics don't depend on apr (directly), statics don't depend on aprlib,
and ONLY the apr project contains all four configs (R/D * Dyn/Static)


This works REALLY WELL, until we get into what happens when:


(Examples above)
Apache - Win32 Release
htdigest - Win32 Static Release
  InstallBin - Win32 Release (wraps makefile.win)

Ok, InstallBin knows to build the - Win32 Release of all the projects
it depends on - great!  But what will it choose when the name is
ambigous:

htdigest - Win32 Static Release  !=  - Win32 Release
htdigest - Win32 Static Debug    !=  - Win32 Release

I'm not sure we can predict how this will behave in VC5, and we can't
explicitly tell VC5 by config (we could in VC6).

That's why I've killed the idea.


I say, today:

apr (lib with all export symbols declared) -> aprlib (dll with exports lib)

We can link an app to apr.lib or aprlib.lib (to bind to the aprlib.dll).

Link all support, for debugging now, to apr.lib (not bound to aprlib.dll).

Also, before beta release, 
  rename support to sbin (?) (make modules a folder within sbin?)
  add it to the system path in the install (admins can htpasswd anywhere)
  put Apache.exe in sbin
  put Aprlib.dll in sbin
  put ApacheCore.dll in modules (it is, isn't it :-) ?)
  make Apache.exe late bind to ApacheCore and add
      arg[0]path\..\modules to the running path.

  *** Create the process of ApacheCore.dll, rather than Apache.exe!
      Task manager would show (1) Apache, (1+) ApacheCore in the list.
      [I'm trying to figure out how to accomplish this cleanly.]

That's my thought.  New Apache.dsw and apr.dsp, plus patches to aprlib.dsp,
makefile.win, and all support/ .dsp/.c to bind to apr to follow tommorow.

Bill

Mime
View raw message