Date: Sat, 20 Jul 2002 12:14:07 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: mark@thuvia.demon.co.uk Cc: ru@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: [POLL] need a good name for share/mk API versioning Message-ID: <20020720.121407.17240249.imp@bsdimp.com> In-Reply-To: <200207201648.g6KGmZJE085462@dotar.thuvia.org> References: <20020719.100151.96158427.imp@bsdimp.com> <200207201648.g6KGmZJE085462@dotar.thuvia.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <200207201648.g6KGmZJE085462@dotar.thuvia.org>
Mark Valentine <mark@thuvia.demon.co.uk> writes:
: > From: "M. Warner Losh" <imp@bsdimp.com>
: > Date: Fri 19 Jul, 2002
: > Subject: Re: [POLL] need a good name for share/mk API versioning
:
: > In message: <200207181943.g6IJhu5A016231@dotar.thuvia.org>
: > Mark Valentine <mark@thuvia.demon.co.uk> writes:
: > : If this were only for ports, the existing OSVERSION in bsd.port.mk
: > : would suffice, no?
: >
: > No. The OS version and the .mk files may (and often are) unrelated.
: > This is especially true in the case of cross build environments, which
: > are often used to insulate products from whatever version of FreeBSD
: > they happen to be running on. At Timing solutions, we often build 4.5
: > based products on a 4.3 machine, and vice versa.
:
: Does this work for the ports system? I recognise the need for cross builds,
: but didn't consider it for ports. After all, they already use OSVERSION...
Using OSVERSION may be sufficient for the ports. Using a
__FREEBSD_MK_API_VERSION variable would also be sufficient, as well as
allowing for people that use the bsd.*.mk files externally to the
project to continue to do so and cope with the different APIs.
I've not looked at porting out .mk files over to the new scheme, so I
don't know how necessary this would be.
Warner
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020720.121407.17240249.imp>