httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Robb <sr...@wisewire.com>
Subject RE: Window's Makefiles
Date Fri, 23 Jan 1998 19:09:30 GMT
I'm comfortable with the Visual C++ IDE, and with having
it generate makefiles for me.  Last night, I spent about
10 minutes adding a new profiling target to the makefiles
for NT using the IDE.  If I had to do it by hand, it never
would have gotten done.

Loosing this convenience and familarity for Windows
developers will make it (IMHO) hard to convince people
to sign on to work on the NT version.  I think most VC
developers (myself included) would rather not deal with
makefile maintenance if we can help it.

Another point - if you keep the DSP files around, and they fall
out of sync with the makefiles, you can have two completely
different builds of the same source code (an IDE build using
the DSP and a makfeil build from the command line).  Not a good
thing.  On top of that, exporting the DSP makefile will overwrite
the hand-edited makefile.

Keep the DSP files around.  I'll volunteer to maintain them,
if it's that much of an issue.

- Samrobb (srobb@wisewire.com)
- WiseWire Corporation - "Information - Online, On Target, All the Time"
- http://www.wisewire.com
- http://www.lycos.com/webguides/webguides.html

The box said 'Requires Windows 95, or better.' So I bought a Macintosh.



> -----Original Message-----
> From:	bhyde@gensym.com [SMTP:bhyde@gensym.com]
> Sent:	Friday, January 23, 1998 11:04 AM
> To:	new-httpd@apache.org
> Subject:	Window's Makefiles
> 
> Rules I'd propose:
> 
>  - Changes to the unix makefiles should have
>    a simultaneous change in the NT makefiles.
>    This is the responsibility of the all developers.
>    If you break the NT makefiles then:
>      a) don't sweat it, we forgive you.
>      b) one of the NT developers will make
>         a best effort to step up and kindly
>          help fix the breakage.
> 
>  - NT makefiles are maintained by hand, not by
>    emitting them from the Developer's studio.
> 
>  - A best effort is made to keep the NT project
>    (aka .DSP) files in synch with the unix
>    makefiles, but as this requires significant 
>    NT expertise they sadly will often lag behind.
>    This is the responsibility of the NT developers.
> 
> Discussion:
> 
> In my shop we have never been able to get sufficient
> craft knowledge under our belts to let the
> Dev. Studio generate our makefiles for us.  So we
> write them by hand.  It's a rule that you commit 
> makefiles as a set.
> 
> You want makefiles if your going to automate the
> build.  In house we build within minutes of a
> commit.  It's sad to break the build, but we
> consider it an accepted fact of life.  Of course
> breaking the build creates a high priority task to
> fix it.
> 
> Yes, it is possible in principle, to let the Dev.
> Studio generate the makefiles for you.  We find this
> doesn't work for us.  We had problems with QA
> surprises due to developers tinkering with settings.
> We had problems with absolute pathnames appearing in
> the files.
> 
> So we've found is best if the makefiles are
> maintained by hand.
> 
> Either way the dsp files and the makefiles want to
> stay in synch.  We have lots of trouble with that,
> and have had live with some roughness in the
> solution.
> 
> It is impossible to get a set of dsp files that
> everybody in a development group can share.  People
> just need to tinker with things.  It's hard to debug
> code in DLL's so people move it into the core code.
> Mortals can not get a set of PC configured identically,
> etc. etc.
> 
> It is very nice to have a set of dsp files people
> can use to get started.  So we check in a set just
> for that purpose.  People use them to get going, but
> very quickly find that CVS want's to check in their
> tinkering - we tell them "DON'T, PLEASE DON'T!"
> 
> When the build topology changes we let somebody
> carefully revise these starter DSP files.  This
> takes a "select" individual.  The the DSP files seem
> to often get an absolute pathnames in them, and then
> they are kind a useless for other users.
> 
> The cost of good DSP files is high, the advantage is
> it quick starts developers.  I often am tempted to
> forgo the benefit.
> 
> I have a dream that somebody someday will write
> the perl script to generate useful dsp files.
> 
>  - ben (the long winded one).

Mime
View raw message