This is the mail archive of the
mailing list for the GCC project.
Re: GCC 3.0.2 and BSD Make
- To: gcc at gcc dot gnu dot org
- Subject: Re: GCC 3.0.2 and BSD Make
- From: Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>
- Date: Wed, 31 Oct 2001 22:12:41 -0600 (CST)
- Organization: Networks and Infrastructure Lab (IL02/2240), Motorola Labs
- References: <200110301753.JAA22587@kankakee.wrs.com>
In article <20011030121920.K2079@rjlhome.caldera.com> you write:
> In case any BSD'er (and it doesn't have to be a compiler stud) would
> like a little project, I'll offer that I've found a cron job that does
> a nightly pull, build, and test to be rather effective in solving this
> sort of issue.
Agreed. Since before the 3.0 release FreeBSD.org has been doing
nightly builds of gcc. Today, we test both the mainline and the 3.0.X
branch every night with automatic report filing. A month ago, I added
checks against both in-source and out-out-source directory
configuration. We recently added the check against BSD make as well
as GNU make. On alternate nights we build with GNU make and BSD make.
The BSD make is currently broken without an exact pinpoint to the
patch that broke it. Once I get the right patch in to fix it, then we
will catch it ASAP instead of only once BSD projects do an import
(although the point is moot for FreeBSD which maintains its own set of
Makefiles when gcc is built within the OS).
It is possible that someone related to the NetBSD project will be
donating more CPU cycles to do the same daily tests for themselves.
> Armed with the ChangeLog for that day, you can generally figure out
> the source of the breakage and get it identified closer to the
> source rather than awaiting the final stretch of a release to expose it.
> I've found those that accidentally hose my target are generally quite
> responsive when contacted the day after the change was committed. I
> tend to have more compute cycles than cereberal cycles available so
> this spares me from having to do extensive debugging over months worth
> of changes and the person that recently did the work still has the
> intellectualization of the surrounding context in their cereberal cache.