Date: Sun, 31 Aug 2003 19:20:41 -0400 (EDT) From: "Adam C. Migus" <adam@migus.org> To: "Clement Laforet" <sheepkiller@cultdeadsheep.org> Cc: ports@freebsd.org Subject: Re: devel/libtool13 <-> databases/mysql40-client dependency problem Message-ID: <50785.192.168.4.2.1062372041.squirrel@mail.migus.org> In-Reply-To: <20030901003219.67e3f67c.sheepkiller@cultdeadsheep.org> References: <50603.192.168.4.2.1062361689.squirrel@mail.migus.org><20030831225446.47626642.sheepkiller@cultdeadsheep.org><50690.192.168.4.2.1062366560.squirrel@mail.migus.org> <20030901003219.67e3f67c.sheepkiller@cultdeadsheep.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Clement Laforet said: > On Sun, 31 Aug 2003 17:49:20 -0400 (EDT) > "Adam C. Migus" <adam@migus.org> wrote: >semanticallyenvironmentappropriate >> So I suppose >> the question is should defining it universally really cause aMk >> loop? >> It seems right now defining USE_MYSQL globally makes every packageMk >> you compile dependent on mysql... > > USE_MYSQL is now a macro in bsd.port.mk that implies MYSQL > dependency. > I gonna write patches to for MySQL ports to avoid this kind of loop > in > some case (like USE_OPENLDAP and USE_GMAKE). > Thanks for the pointing :-) > >> Thanks, > > You're welcome Adam. > > clem > Clem, The thing with the USE_ variables is they seem to be a bit over used and symatically ambiguous. They're used for things in the make enviornment itself as well as packages themselves. They also have a dual internal/external use nature about them. Sometimes it works to simply define the WITH_ variables and rely on them to define the approriate USE_ variables, but not always. Upon encountering this problem I got to thinking and wondered if something a little more drastic were in order. Perhaps something like a "SUPPORTED_" variable a port could define to say it "supports" the use of another, along with some separated out .mk logic to deal with the "support" semantics. It would require much more thought to iron out the details or even see if this idea is worth doing or if there would be a better solution. None the less having the notion of a "supported feature" in a port might help developers by simplifying existing .mk logic and users by being able to tell at-a-glance if a package has features to work with something else they use as well as a few other benefits. -- Adam - (http://people.migus.org/~amigus/) Migus Dot Org - (http://www.migus.org/)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50785.192.168.4.2.1062372041.squirrel>