httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Ben Hyde)
Subject Re: Window's Makefiles
Date Fri, 23 Jan 1998 20:52:12 GMT
I wrote:
> 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.

I'm not married to these.  I'd just like to clarify
how this mess is managed.  This was the best "strawman"
I could come up with.

Sam Robb <> wrote:
> 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.

I sure don't want to come off as being ain't IDE.  The
problem we encounter in our shop is that our developers
are always doing this kind of thing, but such
experimental setups don't belong in the master source
code repository and we were having lots of trouble with
the litter of this work slipping in.

> 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 agree this is a VERY important issue.  We need some
natives at the table.

> Another point  ... out of sync ... On top of that, 
> exporting the DSP makefile will overwrite the hand-edited 
> makefile.

This is all about keeping N versions of the same data
in synch!  See below.

> I'll volunteer to maintain them.

Your a saint!

The rule's I suggested are intended to be slightly
robust inspite of the comming and going of the pool
of labor.

Marc Slemko wrote:
> Because you need to do certain things from the GUI and just having
> makefiles isn't enough for that?  Try debugging a NT program from the
> command line, for example.

That's for sure!

> If we don't want two seperate copies of things (ie. makefiles, then
> seperate .dsp files) that means we have to autogenerate makefiles from
> dsps and that's that.

We have 3 (almost 4) copies of everything.  The unix makefile
templates, the dsp files, and the nmake files (which have two
varients in them for debug and release).  The heart of this
problem is how to keep them all in synch.  The rules I proposed
make choices about how to do that.

"Paul Brophy" <> wrote:
> ... Since
> the Unix guys can't test the Windows makefiles before they commit them,
> they shouldn't change them.

The problem is where to absorb the "out of synch".  No matter
were the change begins it needs to get to all N, and via a
set of procedures that are well understood.  Otherwise everybody
gets testy.

Marc Slemko wrote:
> You still can't really have non-NT developres editing .dsp or .mak files
> without being able to test.  It just doesn't make sense.

Ah, caught me!  That is exactly what I'm suggesting, weird as
it sounds.  The other option is to say developer X changes
one of the four version.  He then commits his changes.  Full Stop?

Well that just doesn't make sense either.

So what does he do?  Post to new-httpd "Subject: hot potato, no charge"
and then a few days latter I notice that the build is breaking and
I post.  Now Mr. X is getting pretty embaressed, but what can
he do?  My suggested rules say - go ahead try and fix it.  I prefer
a rule that encourages edits rather than mail :-).  You can't
make it worse, we can back out your edit, and it at least offers the
chance things will all "just work out."

Sadly my rules don't really fix everything since they clearly
treat the DSP files as the last to get fixed (unless of course
the change began there).

Dean wrote:
> we could support more windows compilation environments?

One thing at a time!

Dean wrote, in reference to the power of nmake.
> I can't believe that the windows development  environment is this stupid.

My impression is that nmake is just as powerful as make.  But that
the makefiles that are generated from the Dev. Studio, are all unwound
so that the power is almost entirely left unused.  Of course you still
stuck with that dos shell!

In my shop we hold the build in pretty high reguard, since it is at
the begining of a pipeline of automated testing, other projects
that compile on top of it, and risk taking users.  That
colors my thinking - may help explain why I realy realy want the
makefiles kept in synch and functional.

I'll repeat that we have had an awful time getting the Dev. Studio
to make dependable Makefiles that actually work on all the machines
in the building.  That too colors my thinking about this and 
partially explains why I lean toward letting that one of the N
fall a little more out of synch.

 - ben h.

View raw message