From: "Greg Stein" <[EMAIL PROTECTED]>
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.
> 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.
Agreed
> > 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.
That's much more tricky than, say, transforming makefile.in files into .dsp files.
The problem is parsing for dependencies. Any good C parser out there in perlland
to generate dependency info?
> 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 dsp5tocvs.pl script into the checkin, so the
revised copy is always submitted in the same format. But that's all post-AC games.
Bill
