From owner-freebsd-ports  Fri Apr  7 02:36:53 1995
Return-Path: ports-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id CAA00425
          for ports-outgoing; Fri, 7 Apr 1995 02:36:53 -0700
Received: (from jkh@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id CAA00414
          ; Fri, 7 Apr 1995 02:36:51 -0700
Date: Fri, 7 Apr 1995 02:36:51 -0700
From: "Jordan K. Hubbard" <jkh>
Message-Id: <199504070936.CAA00414@freefall.cdrom.com>
To: asami
Subject: Portsmeister!
Cc: ports
Sender: ports-owner@FreeBSD.org
Precedence: bulk

Well, now that you've started your new job.. :-)

Perhaps you can deal with this thorny one:

What do we do about ports like dore and STk that don't really _do_
anything except create a library or two and don't really install
full documentation given the author's assumption that the user is
going to go in and actually LOOK at the port.  They'll see a "README"
and read it, or a "Demos" dir and go in and build one or two demos to
see how things work.  That's all fine, and many things like Stk are
definitely *worth* the effort!  However, that's not my point.
My point is that our new fancy ports scheme HIDES the source trees
for these ports and thus makes it a lot harder for someone to grasp
their purpose quickly.

To put it another way, our ports scheme is built strongly on the premise
that you almost _shouldn't_ have to look at source, that the tarball is
this weird canned object on which strange and incomprehensible magics 
be worked automatically on your behalf.  This works really well for most
ports (well, if the friggin' people would stop shooting archived tarballs
out from under us, anyway :-) but these others are an exception.

We need to figure out some way (or even just a policy) for a port to "export"
parts of itself out of its work directory, ideally in response to some user
feedback ("Do you want to compile and run the demos?").

Hmmmm...  I'm thinking..

How about 2 new features:

1. files/post-build

If this file exists then we execute it as a script (I'd like this as
the default action for the post-build target, anyway).  This would be
very good for putting in post-build files like this:

#!/bin/sh
#
# post-build file for Stk
#
cat << '_*_GORBLE_FINCH_*_'
Stk ===> Now that you've finished the build, you may wish to cd to the
Stk ===> ${WRKDIR}/${DISTNAME}/Demos directory and read the file %README
Stk ===> there - it describes how to run the various demos that really show
Stk ===> off Stk's abilities.
_*_GORBLE_FINCH_*_
<EOF>

This will then at least come up on the user's screen (or build logs)
and give them some warning that the port may need a little special handling.

I assume you were already sort of planning on going in this direction anyway?

2. A demo target.

This would default to a boring "This target provides no demonstration, sorry!"
echo target, but could be overridden to do all KINDS of neat stuff!
You want to show off Dore or STk?  Easy..  Just have demo depend on build
and then go build and run a few demos right out of ${WRKDIR}.  If your demo
requires the software to be installed, depend on install!  Very easy..

What do you think?

						Jordan