You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2001/03/08 06:59:48 UTC
Re: cvs commit: httpd-2.0/modules/generators mod_info.mak mod_status.mak
From: <wr...@apache.org>
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.
dev.apache.org/dist/httpd-2_0_14-win32-buildfix.zip should do it. I'm halfway to
arguing we should drop .mak files from the tree once again.
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.
I'll let any Win32 hackers comment here, I'm just mulling options.
Bill
Re: 2.0.14-win32-buildfix (was: Re: cvs commit: ...)
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Mar 09, 2001 at 08:27:08AM -0600, William A. Rowe, Jr. wrote:
> From: "Greg Stein" <gs...@lyra.org>
> 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 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.
However it gets done. Makefile.in -> .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
everything.
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 dsp5tocvs.pl 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.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: 2.0.14-win32-buildfix (was: Re: cvs commit: ...)
Posted by "William A. Rowe, Jr." <ad...@rowe-clan.net>.
From: "Greg Stein" <gs...@lyra.org>
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
2.0.14-win32-buildfix (was: Re: cvs commit: ...)
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Mar 07, 2001 at 11:59:48PM -0600, William A. Rowe, Jr. wrote:
> From: <wr...@apache.org>
> 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.
>
> dev.apache.org/dist/httpd-2_0_14-win32-buildfix.zip 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.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/