Mailing List Archive

>
>
> If there's anything that needs to be fixed in 0.6.2, speak
> now.
>
> 0.6.3 will have
>
> CFLAGS= -g -O2
>
> and Makefile.new = O58
>
>

There was one issue that David Robinson brought up that can
be quickly fixed in the Makefile so that it is possible to
set the CFLAGS and LFLAGS defines in the command line for the
make.


Changing

CFLAGS=
LFLAGS=

to

CFLAGS=$(CFLAGS)
LFLAGS=$(LFLAGS)

I'm on my way to do this.

> RobH wrote:
> >If there's anything that needs to be fixed in 0.6.2, speak
> >now.
> >
> >0.6.3 will have
> >
> >CFLAGS= -g -O2
>
> Personally, I'd rather it were
> CFLAGS= -O2
> #CFLAGS= -g
>
> >and Makefile.new = O58
>
> No it won't... I vetoed O58 8-(

As I remember, we had enough votes before your veto.
Also as I remember...

You did not like it because it required you to type 'make arch'
and that you could not override the CFLAGS/LFLAGS/CC defines.

The later has be corrected. As I mentioned in earlier mail,
I wanted the Makefile to provide the ability to compile for
multi-architectures in an NFS separating the binaries into
their respective directories.

> Your statement is true, but misleading; that is not why I vetoed the
> patch. I vetoed it because
> * It didn't support Solaris

I can't help you there. Neither does the current Makefile.
If we can commit a Makefile, then you could offer patches to
add Solaris support.

> * It didn't allow incremental re-compilation; it recompiled every
> source file every time I ran make.

'make' bug in Solaris? As long as I did not change a depended
file, it only compiled what was necessary on the archs I tested
on.

> >> I vetoed it because
> >> * It didn't support Solaris
> >
> >I can't help you there. Neither does the current Makefile.
> Yes it does! You must have missed it; it's the second OS listed:
>
> # For Solaris 2. NOTE: Lots of problems have been identified with compiling
> # httpd under Solaris. Use with caution. If you see aberrant behavior with
> # httpd under Solaris 2, please mail us.
> AUX_CFLAGS= -DSOLARIS2

I *am* sorry David. I totally missed that entry! Must be a
mental block... :-)

I will add it immediately.


> The main problems:
>
> * The rule for compiling source files is
> .c.o:
> $(CC) -c $(CFLAGS) $(LDEFINE) $(AUX_CFLAGS) $< -o $(ARCH)/$@
>
> this only checks for a .o file in the same directory as the .c file.
> As the .o's are put in $(ARCH), this rule never sees them, and so will
> always recompile the source file.

Again your correct. I'll slither off and work on this some more.


I've had more coffee now....

RobH wrote:
>If there's anything that needs to be fixed in 0.6.2, speak
>now.
>
>0.6.3 will have
>
>CFLAGS= -g -O2

Personally, I'd rather it were
CFLAGS= -O2
#CFLAGS= -g

>and Makefile.new = O58

No it won't... I vetoed O58 8-(

I think we should do another beta release (0.6.3) which includes any
portability patches we get, i.e. for AIX, NEXT etc.

Do we plan to keep the beta releases numbered consecutively, or will there
be gaps for the non-released versions?

David.

On Tue, 25 Apr 1995, David Robinson wrote:
> I think we should do another beta release (0.6.3) which includes any
> portability patches we get, i.e. for AIX, NEXT etc.
>
> Do we plan to keep the beta releases numbered consecutively, or will there
> be gaps for the non-released versions?

I'd vote for just making the 0.x releases public. Lets us go through a
few rounds internally first.

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/

Randy Terbush wrote:
>> No it won't... I vetoed O58 8-(
>
>As I remember, we had enough votes before your veto.

Doesn't matter...

>Also as I remember...
>
>You did not like it because it required you to type 'make arch'
>and that you could not override the CFLAGS/LFLAGS/CC defines.

