httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject 2.0.14-win32-buildfix (was: Re: cvs commit: ...)
Date Fri, 09 Mar 2001 14:15:00 GMT
On Wed, Mar 07, 2001 at 11:59:48PM -0600, William A. Rowe, Jr. wrote:
> From: <>
> Sent: Wednesday, March 07, 2001 11:38 PM
> > wrowe       01/03/07 21:38:17
> > 
> >   Modified:    .        libhttpd.mak
> >                modules/aaa mod_auth_digest.mak
> >                modules/dav/main mod_dav.mak
> >                modules/generators mod_info.mak mod_status.mak
> >   Log:
> >     Refreshing the .mak files.  Dang... should have done this in the a.m.
> Well that just bites it.  Now I know I should never have gotten FirstBill into using
> the .dsp files... now nobody notices when .mak files are broken.
> should do it.  I'm halfway to
> arguing we should drop .mak files from the tree once again.

Urk. Can you move the 2.0.14 tag on the above files, and then we can re-roll
a tar ball? (I see no reason to bump to 2.0.15; the tarball was "private" to
dev anyways)

I'm concerned that if we send the .zip out, we don't have any record of what
went into it. By moving the tag and rerolling, then we'll be sure.

> The problem is packaging.  Can we make this a seperate step?  How?  I can't roll a
> .zip release since some 36 files are generated independent of the tree.  Unix folks
> can't generate these 20 some files.  I feel strongly that all source packages should

> remain identical, short of the lf vs. crlf fixups to the win32 .zip file.

Sounds like a Perl script to transform .dsp files into .mak files would be
the trick. That script could then be invoked in buildconf (which is part of
our roll process). No more falling out of sync.

Now... I don't know the feasibility of a script to create .mak files, but I
gotta believe something can be hacked together.


Greg Stein,

View raw message