Date: Thu, 13 Apr 2000 11:19:43 +0900 From: "R. Imura" <imura@af.airnet.ne.jp> To: "Satoshi - Ports Wraith - Asami" <asami@FreeBSD.org> Cc: <knu@idaemons.org>, <cvs-committers@FreeBSD.org>, <cvs-all@FreeBSD.org> Subject: Re: cvs commit: ports/chinese Makefile.inc ports/german Makefile.inc ports/japanese Makefile.inc ports/korean Makefile.inc ports/russian Makefile.inc ports/vietnamese Makefile.inc Message-ID: <006101bfa4ee$cdff1000$6010a8c0@nttdtec.co.jp> References: <vqc4s99ox22.fsf@silvia.hip.berkeley.edu> <20000412005730F.imura@cs.titech.ac.jp> <86bt3gk2oi.wl@archon.local.idaemons.org> <20000412083621F.imura@cs.titech.ac.jp> <vqcn1n0i2pr.fsf@silvia.hip.berkeley.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Sorry for my late reply.
> * Do we have to move all CATEGORIES variables to Makefile.inc?
>
> We don't have to, but that was one of the things I thought about too.
> There can be a "CATEGORIES+=whatever" in all the Makefile.inc's. That
> way we can reduce most of the CATEGORIES lines (leaving only virtual
> and extra secondary categories). This could be even more beneficial
> when we go to multi-level categories, since it will allow us to move
> things around without having to change too much in the Makefiles
> (basically the default category will mirror the directory structure).
>
> * I don't like it.
>
> Why not? Is there a case where a port in category X not having X in
> the CATEGORIES line?
I think, our ports' good point is each skeltons are independent and
we can build many applications with very a few files.
Yes, if no CATEGORIES in its Makefile, we can build with no problem,
but if he really want in what category the port is, it requires a hole
tree of ports. I just worry about it. (You know, master/slave ports
are the out of this case)
About PKGNAMEPREFIX, even if I don't have Makefile.inc, I will know
PKGNAMEPREFIX from its CATEGORIES, because CATEGORIES is still in
each Makefiles.
> * > We need to include both ${.CURDIR}/../Makefile.inc and
> * > ${MASTERDIR}/../Makefile.inc (in the order named) for the reason I
> * > mentioned above in 1).
> *
> * Ok, you mean "after" or "before" is not the issue, right? :)
>
> Um, I don't understand what you are trying to say, but the ordering
> (${.CURDIR} before ${MASTERDIR}) is actually important so we can get
> things like PKGNAMEPREFIX right.
There should be misunderstandings. :(
At first, I wondered about knu's "including ${.CURDIR}/../Makefile.inc before
${MASTERDIR}/Makefile is bad". I thought it is strange, I showed it will
not happen, and I wanted to say "you don't have to think about it".
But, knu didn't mention about ordering of Makefile.inc and Makefile again,
I knew the issue kind of this is not his problem.
I know well about first ${.CURDIR}../Makefile.inc, second ${MASTERDIR}../Makefile.inc
is very important.
- R. Imura
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?006101bfa4ee$cdff1000$6010a8c0>