httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: 2.0.14-win32-buildfix (was: Re: cvs commit: ...)
Date Fri, 09 Mar 2001 14:45:39 GMT
On Fri, Mar 09, 2001 at 08:27:08AM -0600, William A. Rowe, Jr. wrote:
> From: "Greg Stein" <>
> Sent: Friday, March 09, 2001 8:15 AM
> > 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)
> +1 ... I've always understood folks hate the concept, I'm willing to retag the
> original tags as APACHE_2_0_14_a1 as a little remimder we did once tag them.

Nah. Forget the original tags. They hold no interest/usefulness.

> > > 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
> > > can't generate these 20 some files.  I feel strongly that all source packages
> > > 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.
> That's much more tricky than, say, transforming files into .dsp files.

However it gets done. -> .dsp and -> .mak? Fine. Keep .in and
.dsp, and just create .mak?

You asked about .mak, not .dsp :-) But we can talk about that, too.

> The problem is parsing for dependencies.  Any good C parser out there in perlland
> to generate dependency info?

Who cares about dependencies? Unzip the thing. Build. It'll just build

Now... if somebody wants to do development, and pick up dependent changes,
then they ought to use the .dsp files. We have a mkdep.perl laying around;
dunno how good it is. But typically an approximation is Good Enough.

But my vote is to simply ignore deps for the .mak files. We can't guarantee
they work *now*, so losing the deps certainly can't *break* them :-)

[ and the failure mode is obvious: change, make. hey! ]

> > Now... I don't know the feasibility of a script to create .mak files, but I
> > gotta believe something can be hacked together.
> Might even be easier to refuse a .dsp checkin without the .mak file at the same
> time.  Also considering migrating the script into the checkin, so the
> revised copy is always submitted in the same format.  But that's all post-AC games.

That would be a bitch. And I don't think that I'd be all that keen to muck
with our CVS system to do this. Realize that /home/cvs/CVSROOT is for *all*
Apache projects. We'd have to do some work to ensure the guarantees only
applied to certain projects. Getting fragile... :-)

I'm at least a -0 on this.


Greg Stein,

View raw message