From owner-freebsd-ports@freebsd.org Sat Feb 13 13:40:23 2016 Return-Path: Delivered-To: freebsd-ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0B0B8AA7FEC for ; Sat, 13 Feb 2016 13:40:23 +0000 (UTC) (envelope-from elferdo@gmail.com) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CEC3014D0 for ; Sat, 13 Feb 2016 13:40:22 +0000 (UTC) (envelope-from elferdo@gmail.com) Received: by mail-io0-x22e.google.com with SMTP id 9so118703140iom.1 for ; Sat, 13 Feb 2016 05:40:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=OX+QZ3nuEjO/zd59nqUPIAHGErO7NWEL6jo/ga5EGeg=; b=aBW+Z4McDWuywOYg8jrgxxx+glHZHdcokbK14TEnQlk985A8hXxa64Ex8YOPcdQc6z 4P3BEuaHNrcexixrUys4NbSP2Pb850jDB5EWxNy+QJs9biiMzft8lxRbtXhPQ3mpoYJ8 xxqSG/1TJ4sLqyEJXAnH5E7ezfXs8gxmiCE3Azjf1uCg8+zqJ1FzlrDnH49/5E1i0XvD hIVAEG3uO/bMY0+DyGDrRctbxZ2yWu1OgwY+nV6uS28YDeJD/WPrIgktH1CmIUSmYgRi ahAeSiSbeNZ1GTR1Ya1W7Ohn/rqWozMS+SObJ2FQDXqwyA0+7T0Eps/VE1azZj76fYA6 yydg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=OX+QZ3nuEjO/zd59nqUPIAHGErO7NWEL6jo/ga5EGeg=; b=SxVos2stdoFTmmkrL15F2Y07VYXM0JybIoeI7WNXK2dehhpawb9YagWSsPr1t+WcJX 8FAjxkkaPNcbRKsLeX7VNYKEI87omkmJcSbaKpLl+vtuhNfxDPcxJJ1peNQx4+hCPH1R pGHRNqDfw38giMpQOK0GfxpdfMGZMoFDqTB8CbpVI7sHiQpmK5zDtePPP81uZL/+Imgs Ow8r3RqXzRR+L4FRtSAGAs7hivFLlEWm9Ker6OXsORNio57LM1rc0fRW+ZC33A5k5/jh 4vMbhHyLv3LboJzYRxUWXCw3dL3nMownyo3SHRWAmeQv7srpL1a2wx9KY0a8yyZI3v4O LsFg== X-Gm-Message-State: AG10YOTUi5Sb91QAasSFBSJ9xIzj6TUkNwQmWrMtxgjm+N3UzQVnEj6ZCvxqWlkPGRQMn5kLNjHQ0dxeFTU+uw== MIME-Version: 1.0 X-Received: by 10.107.32.144 with SMTP id g138mr7938875iog.33.1455370822333; Sat, 13 Feb 2016 05:40:22 -0800 (PST) Received: by 10.36.77.1 with HTTP; Sat, 13 Feb 2016 05:40:22 -0800 (PST) Date: Sat, 13 Feb 2016 14:40:22 +0100 Message-ID: Subject: math/R and slave ports guidelines From: =?UTF-8?Q?Fernando_Herrero_Carr=C3=B3n?= To: freebsd-ports@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2016 13:40:23 -0000 Hi all, I am working on some upgrades to the Makefile of math/R and I have found that there are two slave ports depending on it: math/libR and math/libRmath. Now I have some questions about how slave ports should be handled. As it stands, the master port will only set some options *if* it is the master port itself being built and not one of the slaves. For example (math/R/Makefile:145): *.if !defined(LIBRMATH_SLAVEPORT)* .if ${PORT_OPTIONS:MATLAS} LIB_DEPENDS+= libatlas.so:${PORTSDIR}/math/atlas BLAS?= ${LIBM} -lf77blas LAPACK?= ${LIBM} -lalapack -lcblas .else BLAS?= no LAPACK?= no .endif CONFIGURE_ARGS+= --with-blas="${BLAS}" --with-lapack="${LAPACK}" .if ${BLAS} == "no" || ${LAPACK} == "no" PLIST_SUB+= LAPACK="" .else PLIST_SUB+= LAPACK="@comment " .endif [...] this fragment will only try compiling against ATLAS if it is not the math/libRmath port the one being compiled. In my opinion having the choice to link against ATLAS/openBLAS/netlib/none_of_them is interesting to any maths ports. Is there any reason why this specific slave port rejects it? Are there any general guidelines as to how options from master ports should be handled in slave ports? I haven't found any specific hints in the porter's handbook. Having a look at editors/emacs-nox11/Makefile (emacs-nox11 is a slave to emacs) I see the possibility of specifying OPTIONS_EXCLUDE, which seems a more reasonable place to handle such cases. Any help with this will be highly appreciated. Best, Fernando