httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Sutton <>
Subject Re: cvs commit: apachen/src/os/win32 ApacheOS.dsp ApacheOS.mak os.c os.h
Date Fri, 12 Sep 1997 17:50:19 GMT
On Fri, 12 Sep 1997, Ben Laurie wrote:
> Paul Sutton wrote:
> > Erm, it's normal procedure on multiple-directory source projects to have
> > the top level build do some initial setting up before the sub-directories
> > are called. For example, setting up the correct OS environment.
> > Unfortunately Win32 (or MSVC++) makes multiple directory environments
> > difficult to manage in an open way (while maintaining the ability to use
> > the IDE).
> I'm not sure what you think MSVC++ makes difficult to manage, but having
> header files in a different directory isn't it.

What makes MSVC difficult is its fundamental assumption that *all* the
development process will be managed as a single workspace within the IDE. 
For example, when we moved the directories around recently *all* the
projects (.dsp and .mak files) had to be updated with the new paths,
interactively using the IDE. It would be nice to have a single place where
all this information could be stored, which could be used within each
makefile (say, by pregenerating the makefiles as in Unix, or by having a
".include" type functionality within the makefiles. Note that we have
already accepted that we must have different makefiles for Unix and Win32,
even when the build process is virtually identical (for example, in

> What is wrong with it is that I right click on '#include "os.h"' to open
> os.h, and it opens the wrong one. Or I browse to a function defined in
> os.h, or...
> What's wrong with having it already in the right directory, and with an
> appropriate name? Or in a different directory, and still called "os.h"?

Because then you are putting an OS specific file within src/main (or
wherever), whereas it should live in the OS specific directory. The
correct way to do this would be to symbolically link from
src/main/os.{c,h} to the real file's location in os/win32, but (of course)
Win32 cannot do this.

Almost any way you look at it, developing cross platform projects on Win32
is a pain. 


View raw message