X-Spam-Check-By: sourceware.org
Message-ID: <45A759DE.2080304@users.sourceforge.net>
Date: Fri, 12 Jan 2007 03:50:22 -0600
From: "Yaakov (Cygwin Ports)" <yselkowitz AT users DOT sourceforge DOT net>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: [patch] cygport-0.2.7 hooks for additional prep, install customization
References: <459F1407 DOT 3010200 AT cwilson DOT fastmail DOT fm>
In-Reply-To: <459F1407.3010200@cwilson.fastmail.fm>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Charles Wilson wrote:
> [implementation details]
> [1] Possibiliyt: remove the readonly protection on the existing,
> internal, automation functions (like __prep_installdir or src_prep).
> This is a really bad idea: some of these functions (especially the __*
> ones) are NOT part of cygport's public interface, and are subject to
> change in later releases -- a .cygport file that redefines these is
> brittle with respect to future releases of the cygport framework.

Exactly why they must be marked readonly.

> Others, like src_prep(), are large, complicated, and must NOT be changed
> in any appreciable way, because other functions in cygport depend on
> stuff being "just so".  .cygport files that redefine these functions
> will ALSO be brittle -- and worse, could break things with respect to
> later cygport framework releases that are hard to identify.  Finally,
> carrying around duplicate copies (one in cygport itself, the other in
> the .cygport file) with only minor difference is a silly waste. IMNSHO.

src_prep is not a public interface function either.  I should go through
and rename this and perhaps other functions so that it's clear what's
public API.  (Of course, if cygport were better documented...)

> [2] Possibility: supply additional customization/extension points to
> allow the end user more flexibility to customize certain aspects of the
> automated "tedious steps" when necessary.  Without, mind you, obligating
> .cygport files to carry around lots of redundant copies of functions
> defined in the main cygport framework, nor overriding functions which
> are *supposed* to be internal implementation details of the cygport
> framework itself.

Could you please provide a sample .cygport showing what would be
accomplished with this?

> Obviously, I prefer [2], which is implemented below for the prep and
> install stages.

Refresh my memory, what is the need for the src_install hooks?


Yaakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFp1nepiWmPGlmQSMRCLOUAKDwQzHJQs4krbWDkTxeO0o1nXSStgCcCwud
/PHtARBeISQwuKqxH1dkPMw=
=PgnP
-----END PGP SIGNATURE-----

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/