svn commit: r400121 - head/net-im/teamwords
Don Lewis
truckman at FreeBSD.org
Sat Oct 24 16:22:00 UTC 2015
On 24 Oct, Alexey Dokuchaev wrote:
> On Sat, Oct 24, 2015 at 11:10:29AM -0400, Kris Moore wrote:
>> On 10/24/2015 10:29, Alexey Dokuchaev wrote:
>> > On Sat, Oct 24, 2015 at 02:06:56PM +0000, Kris Moore wrote:
>> >> [...]
>> >> do-install:
>> >> ${STRIP_CMD} ${WRKSRC}/teamwords
>> >> ${INSTALL} ${WRKSRC}/teamwords ${STAGEDIR}${PREFIX}/bin
>> >
>> > Wait, what? You strip the binary first and then install it? Why not
>> > use ${INSTALL_PROGRAM} which DTRT itself?
>>
>> It's what was suggested when I built the port with DEVELOPER=yes. Is the
>> end-result the same or is this just for the sake of minimalism?
>
> I'm not sure where does this suggestion come from; it makes little sense
> to me. INSTALL_PROGRAM correctly respects your stripping policy, i.e.:
>
> $ make -V INSTALL_PROGRAM
> install -s -m 555
> $ make -V INSTALL_PROGRAM STRIP=''
> install -m 555
>
> As for stripping binaries explicitly in the Makefile: I'm actually against
> it; it made sense in pre-staging times when we've been installing stuff
> directly into user's filesystem, but now with staging we ideally should be
> just dumping unstripped binaries to staging area, and stripping should be
> done upon "make install" by the framework. Those ${STRIP_CMD}'s just make
> Makefiles more imperative and hard to control. Think of what would I have
> to do if I want to build debug package? -- patching individual ports on an
> ad-hoc basis in many little places instead of setting some universal knob
> like NO_STRIP in /etc/make.conf or something.
Debug builds set ${STRIP_CMD} to /bin/true. From bsd.port.mk:
# Reset value from bsd.own.mk.
.if defined(WITH_DEBUG) && !defined(WITHOUT_DEBUG)
.if !defined(INSTALL_STRIPPED)
STRIP= #none
MAKE_ENV+= DONTSTRIP=yes
STRIP_CMD= ${TRUE}
.endif
DEBUG_FLAGS?= -g
CFLAGS:= ${CFLAGS:N-O*:N-fno-strict*} ${DEBUG_FLAGS}
.if defined(INSTALL_TARGET)
INSTALL_TARGET:= ${INSTALL_TARGET:S/^install-strip$/install/g}
.endif
.endif
More information about the svn-ports-head
mailing list