From owner-freebsd-ports@FreeBSD.ORG Sat Apr 14 16:37:36 2012 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FB6B106564A for ; Sat, 14 Apr 2012 16:37:36 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id BF2F68FC08 for ; Sat, 14 Apr 2012 16:37:35 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so3953288bkc.13 for ; Sat, 14 Apr 2012 09:37:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=D09aDfn8ZlXGp5jJE/ok2+q/pcy6L/n5voo5VBcY+xU=; b=WrG8is9NdFw2Ob//ZAjhrCDlWynKjkfXnBfuWFbBxbXG+dgGkVQQfgeAXRN0kE0QHm YOUeCIZ8LevQRXoBh8qkXaZqDA7+VST0RAwosvb8Fk+2QTCxh7ufI3mK59vFAe/C1qQv Sf5U85ilYWwx/IRPIELWKKjPXDcpZVhwvY7YO5HGRcsufo3OrNVS3PaWNJYhov6cXcVA V0PBhL6u+IckXPiQViPM+FExvZDIiTnn8+Bam10JCB28g0Bbs7R6+POPTSAXzvRbJ+pX IKzhen/FRODAvxsx2kG7HaAKHXAzjB4jtDxJq5H1j/Lh1DMPdRgvfYI7ChLPHxGRCShO E63A== Received: by 10.204.156.69 with SMTP id v5mr1764384bkw.5.1334421454629; Sat, 14 Apr 2012 09:37:34 -0700 (PDT) MIME-Version: 1.0 Sender: utisoft@gmail.com Received: by 10.204.202.142 with HTTP; Sat, 14 Apr 2012 09:37:04 -0700 (PDT) In-Reply-To: References: <0E61DE82-499B-47EF-9EEA-F9F3EB166A0A@gmail.com> <866281334347264@web24.yandex.ru> From: Chris Rees Date: Sat, 14 Apr 2012 17:37:04 +0100 X-Google-Sender-Auth: 06wsMcxXzBJ4jqBCljDhOS16oHo Message-ID: To: Kevin Oberman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-ports@freebsd.org" , Konstantin Tokarev , Chris Inacio Subject: Re: port variants X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 16:37:36 -0000 On 13 April 2012 23:38, Kevin Oberman wrote: > 2012/4/13 Konstantin Tokarev : >> 13.04.2012, 23:55, "Chris Inacio" : >>> On Apr 13, 2012, at 3:39 PM, Freddie Cash wrote: >>> >>>> =A0On Fri, Apr 13, 2012 at 12:04 PM, Chris Inacio = wrote: >>>>> =A0I was recently asked to do some FreeBSD ports support work. =A0I m= ostly use a >>>>> =A0Mac and the MacPorts system. =A0MacPorts has the concept of a vari= ant for a >>>>> =A0port, but I can't find the analogue in the FreeBSD system. >>>>> >>>>> =A0Does the FreeBSD ports system have the concept of a variant? =A0If= so, can >>>>> =A0someone point me in the right direction on how to create one? >>>> =A0Describing what a "variant" is, how it works in MacPorts, and what = you >>>> =A0are trying to do would help a lot. =A0:) >>>> >>>> =A0The closest guess I could make would be "slave port", but I don't >>>> =A0think that works the same way. >>> >>> Sorry, you're right. >>> >>> For example, a port of say Emacs could have a variant of X11. >>> >>> So Emacs or Emacs+X11. >>> >>> The X11 variant would (somewhat obviously) include building regular Ema= cs but also the X11 toolbar etc. while Emacs wouldn't include any X11 featu= res (& dependencies). >>> >>> On the Mac, we can build universal binaries (PowerPC, ia32, and x86_64)= , at the cost of disk space. So we can build almost any package with the +u= niversal variant. >>> >>> Is that a reasonable explanation? >> >> Seems like you need makefile options: >> >> http://www.freebsd.org/doc/en/books/porters-handbook/makefile-options.ht= ml > > While I think makefile-options is the way to go, I should also point > out that for the specific case of emacs and X11, it is not used due to > the very large differences. Other "variants" are handled via options, > but there are separate emacs and emacs-nox11 ports. > > Most obviously, all of the emacs options are X11 related and there is > no way that I know to have two sets of options with one list dependent > on the other. If there are only a coupe of cases of this, it may be > noted on the options like: > THREADS =A0 =A0 =A0 " Build with thread support" > =A0 =A0 =A0 =A0 =A0 =A0On \ > FOO =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"Foo support (requires THREADS)" > =A0 =A0 =A0 =A0 OFF \ > > The port maintainer/developer has to make a call as to which approach > is more practical, but I suspect portmgr@ will press for maximum use > of makefile-options. It's unusual for portmgr to intervene in individual ports-- if the maintainer takes the trouble to make test and support OPTIONS, then great, but it's by no means mandatory. It's better to be slightly less flexible than have loads of OPTIONS which break other ports in subtle ways. Chris