From owner-freebsd-ports  Sun Apr  9 03:50:44 1995
Return-Path: ports-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id DAA16859
          for ports-outgoing; Sun, 9 Apr 1995 03:50:44 -0700
Received: from localhost (localhost [127.0.0.1])
          by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id DAA16850
          ; Sun, 9 Apr 1995 03:50:41 -0700
X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol
To: asami@cs.berkeley.edu (Satoshi Asami |
    =?ISO-2022-JP?B?GyRCQHUbKEI=?=
    =?ISO-2022-JP?B?GyRCOCsbKEIgGyRCOC0bKEI=?=)
cc: ports@freefall.cdrom.com
Subject: Re: Portsmeister! 
In-reply-to: Your message of "Sat, 08 Apr 95 22:12:58 PDT."
             <199504090512.WAA04019@silvia.HIP.Berkeley.EDU> 
Date: Sun, 09 Apr 1995 03:50:41 -0700
Message-ID: <16849.797424641@freefall.cdrom.com>
From: "Jordan K. Hubbard" <jkh@freefall.cdrom.com>
Sender: ports-owner@FreeBSD.org
Precedence: bulk

> 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.

So what would you have us do?  Go *only* with targets and eliminate
the optional shell scripts?  Shell scripts do have the benefit of
being easy to write and test, but they also obfuscate things somewhat
and, as you say, they don't follow a target when you override its
rules.  On the other hand, it's also hard to override targets that
depend on cookies!  You have to duplicate the cookie-checking behavior
entirely in the Makefile since its rules come before .include <bsd.port.mk>.

Maybe you want to split things into <bsd.port-var.mk> and <bsd.port-rules.mk>
(<bsd.port.mk would just include them both, for backwards compat)
so that you can sandwich the custom rules in-between if you like? :-)

> 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}

Ah, so you're essentially advocating the elevation of shell scripts to
sainthood status, since they'd now be used to do just about *all*
override actions.. :-)  

> .if !target(post-extract)
> post-extract:
>         @${DO_NADA}
> .endif

But who runs post-extract?  What if that target is overridden?  You
still want the rule chain to be obeyed, no matter which pieces have
been "jacked out" in favor of a local target..

> 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.

I see - you don't *want* people to jack out the main targets.. :-) I'm
not sure that will fly - you really should be able to override any
phase of the port's lifecycle with minimal collateral damage.

> 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>

Not me.  A clear forgery.  I sign the "." at the end of "K" with an
entirely different "hidden attribute" font, and I can spot imitations
immediately from the subtle imperfections..

:-)

					Jordan