httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: architecture-specific directories
Date Wed, 15 Nov 2000 01:37:45 GMT
On Tue, Nov 14, 2000 at 06:56:44PM -0500, Jeff Trawick wrote:
> Before I go too far, let me post a sketch of where I am headed:
> After running configure, "make depend" from the apr base directory
> will do the right thing.

I believe Ryan would like the "make depend" to occur in "buildconf".
Personally, I wouldn't want to see that, but I'm okay with deferring that to
a later decision. First order of biz is to clear up the deps and implement a
new system for generating them.

> Code changes:
> 1) Create lib/apr/build/ with this line:
>   MKDEP = gcc -MM 
> This can made more platform-independent in the future...
> doesn't do quite the right thing for me, but I may not have used it
> correctly.  I think it is set up for apache object file names (.lo).
> Note that apr/build is a new directory for APR...


I don't want to see Yet Another Directory. In fact, Apache's complicated
build/*.mk stuff pisses me off. Every time that I dig in there, I want to go
and clean it up. This guys includes that guy, who defines rules over in that
other file. It is totally unclear what goes where, and how to find anything
in that rathole.

I don't want to see that happen to APR, too.

Put the MKDEP into each Makefile and put build/

> 2) In the various files, do something like the patch
>    below.  
> I would prefer to start with the files used on Unix but simply post a
> patch for the OS/2 and BeOS files, as I can't test them
> and will surely mess up the sed scripts somehow.
> Comments?

The rule is a bit too long. We could simplify things by creating
helpers/ and Do The Right Thing in there. The depend rule would
simply be:


Note that it may be possible we would need to have to allow the
configure process to feed some platform-specific stuff in there. But I'd
rather just see have the needed checks / fallbacks for the non-gcc


Greg Stein,

View raw message