From owner-freebsd-ports-bugs@FreeBSD.ORG Thu Feb 5 06:52:57 2015 Return-Path: Delivered-To: freebsd-ports-bugs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 48AC37FA for ; Thu, 5 Feb 2015 06:52:57 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2F7CB97C for ; Thu, 5 Feb 2015 06:52:57 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t156qvTa080660 for ; Thu, 5 Feb 2015 06:52:57 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ports-bugs@FreeBSD.org Subject: [Bug 197234] [UPDATE] lang/execline: update to 2.0.2.0 and take maintainership Date: Thu, 05 Feb 2015 06:52:57 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: colin@heliocat.net X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ports-bugs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Ports bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 06:52:57 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D197234 --- Comment #4 from Colin Booth --- (In reply to Jan Beich from comment #1) >> +LDFLAGS?=3D -s >> +STRIPFLAGS?=3D -x >Better use ${STRIP} or depend on ! ${PORT_OPTIONS:MDEBUG} and maybe use ve= ndor >`strip` make target e.g., > # STRIP can only be `-s` or empty > ALL_TARGET=3D all ${STRIP:S/-s/strip/} Adapted from the old Makefile for skalibs in ports. I'll yank those out bec= ause it doesn't run strip by default anyway.=20 >> +CC?=3D cc >CC is always defined by sys.mk (fmake, bmake) or embedded (gmake). >> +WRKSRC=3D ${WRKDIR}/${DISTNAME} >No need to redefine the default value. You're right on both counts. I thought I'd have to force-define what the default cc pointed to since without specifying CC=3D${CC} the upstream Make= file autodetects a compiler that doesn't support the -i flag. As for WRKSRC, I d= on't know why I didn't think that came included. >> +USES=3D ${GMAKE} >This works only by accident because the path to GNU make isn't an absolute= one. That was on the suggestion of portlint since building execline (and skalibs= and s6) don't work with the stock make and I'm working around a reasonably linux-tools centric design. >Define HAS_CONFIGURE and populate CONFIGURE_ARGS. This would also fix a ca= se where CC contains spaces e.g., Unless I'm reading the porters stuff wrong HAS_CONFIGURE only works with autoconf and its ilk. Since skalibs et. al. don't use autotools I'm going to omit HAS_CONFIGURE (it seems to be ignored). However, that appears to mean = that I need the CC=3D${CC} definition which breaks if there's a multiple item CC definition. If I find out a better way to override this, I'll fix it. >do-build... >do-install... >use post-install... All good suggestions and updated.=20 >> +lib/libexecline.so >> +lib/libexecline.so.2 >This requires USE_LDCONFIG in Makefile. Missed that in the port handbook. Updated. >> + --prefix=3D${LOCALBASE} \ >This would break install if PREFIX !=3D LOCALBASE i.e., poudriere testport= -P. >You may need to pass --with-sysdeps as well to unbreak it. Changed all LOCALBASE to PREFIX though that's still going to break if skali= bs isn't going to be installed in the same root tree since execline needs to f= ind the skalibs headers and I'm unaware of a good way of autodetecting that.=20 Related to that, I've debated whether to static link libskarnet into the execline binaries. On the one hand dynamic linking is the standard, on the other it's nice to have the only external runtime dependency be your libc f= or things like proces supervisors. Since there's already a compile-time depend= ency on skalibs being installed in the same PREFIX as execline I'm going to leav= e it the default (static linking) unless there's a serious argument in the other direction. Thanks for the commentary and advice, the skarnet stuff is my first foray i= nto porting so I'm sure I'll make mistakes along the way. --=20 You are receiving this mail because: You are the assignee for the bug.=