On Fri, Aug 24, 2001 at 09:05:16AM -0700, Bruce A. Mah wrote:
> If memory serves me right, Wilko Bulte wrote:
> > I get the impression that even if a machine has the necessary docproj
> > buildtools ports installed a 'make release' builds them from scratch
> > again? Is this true? And why?
>
> Yes, it's true. We need to rebuild the docproj ports inside the chroot
Why? Why can't the docs not be generated using the tools installed on the
system?
> area. There's one optimization made...anything in /usr/ports/distfiles
> gets copied to the the chroot area's /usr/ports/distfiles. This can
> save needing to fetch the distfiles for all of the docproj ports all
> over again.
And it appears to be broken too:
In file included from gdcache.h:43,
from gdft.c:35:
/usr/include/malloc.h:2: warning: #warning "this file includes <malloc.h>
which is deprecated, use <stdlib.h> instead"
gdft.c:36: freetype/freetype.h: No such file or directory
gdft.c:37: freetype/ftglyph.h: No such file or directory
*** Error code 1
Stop in /usr/ports/graphics/gd/work/gd-1.8.4.
*** Error code 1
this is because 'gd' does not depend correctly on 'freetype2'
a plain 'make' on the docproj port on Alpha fails in an identical fashion.
<sigh; I want a working .iso to test the booting issue that plagued us>
> A little brainstorming...
>
> I wonder if we could hand the release building process a list of
> packages to install before building docs? Like we could try to do
> pkg_add for each of the ports defined in ${MINIMALDOCPORTS} (insert
> hand-waving here to convert directory names to package filenames). This
> introduces two problems...the release builder needs to have a set of
> packages that's consistent with the requirement of the doc/ and src/
> release/doc trees (as well as the release being built). Second, it
> introduces a Yet Another Knob To Tweak During Release Building (TM).
Why not depend the make release on 'docproj-v.foo' and be done with it?
And if it is lacking docproj and cannot build it either just continue the
make release and leave the docs out?
> Another, truly ugly way would be an option to tar up /usr/local and drop
> it into the chroot area (yeah, this doesn't work for people who don't
> install ports to /usr/local).
>
> > This takes bloody forever..
> > Observed with make release for RELENG_4 on Alpha.
>
> Now if I can crank out releases on my puny PII-400, surely an Alpha can
> do it, right? :-)
And this is not the puniest of Alphas, this is a 466MHz EV6 box. Most
FreeBSD folks have (much) slower machines.
> /me ducks and covers.
gcc sucks on Alpha and hence the performance of it all leaves a bit to
be desired. [understatement alert]
Wilko
--
| / o / / _ Arnhem, The Netherlands email: [EMAIL PROTECTED]
|/|/ / / /( (_) Bulte
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
