Date: Sun, 9 Apr 1995 04:18:59 -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: <199504091118.EAA06344@silvia.HIP.Berkeley.EDU> In-Reply-To: <16849.797424641@freefall.cdrom.com> (jkh@freefall.cdrom.com)
next in thread | previous in thread | raw e-mail | index | archive | help
* 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>.
Well, if you ask me to design the bsd.port.mk from scratch (with all
the 20-20 hindsight, of course :), I'd probably get rid of the shell
scripts. Overridable Makefile targets should be fine, 'cause the user
can then call the shell script from there if s/he wants. :)
One thing I don't like about shell scripts is that (I think this is
what you mean when you said they "obfuscate" things) they are not in
the Makefile. I often forget to do "ls files/" and scratch my head
wondering why the Makefile is doing something I can't see. ;)
And about the Otis Spunkmeyer cookie things, my previous proposal was
aimed exactly to eliminate that problem...i.e., the porter can change
(almost) anything s/he wants without worrying about the cookies.
* > 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.. :-)
Or you can re-define the targets. As you can see, you can either
define pre-extract in the Makefile or put a shell script in
scripts/pre-extract. Both will be supported.
* > .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..
Hmm, I'm not sure what you are asking here. It's run from within the
extract rule, as you can see above. It (post-extract) will be run
even if it's overridden, of course. Or am I missing something here?
* > 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.
Well, okay, then what about "touch it at your own risk, but we really
think you can do what you want by only modifying do-extract". :)
The "extract" target doesn't do any real work, it's just a skeleton
that calls various targets/shell scripts. So why do you need to
redefine it? The actual extraction is done in "do-extract"....
* > # 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..
*
* :-)
Gee, I guess we need to start PGP encoding messages soon.... ;)
Satoshi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504091118.EAA06344>