This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: Recent cygport and cygwin-specific READMEs [Was: Re: GCC-4.7.2-2: Go/No-go?]
- From: "Yaakov (Cygwin/X)" <yselkowitz at users dot sourceforge dot net>
- To: cygwin-apps at cygwin dot com
- Date: Thu, 11 Apr 2013 17:37:34 -0500
- Subject: Re: Recent cygport and cygwin-specific READMEs [Was: Re: GCC-4.7.2-2: Go/No-go?]
- References: <51643F10 dot 7000905 at gmail dot com> <87eheixuz8 dot fsf at Rainer dot invalid> <20130410154730 dot GA404 at ednor dot casa dot cgf dot cx> <516599BE dot 7090000 at gmail dot com> <51661EA2 dot 1070801 at users dot sourceforge dot net> <51665212 dot 6050101 at gmail dot com> <51665F0F dot 8040902 at users dot sourceforge dot net> <5166AE89 dot 2050704 at cwilson dot fastmail dot fm>
On 2013-04-11 07:37, Charles Wilson wrote:
#1) Is it possible to also record cygwin-specific README content within
the cygport(5)? [1] If so, can you do more than one? (I'm thinking here
of inetutils, which has a separate cygwin-specific README for the
-server (sub)package and for the -client (sub)package).
No, cygport(1) doesn't generate README content.
#2) Is it possible to use the auto-setup.hint-generator functionality
for multi-part package sets (e.g. which contain multiple separate
tarballs, in addition to -src and -debuginfo)? If so, how?
Yes; it just works, and also handles inter-subpackage dependencies (e.g.
apps in foo will dep libfooX, and implibs in libfoo-devel will dep the
corresponding DLL in libfooX). Just define CATEGORY/SUMMARY/DESCRIPTION
(there are also subpackage-specific variants of these) and omit the hint
files from $C; at the end of the package stage, cygport will show you
the dependencies it computes for each package so you can check them. If
there are undetectable deps (e.g. commands called by a script or fork(),
or runtime data, etc.), then those can be added in [$subpackage]_REQUIRES.
#3) As I've been gone for a while, I might've missed recent changes: do
setup.exe and/or cygport support build dependencies directly in any way,
rather than the ad-hoc put-it-in-a-cygwin-README "technique" I've been
using 'til now?
See DEPEND in the cygport manual. (Yes, this is confusing now that
REQUIRES exists for additional *runtime* dependencies. I'm thinking of
renaming this to BUILDREQUIRES or the like, but for API compatibility
DEPEND would still work.) These are checked at the beginning of the
build step, and a warning issued if any are missing.
Yaakov