Date: Sat, 8 Apr 1995 22:12:58 -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: Portsmeister! Message-ID: <199504090512.WAA04019@silvia.HIP.Berkeley.EDU> In-Reply-To: <25886.797308894@freefall.cdrom.com> (jkh@freefall.cdrom.com)
next in thread | previous in thread | raw e-mail | index | archive | help
* post-configure is a special action carried out by the configure target
* itself. It *goes away* if you override the configure target and don't
* clone the post-configure pass in! Put another way, post-configure is
* not a _real_ target the way pre-configure is (pre-configure is
* actually a target OR a script - you can have both). If it's not a
* real target, then you can't override it and/or layer it into a
* existing override sequence easily.
Well, you are right that pre-configure is a "real" target, but it's
called from within configure too so it will also go away if the porter
redefines configure and doesn't put in the call to pre-configure.
Also, the calling of ${SCRIPTDIR}/pre-configure is inside configure,
not pre-configure, so it is still in the exact same boat as the
post-configure script.
Note that we can't completely take the {pre,post}-configure targets
out of the configure target (including depending on it) because when
the user types "make configure" s/he would expect it to do all three,
not only the middle part.
Right now, the various stages (fetch, extract, configure, etc.) have
all sorts of different ways to handle the pre-* targets. Some are
called recursively from within the "main" target of that stage, some
are dependencies of the main target, some are scripts called from the
main target. I think we should clean this up a bit.
There is also this problem of dependency linkage, as right now extract
depends on fetch, patch depends on extract, etc., so if the porter
redefines the patch target and forgets to include the dependency to
the extract target, it would lead to strange errors.
This is the solution I propose:
Change the current targets to skeletons that only serve as a chain of
dependencies, and call the "real" targets, including the pre-* and
post-* targets, from there. The default pre-* and post-* targets are
empty, but the main chain includes calls to scripts if they exist.
For example, the "extract" stage will go like this:
extract: fetch ${EXTRACT_COOKIE}
@${ECHO_MSG} "===> Extracting for ${DISTNAME}"
@{MAKE} ${.MAKEFLAGS} pre-extract
@if [ -f ${SCRIPTDIR}/pre-extract ]; then \
env (a bunch of stuff here...can we use a macro?) \
sh ${SCRIPTDIR}/pre-extract; \
fi
@{MAKE} ${.MAKEFLAGS} do-extract
@{MAKE} ${.MAKEFLAGS} post-extract
@if [ -f ${SCRIPTDIR}/post-extract ]; then \
env (a bunch of stuff here...can we use a macro?) \
sh ${SCRIPTDIR}/post-extract; \
@${TOUCH} ${TOUCH_FLAGS} ${EXTRACT_COOKIE}
.if !target(pre-extract)
pre-extract:
@${DO_NADA}
.endif
.if !target(do-extract)
do-extract:
(the current (real) extract target goes here....)
.endif
.if !target(post-extract)
post-extract:
@${DO_NADA}
.endif
The porter is not supposed to touch the "main" targets (extract in
this case), but s/he can do pretty much anything without worrying
about the GRANMAS_COOKIE and dependencies and other fancy stuff.
The downside of this is that it will break the backward compatibility
so we'll need to shut down the auto-update of the ports tree on
wcarchive for a while while we go in and rewrite some of the
Makefiles. Fortunately, in most cases, it only means adding "do-" in
front of the porter-defined target and taking out the cookies and
other crunchy stuff, so it shouldn't be too hard.
* > * Yes, well, since you're working on the GUIDELINES _anyway_.. :-)
* >
* > Hey, I thought I punted the GUIDELINES and you fair-caught it! No? ;)
*
* Heck no..! :)
But but but but but....
# Date: Tue, 04 Apr 1995 04:09:08 -0700
# Message-ID: <10190.796993748@freefall.cdrom.com>
# From: "Jordan K. Hubbard" <jkh@freefall.cdrom.com>
:
# > However, I just don't have the time to finish it now so I'm going to
# > punt for now, hopefully someone with a fresh brain and a better
# > command of English can take a look. I don't want to confuse users, so
# > I won't commit my unfinished work, you can get it from my home
# > directory on freefall or "ftp://forgery.cs.berkeley.edu/pub/GUIDELINES.gz".
#
# Ok, I'll have a look! Thanks for at least trying, Satoshi!
Wasn't this you? ;)
Satoshi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504090512.WAA04019>