Your statement is true, but misleading; that is not why I vetoed the
patch. I vetoed it because
* It didn't support Solaris
* It didn't allow incremental re-compilation; it recompiled every
source file every time I ran make.

>The later has be corrected. As I mentioned in earlier mail,
>I wanted the Makefile to provide the ability to compile for
>multi-architectures in an NFS separating the binaries into
>their respective directories.

Nothing wrong with that. However, I was commenting that I would
prefer
% make
_not_ to print out a list of supported architectures, and then _require_
you to type
% make arch

I would suggest that it might be better for the default make target
to compile in the source directory using compilation and link flags
set by the user in the Makefile. But that is only my preference.

David.

> On Tue, 25 Apr 1995, David Robinson wrote:
> > I think we should do another beta release (0.6.3) which includes any
> > portability patches we get, i.e. for AIX, NEXT etc.

> > Do we plan to keep the beta releases numbered consecutively, or will there
> > be gaps for the non-released versions?

> I'd vote for just making the 0.x releases public. Lets us go through a
> few rounds internally first.

we'll need to start numbering the non-forking version.

I'd suggest we keep patching fixes to the public beta, and
call them 0.x.y (x=big change, y = small change) and at
the same time call the non-forking stuff 1.x.y

0.x.y will contain no new features, just fixes. When it is stable,
we can leave that as a working version while we privately and then
publically test 1.x.y


How does that sound ?

robh

>> I vetoed it because
>> * It didn't support Solaris
>
>I can't help you there. Neither does the current Makefile.
Yes it does! You must have missed it; it's the second OS listed:

# For Solaris 2. NOTE: Lots of problems have been identified with compiling
# httpd under Solaris. Use with caution. If you see aberrant behavior with
# httpd under Solaris 2, please mail us.
AUX_CFLAGS= -DSOLARIS2
EXTRA_LIBS= -lsocket -lnsl

[I think we can remove the warning]

>> * It didn't allow incremental re-compilation; it recompiled every
>> source file every time I ran make.
>
>'make' bug in Solaris? As long as I did not change a depended
>file, it only compiled what was necessary on the archs I tested
>on.

I'm really amazed. I don't know what system you are using, but I'd recommend
getting access to a more 'normal' one, because I think the one you've got
is misleading you...

I cannot get the makefile to work under linux, OSF/1, SunOS 4, Solaris 2
or GNU make (SunOS and Solaris).

The main problems:

* The rule for compiling source files is
.c.o:
$(CC) -c $(CFLAGS) $(LDEFINE) $(AUX_CFLAGS) $< -o $(ARCH)/$@

this only checks for a .o file in the same directory as the .c file.
As the .o's are put in $(ARCH), this rule never sees them, and so will
always recompile the source file.

* Either give no dependancies for the OS target, or _all_ the dependancies.
i.e. either
aix:
make httpd...
or (maybe)
aix: Makefile $(ARCH)/httpd $(ARCHOBJS) httpd.h
make httpd...

otherwise make can decide that the target is up to date when it isn't.

* There is an unterminated string in the no_type rules.

Minor problems:

* Only some object files depend on stream.h; it would be nice not to make
them all depend on it.


David.

From: Rob Hartill <hartill@ooo.lanl.gov>
Date: Tue, 25 Apr 95 14:02:08 MDT

we'll need to start numbering the non-forking version.

I'd suggest we keep patching fixes to the public beta, and
call them 0.x.y (x=big change, y = small change) and at
the same time call the non-forking stuff 1.x.y

0.x.y will contain no new features, just fixes. When it is stable,
we can leave that as a working version while we privately and then
publically test 1.x.y


How does that sound ?

Some such split is a good idea. I might prefer 0.6.x for the new
public version (which should get *no* new features from here out, just
bugfixes) --- this is the pattern we seem to have settled into anyway,
and it would allow us to continue the former 0.7, 0.8, 0.9... pattern
for development releases. When we've got one of those which we're
ready to release, it might be time for 1.0bx, followed by 1.0.

Just a thought...

rst