Mailing-List:	contact cygwin-apps-help AT cygwin DOT com; run by ezmlm
Sender:	cygwin-apps-owner AT cygwin DOT com
List-Subscribe:	<mailto:cygwin-apps-subscribe AT cygwin DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin-apps/>
List-Post:	<mailto:cygwin-apps AT cygwin DOT com>
List-Help:	<mailto:cygwin-apps-help AT cygwin DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To:	mailing list cygwin-apps AT cygwin DOT com
Message-ID:	<08a901c19a99$d9a09c60$0200a8c0@lifelesswks>
From:	"Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To:	"Gareth Pearce" <tilps AT hotmail DOT com>, <cygwin-apps AT sources DOT redhat DOT com>
References:	<079301c19a87$404969a0$0200a8c0 AT lifelesswks> <OE38GpaoG1VRIjn04x20000c6a4 AT hotmail DOT com>
Subject:	Re: new policy for packages
Date:	Fri, 11 Jan 2002 23:16:50 +1100
MIME-Version:	1.0
X-Priority:	3
X-MSMail-Priority:	Normal
X-Mailer:	Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE:	Produced By Microsoft MimeOLE V6.00.2600.0000
X-OriginalArrivalTime:	11 Jan 2002 12:16:48.0719 (UTC) FILETIME=[D7F92DF0:01C19A99]

===
----- Original Message -----
From: "Gareth Pearce" <tilps AT hotmail DOT com>

> This makes sense to me - however I was wondering to what extent.
> 1. no packages which have run-time dependencies on non-packaged.

Yes.

> 2. no packages which have Build time dependencies on non-packaged
during
> 'standard' compile.
> 3. as 2 but even if the code distributes an 'internal' copy.

Hmm, less concerned about these while setup doesn't support
build-depends. Once it does, perhaps a case by case approach. While
Chuck goes to heroic efforts (and I'm leveraging off those :}) to make
building trivial, the key for binary distro's is to remove the need for
users to build - thus making building a significantly lower priority.

> 4. no packages which can have build time dependencies on non-packaged
with
> an additional configure flag or similar.

This one is insane :}. Most packages have configure options for
different platforms, and this would exclude them - including many of our
current packages.

> Another requirement consideration - which I am unsure if would be
wanted -
> but thought I might put it up for discussion.
> All 'library' style packages must provide dynamic link libraries (if
> possible?).

No. I think it's preferred, but certainly not a requirement. bfd for
instance isn't available on win32 as a .dll. It would be nice if it was
though :].

> I was considering looking at packaging up slang or a few other
things - but
> thought that not providing dynamic libs would be the wrong move to
take, and
> due to lack of experience in making 'good' dynamic libraries on my
behalf -
> decided I would put it off, (prehaps hoping someone else would do it)

Start with static libraries, and as you get more experienced start with
the easy ones then to the harder ones, making them dynamic. I'm happy to
provide tips, as (I think) Chuck is on .dllizing libraries. libtool
libraries are easy, and my -shared and --auto-export hack to libtool has
been accepted, so we should have offical support soon for that.

Rob

- Raw text -