From owner-freebsd-ports Wed May 17 10:04:43 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA09050 for ports-outgoing; Wed, 17 May 1995 10:04:43 -0700 Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id KAA09034 for ; Wed, 17 May 1995 10:04:40 -0700 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.11/8.6.9) id KAA03565; Wed, 17 May 1995 10:04:23 -0700 Date: Wed, 17 May 1995 10:04:23 -0700 Message-Id: <199505171704.KAA03565@silvia.HIP.Berkeley.EDU> To: jhs@vector.eikon.e-technik.tu-muenchen.de CC: ports@FreeBSD.org In-reply-to: <199505171233.OAA24418@vector.eikon.e-technik.tu-muenchen.de> (message from Julian Howard Stacey on Wed, 17 May 1995 14:33:59 +0200) Subject: Re: SUBDIR in Makefiles - usage thereof From: asami@CS.Berkeley.EDU (Satoshi Asami | =?ISO-2022-JP?B?GyRCQHUbKEI=?= =?ISO-2022-JP?B?GyRCOCsbKEIgGyRCOC0bKEI=?=) Sender: ports-owner@FreeBSD.org Precedence: bulk * SUBDIR?= * SUBDIR += this * SUBDIR += that * SUBDIR += the_other * SUBDIR += foobar Actually I thought about this before when I was cleaning up the Makefiles, the reason why I didn't want to go for it at that time was because I thought it will make the subdir Makefiles too long and scroll off my screen. Now that I think of it, if the Makefile is so long it's scrolling off my screen, that category has too much stuff in it and should be split up anyway so that's not a valid argument against it. :) * This will enable a higher success ratio when multiple & possibly overlapping/ * inconsistent patch scripts, that are are applied from time to time on local * ports dirs that aren't monolithcally & repetitively remade on the odd spare * gigabyte drive that we all have handy ;-) Well, I'm not sure why people would want to deal with hand-made patches to the ports Makefiles, they are all so small anyway! In fact, the entire ports tree in less than 10MB (without distfiles), so why don't you all go and grab the whole hting today! (And start testing! :) You didn't mention one thing by the way, it is that the current method can become very irritating when you are adding/subtracting things. The ordering sometimes gets screwed up, you need to break lines when it gets too long, etc. Also, it will make it easier when we formally support the RESTRICTED and BROKEN keywords, as we can do something like BROKEN += a_broken_port SUBDIR += a_good_port RESTRICTED += cryptic_port SUBDIR += great_port SUBDIR += some_port RESTRICTED += what_a_jerk and still have them in alphabetical order. :) * This minor change buys flexibility, it's also been tried & tested before * (& is still to be seen in such files as src/Makefile) BTW, I definitely don't want turn this into a sea of .if exists(foodir) SUBDIR += foodir .endif like seen in /usr/src/Makefile, it's ugly and hard to read. If we want to deal with these sort of things (i.e., missing directories), we can do it in bsd.port.subdir.mk. * I also propose we prepend a SUBDIR?= to allow for extra things `on * the fly', this hook would allow (eg) to have `ports in progress' * that we want in the tree for some reason, but don't want * automatically compiled ... yet. I'm not sure about the feasability of doing "make SUBDIR=new_port" though, it may screw things up royally if there is something down the tree that includes a different bsd.*.mk file. I remember running into this problem when I was trying to compile linpack or something. * Whether this is done before or after 2.0.5 is (I imagine) Satoshi's choice. I don't have anything against it, there is no change of functionality here, and it will certainly look much cleaner. If nobody objects in the next 24 hours or so, I'll go ahead and update all the Makefiles. Satoshi