You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Marc Slemko <ma...@worldgate.com> on 1998/01/24 05:11:43 UTC
Re: cvs commit: apachen/src/os/win32 ApacheModuleAuthAnon.dsp ApacheModuleAuthAnon.mak ApacheModuleCERNMeta.dsp ApacheModuleCERNMeta.mak ApacheModuleDigest.dsp ApacheModuleDigest.mak ApacheModuleExpires.dsp ApacheModuleExpires.mak ApacheModuleHeaders.dsp ApacheModuleHeaders.mak ApacheModuleInfo.dsp ApacheModuleInfo.mak ApacheModuleRewrite.dsp ApacheModuleRewrite.mak ApacheModuleSpeling.dsp ApacheModuleSpeling.mak ApacheModuleStatus.dsp ApacheModuleStatus.mak ApacheModuleUserTrack.dsp ApacheModuleUserTrack.mak
On 24 Jan 1998 marc@hyperreal.org wrote:
> marc 98/01/23 20:07:24
>
> Modified: src ApacheCore.dsp ApacheCore.mak
> src/modules/proxy ApacheModuleProxy.dsp
> ApacheModuleProxy.mak
> src/os/win32 ApacheModuleAuthAnon.dsp
> ApacheModuleAuthAnon.mak ApacheModuleCERNMeta.dsp
> ApacheModuleCERNMeta.mak ApacheModuleDigest.dsp
> ApacheModuleDigest.mak ApacheModuleExpires.dsp
> ApacheModuleExpires.mak ApacheModuleHeaders.dsp
> ApacheModuleHeaders.mak ApacheModuleInfo.dsp
> ApacheModuleInfo.mak ApacheModuleRewrite.dsp
> ApacheModuleRewrite.mak ApacheModuleSpeling.dsp
> ApacheModuleSpeling.mak ApacheModuleStatus.dsp
> ApacheModuleStatus.mak ApacheModuleUserTrack.dsp
> ApacheModuleUserTrack.mak
> Log:
> Update Win32 build to add new ap directory to includes.
Trust me, you don't want to try doing _that_ by hand.
Is there any way to export the makefile from MVSC from the command
line?
Regardless of any long-term changes to make stuff like this easier
and better, we need Win32 to build now. This does that.
I think I got all the .dsp files that need updating and I don't think
all the change it made to the .mak files should hurt anything.
Re: cvs commit: apachen/src/os/win32 ApacheModuleAuthAnon.dsp
ApacheModuleAuthAnon.mak ApacheModuleCERNMeta.dsp ApacheModuleCERNMeta.mak
ApacheModuleDigest.dsp ApacheModuleDigest.mak ApacheModuleExpires.dsp
ApacheModuleExpires.mak ApacheModuleHeaders.dsp ApacheModuleHeaders.mak
ApacheModuleInfo.dsp ApacheModuleInfo.mak ApacheModuleRewrite.dsp
ApacheModuleRewrite.mak ApacheModuleSpeling.dsp ApacheModuleSpeling.mak
ApacheModuleStatus.dsp ApacheModuleStatus.mak ApacheModuleUserTrack.dsp
ApacheModuleUserTrack.mak
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Dean Gaudet wrote:
>
> Yeah well my point was that maintaining by hand isn't that hard. If you
> weren't using the MSVC IDE then you'd just be adding something to one line
> in one Makefile I'm sure... because your makefiles would actually use some
> of the features of make.
Your example is, I think, a massive oversimplification - because of
the different subdirectory levels. Some added lines need ".\", some
need "..\", and some need "..\..\" prefixes.
> My example could have been changed to edit the .dsp files instead.
But then it takes someone with DS to do the export, so part of the
work is done on UNIX and part on Win32, rather than all on Win32.
You want to be a hero? Write a Perl script that will export the
.mak files from the .dsp files the way DS does - then we can all do
all the work from the command line. <G>
> If the makefiles are autogenerated why do we even have them checked into
> CVS?
Can the build be done just from the makefiles without setting up or
loading the DS projects? I mean, I don't have an NT machine at the
moment; if I did, would I just be able to install DS, load the
source tree, and do an nmake without having to learn DS? If so,
there's your answer. If a Win32 developer *has* to learn DS in order
to build this stuff, then there may be no point in keeping the
makefiles in CVS.
#ken P-)}
Re: cvs commit: apachen/src/os/win32 ApacheModuleAuthAnon.dsp ApacheModuleAuthAnon.mak ApacheModuleCERNMeta.dsp ApacheModuleCERNMeta.mak ApacheModuleDigest.dsp ApacheModuleDigest.mak ApacheModuleExpires.dsp ApacheModuleExpires.mak ApacheModuleHeaders.dsp ApacheModuleHeaders.mak ApacheModuleInfo.dsp ApacheModuleInfo.mak ApacheModuleRewrite.dsp ApacheModuleRewrite.mak ApacheModuleSpeling.dsp ApacheModuleSpeling.mak ApacheModuleStatus.dsp ApacheModuleStatus.mak ApacheModuleUserTrack.dsp ApacheModuleUserTrack.mak
Posted by Marc Slemko <ma...@worldgate.com>.
On Fri, 23 Jan 1998, Dean Gaudet wrote:
>
>
> On Fri, 23 Jan 1998, Marc Slemko wrote:
>
> > On Fri, 23 Jan 1998, Dean Gaudet wrote:
> >
> > >
> > >
> > > On Fri, 23 Jan 1998, Marc Slemko wrote:
> > >
> > > > Trust me, you don't want to try doing _that_ by hand.
> > >
> > > find . -name \*.mak | xargs perl -pi -e 'print "new line to add\n" if (/blahblah/);'
> >
> > The problem is that you get files out of sync with what MSVC thinks they
> > should be, so if you export at some point in the future for some other
> > reason, you could have all sorts of things suddenly pop up broken. That
> > still sticks you with two supposedly canonical sources of make info and no
> > way to keep them in sync. Exporing from MSVC, while it generates an awful
> > mess, does keep them in sync.
>
> Yeah well my point was that maintaining by hand isn't that hard. If you
> weren't using the MSVC IDE then you'd just be adding something to one line
> in one Makefile I'm sure... because your makefiles would actually use some
> of the features of make.
Of course.
>
> My example could have been changed to edit the .dsp files instead.
But there is a fundamental incompatibility between having one canonical
source and trying to second-guess what MSVC will generate as a makefile.
If you had real makefiles then you have two easier to edit things. If you
use MSVC generated makefiles, you only have one thing to edit.
I really don't like the idea of having two seperate ways to build. From
what I can see, MSVC is pretty reasonable about keeping its generated
makefiles doing the same thing as the IDE. Changing that so we have to do
it is more pain than I think is wise.
Yes, it sucks, but...
>
> If the makefiles are autogenerated why do we even have them checked into
> CVS?
So that someone who wants to use nmake and not the IDE doesn't have to go
into the IDE and go through each and every of the two zillion projects to
manually create them.
Re: cvs commit: apachen/src/os/win32 ApacheModuleAuthAnon.dsp ApacheModuleAuthAnon.mak ApacheModuleCERNMeta.dsp ApacheModuleCERNMeta.mak ApacheModuleDigest.dsp ApacheModuleDigest.mak ApacheModuleExpires.dsp ApacheModuleExpires.mak ApacheModuleHeaders.dsp ApacheModuleHeaders.mak ApacheModuleInfo.dsp ApacheModuleInfo.mak ApacheModuleRewrite.dsp ApacheModuleRewrite.mak ApacheModuleSpeling.dsp ApacheModuleSpeling.mak ApacheModuleStatus.dsp ApacheModuleStatus.mak ApacheModuleUserTrack.dsp ApacheModuleUserTrack.mak
Posted by Dean Gaudet <dg...@arctic.org>.
On Fri, 23 Jan 1998, Marc Slemko wrote:
> On Fri, 23 Jan 1998, Dean Gaudet wrote:
>
> >
> >
> > On Fri, 23 Jan 1998, Marc Slemko wrote:
> >
> > > Trust me, you don't want to try doing _that_ by hand.
> >
> > find . -name \*.mak | xargs perl -pi -e 'print "new line to add\n" if (/blahblah/);'
>
> The problem is that you get files out of sync with what MSVC thinks they
> should be, so if you export at some point in the future for some other
> reason, you could have all sorts of things suddenly pop up broken. That
> still sticks you with two supposedly canonical sources of make info and no
> way to keep them in sync. Exporing from MSVC, while it generates an awful
> mess, does keep them in sync.
Yeah well my point was that maintaining by hand isn't that hard. If you
weren't using the MSVC IDE then you'd just be adding something to one line
in one Makefile I'm sure... because your makefiles would actually use some
of the features of make.
My example could have been changed to edit the .dsp files instead.
If the makefiles are autogenerated why do we even have them checked into
CVS?
Dean
Re: cvs commit: apachen/src/os/win32 ApacheModuleAuthAnon.dsp ApacheModuleAuthAnon.mak ApacheModuleCERNMeta.dsp ApacheModuleCERNMeta.mak ApacheModuleDigest.dsp ApacheModuleDigest.mak ApacheModuleExpires.dsp ApacheModuleExpires.mak ApacheModuleHeaders.dsp ApacheModuleHeaders.mak ApacheModuleInfo.dsp ApacheModuleInfo.mak ApacheModuleRewrite.dsp ApacheModuleRewrite.mak ApacheModuleSpeling.dsp ApacheModuleSpeling.mak ApacheModuleStatus.dsp ApacheModuleStatus.mak ApacheModuleUserTrack.dsp ApacheModuleUserTrack.mak
Posted by Marc Slemko <ma...@worldgate.com>.
On Fri, 23 Jan 1998, Dean Gaudet wrote:
>
>
> On Fri, 23 Jan 1998, Marc Slemko wrote:
>
> > Trust me, you don't want to try doing _that_ by hand.
>
> find . -name \*.mak | xargs perl -pi -e 'print "new line to add\n" if (/blahblah/);'
The problem is that you get files out of sync with what MSVC thinks they
should be, so if you export at some point in the future for some other
reason, you could have all sorts of things suddenly pop up broken. That
still sticks you with two supposedly canonical sources of make info and no
way to keep them in sync. Exporing from MSVC, while it generates an awful
mess, does keep them in sync.
Actually editing the .dsp files took 2 minutes. A couple more for going
through and manually exporting the makefiles, which was made harder
because they are in seperate projects. If you can automate exporting of
makefiles from .dsps, then you would have a system that is reasonably easy
to update.
It also does dependencies and it isn't just one line that it updates.
Re: cvs commit: apachen/src/os/win32 ApacheModuleAuthAnon.dsp ApacheModuleAuthAnon.mak ApacheModuleCERNMeta.dsp ApacheModuleCERNMeta.mak ApacheModuleDigest.dsp ApacheModuleDigest.mak ApacheModuleExpires.dsp ApacheModuleExpires.mak ApacheModuleHeaders.dsp ApacheModuleHeaders.mak ApacheModuleInfo.dsp ApacheModuleInfo.mak ApacheModuleRewrite.dsp ApacheModuleRewrite.mak ApacheModuleSpeling.dsp ApacheModuleSpeling.mak ApacheModuleStatus.dsp ApacheModuleStatus.mak ApacheModuleUserTrack.dsp ApacheModuleUserTrack.mak
Posted by Dean Gaudet <dg...@arctic.org>.
On Fri, 23 Jan 1998, Marc Slemko wrote:
> Trust me, you don't want to try doing _that_ by hand.
find . -name \*.mak | xargs perl -pi -e 'print "new line to add\n" if (/blahblah/);'
Dean