Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 17 May 1995 10:04:23 -0700
From:      asami@CS.Berkeley.EDU (Satoshi Asami | =?ISO-2022-JP?B?GyRCQHUbKEI=?= =?ISO-2022-JP?B?GyRCOCsbKEIgGyRCOC0bKEI=?=)
To:        jhs@vector.eikon.e-technik.tu-muenchen.de
Cc:        ports@FreeBSD.org
Subject:   Re: SUBDIR in Makefiles - usage thereof
Message-ID:  <199505171704.KAA03565@silvia.HIP.Berkeley.EDU>
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 %2B0200)

next in thread | previous in thread | raw e-mail | index | archive | help
 * 	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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199505171704.KAA03565>