Skip site navigation (1)Skip section navigation (2) 
Date:      Sun, 9 Apr 1995 21:44:05 -0700
From:      asami@cs.berkeley.edu (Satoshi Asami | =?ISO-2022-JP?B?GyRCQHUbKEI=?= =?ISO-2022-JP?B?GyRCOCsbKEIgGyRCOC0bKEI=?=)
To:        jkh@freefall.cdrom.com
Cc:        ports@freefall.cdrom.com
Subject:   Re: OK, I've done part of it..
Message-ID:  <199504100444.VAA02923@silvia.HIP.Berkeley.EDU>
In-Reply-To: <24230.797440549@freefall.cdrom.com> (jkh@freefall.cdrom.com)
next in thread | previous in thread | raw e-mail | index | archive | help 
 * I've added the true dependency stuff built on LIB_DEPENDS and
 * EXEC_DEPENDS and also modified pkg_add to try and load depends on
 * demand.  At the very least, it will bitch about missing packages
 * and quit.

Thanks!  It was not quite I had in mind, as it always tries to look at
the installed packages without checking the existence of shared
libraries (LIB_DEPENDS) or executables (EXEC_DEPENDS).  But that
shouldn't matter very much, because:

 * I haven't done the "make install pretend to be a pkg_add" mods yet
 * since I'm still thinking about them.

you're going to add this soon, right? :)  After we get this, we can
assume that the pkg info will be registered in /var/db/pkg when the
user types "make install" in the ports directory, so pkg_add should be
able to find it.

However, there is another problem, i.e., we don't need everything in
EXEC_DEPENDS to run a precompiled package.  For instance, a package
might need gmake for compilation, but not for running.

To work around this, we'll have to change bsd.port.mk yet again
(further classifying required executables into "needed for
compilation" and "needed for running").

By the way, what about DEPENDS?  I know there aren't many packages
that use that, though....

 * I'm thinking that given my preference of hacks, I'd prefer to see
 * bsd.port.mk have an install rule that mimics pkg_add itself - it can
 * easily create a /var/db/pkg/${PKGNAME}/... directory with the
 * appropriate contents, and it knows more about any peculiarities of the
 * port (like changed PKG_ARGS) that might preclude its being registered
 * this way.

That's right...that's why I was thinking more about modifying (or at
least borrowing code from) pkg_create, that puppy knows how to get the
name of the contents file, etc.

 * This will have to wait until you write your skeleton framework thing
 * so that we don't have to worry about people overridding install and
 * breaking all of this! :-)

Well, I have a little test code.  Check this out:

=======
.if !target(extract)
extract: fetch checksum ${EXTRACT_COOKIE}

${EXTRACT_COOKIE}:
	@${ECHO_MSG} "===>  Extracting for ${DISTNAME}"
.if target(pre-extract)
	@${MAKE} ${.MAKEFLAGS} pre-extract
.endif
	@if [ -f ${SCRIPTDIR}/pre-extract ]; then \
		env CURDIR=${.CURDIR} DISTDIR=${DISTDIR} WRKDIR=${WRKDIR} \
		  WRKSRC=${WRKSRC} PATCHDIR=${PATCHDIR} SCRIPTDIR=${SCRIPTDIR} \
		  FILESDIR=${FILESDIR} PORTSDIR=${PORTSDIR} PREFIX=${PREFIX} \
		  DEPENDS="${DEPENDS}" \
			sh ${SCRIPTDIR}/pre-extract; \
	fi
	@${MAKE} ${.MAKEFLAGS} do-extract
.if target(post-extract)
	@${MAKE} ${.MAKEFLAGS} post-extract
.endif
	@if [ -f ${SCRIPTDIR}/post-extract ]; then \
		env CURDIR=${.CURDIR} DISTDIR=${DISTDIR} WRKDIR=${WRKDIR} \
		  WRKSRC=${WRKSRC} PATCHDIR=${PATCHDIR} SCRIPTDIR=${SCRIPTDIR} \
		  FILESDIR=${FILESDIR} PORTSDIR=${PORTSDIR} PREFIX=${PREFIX} \
		  DEPENDS="${DEPENDS}" \
			sh ${SCRIPTDIR}/post-extract; \
	fi
	@${TOUCH} ${TOUCH_FLAGS} ${EXTRACT_COOKIE}
.endif

.if !target(do-extract)
do-extract:
	@rm -rf ${WRKDIR}
	@mkdir -p ${WRKDIR}
.if defined(EXTRACT_ONLY)
	@for file in ${EXTRACT_ONLY}; do \
		if ! (cd ${WRKDIR};${EXTRACT_CMD} ${EXTRACT_BEFORE_ARGS} ${DISTDIR}/$$file ${EXTRACT_AFTER_ARGS});\
		then \
			exit 1; \
		fi \
	done
.else
	@for file in ${DISTFILES}; do \
		if ! (cd ${WRKDIR};${EXTRACT_CMD} ${EXTRACT_BEFORE_ARGS} ${DISTDIR}/$$file ${EXTRACT_AFTER_ARGS});\
		then \
			exit 1; \
		fi \
	done
.endif
.endif
=======

Replace *both* the pre-extract and extract targets in bsd.port.mk with
this, and see how it works.  The extract stage proceeds as follows:

(1) The pre-extract target (if defined)
(2) The scripts/pre-extract script (if exists)
(3) The do-extract target (defaults to tar -xzf)
(4) The post-extract target (if defined)
(5) The scripts/post-extract script (if exists)

You (the porter) can add any of 1, 2, 4, 5, or redefine 3 as you wish.
It should work without you worrying about the cookie at all.
Redefining the extract target itself is not advised, but if you know
what you are doing, it's ok too (that's why it is surrounded by .if !
target(extract)).

If this looks fine, I'll go in and modify bsd.port.mk.  We'll have to
wait until the 2.0R-ports freeze though.

Is there any way to define a macro to do the env stuff though?
Otherwise, we'll have to duplicate this all over the place....

Satoshi

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504100444.VAA02923>