Re: Overdone rescue cleaning as part of buildworld?
Gordon Tetlow wrote: Attached is the patch. It basically makes CRUNCH_PROGS into a per directory item and then only does a make obj on the per program directory. Tim Kientzle whined: Hmmm I do have a philosophical quibble ... Gordon Tetlow generously suggested: That could probably be solved with a bit of make-foo. I'll see if I can work that up. But I don't think it's going to be a huge priority. Don't bother. I was just whining. ;-) Realistically, the parallel build problem is the highest priority right now for /rescue. Your patch works. Let's commit it and move on. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Overdone rescue cleaning as part of buildworld?
David O'Brien wrote: Gordon, 'make world' times have climbed up to over 1 hour on a machine that used to do it in 25 minutes. Can you please commit to understanding how /resuce is build and optimizing it ... Just out of curiosity, I timed 'buildworld' to see what impact /rescue really has. These are all approximate timings on my desktop machine: without /rescue: 47:30 with original /rescue: 50:12 with optimized /rescue: 50:10 Tim Kientzle ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Overdone rescue cleaning as part of buildworld?
On Tue, 15 Jul 2003, Tim Kientzle wrote: David O'Brien wrote: Gordon, 'make world' times have climbed up to over 1 hour on a machine that used to do it in 25 minutes. Can you please commit to understanding how /resuce is build and optimizing it ... Just out of curiosity, I timed 'buildworld' to see what impact /rescue really has. These are all approximate timings on my desktop machine: without /rescue: 47:30 with original /rescue: 50:12 with optimized /rescue: 50:10 My machine is a laptop and thus disk IO is a killer. Your numbers are much better than what I've seen. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Overdone rescue cleaning as part of buildworld?
On Sun, Jul 13, 2003 at 09:49:46PM -0700, Nate Lawson wrote: It appears /rescue is cleaning for way too much as part of buildworld. For instance, groff is NOT part of /rescue (or we have other things to discuss. :) This adds a bit of time to buildworld, can it be removed? Gordon, 'make world' times have climbed up to over 1 hour on a machine that used to do it in 25 minutes. Can you please commit to understanding how /resuce is build and optimizing it before 5.2-RELEASE. thanks, -- -- David([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Overdone rescue cleaning as part of buildworld?
On Mon, Jul 14, 2003 at 12:40:42AM -0700, David O'Brien wrote: On Sun, Jul 13, 2003 at 09:49:46PM -0700, Nate Lawson wrote: It appears /rescue is cleaning for way too much as part of buildworld. For instance, groff is NOT part of /rescue (or we have other things to discuss. :) This adds a bit of time to buildworld, can it be removed? Gordon, 'make world' times have climbed up to over 1 hour on a machine that used to do it in 25 minutes. Can you please commit to understanding how /resuce is build and optimizing it before 5.2-RELEASE. I've already started this process and I have some work in a local tree to depessimize the build dramatically. Thank you for the reminder. Would you be interested in taking a look at the patches? -gordon pgp0.pgp Description: PGP signature
Re: Overdone rescue cleaning as part of buildworld?
On Mon, Jul 14, 2003 at 09:09:52AM -0700, Gordon Tetlow wrote: On Mon, Jul 14, 2003 at 12:40:42AM -0700, David O'Brien wrote: On Sun, Jul 13, 2003 at 09:49:46PM -0700, Nate Lawson wrote: It appears /rescue is cleaning for way too much as part of buildworld. For instance, groff is NOT part of /rescue (or we have other things to discuss. :) This adds a bit of time to buildworld, can it be removed? Gordon, 'make world' times have climbed up to over 1 hour on a machine that used to do it in 25 minutes. Can you please commit to understanding how /resuce is build and optimizing it before 5.2-RELEASE. I've already started this process and I have some work in a local tree to depessimize the build dramatically. Thanks! :-) Would you be interested in taking a look at the patches? If it would be a help to you, I am willing. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Overdone rescue cleaning as part of buildworld?
At 9:09 AM -0700 7/14/03, Gordon Tetlow wrote: On Mon, Jul 14, 2003 at 12:40:42AM -0700, David O'Brien wrote: Gordon, 'make world' times have climbed up to over 1 hour on a machine that used to do it in 25 minutes. Can you please commit to understanding how /resuce is build and optimizing it before 5.2-RELEASE. I've already started this process and I have some work ... Btw, when I was doing a buildworld this weekend, I noticed the following error in the section that builds /rescue. Has anyone else noticed this? It may be easy to miss, because 'make buildworld' does not abort at the error. The following is some information I sent to Tim Kientzle [EMAIL PROTECTED] early this morning, but I thought I'd send it to the list just to see if anyone else has seen this problem. Perhaps it is due to something at my end of things. For me, 'make buildworld' goes through: === rescue/rescue/dhcpctl === rescue/rescue/client === rescue/rescue/omshell successfully, and then while building: === rescue/rescue/common Here is the last few lines I get: cc -O -pipe -mcpu=pentiumpro -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/usr\ -I/usr/obj/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config -DHAVE_CONFIG_H -DTARGET_NAME=\i386-undermydesk-freebsd\ -DIN_GCC -c /usr/src/contrib/gcc/make-temp-file.c make: don't know how to make /usr/obj/usr/src/rescue/rescue//usr/src/sbin/dhclient/client/clparse.o. Stop *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 Now, after those Error's, make seems to go merrily along, and makes bunch of other stuff. It looks like it even gets to the end of the buildworld OK. However the way I do buildworld's notices those '*** Error' lines, and it starts waving flags at me. I am generally reluctant to ignore those flags... I did a bunch of cvsup's and cross-checks to make sure I had the correct up-to-the-minute sources. I had also removed all of /usr/obj/usr/src in case I had old cruft there (well, actually I did that just because of the new gcc import...). I rebuilt with -DNORESCUE and the buildworld finished OK. I am building with -j5 on a dual-processor Athlon system, if that is significant. I am not doing any cross-build. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Overdone rescue cleaning as part of buildworld?
On Mon, Jul 14, 2003 at 01:53:29PM -0400, Garance A Drosihn wrote: At 9:09 AM -0700 7/14/03, Gordon Tetlow wrote: On Mon, Jul 14, 2003 at 12:40:42AM -0700, David O'Brien wrote: Gordon, 'make world' times have climbed up to over 1 hour on a machine that used to do it in 25 minutes. Can you please commit to understanding how /resuce is build and optimizing it before 5.2-RELEASE. I've already started this process and I have some work ... Btw, when I was doing a buildworld this weekend, I noticed the following error in the section that builds /rescue. Has anyone else noticed this? It may be easy to miss, because 'make buildworld' does not abort at the error. The following is some information I sent to Tim Kientzle [EMAIL PROTECTED] early this morning, but I thought I'd send it to the list just to see if anyone else has seen this problem. Perhaps it is due to something at my end of things. For me, 'make buildworld' goes through: === rescue/rescue/dhcpctl === rescue/rescue/client === rescue/rescue/omshell successfully, and then while building: === rescue/rescue/common Here is the last few lines I get: cc -O -pipe -mcpu=pentiumpro -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/usr\ -I/usr/obj/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config -DHAVE_CONFIG_H -DTARGET_NAME=\i386-undermydesk-freebsd\ -DIN_GCC -c /usr/src/contrib/gcc/make-temp-file.c make: don't know how to make /usr/obj/usr/src/rescue/rescue//usr/src/sbin/dhclient/client/clparse.o. Stop *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 Now, after those Error's, make seems to go merrily along, and makes bunch of other stuff. It looks like it even gets to the end of the buildworld OK. However the way I do buildworld's notices those '*** Error' lines, and it starts waving flags at me. I am generally reluctant to ignore those flags... I did a bunch of cvsup's and cross-checks to make sure I had the correct up-to-the-minute sources. I had also removed all of /usr/obj/usr/src in case I had old cruft there (well, actually I did that just because of the new gcc import...). I rebuilt with -DNORESCUE and the buildworld finished OK. I am building with -j5 on a dual-processor Athlon system, if that is significant. I am not doing any cross-build. I've heard some reports of this specifically with -j flag. I'll see if I can look at it once I finish depessimizing the build. -gordon pgp0.pgp Description: PGP signature
Re: Overdone rescue cleaning as part of buildworld?
Gordon Tetlow wrote:
On Mon, Jul 14, 2003 at 12:40:42AM -0700, David O'Brien wrote:
On Sun, Jul 13, 2003 at 09:49:46PM -0700, Nate Lawson wrote:
It appears /rescue is cleaning for way too much as part of buildworld.
For instance, groff is NOT part of /rescue (or we have other things to
discuss. :) This adds a bit of time to buildworld, can it be removed?
Yeah, I took a few shortcuts; /rescue does build far more in
OBJDIR than it needs to, and similarly cleans much more than it needs
to. (Those extra dirs are never populated, but building and cleaning
them does still take time.) I believe the attached patch addresses
this issue; it trims down /usr/obj/usr/src/rescue/rescue/usr/src/... to
just the directories actually needed.
David's claim that /rescue is more than doubling the build time is
surprising, though. Compiling all of /bin and /sbin (which is more-or-less
what /rescue consists of) should not take more time than building the
entire system including /bin and /sbin. Perhaps something else is
going on here?
I've already started this process and I have some work in a local tree
to depessimize the build dramatically. Thank you for the reminder. Would
you be interested in taking a look at the patches?
Gordon,
I apologize that my shortcuts are causing you more work. sigh
If you've already solved these problems, feel free to ignore
this and commit your work. On the other hand, since I _do_
understand how /rescue is built, I thought I might be able
to save you some effort by feeding you fixes for this.
I'm waiting on a buildworld with this patch to finish. I'll
let you know if anything goes awry, but I believe it works.
(Unfortunately, I _don't_ understand the parallel build
issue. I strongly suspect that it only impacts dhclient,
which has some rather unique build architecture. The
draconian solution would be to carve dhclient out of the
rescue crunchgen and build it separately, or just
statically link the official copy in /sbin and put
off the whole issue. I find both of these approaches
expedient but unsatisfying.)
Tim
Index: Makefile
===
RCS file: /usr/cvs/FreeBSD-CVS/src/rescue/rescue/Makefile,v
retrieving revision 1.5
diff -u -r1.5 Makefile
--- Makefile30 Jun 2003 21:13:56 - 1.5
+++ Makefile14 Jul 2003 19:25:02 -
@@ -64,7 +64,7 @@
# WARNING: Changing this list may require adjusting
# /usr/include/paths.h as well! You were warned!
#
-CRUNCH_SRCDIRS+=$(.CURDIR)/../../bin $(.CURDIR)/../../usr.bin
+CRUNCH_SRCDIRS+=$(.CURDIR)/../../bin
CRUNCH_PROGS=cat chflags chio chmod cp date dd df domainname echo ed \
expr getfacl hostname kenv kill ln ls mkdir mv pax ps pwd \
realpath rm rmdir setfacl sh sleep stty sync test
@@ -99,9 +99,6 @@
# WARNING: Changing this list may require adjusting
# /usr/include/paths.h as well! You were warned!
#
-# Note that mdmfs and shutdown have their own private 'pathnames.h'
-# headers in addition to the standard 'paths.h' header.
-#
CRUNCH_SRCDIRS+=$(.CURDIR)/../../sbin
CRUNCH_PROGS+=atm adjkerntz atacontrol badsect bsdlabel camcontrol \
ccdconfig clri comcontrol conscontrol devfs dmesg dump \
@@ -159,28 +156,32 @@
CRUNCH_ALIAS_fsck_ffs=fsck_4.2bsd fsck_ufs
CRUNCH_ALIAS_mount_std= mount_devfs mount_fdescfs mount_linprocfs mount_procfs
-# dhclient has historically been troublesome...
+# dhclient is troublesome...
CRUNCH_PROGS+=dhclient
CRUNCH_BUILDOPTS_dhclient=-DRELEASE_CRUNCH -Dlint
##
# Programs from stock /usr/bin
#
-CRUNCH_SRCDIRS+=$(.CURDIR)/../../usr.bin
-CRUNCH_SRCDIRS+=$(.CURDIR)/../../gnu/usr.bin
CRUNCH_PROGS+=wall
+CRUNCH_SRCDIR_wall+=$(.CURDIR)/../../usr.bin/wall
CRUNCH_PROGS+=gzip
+CRUNCH_SRCDIR_gzip+=$(.CURDIR)/../../gnu/usr.bin/gzip
CRUNCH_ALIAS_gzip=gunzip gzcat zcat
CRUNCH_PROGS+=bzip2
+CRUNCH_SRCDIR_bzip2+=$(.CURDIR)/../../usr.bin/bzip2
CRUNCH_ALIAS_bzip2=bunzip2 bzcat
CRUNCH_LIBS+=-lbz2
CRUNCH_PROGS+=tar
+CRUNCH_SRCDIR_tar+=$(.CURDIR)/../../gnu/usr.bin/tar
+
CRUNCH_PROGS+=vi
CRUNCH_ALIAS_vi=ex
+CRUNCH_SRCDIR_vi+=$(.CURDIR)/../../usr.bin/vi
##
# The following is pretty nearly a generic crunchgen-handling makefile
@@ -244,8 +245,6 @@
$(OUTPUTS): $(CONF)
MAKEOBJDIRPREFIX=${CRUNCHOBJS} crunchgen -q -m $(OUTMK) -c $(OUTC) $(CONF)
-# -m here forces make to treat the bsd.prog.mk and bsd.lib.mk in
-# this directory as overrides for the standard shared ones.
$(PROG): $(OUTPUTS)
MAKEOBJDIRPREFIX=${CRUNCHOBJS} make -f $(OUTMK)
@@ -260,14 +259,34 @@
.for D in $(CRUNCH_SRCDIRS)
cd ${D} MAKEOBJDIRPREFIX=${CANONICALOBJDIR} make ${.TARGET}
.endfor
+.for P in $(CRUNCH_PROGS)
+.ifdef CRUNCH_SRCDIR_${P}
+ cd ${CRUNCH_SRCDIR_${P}} \
+ MAKEOBJDIRPREFIX=${CANONICALOBJDIR} make ${.TARGET}
+.endif
+.endfor
clean:
Re: Overdone rescue cleaning as part of buildworld?
On Mon, Jul 14, 2003 at 12:44:05PM -0700, Tim Kientzle wrote: Gordon Tetlow wrote: On Mon, Jul 14, 2003 at 12:40:42AM -0700, David O'Brien wrote: On Sun, Jul 13, 2003 at 09:49:46PM -0700, Nate Lawson wrote: It appears /rescue is cleaning for way too much as part of buildworld. For instance, groff is NOT part of /rescue (or we have other things to discuss. :) This adds a bit of time to buildworld, can it be removed? Yeah, I took a few shortcuts; /rescue does build far more in OBJDIR than it needs to, and similarly cleans much more than it needs to. (Those extra dirs are never populated, but building and cleaning them does still take time.) I believe the attached patch addresses this issue; it trims down /usr/obj/usr/src/rescue/rescue/usr/src/... to just the directories actually needed. This solution is kinda hackish, I have a more generic solution that makes it easier to add programs without having to specifically add CRUNCH_SRCDIR_foo to every program outside of src/bin and src/sbin. I'm hoping to iron out the wrinkles today and post the patches. Other than that the patch is pretty much complete. -gordon pgp0.pgp Description: PGP signature
Re: Overdone rescue cleaning as part of buildworld?
Gordon Tetlow wrote: On Mon, Jul 14, 2003 at 12:44:05PM -0700, Tim Kientzle wrote: Gordon Tetlow wrote: On Sun, Jul 13, 2003 at 09:49:46PM -0700, Nate Lawson wrote: It appears /rescue is cleaning for way too much as part of buildworld. For instance, groff is NOT part of /rescue (or we have other things to discuss. :) This adds a bit of time to buildworld, can it be removed? Yeah, I took a few shortcuts; /rescue does build far more in OBJDIR than it needs to, and similarly cleans much more than it needs to. (Those extra dirs are never populated, but building and cleaning them does still take time.) I believe the attached patch addresses this issue; it trims down /usr/obj/usr/src/rescue/rescue/usr/src/... to just the directories actually needed. This solution is kinda hackish, I have a more generic solution that makes it easier to add programs without having to specifically add CRUNCH_SRCDIR_foo to every program outside of src/bin and src/sbin. I'm hoping to iron out the wrinkles today and post the patches. Other than that the patch is pretty much complete. Great! Looking forward to it. Do take a look, though at the edits near the end of that patch file. There are a couple of corrections there that actually complete the support for CRUNCH_SRCDIR_foo, and should be included even if you solve this particular problem in a more sophisticated way. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Overdone rescue cleaning as part of buildworld?
On Mon, Jul 14, 2003 at 03:15:01PM -0700, Tim Kientzle wrote:
Gordon Tetlow wrote:
On Mon, Jul 14, 2003 at 12:44:05PM -0700, Tim Kientzle wrote:
Gordon Tetlow wrote:
On Sun, Jul 13, 2003 at 09:49:46PM -0700, Nate Lawson wrote:
It appears /rescue is cleaning for way too much as part of buildworld.
For instance, groff is NOT part of /rescue (or we have other things to
discuss. :) This adds a bit of time to buildworld, can it be removed?
Yeah, I took a few shortcuts; /rescue does build far more in
OBJDIR than it needs to, and similarly cleans much more than it needs
to. (Those extra dirs are never populated, but building and cleaning
them does still take time.) I believe the attached patch addresses
this issue; it trims down /usr/obj/usr/src/rescue/rescue/usr/src/... to
just the directories actually needed.
This solution is kinda hackish, I have a more generic solution that makes
it easier to add programs without having to specifically add
CRUNCH_SRCDIR_foo to every program outside of src/bin and src/sbin. I'm
hoping to iron out the wrinkles today and post the patches. Other than
that the patch is pretty much complete.
Great! Looking forward to it.
Attached is the patch. It basically makes CRUNCH_PROGS into a per
directory item and then only does a make obj on the per program
directory. I've incorporated the CRUNCH_SRCDIR_foo stuff you had
although I had come up with a similar solution.
It's lightly tested, some more eyes looking at it would be useful.
I'm currently running it through a buildworld.
-gordon
--- //depot/vendor/freebsd/src/rescue/rescue/Makefile 2003/07/11 10:38:05
+++ //depot/user/gordon/dynamic/src/rescue/rescue/Makefile 2003/07/14 13:04:49
@@ -1,4 +1,4 @@
-#$FreeBSD: src/rescue/rescue/Makefile,v 1.6 2003/07/11 16:57:43 gordon Exp $
+#$FreeBSD: src/rescue/rescue/Makefile,v 1.5 2003/06/30 21:13:56 gordon Exp $
# @(#)Makefile8.1 (Berkeley) 6/2/93
PROG= rescue
@@ -66,9 +66,9 @@
# WARNING: Changing this list may require adjusting
# /usr/include/paths.h as well! You were warned!
#
-CRUNCH_SRCDIRS+=$(.CURDIR)/../../bin $(.CURDIR)/../../usr.bin
-CRUNCH_PROGS=cat chflags chio chmod cp date dd df domainname echo ed \
-expr getfacl hostname kenv kill ln ls mkdir mv pax ps pwd \
+CRUNCH_SRCDIRS+=bin
+CRUNCH_PROGS_bin=cat chflags chio chmod cp date dd df domainname echo \
+ed expr getfacl hostname kenv kill ln ls mkdir mv pax ps pwd \
realpath rm rmdir setfacl sh sleep stty sync test
CRUNCH_LIBS+=-lcrypt -lcrypto -ledit -lkvm -ll -lm -ltermcap -lutil
@@ -82,18 +82,18 @@
CRUNCH_ALIAS_ed= red
.if !defined(NO_RCMNDS)
-CRUNCH_PROGS+= rcp
+CRUNCH_PROGS_bin+= rcp
.endif
.if !defined(NO_TCSH)
-CRUNCH_PROGS+= csh
+CRUNCH_PROGS_bin+= csh
CRUNCH_ALIAS_csh= -csh tcsh -tcsh
CRUNCH_SUPPRESS_LINK_-csh=1
CRUNCH_SUPPRESS_LINK_-tcsh=1
.endif
#Is rmail of any use at all here? I think not.
-#CRUNCH_PROGS+= rmail
+#CRUNCH_PROGS_bin+= rmail
###
# Programs from standard /sbin
@@ -104,8 +104,8 @@
# Note that mdmfs and shutdown have their own private 'pathnames.h'
# headers in addition to the standard 'paths.h' header.
#
-CRUNCH_SRCDIRS+=$(.CURDIR)/../../sbin
-CRUNCH_PROGS+=atm adjkerntz atacontrol badsect bsdlabel camcontrol \
+CRUNCH_SRCDIRS+=sbin
+CRUNCH_PROGS_sbin=atm adjkerntz atacontrol badsect bsdlabel camcontrol \
ccdconfig clri comcontrol conscontrol devfs dmesg dump \
dumpfs dumpon fore_dnld fsck fsck_ffs fsck_msdosfs fsdb \
fsirand gbde growfs ifconfig ilmid init ip6fw ipf ipfs ipfstat \
@@ -124,7 +124,7 @@
-lgeom -lmd -lreadline -lsbuf -lufs -lz
.if ${MACHINE_ARCH} == i386
-CRUNCH_PROGS+= cxconfig fdisk
+CRUNCH_PROGS_sbin+= cxconfig fdisk
CRUNCH_ALIAS_bsdlabel= disklabel
#CRUNCH_PROGS+= mount_nwfs mount_smbfs
#CRUNCH_LIBS+= -lncp -lsmb
@@ -135,11 +135,11 @@
.endif
.if ${MACHINE_ARCH} == ia64
-CRUNCH_PROGS+= mca gpt fdisk
+CRUNCH_PROGS_sbin+= mca gpt fdisk
.endif
.if ${MACHINE_ARCH} == sparc64
-CRUNCH_PROGS+= sunlabel
+CRUNCH_PROGS_sbin+= sunlabel
.endif
.if ${MACHINE_ARCH} == alpha
@@ -147,7 +147,7 @@
.endif
.if ${MACHINE_ARCH} == amd64
-CRUNCH_PROGS+= fdisk
+CRUNCH_PROGS_sbin+= fdisk
CRUNCH_ALIAS_bsdlabel= disklabel
.endif
@@ -162,26 +162,26 @@
CRUNCH_ALIAS_mount_std= mount_devfs mount_fdescfs mount_linprocfs mount_procfs
# dhclient has historically been troublesome...
-CRUNCH_PROGS+=dhclient
+CRUNCH_PROGS_sbin+=dhclient
CRUNCH_BUILDOPTS_dhclient=-DRELEASE_CRUNCH -Dlint
##
# Programs from stock /usr/bin
#
-CRUNCH_SRCDIRS+=$(.CURDIR)/../../usr.bin
-CRUNCH_SRCDIRS+=$(.CURDIR)/../../gnu/usr.bin
+CRUNCH_SRCDIRS+=usr.bin
+CRUNCH_SRCDIRS+=gnu/usr.bin
-CRUNCH_PROGS+=wall
+CRUNCH_PROGS_usr.bin+=wall
-CRUNCH_PROGS+=gzip
+CRUNCH_PROGS_gnu/usr.bin+=gzip
CRUNCH_ALIAS_gzip=gunzip
Re: Overdone rescue cleaning as part of buildworld?
Gordon Tetlow wrote:
Attached is the patch. It basically makes CRUNCH_PROGS into a per
directory item and then only does a make obj on the per program
directory.
Hmmm I do have a philosophical quibble with your
approach: My original intent for this Makefile was
that the top part was rescue-specific and the bottom
part would be sufficiently generic to be used in other
crunchgen-based projects.
Your patches embed a certain amount of /rescue-specific knowledge
into the generic portion of the Makefile. For example,
+ cd $(.CURDIR)/../../${D}/${P}
makes a prett strong assumption about the relative
locations of the crunchgen-using source directory
and its components.
The advantage of your approach is that you are
making the subdirectory handling very tight.
Essentially, you are listing exactly the
subdirectories to be handled, where my approach
is a bit sloppier.
The advantage of my approach is that it is less
tied to the particulars of building /rescue as
part of the FreeBSD source code.
But, this is only a philosophical objection, and no
doubt others will see it differently. As you seem
willing to be responsible for this code, you should do
it in a way that makes you comfortable.
In short, go for it.
Tim
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Overdone rescue cleaning as part of buildworld?
On Mon, Jul 14, 2003 at 03:48:33PM -0700, Tim Kientzle wrote:
Gordon Tetlow wrote:
Attached is the patch. It basically makes CRUNCH_PROGS into a per
directory item and then only does a make obj on the per program
directory.
Hmmm I do have a philosophical quibble with your
approach: My original intent for this Makefile was
that the top part was rescue-specific and the bottom
part would be sufficiently generic to be used in other
crunchgen-based projects.
Your patches embed a certain amount of /rescue-specific knowledge
into the generic portion of the Makefile. For example,
+cd $(.CURDIR)/../../${D}/${P}
makes a prett strong assumption about the relative
locations of the crunchgen-using source directory
and its components.
That could probably be solved with a bit of make-foo. I'll see if I
can work that up. But I don't think it's going to be a huge priority.
-gordon
pgp0.pgp
Description: PGP signature
