From owner-freebsd-arch Sun Mar 4 11:41:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 5C6BF37B71A; Sun, 4 Mar 2001 11:41:56 -0800 (PST) (envelope-from nectar@nectar.com) Received: by gw.nectar.com (Postfix, from userid 1001) id D1C9D18C97; Sun, 4 Mar 2001 13:41:55 -0600 (CST) Date: Sun, 4 Mar 2001 13:41:55 -0600 From: "Jacques A. Vidrine" To: Cy Schubert - ITSD Open Systems Group Cc: "Brian F. Feldman" , Will Andrews , FreeBSD Architecture , bde@zeta.org.au, obrien@nuxi.com, nate@yogotech.com Subject: Re: ksh93 (was: Re: cvs commit: src/gnu/usr.bin/binutils/ar ...) Message-ID: <20010304134155.A72948@spawn.nectar.com> References: <20010303091958.A68223@spawn.nectar.com> <200103031650.f23GoWS12086@cwsys.cwsent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103031650.f23GoWS12086@cwsys.cwsent.com>; from Cy.Schubert@uumail.gov.bc.ca on Sat, Mar 03, 2001 at 08:50:13AM -0800 X-Url: http://www.nectar.com/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Mar 03, 2001 at 08:50:13AM -0800, Cy Schubert - ITSD Open Systems Group wrote: [snip] > If we are going to import ksh93 into the source tree, which I think is > a good thing, my vote is # 4 or # 4a. For something as critical as a > shell that is used virtually everywhere I think 100% backward > compatibility must be maintained and therefore we should keep ash in > FreeBSD. Boot scripts can reference #!/bin/ksh a short while after > notifying people on -stable (a plan would be nice). /bin/sh should be > renamed to /bin/ash with a /bin/sh hard link linked to it. Later we > can change the /bin/sh hard link to /bin/ksh, while keeping /bin/ash > for backward compatibility (if anyone has forgotten my point about > compatibility by now see my print example above). > > Hopefully I covered it all. Thanks for your summary. I would not support the import of any new shell unless it was (ultimately) for the replacement of /bin/tcsh or /bin/sh. We don't need "another" shell, but I do think we need a "better" shell. I don't expect builtins to be a significant issue. If someone is unfortunate enough to be using a binary with the name of a shell built-in in their scripts, and is not using a full path to that script, then the script would need to be modified. I don't think that in reality this will be much heartache. ksh is attractive because it is quite possibly the most standardized shell in existence, and at the same time is one of the better shell programming languages. Potentially it could make some uses of Perl during the build go away (David Korn says: ``For the most part ksh93 has the functionality of perl 5 and arguably a more readable syntax.'' I don't agree, but it isn't that far off). Cheers, -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 4 15:21:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from green.dyndns.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 28FCB37B719; Sun, 4 Mar 2001 15:20:58 -0800 (PST) (envelope-from green@FreeBSD.org) Received: from localhost (zw3v0y@localhost [127.0.0.1]) by green.dyndns.org (8.11.2/8.11.1) with ESMTP id f240FCV03680; Sat, 3 Mar 2001 19:15:12 -0500 (EST) (envelope-from green@FreeBSD.org) Message-Id: <200103040015.f240FCV03680@green.dyndns.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Bruce Evans Cc: "Brian F. Feldman" , "Jacques A. Vidrine" , Will Andrews , FreeBSD Architecture , obrien@nuxi.com, nate@yogotech.com Subject: Re: cvs commit: src/gnu/usr.bin/binutils/ar Makefile src/gnu/usr.bin/binutils/as Makefile.inc0 src/gnu/usr.bin/binutils/ld Makefile src/gnu/usr.bin/binutils/ranlib Makefile In-Reply-To: Message from Bruce Evans of "Sun, 04 Mar 2001 06:15:07 +1100." From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 03 Mar 2001 19:15:12 -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Bruce Evans wrote: > On Sat, 3 Mar 2001, Brian F. Feldman wrote: > > > "Jacques A. Vidrine" wrote: > > > On Thu, Mar 01, 2001 at 09:52:42AM -0500, Will Andrews wrote: > > > > I'd like to note this was added by green so he could use ksh with > > > > make. > > > > > > I think the better way to accomplish that is to replace /bin/sh with > > > ksh93 :-) But I'm not volunteering to update /etc/rc* at this time, > > > no matter how trivial the required modifications appear to be. > > > > The change was made so that I could gain a good 10% speed increase on make > > world by using a better shell. Using ksh93 as an option would be good, > > This seems unlikely. You are doing something wrong if shells take more > than 1% of the time for makeworld. You think so? Most of the overhead goes into the compiling phase, but a lot of it goes into the initial start-up of tons of shells and make(1)s. I'll test it again some time, but I know it certainly made it faster. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 4 15:21:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from green.dyndns.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 2D71F37B72A; Sun, 4 Mar 2001 15:21:14 -0800 (PST) (envelope-from green@FreeBSD.org) Received: from localhost (67p6o3@localhost [127.0.0.1]) by green.dyndns.org (8.11.2/8.11.1) with ESMTP id f23HB3V99101; Sat, 3 Mar 2001 12:11:08 -0500 (EST) (envelope-from green@FreeBSD.org) Message-Id: <200103031711.f23HB3V99101@green.dyndns.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: "Jacques A. Vidrine" Cc: "Brian F. Feldman" , Will Andrews , FreeBSD Architecture , bde@zeta.org.au, obrien@nuxi.com, nate@yogotech.com Subject: Re: cvs commit: src/gnu/usr.bin/binutils/ar Makefile src/gnu/usr.bin/binutils/as Makefile.inc0 src/gnu/usr.bin/binutils/ld Makefile src/gnu/usr.bin/binutils/ranlib Makefile In-Reply-To: Message from "Jacques A. Vidrine" of "Sat, 03 Mar 2001 09:19:58 CST." <20010303091958.A68223@spawn.nectar.com> From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 03 Mar 2001 12:11:03 -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Jacques A. Vidrine" wrote: > On Sat, Mar 03, 2001 at 01:04:04AM -0500, Brian F. Feldman wrote: > > As far as making rc compatible with ksh... ksh is a _super_set of the POSIX > > shell, not a completely, totally new language. This means in all but the > > most esoteric cases, it will act exactly the same (or better, but compatibly > > so). > > I already tried dropping ksh93 into /bin/sh and booting with it. Two > issues came up immediately: the `local' command, and some business > with signal handlers (can't recall exact details at the moment). > I don't think these would be hard to fix, though. Well, local is a non-standard extension if I recall correctly. I'd expect, though, ksh93 to have aliased it to typedef. As far as signal handlers go, I'll see if I can find out what the problem is there. We shouldn't be writing our scripts to a "standard" of whatever is in our /bin/sh, but instead to what is portable. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 4 15:30:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.inka.de (quechua.inka.de [212.227.14.2]) by hub.freebsd.org (Postfix) with ESMTP id 0330937B719 for ; Sun, 4 Mar 2001 15:30:43 -0800 (PST) (envelope-from daemon@mips.inka.de) Received: from kemoauc.mips.inka.de (uucp@) by mail.inka.de with local-bsmtp id 14Zhxa-0007GX-01; Mon, 5 Mar 2001 00:30:42 +0100 Received: (from daemon@localhost) by kemoauc.mips.inka.de (8.11.2/8.11.1) id f24NSBL02700 for freebsd-arch@freebsd.org; Mon, 5 Mar 2001 00:28:11 +0100 (CET) (envelope-from daemon) From: naddy@mips.inka.de (Christian Weisgerber) Subject: Re: ksh93 Date: Sun, 4 Mar 2001 23:28:11 +0000 (UTC) Message-ID: <97uj2b$2k3$1@kemoauc.mips.inka.de> References: <20010303091958.A68223@spawn.nectar.com> <200103031650.f23GoWS12086@cwsys.cwsent.com> Originator: naddy@mips.inka.de (Christian Weisgerber) To: freebsd-arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Cy Schubert - ITSD Open Systems Group wrote: > I can see a problem with replacing ash with ksh. [...] I don't agree, but I don't want to discuss that level of detail yet. > If we are going to import ksh93 into the source tree, which I think is > a good thing, Considering the AT&T license, is this even an option? The actual license text is impenetrable for me, but here are some excerpts from : ... | 5. Can I modify the source and distribute it to someone else? | | Yes, but you need to package the modifications separately, usually as a | patch file. ... | 7. Can I give the original source package to someone else? | | You can, provided that the person you give it to has agreed to the | license. The person does not have to physically sign the license, but | they must affirmatively agree to the same license agreement. We have | enclosed this agreement with the package. ... There is also a termination clause. -- Christian "naddy" Weisgerber naddy@mips.inka.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 4 16:46:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 6C14237B718 for ; Sun, 4 Mar 2001 16:46:26 -0800 (PST) (envelope-from nectar@nectar.com) Received: from hamlet.nectar.com (hamlet.nectar.com [10.0.1.102]) by gw.nectar.com (Postfix) with ESMTP id 9D68218C97; Sun, 4 Mar 2001 18:46:25 -0600 (CST) Received: (from nectar@localhost) by hamlet.nectar.com (8.11.2/8.9.3) id f250kPu19239; Sun, 4 Mar 2001 18:46:25 -0600 (CST) (envelope-from nectar@spawn.nectar.com) Date: Sun, 4 Mar 2001 18:46:25 -0600 From: "Jacques A. Vidrine" To: Christian Weisgerber Cc: freebsd-arch@freebsd.org Subject: Re: ksh93 Message-ID: <20010304184625.A19202@hamlet.nectar.com> Mail-Followup-To: "Jacques A. Vidrine" , Christian Weisgerber , freebsd-arch@freebsd.org References: <20010303091958.A68223@spawn.nectar.com> <200103031650.f23GoWS12086@cwsys.cwsent.com> <97uj2b$2k3$1@kemoauc.mips.inka.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <97uj2b$2k3$1@kemoauc.mips.inka.de>; from naddy@mips.inka.de on Sun, Mar 04, 2001 at 11:28:11PM +0000 X-Url: http://www.nectar.com/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Mar 04, 2001 at 11:28:11PM +0000, Christian Weisgerber wrote: > Considering the AT&T license, is this even an option? The actual > license text is impenetrable for me, but here are some excerpts > from : I don't pretend to understand it, either. However, in a Slashdot interview, David Korn said: The primary drawback to ksh has been that it was proprietary. This has recently changed however. The new AT&T open source license allows ksh source and binaries to be shipped as part of the system and is now just beginning to start showing up in Linux systems; for example the latest slackware. The source or binary for over a dozen architectures can be downloaded from (http://www.research.att.com/sw/download). Hopefully other systems will start shipping ksh93 and start using this for /bin/sh as well. So although I don't understand the license, I think David's intent is pretty clear. Should we decide that importing ksh93 is worthwhile (as I think it would be), then I think it would be prudent to ask David or AT&T for a statement just to be on the safe side. > There is also a termination clause. That might be more trouble. Personally I don't think such clauses hold much water, but some reasonable people disagree. Cheers, -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 4 17:58:38 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-158.dsl.lsan03.pacbell.net [63.207.60.158]) by hub.freebsd.org (Postfix) with ESMTP id D9DE837B719 for ; Sun, 4 Mar 2001 17:58:30 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 56A1266B09; Sun, 4 Mar 2001 17:58:30 -0800 (PST) Date: Sun, 4 Mar 2001 17:58:29 -0800 From: Kris Kennaway To: arch@FreeBSD.org Subject: Using CPUTYPE in COPTFLAGS Message-ID: <20010304175829.A45353@mollari.cthul.hu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Okay, here's the next step in the CPUTYPE integration: adding it to COPTFLAGS automatically. I also updated the default COPTFLAGS value to "-O -pipe" from "-O" to match the documentation and because it's just better. I would have liked to get this in to 4.3, but that's probably not going to happen because the changes need public airing first. Comments welcome. Kris Index: etc/defaults/make.conf =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /mnt/ncvs/src/etc/defaults/make.conf,v retrieving revision 1.148 diff -u -r1.148 make.conf --- etc/defaults/make.conf 2001/03/04 03:14:27 1.148 +++ etc/defaults/make.conf 2001/03/05 01:28:09 @@ -29,6 +29,7 @@ # #CPUTYPE=3Di686 #NO_CPU_CFLAGS=3D true # Don't add -march=3D to CFLAGS automatically +#NO_CPU_COPTFLAGS=3Dtrue # Don't add -march=3D to COPTFLAGS automatic= ally # # CFLAGS controls the compiler settings used when compiling C code. # Note that optimization settings above -O (-O2, ...) are not recommended Index: share/mk/bsd.cpu.mk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /mnt/ncvs/src/share/mk/bsd.cpu.mk,v retrieving revision 1.2 diff -u -r1.2 bsd.cpu.mk --- share/mk/bsd.cpu.mk 2001/02/27 11:21:47 1.2 +++ share/mk/bsd.cpu.mk 2001/03/05 01:50:44 @@ -28,46 +28,52 @@ # after /etc/make.conf so it can react to the local value of CPUTYPE # defined therein. =20 -.if !defined(NO_CPU_CFLAGS) +.if !defined(NO_CPU_CFLAGS) || !defined(NO_CPU_COPTFLAGS) . if ${MACHINE_ARCH} =3D=3D "i386" . if ${CPUTYPE} =3D=3D "k7" -CFLAGS +=3D -march=3Dk6 # gcc doesn't support athlon yet, but it will +_CFLAGS =3D -march=3Dk6 # gcc doesn't support athlon yet, but it will . elif ${CPUTYPE} =3D=3D "k6-2" -CFLAGS +=3D -march=3Dk6 +_CFLAGS =3D -march=3Dk6 . elif ${CPUTYPE} =3D=3D "k6" -CFLAGS +=3D -march=3Dk6 +_CFLAGS =3D -march=3Dk6 . elif ${CPUTYPE} =3D=3D "k5" -CFLAGS +=3D -march=3Dpentium +_CFLAGS =3D -march=3Dpentium . elif ${CPUTYPE} =3D=3D "p4" -CFLAGS +=3D -march=3Dpentiumpro +_CFLAGS =3D -march=3Dpentiumpro . elif ${CPUTYPE} =3D=3D "p3" -CFLAGS +=3D -march=3Dpentiumpro +_CFLAGS =3D -march=3Dpentiumpro . elif ${CPUTYPE} =3D=3D "p2" -CFLAGS +=3D -march=3Dpentiumpro +_CFLAGS =3D -march=3Dpentiumpro . elif ${CPUTYPE} =3D=3D "i686" -CFLAGS +=3D -march=3Dpentiumpro +_CFLAGS =3D -march=3Dpentiumpro . elif ${CPUTYPE} =3D=3D "i586/mmx" -CFLAGS +=3D -march=3Dpentium +_CFLAGS =3D -march=3Dpentium . elif ${CPUTYPE} =3D=3D "i586" -CFLAGS +=3D -march=3Dpentium +_CFLAGS =3D -march=3Dpentium . elif ${CPUTYPE} =3D=3D "i486" -CFLAGS +=3D -m486 +_CFLAGS =3D -m486 . endif . elif ${MACHINE_ARCH} =3D=3D "alpha" . if ${CPUTYPE} =3D=3D "ev6" -CFLAGS +=3D -mcpu=3Dev6 +_CFLAGS =3D -mcpu=3Dev6 . elif ${CPUTYPE} =3D=3D "pca56" -CFLAGS +=3D -mcpu=3Dpca56 +_CFLAGS =3D -mcpu=3Dpca56 . elif ${CPUTYPE} =3D=3D "ev56" -CFLAGS +=3D -mcpu=3Dev56 +_CFLAGS =3D -mcpu=3Dev56 . elif ${CPUTYPE} =3D=3D "ev5" -CFLAGS +=3D -mcpu=3Dev5 +_CFLAGS =3D -mcpu=3Dev5 . elif ${CPUTYPE} =3D=3D "ev45" -CFLAGS +=3D -mcpu=3Dev4 # No -mcpu=3Dev45 for gcc +_CFLAGS =3D -mcpu=3Dev4 # No -mcpu=3Dev45 for gcc . elif ${CPUTYPE} =3D=3D "ev4" -CFLAGS +=3D -mcpu=3Dev4 +_CFLAGS =3D -mcpu=3Dev4 . endif . endif +.endif + +# NB: COPTFLAGS is handled in /usr/src/sys/conf/Makefile. + +.if !defined(NO_CPU_CFLAGS) +CFLAGS +=3D ${_CFLAGS} .endif =20 # Set up the list of CPU features based on the CPU type. This is an Index: sys/conf/Makefile.alpha =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /mnt/ncvs/src/sys/conf/Makefile.alpha,v retrieving revision 1.92 diff -u -r1.92 Makefile.alpha --- sys/conf/Makefile.alpha 2001/02/25 07:51:18 1.92 +++ sys/conf/Makefile.alpha 2001/03/05 01:54:56 @@ -37,7 +37,10 @@ SIZE?=3D size OBJCOPY?=3D objcopy =20 -COPTFLAGS?=3D-O +COPTFLAGS?=3D-O -pipe +.if !defined(NO_CPU_COPTFLAGS) +COPTFLAGS+=3D ${_CFLAGS} +.endif INCLUDES=3D -nostdinc -I- ${INCLMAGIC} -I. -I$S -I$S/dev # This hack is to allow kernel compiles to succeed on machines w/out srcdi= st .if exists($S/../include) Index: sys/conf/Makefile.i386 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /mnt/ncvs/src/sys/conf/Makefile.i386,v retrieving revision 1.225 diff -u -r1.225 Makefile.i386 --- sys/conf/Makefile.i386 2001/02/25 07:51:19 1.225 +++ sys/conf/Makefile.i386 2001/03/05 01:54:45 @@ -37,7 +37,10 @@ SIZE?=3D size OBJCOPY?=3D objcopy =20 -COPTFLAGS?=3D-O +COPTFLAGS?=3D-O -pipe +.if !defined(NO_CPU_COPTFLAGS) +COPTFLAGS+=3D ${_CFLAGS} +.endif INCLUDES=3D -nostdinc -I- ${INCLMAGIC} -I. -I$S -I$S/dev # This hack is to allow kernel compiles to succeed on machines w/out srcdi= st .if exists($S/../include) Index: sys/conf/Makefile.ia64 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /mnt/ncvs/src/sys/conf/Makefile.ia64,v retrieving revision 1.14 diff -u -r1.14 Makefile.ia64 --- sys/conf/Makefile.ia64 2001/02/12 05:55:33 1.14 +++ sys/conf/Makefile.ia64 2001/03/05 01:55:18 @@ -47,7 +47,10 @@ SIZE?=3D size OBJCOPY?=3D objcopy =20 -COPTFLAGS?=3D-O +COPTFLAGS?=3D-O -pipe +.if !defined(NO_CPU_COPTFLAGS) +COPTFLAGS+=3D ${_CFLAGS} +.endif INCLUDES=3D -nostdinc -I- ${INCLMAGIC} -I. -I$S -I$S/dev # This hack is to allow kernel compiles to succeed on machines w/out srcdi= st .if exists($S/../include) Index: sys/conf/Makefile.pc98 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /mnt/ncvs/src/sys/conf/Makefile.pc98,v retrieving revision 1.124 diff -u -r1.124 Makefile.pc98 --- sys/conf/Makefile.pc98 2001/02/25 07:51:19 1.124 +++ sys/conf/Makefile.pc98 2001/03/05 01:55:08 @@ -39,7 +39,10 @@ SIZE?=3D size OBJCOPY?=3D objcopy =20 -COPTFLAGS?=3D-O +COPTFLAGS?=3D-O -pipe +.if !defined(NO_CPU_COPTFLAGS) +COPTFLAGS+=3D ${_CFLAGS} +.endif INCLUDES=3D -nostdinc -I- ${INCLMAGIC} -I. -I$S -I$S/dev # This hack is to allow kernel compiles to succeed on machines w/out srcdi= st .if exists($S/../include) --2oS5YaxWCcQjTEyO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6ovLFWry0BWjoQKURAna0AKC8tcLSHcrJDXQiT5H+VfqEO76BIQCfd7at ZsAaOwuDB9iB1pxXdghLPns= =ZNT7 -----END PGP SIGNATURE----- --2oS5YaxWCcQjTEyO-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 4 18: 9:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-158.dsl.lsan03.pacbell.net [63.207.60.158]) by hub.freebsd.org (Postfix) with ESMTP id DEAEE37B71A for ; Sun, 4 Mar 2001 18:09:11 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 92C9866B09; Sun, 4 Mar 2001 18:09:11 -0800 (PST) Date: Sun, 4 Mar 2001 18:09:11 -0800 From: Kris Kennaway To: Kris Kennaway Cc: arch@FreeBSD.org Subject: Re: Using CPUTYPE in COPTFLAGS Message-ID: <20010304180911.A45581@mollari.cthul.hu> References: <20010304175829.A45353@mollari.cthul.hu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="ibTvN161/egqYuK8" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010304175829.A45353@mollari.cthul.hu>; from kris@obsecurity.org on Sun, Mar 04, 2001 at 05:58:29PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --ibTvN161/egqYuK8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable David O'Brien suggested s/_CFLAGS/CPUCFLAGS/. Updated patch attached. Kris Index: etc/defaults/make.conf =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /mnt/ncvs/src/etc/defaults/make.conf,v retrieving revision 1.148 diff -u -r1.148 make.conf --- etc/defaults/make.conf 2001/03/04 03:14:27 1.148 +++ etc/defaults/make.conf 2001/03/05 01:28:09 @@ -29,6 +29,7 @@ # #CPUTYPE=3Di686 #NO_CPU_CFLAGS=3D true # Don't add -march=3D to CFLAGS automatically +#NO_CPU_COPTFLAGS=3Dtrue # Don't add -march=3D to COPTFLAGS automatic= ally # # CFLAGS controls the compiler settings used when compiling C code. # Note that optimization settings above -O (-O2, ...) are not recommended Index: share/mk/bsd.cpu.mk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /mnt/ncvs/src/share/mk/bsd.cpu.mk,v retrieving revision 1.2 diff -u -r1.2 bsd.cpu.mk --- share/mk/bsd.cpu.mk 2001/02/27 11:21:47 1.2 +++ share/mk/bsd.cpu.mk 2001/03/05 01:50:44 @@ -28,46 +28,52 @@ # after /etc/make.conf so it can react to the local value of CPUTYPE # defined therein. =20 -.if !defined(NO_CPU_CFLAGS) +.if !defined(NO_CPU_CFLAGS) || !defined(NO_CPU_COPTFLAGS) . if ${MACHINE_ARCH} =3D=3D "i386" . if ${CPUTYPE} =3D=3D "k7" -CFLAGS +=3D -march=3Dk6 # gcc doesn't support athlon yet, but it will +CPUCFLAGS =3D -march=3Dk6 # gcc doesn't support athlon yet, but it will . elif ${CPUTYPE} =3D=3D "k6-2" -CFLAGS +=3D -march=3Dk6 +CPUCFLAGS =3D -march=3Dk6 . elif ${CPUTYPE} =3D=3D "k6" -CFLAGS +=3D -march=3Dk6 +CPUCFLAGS =3D -march=3Dk6 . elif ${CPUTYPE} =3D=3D "k5" -CFLAGS +=3D -march=3Dpentium +CPUCFLAGS =3D -march=3Dpentium . elif ${CPUTYPE} =3D=3D "p4" -CFLAGS +=3D -march=3Dpentiumpro +CPUCFLAGS =3D -march=3Dpentiumpro . elif ${CPUTYPE} =3D=3D "p3" -CFLAGS +=3D -march=3Dpentiumpro +CPUCFLAGS =3D -march=3Dpentiumpro . elif ${CPUTYPE} =3D=3D "p2" -CFLAGS +=3D -march=3Dpentiumpro +CPUCFLAGS =3D -march=3Dpentiumpro . elif ${CPUTYPE} =3D=3D "i686" -CFLAGS +=3D -march=3Dpentiumpro +CPUCFLAGS =3D -march=3Dpentiumpro . elif ${CPUTYPE} =3D=3D "i586/mmx" -CFLAGS +=3D -march=3Dpentium +CPUCFLAGS =3D -march=3Dpentium . elif ${CPUTYPE} =3D=3D "i586" -CFLAGS +=3D -march=3Dpentium +CPUCFLAGS =3D -march=3Dpentium . elif ${CPUTYPE} =3D=3D "i486" -CFLAGS +=3D -m486 +CPUCFLAGS =3D -m486 . endif . elif ${MACHINE_ARCH} =3D=3D "alpha" . if ${CPUTYPE} =3D=3D "ev6" -CFLAGS +=3D -mcpu=3Dev6 +CPUCFLAGS =3D -mcpu=3Dev6 . elif ${CPUTYPE} =3D=3D "pca56" -CFLAGS +=3D -mcpu=3Dpca56 +CPUCFLAGS =3D -mcpu=3Dpca56 . elif ${CPUTYPE} =3D=3D "ev56" -CFLAGS +=3D -mcpu=3Dev56 +CPUCFLAGS =3D -mcpu=3Dev56 . elif ${CPUTYPE} =3D=3D "ev5" -CFLAGS +=3D -mcpu=3Dev5 +CPUCFLAGS =3D -mcpu=3Dev5 . elif ${CPUTYPE} =3D=3D "ev45" -CFLAGS +=3D -mcpu=3Dev4 # No -mcpu=3Dev45 for gcc +CPUCFLAGS =3D -mcpu=3Dev4 # No -mcpu=3Dev45 for gcc . elif ${CPUTYPE} =3D=3D "ev4" -CFLAGS +=3D -mcpu=3Dev4 +CPUCFLAGS =3D -mcpu=3Dev4 . endif . endif +.endif + +# NB: COPTFLAGS is handled in /usr/src/sys/conf/Makefile. + +.if !defined(NO_CPU_CFLAGS) +CFLAGS +=3D ${CPUCFLAGS} .endif =20 # Set up the list of CPU features based on the CPU type. This is an Index: sys/conf/Makefile.alpha =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /mnt/ncvs/src/sys/conf/Makefile.alpha,v retrieving revision 1.92 diff -u -r1.92 Makefile.alpha --- sys/conf/Makefile.alpha 2001/02/25 07:51:18 1.92 +++ sys/conf/Makefile.alpha 2001/03/05 01:54:56 @@ -37,7 +37,10 @@ SIZE?=3D size OBJCOPY?=3D objcopy =20 -COPTFLAGS?=3D-O +COPTFLAGS?=3D-O -pipe +.if !defined(NO_CPU_COPTFLAGS) +COPTFLAGS+=3D ${CPUCFLAGS} +.endif INCLUDES=3D -nostdinc -I- ${INCLMAGIC} -I. -I$S -I$S/dev # This hack is to allow kernel compiles to succeed on machines w/out srcdi= st .if exists($S/../include) Index: sys/conf/Makefile.i386 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /mnt/ncvs/src/sys/conf/Makefile.i386,v retrieving revision 1.225 diff -u -r1.225 Makefile.i386 --- sys/conf/Makefile.i386 2001/02/25 07:51:19 1.225 +++ sys/conf/Makefile.i386 2001/03/05 01:54:45 @@ -37,7 +37,10 @@ SIZE?=3D size OBJCOPY?=3D objcopy =20 -COPTFLAGS?=3D-O +COPTFLAGS?=3D-O -pipe +.if !defined(NO_CPU_COPTFLAGS) +COPTFLAGS+=3D ${CPUCFLAGS} +.endif INCLUDES=3D -nostdinc -I- ${INCLMAGIC} -I. -I$S -I$S/dev # This hack is to allow kernel compiles to succeed on machines w/out srcdi= st .if exists($S/../include) Index: sys/conf/Makefile.ia64 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /mnt/ncvs/src/sys/conf/Makefile.ia64,v retrieving revision 1.14 diff -u -r1.14 Makefile.ia64 --- sys/conf/Makefile.ia64 2001/02/12 05:55:33 1.14 +++ sys/conf/Makefile.ia64 2001/03/05 01:55:18 @@ -47,7 +47,10 @@ SIZE?=3D size OBJCOPY?=3D objcopy =20 -COPTFLAGS?=3D-O +COPTFLAGS?=3D-O -pipe +.if !defined(NO_CPU_COPTFLAGS) +COPTFLAGS+=3D ${CPUCFLAGS} +.endif INCLUDES=3D -nostdinc -I- ${INCLMAGIC} -I. -I$S -I$S/dev # This hack is to allow kernel compiles to succeed on machines w/out srcdi= st .if exists($S/../include) Index: sys/conf/Makefile.pc98 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /mnt/ncvs/src/sys/conf/Makefile.pc98,v retrieving revision 1.124 diff -u -r1.124 Makefile.pc98 --- sys/conf/Makefile.pc98 2001/02/25 07:51:19 1.124 +++ sys/conf/Makefile.pc98 2001/03/05 01:55:08 @@ -39,7 +39,10 @@ SIZE?=3D size OBJCOPY?=3D objcopy =20 -COPTFLAGS?=3D-O +COPTFLAGS?=3D-O -pipe +.if !defined(NO_CPU_COPTFLAGS) +COPTFLAGS+=3D ${CPUCFLAGS} +.endif INCLUDES=3D -nostdinc -I- ${INCLMAGIC} -I. -I$S -I$S/dev # This hack is to allow kernel compiles to succeed on machines w/out srcdi= st .if exists($S/../include) --ibTvN161/egqYuK8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6ovVGWry0BWjoQKURAinnAKDsvyjAe3Ou6jlhKU4Y5T109BTfywCeNpPT iFmeqb//nilOXlshdMnE36s= =O2dD -----END PGP SIGNATURE----- --ibTvN161/egqYuK8-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 4 21:29:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 7F2DE37B71C for ; Sun, 4 Mar 2001 21:29:27 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f255T8q33046; Sun, 4 Mar 2001 21:29:08 -0800 (PST) (envelope-from dillon) Date: Sun, 4 Mar 2001 21:29:08 -0800 (PST) From: Matt Dillon Message-Id: <200103050529.f255T8q33046@earth.backplane.com> To: Kris Kennaway Cc: arch@FreeBSD.ORG Subject: Re: Using CPUTYPE in COPTFLAGS References: <20010304175829.A45353@mollari.cthul.hu> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Okay, here's the next step in the CPUTYPE integration: adding it to :COPTFLAGS automatically. I also updated the default COPTFLAGS value :to "-O -pipe" from "-O" to match the documentation and because it's :just better. I would have liked to get this in to 4.3, but that's :probably not going to happen because the changes need public airing :first. : :Comments welcome. : :Kris The last time -pipe was mentioned there was a whole hullabaloo about not being able to compile on low-memory systems, but I personally am all for turning it on by default because it will make a big difference for 'most' people. Besides, even people w/ low-memory machines will have swap (or they are completely bonkers), and even though they'll bog down a bit compiling the GCC and PERL subsystems it will still go a whole lot faster compiling most everything else. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 5 1:27: 2 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-158.dsl.lsan03.pacbell.net [63.207.60.158]) by hub.freebsd.org (Postfix) with ESMTP id 4150B37B718 for ; Mon, 5 Mar 2001 01:26:58 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 62E9666E79; Mon, 5 Mar 2001 01:26:56 -0800 (PST) Date: Mon, 5 Mar 2001 01:26:56 -0800 From: Kris Kennaway To: Andrea Campi Cc: arch@FreeBSD.org Subject: Re: Using CPUTYPE in COPTFLAGS Message-ID: <20010305012655.A67721@mollari.cthul.hu> References: <20010304175829.A45353@mollari.cthul.hu> <20010304180911.A45581@mollari.cthul.hu> <20010305101156.A367@webcom.it> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="J/dobhs11T7y2rNN" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010305101156.A367@webcom.it>; from andrea@webcom.it on Mon, Mar 05, 2001 at 10:11:56AM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --J/dobhs11T7y2rNN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 05, 2001 at 10:11:56AM +0100, Andrea Campi wrote: > > Index: share/mk/bsd.cpu.mk > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > RCS file: /mnt/ncvs/src/share/mk/bsd.cpu.mk,v > > retrieving revision 1.2 > > diff -u -r1.2 bsd.cpu.mk > > --- share/mk/bsd.cpu.mk 2001/02/27 11:21:47 1.2 > > +++ share/mk/bsd.cpu.mk 2001/03/05 01:50:44 > > @@ -28,46 +28,52 @@ > > # after /etc/make.conf so it can react to the local value of CPUTYPE > > # defined therein. > > =20 > > -.if !defined(NO_CPU_CFLAGS) > > +.if !defined(NO_CPU_CFLAGS) || !defined(NO_CPU_COPTFLAGS) > > . if ${MACHINE_ARCH} =3D=3D "i386" > > . if ${CPUTYPE} =3D=3D "k7" > > -CFLAGS +=3D -march=3Dk6 # gcc doesn't support athlon yet, but it will > > +CPUCFLAGS =3D -march=3Dk6 # gcc doesn't support athlon yet, but it will > > . elif ${CPUTYPE} =3D=3D "k6-2" > > -CFLAGS +=3D -march=3Dk6 > > +CPUCFLAGS =3D -march=3Dk6 > > . elif ${CPUTYPE} =3D=3D "k6" >=20 > Are you sure this is what you really want? If I have >=20 > # NO_CPU_CFLAGS=3Dno > NO_CPU_COPTFLAGS=3Dyes >=20 > then the `if' evaluates to true and you end up with CPUCFLAGS defined. If= this > is intended, it's at least not very intuitive... Yes, but CPUCFLAGS is only used internally, and it will only be added to CFLAGS or COPTFLAGS if the NO_* switches aren't defined. Kris --J/dobhs11T7y2rNN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6o1vfWry0BWjoQKURAqiNAKC7xiaKGsoulMvisA6j6RKB8x2YZACdE8uR OqOzMI76msvzRWyOoRsehM0= =IwyI -----END PGP SIGNATURE----- --J/dobhs11T7y2rNN-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 5 1:36:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from acampi.inet.it (acampi.inet.it [213.92.4.194]) by hub.freebsd.org (Postfix) with SMTP id 6049337B718 for ; Mon, 5 Mar 2001 01:36:49 -0800 (PST) (envelope-from andrea@webcom.it) Received: (qmail 16674 invoked from network); 5 Mar 2001 10:35:35 -0000 Received: from brian.inet.it (HELO webcom.it) (213.92.4.195) by acampi.inet.it with SMTP; 5 Mar 2001 10:35:35 -0000 Received: (qmail 11514 invoked by uid 1000); 5 Mar 2001 09:33:25 -0000 Date: Mon, 5 Mar 2001 10:33:25 +0100 From: Andrea Campi To: Kris Kennaway Cc: arch@FreeBSD.org Subject: Re: Using CPUTYPE in COPTFLAGS Message-ID: <20010305103324.B367@webcom.it> References: <20010304175829.A45353@mollari.cthul.hu> <20010304180911.A45581@mollari.cthul.hu> <20010305101156.A367@webcom.it> <20010305012655.A67721@mollari.cthul.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010305012655.A67721@mollari.cthul.hu>; from kris@obsecurity.org on Mon, Mar 05, 2001 at 01:26:56AM -0800 X-Echelon: BND CIA NSA Mossad KGB MI6 IRA detonator nuclear assault strike Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Yes, but CPUCFLAGS is only used internally, and it will only be added > to CFLAGS or COPTFLAGS if the NO_* switches aren't defined. Of course, sorry - not enough caffeine... looking at the tree I missed the forest :-( BTW, that's why in the end I wrote you private email and didn't Cc the list ;-) Bye, Andrea -- Give a man a fish and you feed him for a day; teach him to use the Net and he won't bother you for weeks. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 5 6:31:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.inka.de (quechua.inka.de [212.227.14.2]) by hub.freebsd.org (Postfix) with ESMTP id D920637B719 for ; Mon, 5 Mar 2001 06:31:22 -0800 (PST) (envelope-from daemon@mips.inka.de) Received: from kemoauc.mips.inka.de (uucp@) by mail.inka.de with local-bsmtp id 14Zw1B-0007HW-01; Mon, 5 Mar 2001 15:31:21 +0100 Received: (from daemon@localhost) by kemoauc.mips.inka.de (8.11.3/8.11.1) id f25EEeE02358 for freebsd-arch@freebsd.org; Mon, 5 Mar 2001 15:14:40 +0100 (CET) (envelope-from daemon) From: naddy@mips.inka.de (Christian Weisgerber) Subject: Re: cvs commit: src/gnu/usr.bin/binutils/ar Makefile src/gnu/usr.bin/binutils/as Makefile.inc0 src/gnu/usr.bin/binutils/ld Makefile src/gnu/usr.bin/binutils/ranlib Makefile Date: Mon, 5 Mar 2001 14:14:40 +0000 (UTC) Message-ID: <98070g$1si$2@kemoauc.mips.inka.de> References: <200103031711.f23HB3V99101@green.dyndns.org> Originator: naddy@mips.inka.de (Christian Weisgerber) To: freebsd-arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Brian F. Feldman wrote: > Well, local is a non-standard extension if I recall correctly. I'd expect, > though, ksh93 to have aliased it to typedef. typeset ksh88 has, and so has pdksh. ksh93 doesn't. -- Christian "naddy" Weisgerber naddy@mips.inka.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 5 11:19:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from androcles.com (androcles.com [204.57.240.10]) by hub.freebsd.org (Postfix) with ESMTP id 7274D37B71C; Mon, 5 Mar 2001 11:19:17 -0800 (PST) (envelope-from alex@androcles.com) Received: (from dhh@localhost) by androcles.com (8.11.1/8.11.1) id f25JIi726684; Mon, 5 Mar 2001 11:18:44 -0800 (PST) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010304134155.A72948@spawn.nectar.com> Date: Mon, 05 Mar 2001 11:18:44 -0800 (PST) From: "Duane H. Hesser" To: "Jacques A. Vidrine" Subject: Re: ksh93 (was: Re: cvs commit: src/gnu/usr.bin/binutils/ar ...) Cc: obrien@nuxi.com, bde@zeta.org.au, FreeBSD Architecture , Will Andrews , "Brian F. Feldman" , Cy Schubert - ITSD Open Systems Group Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 04-Mar-01 Jacques A. Vidrine wrote: > On Sat, Mar 03, 2001 at 08:50:13AM -0800, Cy Schubert - ITSD Open Systems Group wrote: > [snip] >> If we are going to import ksh93 into the source tree, which I think is >> a good thing, my vote is # 4 or # 4a. For something as critical as a >> shell that is used virtually everywhere I think 100% backward >> compatibility must be maintained and therefore we should keep ash in >> FreeBSD. Boot scripts can reference #!/bin/ksh a short while after >> notifying people on -stable (a plan would be nice). /bin/sh should be >> renamed to /bin/ash with a /bin/sh hard link linked to it. Later we >> can change the /bin/sh hard link to /bin/ksh, while keeping /bin/ash >> for backward compatibility (if anyone has forgotten my point about >> compatibility by now see my print example above). >> >> Hopefully I covered it all. > > Thanks for your summary. I would not support the import of any new > shell unless it was (ultimately) for the replacement of /bin/tcsh or > /bin/sh. We don't need "another" shell, but I do think we need a > "better" shell. I'm a little sorry to hear you say this...I wonder if we could change your mind somehow. Ksh93 is a very nice shell, fast and powerful, but the incompatibilities with the ash-based /bin/sh are more extensive than just the "local vs typeset" problem (which is a sticky one) and the problem of name conflicts with builtins. Trap handling is somewhat different, as I recall, and there is a problem with variable scoping in functions in ksh93 unless a "special" syntax (incompatible with "ash") is used to declare them. There are other incompatibilities. I've attempted a partial description of incompatibilities between various "Bourne/Korn-style" shells (including pdksh, ksh93, ash, and various versions of bash and zsh) in a document written for my SHELLINIT distribution. You you can peruse the pertinent section at http://androcles.com/dist/shellinit/using/node56.html What you will find there is not comprehensive (and certainly not authoritative, by all means comment upon any inaccuracies you may find). Nonetheless, I expect that an attempt to replace "ash" with ksh93 would be a disaster so far as *script interpretation* is concerned. The ash-based shell currently known as "/bin/sh" appears to do a very good job of interpreting scripts written for the "real" Bourne shell. At the same time, ksh93 is a far more powerful shell for *interactive* use, and I believe that it would be a very good thing to provide a viable B/K-style shell in the base system. I also agree strongly with your suggestion (below) that ksh93 scripts could be profitably used to replace the non-Unix (perl) processes in the FreeBSD build procedure. None of this is intended to denegrate 'tcsh', either. It is a useful shell for interactive use (if it had functions, I'd probably use it) and should remain. So I guess I'm disagreeing with you mostly when you say 'We don't need "another" shell...'; I submit that FreeBSD could use a more powerful function shell for *interactive* use in the base system. I also submit that the extended facilities of ksh93 (discipline functions, name spaces, co-processes, etc.) will be available to the system in "#!/bin/ksh" scripts if it is in the base. That won't be true if ksh93 lives in "ports" rather than the base system. Summmary...I'd like to see: 1) Ksh 93 imported as "ksh" 2) the ash-based shell retained as "sh" 3) perl replaced in the build process (exec 3> /dev/controversy) It would be necessary, of course, to bikeshed the question of growth in the root filesystem for "minimal root" situations, but that could probably be handled by placing one of the shells in /usr/bin (or Pittsburg, or wherever). > > I don't expect builtins to be a significant issue. If someone is > unfortunate enough to be using a binary with the name of a shell > built-in in their scripts, and is not using a full path to that script, > then the script would need to be modified. I don't think that in > reality this will be much heartache. > > ksh is attractive because it is quite possibly the most standardized > shell in existence, and at the same time is one of the better shell > programming languages. Potentially it could make some uses of Perl > during the build go away (David Korn says: ``For the most part ksh93 has > the functionality of perl 5 and arguably a more readable syntax.'' I > don't agree, but it isn't that far off). > > Cheers, > -- > Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > -------------- Duane H. Hesser dhh@androcles.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 5 19:56: 4 2001 Delivered-To: freebsd-arch@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 3BD5A37B718 for ; Mon, 5 Mar 2001 19:55:59 -0800 (PST) (envelope-from gibbs@scsiguy.com) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.2/8.9.3) with ESMTP id f263tYO00777; Mon, 5 Mar 2001 20:55:35 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200103060355.f263tYO00777@aslan.scsiguy.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Kris Kennaway Cc: arch@FreeBSD.ORG Subject: Re: Using CPUTYPE in COPTFLAGS In-Reply-To: Your message of "Sun, 04 Mar 2001 17:58:29 PST." <20010304175829.A45353@mollari.cthul.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 05 Mar 2001 20:55:34 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Okay, here's the next step in the CPUTYPE integration: adding it to >COPTFLAGS automatically. I also updated the default COPTFLAGS value >to "-O -pipe" from "-O" to match the documentation and because it's >just better. I would have liked to get this in to 4.3, but that's >probably not going to happen because the changes need public airing >first. Can we please stop putting this stuff in make.conf? Put these as "makeoptions" in GENERIC or NOTES instead. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 6 11:59:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-158.dsl.lsan03.pacbell.net [63.207.60.158]) by hub.freebsd.org (Postfix) with ESMTP id 1974037B71A for ; Tue, 6 Mar 2001 11:59:10 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id A900266ED6; Tue, 6 Mar 2001 11:59:09 -0800 (PST) Date: Tue, 6 Mar 2001 11:59:09 -0800 From: Kris Kennaway To: "Justin T. Gibbs" Cc: arch@FreeBSD.ORG Subject: Re: Using CPUTYPE in COPTFLAGS Message-ID: <20010306115909.F60336@mollari.cthul.hu> References: <20010304175829.A45353@mollari.cthul.hu> <200103060355.f263tYO00777@aslan.scsiguy.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="J4XPiPrVK1ev6Sgr" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103060355.f263tYO00777@aslan.scsiguy.com>; from gibbs@scsiguy.com on Mon, Mar 05, 2001 at 08:55:34PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --J4XPiPrVK1ev6Sgr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 05, 2001 at 08:55:34PM -0700, Justin T. Gibbs wrote: > >Okay, here's the next step in the CPUTYPE integration: adding it to > >COPTFLAGS automatically. I also updated the default COPTFLAGS value > >to "-O -pipe" from "-O" to match the documentation and because it's > >just better. I would have liked to get this in to 4.3, but that's > >probably not going to happen because the changes need public airing > >first. >=20 > Can we please stop putting this stuff in make.conf? Put these as > "makeoptions" in GENERIC or NOTES instead. Sounds fine for -current, but -stable should stay as is. Kris --J4XPiPrVK1ev6Sgr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6pUGMWry0BWjoQKURApQjAKDgFSp9Gxx3bAyRsjCKrj6m/Ux6tACfQnC+ 9YxI6TrrQWLfMOuuxX9vxNM= =8HM7 -----END PGP SIGNATURE----- --J4XPiPrVK1ev6Sgr-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 7 3: 3:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id DC88137B71A; Wed, 7 Mar 2001 03:03:41 -0800 (PST) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id MAA12373; Wed, 7 Mar 2001 12:03:39 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: arch@freebsd.org Cc: dawes@freebsd.org Subject: DRI drivers in base system? From: Dag-Erling Smorgrav Date: 07 Mar 2001 12:03:39 +0100 Message-ID: Lines: 25 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG DRI support for FreeBSD in XFree86 4 is languishing, probably mainly due to being maintained outside the FreeBSD source tree, and therefore having all kinds of trouble keeping track of our fast-moving kernel. I am in the process of bringing the KLDs up to date with -CURRENT (using the sources in the 4.0.2 distribution - I haven't finished cvsupping the repo yet). I think I'm about 80% to 90% done - found some bugs in the process, too :) I won't belabour the obvious by explaining how having this code in the FreeBSD source tree would benefit both FreeBSD and XFree86. The total self-contained source for the KLDs (drm, gamma, mga, tdfx) weighs in at slightly less than 400k. The compiled KLDs range from 20k to 70k w/o debugging symbols. (note that this does not replace the 3dfx driver we already have - our 3dfx driver is for Glide, not for XFree86 - but there's a conflict because the 3dfx driver calls itself tdfx internally, which means the kernel can't differentiate between 3dfx and tdfx; this is easily fixed by changing the internal name of one or the other) DES (can't wait to see AlephOne run with 3D acceleration...) -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 7 3:22: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mobile.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id 3B82D37B71B; Wed, 7 Mar 2001 03:22:02 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id f27BLxh75773; Wed, 7 Mar 2001 03:21:59 -0800 (PST) (envelope-from peter@netplex.com.au) Message-Id: <200103071121.f27BLxh75773@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Dag-Erling Smorgrav Cc: arch@FreeBSD.ORG, dawes@FreeBSD.ORG Subject: Re: DRI drivers in base system? In-Reply-To: Date: Wed, 07 Mar 2001 03:21:59 -0800 From: Peter Wemm Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav wrote: > DRI support for FreeBSD in XFree86 4 is languishing, probably mainly > due to being maintained outside the FreeBSD source tree, and therefore > having all kinds of trouble keeping track of our fast-moving kernel. > > I am in the process of bringing the KLDs up to date with -CURRENT > (using the sources in the 4.0.2 distribution - I haven't finished > cvsupping the repo yet). I think I'm about 80% to 90% done - found > some bugs in the process, too :) For what it is worth, I would like this. Linux has its own DRI in the 2.4 kernel tree. (not that it is an excuse to do it, but pointing out that others see the wisdom in it too). I had almost suggested this myself on a couple of occasions. DRI is *not* XFree86 specific, FWIW. It is a generic 3D card / framebuffer management framework. It would be far better to use this than some sort of in-kernel ddx driver Xserver backend. Arbitary libGL apps can call it, in theory with or without the Xserver running [assuming the card is in graphics mode, of course.] I'm sure this is prime bikeshed material though. Oh well. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 7 3:34:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [64.0.106.45]) by hub.freebsd.org (Postfix) with ESMTP id 4161337B718; Wed, 7 Mar 2001 03:34:21 -0800 (PST) (envelope-from scanner@jurai.net) Received: from localhost (scanner@localhost) by sasami.jurai.net (8.9.3/8.8.7) with ESMTP id GAA10962; Wed, 7 Mar 2001 06:33:53 -0500 (EST) Date: Wed, 7 Mar 2001 06:33:52 -0500 (EST) From: To: Peter Wemm Cc: Dag-Erling Smorgrav , arch@FreeBSD.ORG, dawes@FreeBSD.ORG Subject: Re: DRI drivers in base system? In-Reply-To: <200103071121.f27BLxh75773@mobile.wemm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 7 Mar 2001, Peter Wemm wrote: > For what it is worth, I would like this. Linux has its own DRI in the 2.4 > kernel tree. (not that it is an excuse to do it, but pointing out that > others see the wisdom in it too). I had almost suggested this myself on a > couple of occasions. As peter said, I am sure this will be a big massive bikeshed. But I second the opinion of it going in. This is probably one of the top 3 questions I hear about FreeBSD. "Whats the status of DRI". "Do you guys have DRI yet?". "I wanted to install FreeBSD instead of foo Linux but I needed DRI for my q3". I think it's clearly something the populous wants. And DES has already done a large chunk of work on it. And if it is something that will accelerate its adoption into BSD land then I think it would be a mistake not to bring it in. ============================================================================= -Chris Watson (316) 326-3862 | FreeBSD Consultant, FreeBSD Geek Work: scanner@jurai.net | Open Systems Inc., Wellington, Kansas Home: scanner@deceptively.shady.org | http://open-systems.net ============================================================================= WINDOWS: "Where do you want to go today?" LINUX: "Where do you want to go tommorow?" BSD: "Are you guys coming or what?" ============================================================================= irc.openprojects.net #FreeBSD -Join the revolution! ICQ: 20016186 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 7 5:52:47 2001 Delivered-To: freebsd-arch@freebsd.org Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net [194.217.242.38]) by hub.freebsd.org (Postfix) with ESMTP id 74F0737B718; Wed, 7 Mar 2001 05:52:45 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1) id 14aeMu-000GYn-0A; Wed, 7 Mar 2001 13:52:44 +0000 Received: from herring (herring [10.0.0.2]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f27DpS729363; Wed, 7 Mar 2001 13:51:28 GMT (envelope-from dfr@nlsystems.com) Date: Wed, 7 Mar 2001 13:51:28 +0000 (GMT) From: Doug Rabson To: Dag-Erling Smorgrav Cc: , Subject: Re: DRI drivers in base system? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 7 Mar 2001, Dag-Erling Smorgrav wrote: > DRI support for FreeBSD in XFree86 4 is languishing, probably mainly > due to being maintained outside the FreeBSD source tree, and therefore > having all kinds of trouble keeping track of our fast-moving kernel. Its also partly because there wasn't enough code sharing between the Linux and BSD drivers and I didn't have enough time to spend keeping the BSD code up to date. Unfortunately, its rotted quite badly now. On the bright side, the linux drivers are being re-done in a much more modular style and hopefully should allow better BSD support in the long term. I don't have much of an opinion on where the code should live. I have commit privileges on the sourceforge DRI project anyway :-). -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 7 6:25:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from public.xfree86.org (xf86.isc.org [204.152.184.37]) by hub.freebsd.org (Postfix) with ESMTP id 0C3F137B719 for ; Wed, 7 Mar 2001 06:25:42 -0800 (PST) (envelope-from dawes@public.xfree86.org) Received: (from dawes@localhost) by public.xfree86.org (8.11.2/8.11.2) id f27EP6A02239; Wed, 7 Mar 2001 06:25:06 -0800 (PST) Date: Wed, 7 Mar 2001 09:25:06 -0500 From: David Dawes To: Doug Rabson Cc: Dag-Erling Smorgrav , arch@freebsd.org Subject: Re: DRI drivers in base system? Message-ID: <20010307092506.B3986@xfree86.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Mar 07, 2001 at 01:51:28PM +0000, Doug Rabson wrote: >On 7 Mar 2001, Dag-Erling Smorgrav wrote: > >> DRI support for FreeBSD in XFree86 4 is languishing, probably mainly >> due to being maintained outside the FreeBSD source tree, and therefore >> having all kinds of trouble keeping track of our fast-moving kernel. > >Its also partly because there wasn't enough code sharing between the Linux >and BSD drivers and I didn't have enough time to spend keeping the BSD >code up to date. Unfortunately, its rotted quite badly now. > >On the bright side, the linux drivers are being re-done in a much more >modular style and hopefully should allow better BSD support in the long >term. If the drivers are brought into the FreeBSD source tree, which is probably a good idea so that they can be distributed with the base system, it'd probably be best to start with the re-worked Linux drivers as a base. For this to work, someone would need to make sure that updates are fed in both directions. FWIW, the re-worked Linux drivers should be brought in the the XFree86 CVS trunk soon. David -- David Dawes Email: dawes@XFree86.org Founder/President, The XFree86 Project, Inc Phone: +1 510 687 6857 http://www.xfree86.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 7 10:17:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id EB95E37B719; Wed, 7 Mar 2001 10:17:25 -0800 (PST) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id TAA13841; Wed, 7 Mar 2001 19:17:23 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Doug Rabson Cc: , Subject: Re: DRI drivers in base system? References: From: Dag-Erling Smorgrav Date: 07 Mar 2001 19:17:23 +0100 In-Reply-To: Doug Rabson's message of "Wed, 7 Mar 2001 13:51:28 +0000 (GMT)" Message-ID: Lines: 27 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Doug Rabson writes: > Its also partly because there wasn't enough code sharing between the Linux > and BSD drivers and I didn't have enough time to spend keeping the BSD > code up to date. Unfortunately, its rotted quite badly now. Yep. I got MGA kind-of working, but it still panics on unload (the original code is very bad at cleaning up when you unload it), and I have problems with the DMA code. I can almost play AlephOne with my current code (it looks fine, but runs in kind of a stop-and-go fashion due to the DMA trouble) > On the bright side, the linux drivers are being re-done in a much more > modular style and hopefully should allow better BSD support in the long > term. That sounds good. The current code is quite poorly written - I might as well wait for the new Linux code to hit the tree and re-port it from scratch. > I don't have much of an opinion on where the code should live. I think src/sys/dev/dri/ is a good place. The code is under a BSD-like license, so no worries about sys/contrib or anything. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 7 13:59:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [207.154.226.10]) by hub.freebsd.org (Postfix) with ESMTP id 97A3E37B71A; Wed, 7 Mar 2001 13:59:02 -0800 (PST) (envelope-from billf@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1098) id C4B5181D19; Wed, 7 Mar 2001 15:58:51 -0600 (CST) Date: Wed, 7 Mar 2001 15:58:51 -0600 From: Bill Fumerola To: Dag-Erling Smorgrav Cc: Doug Rabson , arch@freebsd.org, dawes@freebsd.org Subject: Re: DRI drivers in base system? Message-ID: <20010307155851.E31752@elvis.mu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from des@ofug.org on Wed, Mar 07, 2001 at 07:17:23PM +0100 X-Operating-System: FreeBSD 4.2-FEARSOME-20010209 i386 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I think src/sys/dev/dri/ is a good place. The code is under a BSD-like > license, so no worries about sys/contrib or anything. sys/contrib's charter isn't "code of which we don't like the license", its for code that isn't native to our tree / is maintained by an external source. There is lots (file, tcpdump, less, etc) of BSD licensed software in src/contrib. DRI seems to be a candidate for sys/contrib. FWIW - I fully support it entering the tree. -- Bill Fumerola - security yahoo / Yahoo! inc. - fumerola@yahoo-inc.com / billf@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 7 18:26:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id BED1037B718 for ; Wed, 7 Mar 2001 18:26:26 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f282QG461637; Wed, 7 Mar 2001 18:26:16 -0800 (PST) (envelope-from obrien) Date: Wed, 7 Mar 2001 18:26:15 -0800 From: "David O'Brien" To: Dag-Erling Smorgrav Cc: arch@freebsd.org Subject: Re: DRI drivers in base system? Message-ID: <20010307182615.C61445@dragon.nuxi.com> Reply-To: arch@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from des@ofug.org on Wed, Mar 07, 2001 at 07:17:23PM +0100 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Mar 07, 2001 at 07:17:23PM +0100, Dag-Erling Smorgrav wrote: > I think src/sys/dev/dri/ is a good place. The code is under a BSD-like > license, so no worries about sys/contrib or anything. License has nothing to do with living in sys/contrib. If it is outside code that will be synced with the outside often (and it does sound like this is the case), it belongs in sys/contrib. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 7 20:17:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from lindyhop.integratus.com (adsl-64-164-192-197.dsl.snfc21.pacbell.net [64.164.192.197]) by hub.freebsd.org (Postfix) with ESMTP id A092C37B71B for ; Wed, 7 Mar 2001 20:17:46 -0800 (PST) (envelope-from jar@integratus.com) Received: from integratus.com (localhost [127.0.0.1]) by lindyhop.integratus.com (8.11.2/8.11.1) with ESMTP id f284ILo39531; Wed, 7 Mar 2001 20:18:24 -0800 (PST) (envelope-from jar@integratus.com) Message-ID: <3AA7080D.3A450101@integratus.com> Date: Wed, 07 Mar 2001 20:18:21 -0800 From: Jack Rusher Organization: http://www.integratus.com X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: arch@freebsd.org Subject: Re: Configuration management Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wes Peters wrote: > > There is an interesting opportunity here for somebody adventurous and > not afraid of hard work to set about converting FreeBSD (or any other > source-available operating system) to a test case for a new management > framework. Gathering up all the various configuration files or data > stores on a system and replacing them with, say, an XML representation > of the same data would be an interesting project. Providing legacy APIs, > like getpwent, etc., that used the XML format, as well as providing the > new API you would like to see would be a straightforward, if somewhat I've had this bug in my ear for awhile now. Unfortunately, there seem to be some pretty strong human engineering difficulties with this sort of work. Some time ago, I took a couple of days of my personal time and converted one of our products to use an XML configuration file format. The other engineers voted this down because they felt that the presence of tags in the files made them less readable than the positional configuration files (!) we had before. I can only imagine the grief we might receive if /etc/passwd were to wake up one morning in a format that differs from what people have come to expect. On the other hand, I would be willing to donate some time and effort, write some DTDs, write some format converters, & produce a stripped down bsdxml library to help experiment with this... if enough people actually expressed interest in the idea. I would hate to experience my previous disappointment on a larger scale after doing a lot more work. I would like to see this effort combined with the work being done on both SonOfSysinstall and the various network directory and configuration database projects that are happening in the world. The parsers for each of these things could come together into a single BSD license XML parser. I'm pretty sure BSDi & Apple would be interested in this work (perhaps to the point of helping out with some funding). Lastly, in an attempt to preempt the "why XML" bikeshed, XML gives you a language with which you may define other little languages within constraints that work especially well for this sort of problem domain. We could come up with our own meta language, but why? XML isn't the great savior the pundits would suggest, but it is a standardized technology that people understand, and it would work for this purpose. Comments? -- Jack Rusher, Senior Engineer | mailto:jar@integratus.com Integratus, Inc. | http://www.integratus.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 8 2: 8:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-158.dsl.lsan03.pacbell.net [63.207.60.158]) by hub.freebsd.org (Postfix) with ESMTP id A4E3037B71B for ; Thu, 8 Mar 2001 02:08:39 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 459FA66E1B; Thu, 8 Mar 2001 02:08:39 -0800 (PST) Date: Thu, 8 Mar 2001 02:08:39 -0800 From: Kris Kennaway To: arch@FreeBSD.org Subject: Breaking up make.conf Message-ID: <20010308020838.A67276@mollari.cthul.hu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I've been thinking a bit about how to break up the monolithic make.conf, which is starting to grow a bit unwieldy of late. The other advantage is that with a broken-up make.conf you can easily have e.g. different CFLAGS settings for src builds, port builds, and "manual" builds, and we reduce namespace pollution quite a bit. Moving port config options to a ports.conf is trivial, since all ports include ${PORTSDIR}/Mk/bsd.port.mk, so the .include can be done there. Moving world config options to a world.conf is a bit more tricky, because we need a way to tell whether we're building in src/ (and not just using 'make world'). The only way I can think to do this is to have everything include ../Makefile.inc back up to the root of the tree, which sets a BUILDING_WORLD variable that is used (in bsd.obj.mk and possibly other makefiles) to control the inclusion of /etc/world.conf and /etc/defaults/world.conf. It's a bit messy, but I can't seem to see any better way. We already have partial coverage from most of the second-level directories like bin/cat, etc, which are leaf nodes and include bin/Makefile.inc, so providing coverage to every directory containing a makefile which we descend into amounts to adding .include "../Makefile.inc" statements to Makefile.inc files which are missing them, and adding new Makefile.inc files where they are missing (I don't know yet whether this will have any other side-effects to the build process). By my calculations, this requires about 91 new Makefile.inc files to provide complete coverage. What do people think of the approach? Is there any easier way I'm missing? Is world.conf even desirable? Kris --FCuugMFkClbJLl1L Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6p1omWry0BWjoQKURApNeAKC3yzgyHH/qthMAXbPyQYxTeGS8/ACfRNdi Y8hAIo96DshLnhjOI8RVaVc= =24Y4 -----END PGP SIGNATURE----- --FCuugMFkClbJLl1L-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 8 2:36:54 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id CEAFF37B71A for ; Thu, 8 Mar 2001 02:36:50 -0800 (PST) (envelope-from roam@orbitel.bg) Received: (qmail 74133 invoked by uid 1000); 7 Mar 2001 11:43:31 -0000 Date: Wed, 7 Mar 2001 13:43:31 +0200 From: Peter Pentchev To: scanner@jurai.net Cc: Peter Wemm , Dag-Erling Smorgrav , arch@FreeBSD.ORG, dawes@FreeBSD.ORG Subject: Re: DRI drivers in base system? Message-ID: <20010307134330.C14620@ringworld.oblivion.bg> Mail-Followup-To: scanner@jurai.net, Peter Wemm , Dag-Erling Smorgrav , arch@FreeBSD.ORG, dawes@FreeBSD.ORG References: <200103071121.f27BLxh75773@mobile.wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from scanner@jurai.net on Wed, Mar 07, 2001 at 06:33:52AM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG FWIW, I absolutely agree with this, on both points - fielding FreeBSD+DRI questions, and DES's work. G'luck, Peter -- I am not the subject of this sentence. On Wed, Mar 07, 2001 at 06:33:52AM -0500, scanner@jurai.net wrote: > On Wed, 7 Mar 2001, Peter Wemm wrote: > > > For what it is worth, I would like this. Linux has its own DRI in the 2.4 > > kernel tree. (not that it is an excuse to do it, but pointing out that > > others see the wisdom in it too). I had almost suggested this myself on a > > couple of occasions. > > As peter said, I am sure this will be a big massive bikeshed. But I second > the opinion of it going in. This is probably one of the top 3 questions I > hear about FreeBSD. "Whats the status of DRI". "Do you guys have DRI > yet?". "I wanted to install FreeBSD instead of foo Linux but I needed DRI > for my q3". I think it's clearly something the populous wants. And DES has > already done a large chunk of work on it. And if it is something that will > accelerate its adoption into BSD land then I think it would be a mistake > not to bring it in. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 8 11:32:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 7D06937B718 for ; Thu, 8 Mar 2001 11:32:18 -0800 (PST) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id LAA26410; Thu, 8 Mar 2001 11:32:08 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <200103081932.LAA26410@gndrsh.dnsmgr.net> Subject: Re: Breaking up make.conf In-Reply-To: <20010308020838.A67276@mollari.cthul.hu> from Kris Kennaway at "Mar 8, 2001 02:08:39 am" To: kris@obsecurity.org (Kris Kennaway) Date: Thu, 8 Mar 2001 11:32:08 -0800 (PST) Cc: arch@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I've been thinking a bit about how to break up the monolithic > make.conf, which is starting to grow a bit unwieldy of late. The > other advantage is that with a broken-up make.conf you can easily have > e.g. different CFLAGS settings for src builds, port builds, and > "manual" builds, and we reduce namespace pollution quite a bit. > > Moving port config options to a ports.conf is trivial, since all ports > include ${PORTSDIR}/Mk/bsd.port.mk, so the .include can be done there. > > Moving world config options to a world.conf is a bit more tricky, > because we need a way to tell whether we're building in src/ (and not > just using 'make world'). The only way I can think to do this is to > have everything include ../Makefile.inc back up to the root of the > tree, which sets a BUILDING_WORLD variable that is used (in bsd.obj.mk > and possibly other makefiles) to control the inclusion of > /etc/world.conf and /etc/defaults/world.conf. It's a bit messy, but I > can't seem to see any better way. I've though about this on and off over the years, and would actually like to see src/make.conf or src/world.conf and remove the /etc dependecy. The major reason is that I often have more than one src tree on a build system and I have to screw around with /etc/make.conf if build environments are different. This can be implemented by a simple backtrace up the tree from any level looking for make.conf, terminating either when we find one, or when we hit /. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 8 13:24:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-158.dsl.lsan03.pacbell.net [63.207.60.158]) by hub.freebsd.org (Postfix) with ESMTP id 592F737B719 for ; Thu, 8 Mar 2001 13:24:39 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id D25BE66BC4; Thu, 8 Mar 2001 13:24:33 -0800 (PST) Date: Thu, 8 Mar 2001 13:24:33 -0800 From: Kris Kennaway To: "Rodney W. Grimes" Cc: Kris Kennaway , arch@FreeBSD.ORG Subject: Re: Breaking up make.conf Message-ID: <20010308132433.C88665@mollari.cthul.hu> References: <20010308020838.A67276@mollari.cthul.hu> <200103081932.LAA26410@gndrsh.dnsmgr.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="VywGB/WGlW4DM4P8" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103081932.LAA26410@gndrsh.dnsmgr.net>; from freebsd@gndrsh.dnsmgr.net on Thu, Mar 08, 2001 at 11:32:08AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --VywGB/WGlW4DM4P8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 08, 2001 at 11:32:08AM -0800, Rodney W. Grimes wrote: > I've though about this on and off over the years, and would actually > like to see src/make.conf or src/world.conf and remove the /etc > dependecy. The major reason is that I often have more than one > src tree on a build system and I have to screw around with /etc/make.conf > if build environments are different. >=20 > This can be implemented by a simple backtrace up the tree from any > level looking for make.conf, terminating either when we find one, > or when we hit /. In other words, pretty much exactly what I was talking about, except you put your world.conf in src/ where I put it in /etc :-) Kris --VywGB/WGlW4DM4P8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6p/iPWry0BWjoQKURApYJAJ9dplZZBjaw2ZocqdI9sQBQdvGIXwCfS6Hx bCxDd+/fWNCVhOxMly6lQC4= =Y4zA -----END PGP SIGNATURE----- --VywGB/WGlW4DM4P8-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 8 13:37:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 8691537B718 for ; Thu, 8 Mar 2001 13:37:27 -0800 (PST) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id NAA26735; Thu, 8 Mar 2001 13:37:24 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <200103082137.NAA26735@gndrsh.dnsmgr.net> Subject: Re: Breaking up make.conf In-Reply-To: <20010308132433.C88665@mollari.cthul.hu> from Kris Kennaway at "Mar 8, 2001 01:24:33 pm" To: kris@obsecurity.org (Kris Kennaway) Date: Thu, 8 Mar 2001 13:37:23 -0800 (PST) Cc: arch@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Thu, Mar 08, 2001 at 11:32:08AM -0800, Rodney W. Grimes wrote: > > I've though about this on and off over the years, and would actually > > like to see src/make.conf or src/world.conf and remove the /etc > > dependecy. The major reason is that I often have more than one > > src tree on a build system and I have to screw around with /etc/make.conf > > if build environments are different. > > > > This can be implemented by a simple backtrace up the tree from any > > level looking for make.conf, terminating either when we find one, > > or when we hit /. > > In other words, pretty much exactly what I was talking about, except > you put your world.conf in src/ where I put it in /etc :-) Pretty much. I think you can elimiate the need for the additional ../Makefile.inc using a .for loop just hunting for the make.conf, it just seems silly to me to need to add 91 one line Makefile.inc's to get this to work. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 8 16:35:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from shell.futuresouth.com (shell.futuresouth.com [198.78.58.28]) by hub.freebsd.org (Postfix) with ESMTP id 22E5537B71A for ; Thu, 8 Mar 2001 16:35:38 -0800 (PST) (envelope-from fullermd@futuresouth.com) Received: (from fullermd@localhost) by shell.futuresouth.com (8.11.1/8.11.1) id f290Z8f19264; Thu, 8 Mar 2001 18:35:08 -0600 (CST) Date: Thu, 8 Mar 2001 18:35:08 -0600 From: "Matthew D. Fuller" To: Kris Kennaway Cc: "Rodney W. Grimes" , arch@FreeBSD.ORG Subject: Re: Breaking up make.conf Message-ID: <20010308183508.E15971@futuresouth.com> References: <20010308020838.A67276@mollari.cthul.hu> <200103081932.LAA26410@gndrsh.dnsmgr.net> <20010308132433.C88665@mollari.cthul.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010308132433.C88665@mollari.cthul.hu>; from kris@obsecurity.org on Thu, Mar 08, 2001 at 01:24:33PM -0800 X-OS: FreeBSD Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Mar 08, 2001 at 01:24:33PM -0800, a little birdie told me that Kris Kennaway remarked > > In other words, pretty much exactly what I was talking about, except > you put your world.conf in src/ where I put it in /etc :-) Putting something like that in src/ seems a bit dangerous. For one thing, it'd be kinda subject to cvs[up] updates, which can totally screw up whatever you have in there. And then there are those of us who avoid any 'non-clean src/' problems by newfs'ing /usr/src and /usr/obj between builds and doing a fresh cvs co. I'd think we could probably come up with some sort of solution that would avoid those little gotchas... -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Unix Systems Administrator | fullermd@futuresouth.com Specializing in FreeBSD | http://www.over-yonder.net/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 8 17:12:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id 4496D37B718 for ; Thu, 8 Mar 2001 17:12:35 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.9.3/8.9.3) with ESMTP id UAA47344; Thu, 8 Mar 2001 20:12:28 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <200103081932.LAA26410@gndrsh.dnsmgr.net> References: <200103081932.LAA26410@gndrsh.dnsmgr.net> Date: Thu, 8 Mar 2001 20:12:27 -0500 To: "Rodney W. Grimes" , kris@obsecurity.org (Kris Kennaway) From: Garance A Drosihn Subject: Re: Breaking up make.conf Cc: arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 11:32 AM -0800 3/8/01, Rodney W. Grimes wrote: > > I've been thinking a bit about how to break up the monolithic > > make.conf, which is starting to grow a bit unwieldy of late. > > > > Moving world config options to a world.conf is a bit more > > tricky [...]. The only way I can think to do this is to > > have everything include ../Makefile.inc back up to the > > root of the tree, which sets a BUILDING_WORLD variable that > > is used to control the inclusion of /etc/world.conf and > > /etc/defaults/world.conf. It's a bit messy, but I can't > > seem to see any better way. > >I've though about this on and off over the years, and would actually >like to see src/make.conf or src/world.conf and remove the /etc >dependecy. The major reason is that I often have more than one >src tree on a build system and I have to screw around with >/etc/make.conf if build environments are different. I like the idea of breaking out the make-options which are specific to /usr/src to their own file. I do think it is worthwhile to keep the check for /etc/make.conf, so the user can set options which really do apply to any 'make' (such as 'CFLAGS= -pipe', which is appropriate for anything compiled on my machine...). How about having the final /usr/src/Makefile.inc define the actual files which should be included by bsd.obj.mk or other makefiles? The standard version would define /etc/world.conf and /etc/defaults/world.conf, because I think do it's best that all these make-options are specified in /etc (by default), just as they currently are. But if that Makefile.inc defines the specific filenames, we would also have the ability to easily handle situations such as Rodney described. In a later message, Rodney also mentioned: >Pretty much. I think you can elimiate the need for the >additional ../Makefile.inc using a .for loop just hunting >for the make.conf, it just seems silly to me to need to add >91 one line Makefile.inc's to get this to work. I would rather this be done by explicit includes, instead of a magic search down the current path trying to find a magically-named file. If I duplicate some branch of /usr/src into my own home directory, then I want an explicit error if it isn't going to pick up some file that it would have picked up if compiled in /usr/src. I suspect we can afford the 91 extra files... -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 8 18:42: 4 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id B108E37B718 for ; Thu, 8 Mar 2001 18:42:01 -0800 (PST) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id SAA27525; Thu, 8 Mar 2001 18:41:52 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <200103090241.SAA27525@gndrsh.dnsmgr.net> Subject: Re: Breaking up make.conf In-Reply-To: <20010308183508.E15971@futuresouth.com> from "Matthew D. Fuller" at "Mar 8, 2001 06:35:08 pm" To: fullermd@futuresouth.com (Matthew D. Fuller) Date: Thu, 8 Mar 2001 18:41:52 -0800 (PST) Cc: kris@obsecurity.org (Kris Kennaway), arch@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Thu, Mar 08, 2001 at 01:24:33PM -0800, a little birdie told me > that Kris Kennaway remarked > > > > In other words, pretty much exactly what I was talking about, except > > you put your world.conf in src/ where I put it in /etc :-) > > Putting something like that in src/ seems a bit dangerous. > For one thing, it'd be kinda subject to cvs[up] updates, which can > totally screw up whatever you have in there. And then there are those of > us who avoid any 'non-clean src/' problems by newfs'ing /usr/src and > /usr/obj between builds and doing a fresh cvs co. I'd think we could > probably come up with some sort of solution that would avoid those little > gotchas... There would never be a src/make.conf in the repository, perhaps a src/make.conf.defaults, but never src/make.conf. My pet peeve is that /etc/make.conf is global and affects all src trees on systems, but src trees may have quite different needs. IIRC bde shares this view. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 8 18:45:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 6FD5A37B718 for ; Thu, 8 Mar 2001 18:45:11 -0800 (PST) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id SAA27552; Thu, 8 Mar 2001 18:45:04 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <200103090245.SAA27552@gndrsh.dnsmgr.net> Subject: Re: Breaking up make.conf In-Reply-To: <20010308183508.E15971@futuresouth.com> from "Matthew D. Fuller" at "Mar 8, 2001 06:35:08 pm" To: fullermd@futuresouth.com (Matthew D. Fuller) Date: Thu, 8 Mar 2001 18:45:04 -0800 (PST) Cc: kris@obsecurity.org (Kris Kennaway), arch@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Thu, Mar 08, 2001 at 01:24:33PM -0800, a little birdie told me > that Kris Kennaway remarked > > > > In other words, pretty much exactly what I was talking about, except > > you put your world.conf in src/ where I put it in /etc :-) > > Putting something like that in src/ seems a bit dangerous. > For one thing, it'd be kinda subject to cvs[up] updates, which can > totally screw up whatever you have in there. And then there are those of > us who avoid any 'non-clean src/' problems by newfs'ing /usr/src and > /usr/obj between builds and doing a fresh cvs co. I'd think we could > probably come up with some sort of solution that would avoid those little > gotchas... Ooppss.. forgot to mention the solution to your newfs /usr/src, simply place your site specific make.conf at /usr. Like I said in the original, backtrack until make.conf is found, or you hit /. Or if you like you can always ln -s /etc/make.conf /usr/src/make.conf after your cvs co. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 8 19:38:11 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id A49CE37B718 for ; Thu, 8 Mar 2001 19:38:07 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f293bFA45745; Thu, 8 Mar 2001 19:37:15 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200103082137.NAA26735@gndrsh.dnsmgr.net> Date: Thu, 08 Mar 2001 19:37:09 -0800 (PST) From: John Baldwin To: "Rodney W. Grimes" Subject: Re: Breaking up make.conf Cc: arch@FreeBSD.org, (Kris Kennaway) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 08-Mar-01 Rodney W. Grimes wrote: >> On Thu, Mar 08, 2001 at 11:32:08AM -0800, Rodney W. Grimes wrote: >> > I've though about this on and off over the years, and would actually >> > like to see src/make.conf or src/world.conf and remove the /etc >> > dependecy. The major reason is that I often have more than one >> > src tree on a build system and I have to screw around with /etc/make.conf >> > if build environments are different. >> > >> > This can be implemented by a simple backtrace up the tree from any >> > level looking for make.conf, terminating either when we find one, >> > or when we hit /. >> >> In other words, pretty much exactly what I was talking about, except >> you put your world.conf in src/ where I put it in /etc :-) > > Pretty much. I think you can elimiate the need for the additional > ../Makefile.inc using a .for loop just hunting for the make.conf, > it just seems silly to me to need to add 91 one line Makefile.inc's > to get this to work. What if I want to use /etc/release.conf for clean release builds and /etc/currentworld.conf for current, etc.? If it's a tweakable variable name in /etc/make.conf (or overridable on the command line to make buildworld of course) then the ../Makefile.inc hack will allow me to stick this file anywhere with any name, rather than forcing it to be in the path of the source tree. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 8 19:52:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id E1BE837B718 for ; Thu, 8 Mar 2001 19:52:28 -0800 (PST) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (billy-club.village.org [10.0.0.3]) by rover.village.org (8.11.2/8.11.0) with ESMTP id f293qGX44754; Thu, 8 Mar 2001 20:52:19 -0700 (MST) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (localhost [127.0.0.1]) by billy-club.village.org (8.11.2/8.8.3) with ESMTP id f293nGs04577; Thu, 8 Mar 2001 20:49:16 -0700 (MST) Message-Id: <200103090349.f293nGs04577@billy-club.village.org> To: "Rodney W. Grimes" Subject: Re: Breaking up make.conf Cc: fullermd@futuresouth.com (Matthew D. Fuller), kris@obsecurity.org (Kris Kennaway), arch@FreeBSD.ORG In-reply-to: Your message of "Thu, 08 Mar 2001 18:41:52 PST." <200103090241.SAA27525@gndrsh.dnsmgr.net> References: <200103090241.SAA27525@gndrsh.dnsmgr.net> Date: Thu, 08 Mar 2001 20:49:16 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : > Putting something like that in src/ seems a bit dangerous. I don't think it would be any more dangerous than having the things we have in src. In message <200103090241.SAA27525@gndrsh.dnsmgr.net> "Rodney W. Grimes" writes: : There would never be a src/make.conf in the repository, perhaps a : src/make.conf.defaults, but never src/make.conf. My pet peeve is that : /etc/make.conf is global and affects all src trees on systems, but src : trees may have quite different needs. IIRC bde shares this view. I share this view strongly. It would solve a whole class of problems. That class is variaions on the "my /etc/make.conf isn't the same as on the machine I builtworld on, so installworld fails." Of course including bsd.cpu.mk and bsd.own.mk from sys.mk is likely the wrong thing to do in the first place. It might be better to search ${.CURDIR}, ${.CURDIR}/.., etc for etc/defaults/make.conf (note no leading shash so it is relative to the dirs listed) and pull that in. You'll eventually hit / in which case you pull in /etc/defaults/make.conf. FreeBSD's etc/default/make.conf should be modified to do the same search except looking for etc/make.conf. We should have no etc/make.conf in the tree. People can edit that, or put it in /etc/make.conf as they see fit. Something like the following patch, included after my sig. Note, I'd also go for nuking bsd.own.mk and bsd.cpu.mk and moving them into etc/defaults/make.conf so we stop polluting the global make space with them. .for loops are hard to terminate in make, so I didn't try. Maybe setting __d equal to -- would be enough to effectively terminate the loop. Maybe hacking make to grok .for loop termination would be better. The efficiency freaks would likely want to write this as a series of if .exists .elif exists.... You likely could not do that with the for loop, however :-(. Warner Index: share/mk/sys.mk =================================================================== RCS file: /home/imp/FreeBSD/CVS/src/share/mk/sys.mk,v retrieving revision 1.50 diff -u -r1.50 sys.mk --- share/mk/sys.mk 2001/02/22 11:14:25 1.50 +++ share/mk/sys.mk 2001/03/09 03:43:58 @@ -236,20 +236,15 @@ .endif -.if exists(/etc/defaults/make.conf) -.include +__d := ${.CURDIR} +.for __i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 +.if exists(${__d}/etc/defaults/make.conf) +.include "${__d}/etc/defaults/make.conf" .endif +__d:=${__d}/.. +.endfor +.undef __d -.if exists(/etc/make.conf) -.include -.endif - .include - -.if exists(/etc/make.conf.local) -.error Error, original /etc/make.conf should be moved to the /etc/defaults/ directory and /etc/make.conf.local should be renamed to /etc/make.conf. -.include -.endif - .include Index: etc/defaults/make.conf =================================================================== RCS file: /home/imp/FreeBSD/CVS/src/etc/defaults/make.conf,v retrieving revision 1.147 diff -u -r1.147 make.conf --- etc/defaults/make.conf 2001/02/27 11:21:47 1.147 +++ etc/defaults/make.conf 2001/03/09 03:44:11 @@ -366,3 +366,11 @@ #SENDMAIL_LDFLAGS= #SENDMAIL_LDADD= #SENDMAIL_DPADD= +__d := ${.CURDIR} +.for __i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +.if exists(${__d}/etc/make.conf) +.include "${__d}/etc/make.conf" +.endif +__d:=${__d}/.. +.endfor +.undef __d To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 8 19:54:32 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 9A55137B71A for ; Thu, 8 Mar 2001 19:54:29 -0800 (PST) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (billy-club.village.org [10.0.0.3]) by rover.village.org (8.11.2/8.11.0) with ESMTP id f293sSX44769; Thu, 8 Mar 2001 20:54:28 -0700 (MST) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (localhost [127.0.0.1]) by billy-club.village.org (8.11.2/8.8.3) with ESMTP id f293pRs04602; Thu, 8 Mar 2001 20:51:27 -0700 (MST) Message-Id: <200103090351.f293pRs04602@billy-club.village.org> To: Kris Kennaway Subject: Re: Breaking up make.conf Cc: arch@FreeBSD.ORG In-reply-to: Your message of "Thu, 08 Mar 2001 02:08:39 PST." <20010308020838.A67276@mollari.cthul.hu> References: <20010308020838.A67276@mollari.cthul.hu> Date: Thu, 08 Mar 2001 20:51:27 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010308020838.A67276@mollari.cthul.hu> Kris Kennaway writes: : Moving port config options to a ports.conf is trivial, since all ports : include ${PORTSDIR}/Mk/bsd.port.mk, so the .include can be done there. Yea. ports are easy :-). : Moving world config options to a world.conf is a bit more tricky, : because we need a way to tell whether we're building in src/ (and not : just using 'make world'). The only way I can think to do this is to : have everything include ../Makefile.inc back up to the root of the : tree, which sets a BUILDING_WORLD variable that is used (in bsd.obj.mk : and possibly other makefiles) to control the inclusion of : /etc/world.conf and /etc/defaults/world.conf. It's a bit messy, but I : can't seem to see any better way. Maybe there's a better way. See my other email on the topic. I don't think that Makefile.inc is going to be a good way to do this. : What do people think of the approach? Is there any easier way I'm : missing? Is world.conf even desirable? I think we should stop thinking of building the world as a special case. It should be part of a more general case. See my other mail for the patches that I'd like to see. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 8 19:58: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id D248937B718; Thu, 8 Mar 2001 19:57:58 -0800 (PST) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (billy-club.village.org [10.0.0.3]) by rover.village.org (8.11.2/8.11.0) with ESMTP id f293vtX44788; Thu, 8 Mar 2001 20:57:55 -0700 (MST) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (localhost [127.0.0.1]) by billy-club.village.org (8.11.2/8.8.3) with ESMTP id f293sss04615; Thu, 8 Mar 2001 20:54:54 -0700 (MST) Message-Id: <200103090354.f293sss04615@billy-club.village.org> To: John Baldwin Subject: Re: Breaking up make.conf Cc: "Rodney W. Grimes" , arch@FreeBSD.ORG, kris@obsecurity.org (Kris Kennaway) In-reply-to: Your message of "Thu, 08 Mar 2001 19:37:09 PST." References: Date: Thu, 08 Mar 2001 20:54:54 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message John Baldwin writes: : What if I want to use /etc/release.conf for clean release builds and : /etc/currentworld.conf for current, etc.? If it's a tweakable variable name in : /etc/make.conf (or overridable on the command line to make buildworld of : course) then the ../Makefile.inc hack will allow me to stick this file anywhere : with any name, rather than forcing it to be in the path of the source tree. That's why I like the idea of having a etc/make.conf in the tree and have it use that file. This file wouldn't be checked into CVS, but would be the user's responsibility to add to the tree in some fashion. Given the patches I posted, they have the nice property that if the user fails to do this, /etc/make.conf is picked up instead. That would allow you to easily manage these things. It would also allow you to have multiple -current and stable trees checked out under one root and use the same config file or different config files for them without having to remember to set special variables. As a side effect, we can reduce the name space polution problem that we have with bsd.own.mk and bsd.cpu.mk being included from /usr/share/mk/sys.mk. They have bugged me (and others) for a long time. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 8 20:14:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-158.dsl.lsan03.pacbell.net [63.207.60.158]) by hub.freebsd.org (Postfix) with ESMTP id 55B4E37B719 for ; Thu, 8 Mar 2001 20:14:23 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id C489966BCD; Thu, 8 Mar 2001 20:14:22 -0800 (PST) Date: Thu, 8 Mar 2001 20:14:22 -0800 From: Kris Kennaway To: Warner Losh Cc: "Rodney W. Grimes" , "Matthew D. Fuller" , Kris Kennaway , arch@FreeBSD.ORG Subject: Re: Breaking up make.conf Message-ID: <20010308201422.A94052@mollari.cthul.hu> References: <200103090241.SAA27525@gndrsh.dnsmgr.net> <200103090349.f293nGs04577@billy-club.village.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="3MwIy2ne0vdjdPXF" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103090349.f293nGs04577@billy-club.village.org>; from imp@village.org on Thu, Mar 08, 2001 at 08:49:16PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Mar 08, 2001 at 08:49:16PM -0700, Warner Losh wrote: > Of course including bsd.cpu.mk and bsd.own.mk from sys.mk is likely > the wrong thing to do in the first place. It might be better to > search ${.CURDIR}, ${.CURDIR}/.., etc for etc/defaults/make.conf (note > no leading shash so it is relative to the dirs listed) and pull that > in. You'll eventually hit / in which case you pull in > /etc/defaults/make.conf. FreeBSD's etc/default/make.conf should be > modified to do the same search except looking for etc/make.conf. We > should have no etc/make.conf in the tree. People can edit that, or > put it in /etc/make.conf as they see fit. All that searching sounds like it would slow things down given the number of times make runs during a make world. On the other hand, recursively including parent Makefile.incs until there are no more parents, and then pulling in a config file also adds more work. That also is a bit funky in that /usr/src/etc/defaults/make.conf controls default settings for /usr/src, but it is also installed as /etc/defaults/make.conf and applies to all makes, so it still has global scope. Perhaps you meant to say ./src.conf.defaults or something (i.e. there would be a /usr/src/src.conf.defaults in the repo which has all of the NO_* crap currently in make.conf, etc., and you can overrride this for any subtree of /usr/src by sticking a src.conf there. Anyway, the only real question here is whether to go for the iterative .for search, or a recursive include. Both can give the same behaviour, so it comes down to which is more efficient. > Something like the following patch, included after my sig. Note, I'd > also go for nuking bsd.own.mk and bsd.cpu.mk and moving them into > etc/defaults/make.conf so we stop polluting the global make space with > them. .for loops are hard to terminate in make, so I didn't try. You can't put bsd.cpu.mk in /etc/defaults/make.conf or I would have done this from the beginning. It has to be included AFTER /etc/make.conf, because thats where CPUTYPE is set. Kris --3MwIy2ne0vdjdPXF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6qFieWry0BWjoQKURAupCAJsF/BtsTzQBU4njABJ9yd9F560xCwCgoZuD bMIo8OWBiiwGmHDWCVOWtCI= =gwBJ -----END PGP SIGNATURE----- --3MwIy2ne0vdjdPXF-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 8 20:33:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 2761037B719 for ; Thu, 8 Mar 2001 20:33:40 -0800 (PST) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (billy-club.village.org [10.0.0.3]) by rover.village.org (8.11.2/8.11.0) with ESMTP id f294XcX44854; Thu, 8 Mar 2001 21:33:39 -0700 (MST) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (localhost [127.0.0.1]) by billy-club.village.org (8.11.2/8.8.3) with ESMTP id f294Ucs04824; Thu, 8 Mar 2001 21:30:38 -0700 (MST) Message-Id: <200103090430.f294Ucs04824@billy-club.village.org> To: Kris Kennaway Subject: Re: Breaking up make.conf Cc: "Rodney W. Grimes" , "Matthew D. Fuller" , arch@FreeBSD.ORG In-reply-to: Your message of "Thu, 08 Mar 2001 20:14:22 PST." <20010308201422.A94052@mollari.cthul.hu> References: <20010308201422.A94052@mollari.cthul.hu> <200103090241.SAA27525@gndrsh.dnsmgr.net> <200103090349.f293nGs04577@billy-club.village.org> Date: Thu, 08 Mar 2001 21:30:38 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010308201422.A94052@mollari.cthul.hu> Kris Kennaway writes: : All that searching sounds like it would slow things down given the : number of times make runs during a make world. On the other hand, : recursively including parent Makefile.incs until there are no more : parents, and then pulling in a config file also adds more work. I think it would be a wash. Also, recursively including the parents is going to need this same sort of searching because you can't just include ${.CURDIR}/../Makefile.inc, since ${.CURDIR} isn't where Makefile.inc lives, but where Makefile lives (trust me on this, I've tried it before and it blows up). We have makefiles at too many different levels in the tree for things to work right all the time (and these Makefile.incs are therefore interpreted in many different contexts and your ../../ in the .include recursive part mess things up, I've been down this path). : That also is a bit funky in that /usr/src/etc/defaults/make.conf : controls default settings for /usr/src, but it is also installed as : /etc/defaults/make.conf and applies to all makes, so it still has : global scope. That's not all that funky. It should be a simple file that really doesn't set anything anyway. More likely it should be called etc/defaults/make.allow-things-to-be-overridden-in-a-sane-way.cf since it really won't have any settings in it. If we want a freebsd specific one, we should have a freebsd specific one that we don't install. Actaully, I'd make a make.conf.freebsd and put the current contents of /etc/defaults/make.conf in that and have etc/defaults/make.conf just be the + lines from my patch below. : Perhaps you meant to say ./src.conf.defaults or something (i.e. there : would be a /usr/src/src.conf.defaults in the repo which has all of the : NO_* crap currently in make.conf, etc., and you can overrride this for : any subtree of /usr/src by sticking a src.conf there. No, I ment to say exactly what I said. I don't want to override things on a per tree basis. I think that's asking for trouble. I really did mean that I want to have the ability to have a tree of trees. I do that all the time. The tree is too intertwined to change options in the middle of it and expect it to work. We shouldn't give our users that much rope. : Anyway, the only real question here is whether to go for the iterative : .for search, or a recursive include. Both can give the same : behaviour, so it comes down to which is more efficient. You have to do the searching no matter what. : > Something like the following patch, included after my sig. Note, I'd : > also go for nuking bsd.own.mk and bsd.cpu.mk and moving them into : > etc/defaults/make.conf so we stop polluting the global make space with : > them. .for loops are hard to terminate in make, so I didn't try. : : You can't put bsd.cpu.mk in /etc/defaults/make.conf or I would have : done this from the beginning. It has to be included AFTER : /etc/make.conf, because thats where CPUTYPE is set. Yes, you can. Here's an updated version that eliminates things. Note, we can and should likely do something different than having every single possible option commented out in /etc/defaults/make.conf. I've not tried to address that in my patches. Also, we can have usr.bin/make install the /etc/defaults/make.conf that is just the + lines in the make.conf part of the patch below. That way it will be radically different than the one we have in src/etc/defaults/make.conf. We would then not install src/etc/defaults/make.conf. Alternatively, we could install it as /etc/defaults/make.conf.freebsd and add a .if defined(__freebsd_world) && .exists (/etc/defaults/make.conf.freebsd) .include "/etc/defaults/make.conf.freebsd" .endif to /etc/defaults/make.conf. /etc/defaults/make.conf.freebsd could then include /etc/make.conf.freebsd if it existed. Right now /etc/defaults/make.conf doesn't follow the same rules of including /etc/make.conf. It also doesn't define anything except BDEFLAGS. I really do want to see a generic mechanism in place. I don't want to see another set of hacks just for FreeBSD. If we have a generic mechanism in place, we can document it and other projects can use or not use it as they see fit. Warner Index: share/mk/sys.mk =================================================================== RCS file: /home/imp/FreeBSD/CVS/src/share/mk/sys.mk,v retrieving revision 1.50 diff -u -r1.50 sys.mk --- share/mk/sys.mk 2001/02/22 11:14:25 1.50 +++ share/mk/sys.mk 2001/03/09 04:22:49 @@ -236,20 +236,11 @@ .endif -.if exists(/etc/defaults/make.conf) -.include +__d := ${.CURDIR} +.for __i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +.if exists(${__d}/etc/defaults/make.conf) +.include "${__d}/etc/defaults/make.conf" .endif - -.if exists(/etc/make.conf) -.include -.endif - -.include - -.if exists(/etc/make.conf.local) -.error Error, original /etc/make.conf should be moved to the /etc/defaults/ directory and /etc/make.conf.local should be renamed to /etc/make.conf. -.include -.endif - - -.include +__d:=${__d}/.. +.endfor +.undef __d Index: etc/defaults/make.conf =================================================================== RCS file: /home/imp/FreeBSD/CVS/src/etc/defaults/make.conf,v retrieving revision 1.147 diff -u -r1.147 make.conf --- etc/defaults/make.conf 2001/02/27 11:21:47 1.147 +++ etc/defaults/make.conf 2001/03/09 04:23:06 @@ -366,3 +366,16 @@ #SENDMAIL_LDFLAGS= #SENDMAIL_LDADD= #SENDMAIL_DPADD= + +__d := ${.CURDIR} +.for __i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +.if exists(${__d}/etc/make.conf) +.include "${__d}/etc/make.conf" +.endif +__d:=${__d}/.. +.endfor +.undef __d + +.include + +.include To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 8 20:52:35 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 7045037B719 for ; Thu, 8 Mar 2001 20:52:32 -0800 (PST) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (billy-club.village.org [10.0.0.3]) by rover.village.org (8.11.2/8.11.0) with ESMTP id f294qVX44902; Thu, 8 Mar 2001 21:52:31 -0700 (MST) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (localhost [127.0.0.1]) by billy-club.village.org (8.11.2/8.8.3) with ESMTP id f294nUs06142; Thu, 8 Mar 2001 21:49:30 -0700 (MST) Message-Id: <200103090449.f294nUs06142@billy-club.village.org> Subject: Re: Breaking up make.conf Cc: Kris Kennaway , "Rodney W. Grimes" , "Matthew D. Fuller" , arch@FreeBSD.ORG In-reply-to: Your message of "Thu, 08 Mar 2001 21:30:38 MST." <200103090430.f294Ucs04824@billy-club.village.org> References: <200103090430.f294Ucs04824@billy-club.village.org> <20010308201422.A94052@mollari.cthul.hu> <200103090241.SAA27525@gndrsh.dnsmgr.net> <200103090349.f293nGs04577@billy-club.village.org> Date: Thu, 08 Mar 2001 21:49:30 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The previous patches are bogus and won't work. Make doesn't let you do __d:=1 __d:=${__d}2 Also, the previous patches don't include bsd.own.mk, which we depend on being included to define OBJFORMAT. So I backed that part of them out. Warner Index: share/mk/sys.mk =================================================================== RCS file: /home/imp/FreeBSD/CVS/src/share/mk/sys.mk,v retrieving revision 1.50 diff -u -r1.50 sys.mk --- share/mk/sys.mk 2001/02/22 11:14:25 1.50 +++ share/mk/sys.mk 2001/03/09 04:48:29 @@ -236,20 +236,16 @@ .endif -.if exists(/etc/defaults/make.conf) -.include +__d= +.for __i in .. ../.. ../../.. ../../../.. ../../../../.. ../../../../../.. \ + ../../../../../../.. ../../../../../../../.. ../../../../../../../../.. +.if exists(${__d}${.CURDIR}/${__i}/etc/defaults/make.conf) +.include "${__d}${.CURDIR}/${__i}/etc/defaults/make.conf" +__d:=-- .endif +.endfor +.undef __d -.if exists(/etc/make.conf) -.include -.endif - .include - -.if exists(/etc/make.conf.local) -.error Error, original /etc/make.conf should be moved to the /etc/defaults/ directory and /etc/make.conf.local should be renamed to /etc/make.conf. -.include -.endif - .include Index: etc/defaults/make.conf =================================================================== RCS file: /home/imp/FreeBSD/CVS/src/etc/defaults/make.conf,v retrieving revision 1.147 diff -u -r1.147 make.conf --- etc/defaults/make.conf 2001/02/27 11:21:47 1.147 +++ etc/defaults/make.conf 2001/03/09 04:49:19 @@ -366,3 +366,13 @@ #SENDMAIL_LDFLAGS= #SENDMAIL_LDADD= #SENDMAIL_DPADD= + +__d= +.for __i in .. ../.. ../../.. ../../../.. ../../../../.. ../../../../../.. \ + ../../../../../../.. ../../../../../../../.. ../../../../../../../../.. +.if exists(${__d}${.CURDIR}/${__i}/etc/make.conf) +.include "${__d}${.CURDIR}/${__i}/etc/make.conf" +__d:=-- +.endif +.endfor +.undef __d To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 8 21:18:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from onet2.cup.hp.com (onet2.cup.hp.com [15.255.208.3]) by hub.freebsd.org (Postfix) with ESMTP id 6F67437B718 for ; Thu, 8 Mar 2001 21:18:23 -0800 (PST) (envelope-from marcel@p1000180.nsr.hp.com) Received: from kayak.muffin.org (p1000180.nsr.hp.com [15.109.0.180]) by onet2.cup.hp.com (Postfix) with ESMTP id 4761518CA0; Thu, 8 Mar 2001 21:18:15 -0800 (PST) Received: from dhcp08.muffin.org (dhcp08.muffin.org [192.168.4.208]) by kayak.muffin.org (8.11.1/8.11.1) with ESMTP id f295IE272000; Thu, 8 Mar 2001 21:18:14 -0800 (PST) (envelope-from marcel@kayak.muffin.org) Received: (from marcel@localhost) by dhcp08.muffin.org (8.11.1/8.11.2) id f295N2Q01120; Thu, 8 Mar 2001 21:23:02 -0800 (PST) (envelope-from marcel) Date: Thu, 8 Mar 2001 21:23:01 -0800 From: Marcel Moolenaar To: Warner Losh Cc: Kris Kennaway , "Rodney W. Grimes" , "Matthew D. Fuller" , arch@FreeBSD.ORG Subject: Re: Breaking up make.conf Message-ID: <20010308212301.A879@dhcp08.muffin.org> Reply-To: marcel@cup.hp.com References: <20010308201422.A94052@mollari.cthul.hu> <200103090241.SAA27525@gndrsh.dnsmgr.net> <200103090349.f293nGs04577@billy-club.village.org> <20010308201422.A94052@mollari.cthul.hu> <200103090430.f294Ucs04824@billy-club.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103090430.f294Ucs04824@billy-club.village.org>; from imp@village.org on Thu, Mar 08, 2001 at 09:30:38PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Mar 08, 2001 at 09:30:38PM -0700, Warner Losh wrote: > I really do want to see a generic mechanism in place. I don't want to > see another set of hacks just for FreeBSD. If we have a generic > mechanism in place, we can document it and other projects can use or > not use it as they see fit. A generic solution for the make.conf problem can be the introduction of a variable I suddenly call MODE. This MODE variable, when set on the commandline triggers the inclusion of bsd.mode.${MODE}. Where to read this file from, can be a combination of system-wide, hardcoded defaults and the use of a variable I suddenly call MODEPATH. This mode file contains defaults for certain variables and thus controls how the software is built, whether this is world or something else is not important. For the ports collection, we can have MODE default to ports. Release builds can have MODE default to release. Kernel and module builds can have MODE default to kernel. To allow a flexible mechanism of overriding modes, so that this scheme can be used in the widest possible scenarios, all mode files found by MODEPATH are read. This works nicely if mode files use the conditional assignment by convention. For example, If I have MODEPATH=~/modes /etc/modes and build my software like make MODE=foo then ~/modes/bsd.mode.foo will be included before /etc/modes/bsd.mode.foo (if it exists) and thus allows per user tweaking of system defaults. In the various Makefile.inc files, we can append to MODEPATH so that we can have /usr/src (assuming that's the root of the FreeBSD tree) part of the MODEPATH. This allows per source tree tweaking of the system default (assuming that system drectories are appended to MODEPATH last). This scheme has the nice property of having a simple way to further enhance parallelism by making MODE part of the name of the object directory. Of course it should be possible to also set MACHINE_ARCH in the mode files as well, so that we can define a cross-build as: make MODE=alpha buildworld instead of make MACHINE_ARCH=alpha buildworld. I suggest we do not traverse source trees down to the root, to search for a make.conf or something equivalent. It's too unstable from an algorithmic point of view and may cause significant build overhead. Just my $0.02... -- Marcel Moolenaar mail: marcel@cup.hp.com / marcel@FreeBSD.org tel: (408) 447-4222 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 8 22:50:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 0D85C37B880 for ; Thu, 8 Mar 2001 22:50:29 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f296o1A49427; Thu, 8 Mar 2001 22:50:01 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200103090354.f293sss04615@billy-club.village.org> Date: Thu, 08 Mar 2001 22:49:42 -0800 (PST) From: John Baldwin To: Warner Losh Subject: Re: Breaking up make.conf Cc: (Kris Kennaway) , arch@FreeBSD.org, "Rodney W. Grimes" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 09-Mar-01 Warner Losh wrote: > In message John Baldwin writes: >: What if I want to use /etc/release.conf for clean release builds and >: /etc/currentworld.conf for current, etc.? If it's a tweakable variable name >: in >: /etc/make.conf (or overridable on the command line to make buildworld of >: course) then the ../Makefile.inc hack will allow me to stick this file >: anywhere >: with any name, rather than forcing it to be in the path of the source tree. > > That's why I like the idea of having a etc/make.conf in the tree and > have it use that file. This file wouldn't be checked into CVS, but > would be the user's responsibility to add to the tree in some > fashion. Given the patches I posted, they have the nice property that > if the user fails to do this, /etc/make.conf is picked up instead. I would prefer to be able to set a variable for its location so I can put it anywhwere, so as to be the most flexible. Requiring it to be higher up in the directory hierarchy at some point limits the places it can be put. > That would allow you to easily manage these things. It would also > allow you to have multiple -current and stable trees checked out under > one root and use the same config file or different config files for > them without having to remember to set special variables. Well, if you have a reasonable default, then the all-using-one-config-file case becomes very easy, because you just use the default name. You only set special variables if you want multiple config files. You could have WORLD_CONF ?= /etc/world.conf (or /etc/make/world.conf if you want a generic place for make configuration files to live) or some such. > As a side effect, we can reduce the name space polution problem that > we have with bsd.own.mk and bsd.cpu.mk being included from > /usr/share/mk/sys.mk. They have bugged me (and others) for a long > time. Yes, this would be nice. > Warner -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 8 23:22:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-158.dsl.lsan03.pacbell.net [63.207.60.158]) by hub.freebsd.org (Postfix) with ESMTP id 2C5AA37B719 for ; Thu, 8 Mar 2001 23:22:53 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id CF1F666C95; Thu, 8 Mar 2001 23:22:52 -0800 (PST) Date: Thu, 8 Mar 2001 23:22:52 -0800 From: Kris Kennaway To: Warner Losh Cc: Kris Kennaway , "Rodney W. Grimes" , "Matthew D. Fuller" , arch@FreeBSD.ORG Subject: Re: Breaking up make.conf Message-ID: <20010308232252.A95896@mollari.cthul.hu> References: <20010308201422.A94052@mollari.cthul.hu> <200103090241.SAA27525@gndrsh.dnsmgr.net> <200103090349.f293nGs04577@billy-club.village.org> <20010308201422.A94052@mollari.cthul.hu> <200103090430.f294Ucs04824@billy-club.village.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="FL5UXtIhxfXey3p5" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103090430.f294Ucs04824@billy-club.village.org>; from imp@village.org on Thu, Mar 08, 2001 at 09:30:38PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Mar 08, 2001 at 09:30:38PM -0700, Warner Losh wrote: > --- etc/defaults/make.conf 2001/02/27 11:21:47 1.147 > +++ etc/defaults/make.conf 2001/03/09 04:23:06 > @@ -366,3 +366,16 @@ > #SENDMAIL_LDFLAGS= > #SENDMAIL_LDADD= > #SENDMAIL_DPADD= > + > +__d := ${.CURDIR} > +.for __i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 > +.if exists(${__d}/etc/make.conf) > +.include "${__d}/etc/make.conf" > +.endif > +__d:=${__d}/.. > +.endfor > +.undef __d > + > +.include > + > +.include Will respond to the rest of this later when I've thought about it a bit more, but if we do this then we have to also protect the above section from being included twice -- lots of people copy /etc/defaults/make.conf to /etc/make.conf as a basis for editing. I thought the above way of doing this is uglier than keeping it in sys.mk, which is why I didn't suggest it. Kris --FL5UXtIhxfXey3p5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6qITMWry0BWjoQKURAkH8AKCEEzoQdUvM5HVjR3EyKreIsYrMOwCg20nZ HFs63NPDUU49W1y87HuGB98= =tBvi -----END PGP SIGNATURE----- --FL5UXtIhxfXey3p5-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 8 23:47: 4 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 25D1537B71A for ; Thu, 8 Mar 2001 23:47:01 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id SAA24487; Fri, 9 Mar 2001 18:46:22 +1100 Date: Fri, 9 Mar 2001 18:45:55 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Kris Kennaway Cc: Warner Losh , "Rodney W. Grimes" , "Matthew D. Fuller" , arch@FreeBSD.ORG Subject: Re: Breaking up make.conf In-Reply-To: <20010308201422.A94052@mollari.cthul.hu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 8 Mar 2001, Kris Kennaway wrote: > On Thu, Mar 08, 2001 at 08:49:16PM -0700, Warner Losh wrote: > Anyway, the only real question here is whether to go for the iterative > .for search, or a recursive include. Both can give the same > behaviour, so it comes down to which is more efficient. Except the .for search is easier to misconfigure and harder to debug (where is your make.conf today?). The search is bad enough in the limited scope of kmod.mk. > > Something like the following patch, included after my sig. Note, I'd > > also go for nuking bsd.own.mk and bsd.cpu.mk and moving them into > > etc/defaults/make.conf so we stop polluting the global make space with > > them. .for loops are hard to terminate in make, so I didn't try. > > You can't put bsd.cpu.mk in /etc/defaults/make.conf or I would have > done this from the beginning. It has to be included AFTER > /etc/make.conf, because thats where CPUTYPE is set. This is a general problem. Parts of make.conf would work better if it were included before sys.mk. E.g., it should used "?=" to set most variables so that it doesn't clobber any previous setting, but it can't do that since sys.mk has alreading provided a previous setting (only a default setting, but make.conf doesn't know that). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 9 0: 0:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 042D737B719 for ; Fri, 9 Mar 2001 00:00:55 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id TAA25284; Fri, 9 Mar 2001 19:00:36 +1100 Date: Fri, 9 Mar 2001 19:00:09 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Warner Losh Cc: Kris Kennaway , "Rodney W. Grimes" , "Matthew D. Fuller" , arch@FreeBSD.ORG Subject: Re: Breaking up make.conf In-Reply-To: <200103090430.f294Ucs04824@billy-club.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 8 Mar 2001, Warner Losh wrote: > In message <20010308201422.A94052@mollari.cthul.hu> Kris Kennaway writes: > : All that searching sounds like it would slow things down given the > : number of times make runs during a make world. On the other hand, > : recursively including parent Makefile.incs until there are no more > : parents, and then pulling in a config file also adds more work. > > I think it would be a wash. Also, recursively including the parents > is going to need this same sort of searching because you can't just > include ${.CURDIR}/../Makefile.inc, since ${.CURDIR} isn't where > Makefile.inc lives, but where Makefile lives (trust me on this, I've > tried it before and it blows up). We have makefiles at too many For this reason, many includes of ${..CURDIR}/../Makefile.inc are style bugs at best. Use `.include "../Makefile.inc"' to prefer including relative to the directory containing the file doing the including. (I think there is an undocumented search path involving that directory, ${.CURDIR} and ${.OBJDIR} even for this. It can be hard to tell which file will be included. E.g., suppose you have a stale .depend in ${.CURDIR} and no .depend in ${.OBJDIR}. Then the stale .depend gets used.) Anyway, make(1) often does lengthy directory searches to find files. I don't know if these are more efficient than explicitly coded searches. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 9 12: 8:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from molly.straylight.com (molly.straylight.com [209.68.199.242]) by hub.freebsd.org (Postfix) with ESMTP id 5628F37B718; Fri, 9 Mar 2001 12:08:15 -0800 (PST) (envelope-from jonathan@graehl.org) Received: from dickie (case.straylight.com [209.68.199.244]) by molly.straylight.com (8.11.0/8.10.0) with SMTP id f29K88w02786; Fri, 9 Mar 2001 12:08:08 -0800 From: "Jonathan Graehl" To: "Walter Goralski" Cc: "Freebsd-Net" , "freebsd-Arch" Subject: missing #includes in /usr/include headers (was RE: Generating SYN packets.) Date: Fri, 9 Mar 2001 12:08:17 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG cd /usr/ports/net/nemesis make install Nemesis (http://www.packetninja.net/nemesis/) is a command line tool that can easily generate syn packets; if you want a flood, write a script. There is also /usr/ports/net/libnet http://www.packetfactory.net/Projects/Libnet/ - it is used by nemesis and is supposed to provide simplified cross-platform support for low level packet building/injection. Specific to your problem: it seems that requires , but does not #include it. n_long is defined in in_systm.h and used in ip_icmp.h and ip.h (not tcp.h) I have complained without response (on freebsd-arch, maybe not the right place) of similar problems with the /usr/include headers - while they include some of their prerequisites, they seem to assume that you have already included several other headers. For instance, requires tcp.h but does not include it, udp_var.h requires udp.h and ip_var.h, icmp_var.h requires ip_icmp.h, ip.h, and in_systm.h ... and probably others that I did not notice since I had earlier included them for other purposes. There seemed to be code that should have been wrapped in an #ifdef KERNEL, although I didn't feel like #ifdefing it out and doing a make world to test. Correcting these compile errors in the headers requires some tiresome find/grep work, although I suppose the whole process of finding missing #includes could be (semi)automated. find . -name '*.[ch]*' -exec grep -H $1 {} \; Very few of the header files include their prereqs, although they are #ifdef wrapped to prevent re-inclusion: find /usr/include -name '*.h' -exec gcc -c -xc {} -o /dev/null \; gives reams of error messages. > -----Original Message----- > From: owner-freebsd-net@FreeBSD.ORG > [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Walter Goralski > Sent: Friday, March 09, 2001 8:04 AM > To: 'freebsd-hackers@freebsd.org'; 'freebsd-net@freebsd.org' > Subject: Generating SYN packets. > > > Folks: > > Andreas Klemm, who ported cflowd to FreeBSD, suggested I use this vehicle to > see if I could get some help. > > I am a course developer for Juniper Networks, and I have just written a > 2-day advanced course on router firewall filters (this is one reason for the > cflowd). > > We have participants in a strictly closed lab environment configuring > filters to stop spoofs, smurf, fraggle, etc. In order to show they work, we > also have a 4.2 FreeBSD laptop that can launch smurf, fraggle, etc. at the > routers and the instructor's PC. > > The missing piece has been DOS SYN attacks. I have the really common > "synk4.c" source that is all over the Web, but I get errors when I try to > compile it ("it's the linux includes" someone told me). Now, I last used my > C programming skills in the 80s on a Silent 700 teletype and a 3B20 mini, so > I tried playing around with "programming by analogy" (hey, it sometimes > works). I took fraggle.c and tried to substitute a tcp header for the udp > header. Anyway, the compiler tells me there is a syntax error in tcp.h > (right before the "n_long"), which strikes me as odd. Then it says I am > using an "incomplete type" and dereferences all of my pointers. Sometimes I > can force a compile and lonk, but none of my paramters get plugged into the > packets when I use it. > > So: anybody got a quick and dirty SYN packet generator out there? A version > of synk4 that runs on 4.2? An executable? > > I even tried to install hping2 from the FreeBSD ports collection, but of > course *that* won't run either. (It says my ep0 interface is not defined (!) > and seems to try to use lo.) If I use "make install," I get these run time > errors; if I use "./configure" and then "make" I get compile errors, also > about "overlapping" includes. (***Are my include files all screwed up?*** > How could I tell?) > > But the cflowd and RADIUS servers, also installed a couple of weeks ago from > these ports, run merrily along, so the basic system seems to be intact. I > don't think my programming efforts have scrammed the system (and I don't > have the cd-rom, since it's a company laptop), but I am very worried that I > have somehow harmed the .h files. > > Meanwhile, I'm re-learning BSD socket coding. But this might be faster if > anyone can help. > > (As a note, if anyone out there works for Juniper, I can configure remote > access to the laptop if required.) > > Walter Goralski > walterg@juniper.net > 952-938-4483 > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 9 12:55:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id A058B37B718 for ; Fri, 9 Mar 2001 12:55:45 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id PAA05962; Fri, 9 Mar 2001 15:55:22 -0500 (EST) (envelope-from wollman) Date: Fri, 9 Mar 2001 15:55:22 -0500 (EST) From: Garrett Wollman Message-Id: <200103092055.PAA05962@khavrinen.lcs.mit.edu> To: jonathan@graehl.org Subject: Re: missing #includes in /usr/include headers (was RE: Generating SYN packets.) X-Newsgroups: mit.lcs.mail.freebsd-arch In-Reply-To: References: Organization: MIT Laboratory for Computer Science Cc: arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article you write: >not the right place) of similar problems with the /usr/include headers - while >they include some of their prerequisites, they seem to assume that you have >already included several other headers. This is intentional, historical, and in most cases documented. In some cases this will be changed in the future to comport with recent POSIX and Open Group specifications. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 9 14:40:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id D29B337B718; Fri, 9 Mar 2001 14:40:14 -0800 (PST) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id XAA25011; Fri, 9 Mar 2001 23:40:09 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: "Jonathan Graehl" Cc: "Walter Goralski" , "Freebsd-Net" , "freebsd-Arch" Subject: Re: missing #includes in /usr/include headers (was RE: Generating SYN packets.) References: From: Dag-Erling Smorgrav Date: 09 Mar 2001 23:40:08 +0100 In-Reply-To: "Jonathan Graehl"'s message of "Fri, 9 Mar 2001 12:08:17 -0800" Message-ID: Lines: 18 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Jonathan Graehl" writes: > Specific to your problem: it seems that requires > , but does not #include it. n_long is defined in > in_systm.h and used in ip_icmp.h and ip.h (not tcp.h) I have > complained without response (on freebsd-arch, maybe not the right > place) of similar problems with the /usr/include headers - while > they include some of their prerequisites, they seem to assume that > you have already included several other headers. "If you want Linux, you know where to find it" The real bug is that the author of that software is a Linux weenie, and Linux header files are broken in such a way that they mask the fact that his program does not include the proper headers. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 9 22:35:35 2001 Delivered-To: freebsd-arch@freebsd.org Received: from molly.straylight.com (molly.straylight.com [209.68.199.242]) by hub.freebsd.org (Postfix) with ESMTP id B73D537B72C for ; Fri, 9 Mar 2001 22:35:31 -0800 (PST) (envelope-from jonathan@graehl.org) Received: from dickie (case.straylight.com [209.68.199.244]) by molly.straylight.com (8.11.0/8.10.0) with SMTP id f2A6ZNw06951 for ; Fri, 9 Mar 2001 22:35:23 -0800 From: "Jonathan Graehl" To: "freebsd-Arch" Subject: RE: missing #includes in /usr/include headers (was RE: Generating SYN packets.) Date: Fri, 9 Mar 2001 22:35:38 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20010309184342.A13688@mollari.cthul.hu> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Correct, -arch is for discussion of new architectural features. ... and, apparently, in which directory which files will reside ;) Seriously, what is the appropriate forum for a request for header file reorganization? > > they include some of their prerequisites, they seem to assume that you have > > already included several other headers. > > This is considered to be the correct behaviour. > > Kris Where is this behavior documented? For instance, sysctl says several sysctl codes are defined in certain header files, but nowhere in that man page or in the header files is any such policy documented. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 10 17: 0: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 3F7D437B718 for ; Sat, 10 Mar 2001 16:59:59 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f2B0xt442373; Sat, 10 Mar 2001 16:59:55 -0800 (PST) (envelope-from obrien) Date: Sat, 10 Mar 2001 16:59:54 -0800 From: "David O'Brien" To: Warner Losh Cc: arch@FreeBSD.ORG Subject: Re: Breaking up make.conf Message-ID: <20010310165954.A36413@dragon.nuxi.com> Reply-To: arch@FreeBSD.ORG References: <200103090241.SAA27525@gndrsh.dnsmgr.net> <200103090349.f293nGs04577@billy-club.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103090349.f293nGs04577@billy-club.village.org>; from imp@village.org on Thu, Mar 08, 2001 at 08:49:16PM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Mar 08, 2001 at 08:49:16PM -0700, Warner Losh wrote: > +__d := ${.CURDIR} > +.for __i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 > +.if exists(${__d}/etc/defaults/make.conf) > +.include "${__d}/etc/defaults/make.conf" I must say, if this is going to live in src/, it belongs in src/, not hidden in src/etc/. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 10 17: 8:52 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 6C22937B719 for ; Sat, 10 Mar 2001 17:08:47 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f2B18io52426; Sat, 10 Mar 2001 17:08:44 -0800 (PST) (envelope-from obrien) Date: Sat, 10 Mar 2001 17:08:44 -0800 From: "David O'Brien" To: Warner Losh Cc: arch@FreeBSD.ORG Subject: Re: Breaking up make.conf Message-ID: <20010310170844.C36413@dragon.nuxi.com> Reply-To: arch@FreeBSD.ORG References: <200103090430.f294Ucs04824@billy-club.village.org> <20010308201422.A94052@mollari.cthul.hu> <200103090241.SAA27525@gndrsh.dnsmgr.net> <200103090349.f293nGs04577@billy-club.village.org> <200103090430.f294Ucs04824@billy-club.village.org> <200103090449.f294nUs06142@billy-club.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103090449.f294nUs06142@billy-club.village.org>; from imp@village.org on Thu, Mar 08, 2001 at 09:49:30PM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Mar 08, 2001 at 09:49:30PM -0700, Warner Losh wrote: > Also, the previous patches don't include bsd.own.mk, which we depend > on being included to define OBJFORMAT. So I backed that part of them > out. Rather than all this funk, why not do what the Ports Collection does -- have its own bsd.*.mk file. So make it that /usr/share/bsd.*.mk all include /etc/world-make.conf, and sys.mk does not. Thus if I am just using BSD make, but not all its bsd.*.mk frame work, I won't get bogus CFLAGS settings. I.E., lets assume /usr/share/mk/bsd.*.mk is the domain of /usr/src only. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 10 17:44:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 4E5E537B719 for ; Sat, 10 Mar 2001 17:44:38 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f2B1iXI23234 for ; Sat, 10 Mar 2001 18:44:33 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200103110144.f2B1iXI23234@harmony.village.org> To: arch@FreeBSD.ORG Subject: Re: Breaking up make.conf In-reply-to: Your message of "Sat, 10 Mar 2001 16:59:54 PST." <20010310165954.A36413@dragon.nuxi.com> References: <20010310165954.A36413@dragon.nuxi.com> <200103090241.SAA27525@gndrsh.dnsmgr.net> <200103090349.f293nGs04577@billy-club.village.org> Date: Sat, 10 Mar 2001 18:44:33 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010310165954.A36413@dragon.nuxi.com> "David O'Brien" writes: : On Thu, Mar 08, 2001 at 08:49:16PM -0700, Warner Losh wrote: : > +__d := ${.CURDIR} : > +.for __i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 : > +.if exists(${__d}/etc/defaults/make.conf) : > +.include "${__d}/etc/defaults/make.conf" : : I must say, if this is going to live in src/, it belongs in src/, not : hidden in src/etc/. The reason that I put it in src/etc/defaults was two fold. First, so people could have a global one, and second they could have a tree one that overrode that. Having it be in bare src/ opens it up for false positives too easily, imho. The etc/default acts as a key to help reduce false positives. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 10 17:45:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 26A3637B718 for ; Sat, 10 Mar 2001 17:45:25 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f2B1jOI23270 for ; Sat, 10 Mar 2001 18:45:24 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200103110145.f2B1jOI23270@harmony.village.org> To: arch@FreeBSD.ORG Subject: Re: Breaking up make.conf In-reply-to: Your message of "Sat, 10 Mar 2001 17:08:44 PST." <20010310170844.C36413@dragon.nuxi.com> References: <20010310170844.C36413@dragon.nuxi.com> <200103090430.f294Ucs04824@billy-club.village.org> <20010308201422.A94052@mollari.cthul.hu> <200103090241.SAA27525@gndrsh.dnsmgr.net> <200103090349.f293nGs04577@billy-club.village.org> <200103090430.f294Ucs04824@billy-club.village.org> <200103090449.f294nUs06142@billy-club.village.org> Date: Sat, 10 Mar 2001 18:45:24 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010310170844.C36413@dragon.nuxi.com> "David O'Brien" writes: : I.E., lets assume /usr/share/mk/bsd.*.mk is the domain of /usr/src only. I think that's a bad assumption. I know of several projects outside of /usr/src that use bsd.*.mk. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message