DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=MnLWeQECeiUGOu94+uJ4eW8Tkf2iYc0qDB2pTv5Ig+eqTRnxcUPSt
	HBVU/Q58olZnXsnCrlHn0TImitO81DY0r/gNn1Ot9wQAYAIRpTNQWJ5tRN1WT8wK
	nBWXOpMgrzPq7F6g9DKGCoIKRGQFdLSlfNgiHQwdnSXg8ESiHcb9Vc=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Mon, 12 Aug 2013 12:37:30 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: hassles with cygport
Message-ID: <20130812103730.GC2691@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <5207C654 DOT 2020401 AT towo DOT net> <5207CF18 DOT 1050104 AT gmail DOT com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="/Uq4LBwYP4y1W6pO"
Content-Disposition: inline
In-Reply-To: <5207CF18.1050104@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Note-from-DJ: This may be spam

--/Uq4LBwYP4y1W6pO
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Aug 11 19:51, marco atzeri wrote:
> Il 8/11/2013 7:13 PM, Thomas Wolff ha scritto:
> >I tried to migrate a package to using cygport. As I had announced before,
> >I'm using this occasion to report some of the trouble I've experienced
> >with it,
> >listing this case as a kind of "log" of my porting attempt (which
> >finally failed).
> >While probably most of the single problems might appear to be small and
> >easily solvable, the mere amount of issues and peculiarities is what
> >makes cygport a rather cumbersome tool for me.
> >[...]
> >rename old cygport file to new version
> >=E2=87=92 why is this needed? couldn't it be version-agnostic?

You could have used the old style with version number in cygport
filename or the new style with version number in the file.  That seems
rather logical to me.  The new style is much easier to maintain in
future.

> >edit cygport file to change version number of patch file, plus
> >rename patch file to new version
> >=E2=87=92 bothersome
> >
> >with SRC_URI=3D"http://.../${P}.tar.gz" trying
> >cygport ... almostall
> >=E2=87=92 *** ERROR: Cannot find source package ...

almostall does not include the download step.  That's a bug in the
help output, I think.

> >now archive already downloaded, so cygport [almost]all not desired
> >=E2=87=92 look up sequence of commands (prep, compile, install, package)=
 I
> >couldn't remember

almostall works fine if the source package is already available.

> >cygport ... prep
> >=E2=87=92 likely, the patch fails, of course, because sources have chang=
ed,
> >so why is there not a step "unpack" after which I would check the patch?
> >
> >trying to adapt patch
> >=E2=87=92 searching for patched files first, somewhere among a bunch of
> >directories;
> >"origsrc" good guess, but tried "src" first anyway
> >=E2=87=92 bothersome
> >
> >trying to remember correct tuning of diff to produce patch;
> >adapted patch
> >=E2=87=92 have to unpack again, with cygport ... prep
> >=E2=87=92 redundant, but well

I really don't understand your problem here.  If a patch doesn't apply
to the original package, in how far is that cygport's fault?  Did you
ever try to write an rpm spec file?  Both, rpm spec files as well as
cygport scripts are build and packaging scripts.  The package's build
problems are expected to be already solved.

> >need to add a parameter to the package configure script
> >=E2=87=92 trying to find out how to achieve this:
> >after some googling etc, running cygstart
> >/usr/share/doc/cygport/manual.html
> >found WAF_CONFIGURE_FLAGS for "additional arguments to pass to 'waf
> >configure'"
> >=E2=87=92 what is waf??? not likely to lead to success

file:///usr/share/doc/cygport-0.13.0/manual.html#robo23

  waf.cygclass

  [...]

  DESCRIPTION

  Waf is a general-purpose build system written in Python used by XMMS2,
  a few GTK+ programs, and some other projects. The build system is
  defined by a 'wscript' file in the top source directory and
  'wscript_build' files in subdirectories, both of which are also
  written in Python.=20

> >found R_CONFIGURE_ARGS for "flag(s) to be passed to the configure script
> >used by module packages containing native code"
> >=E2=87=92 sounds somewhat better, but what the waf are "module packages
> >containing native code"?

You should start at the top of the manual.  waf, just like R, are
cygclasses to handle build environments for waf resp. R.  These are not
used for default settings but only for projects using waf or R.  There
are a lot of cygclasses to handle various different build environments.

What you're looking for is CYGCONF_ARGS, or the cygconf command:

> >found src_compile, looks more likely to be useful
> >=E2=87=92 however, its description is somewhat "nested", so where would =
I insert
> >specific parameters or commands?
> >it basically appears to call cygmake (which is obviously an internal
> >cygport thing),
> >also another cygport file lists:
> >src_compile() {
> >   lndirs
> >   cd ${B}
> >   cygmake
> >}
> >but cygmake is described "Calls 'make'", so where is configure invoked??

Try this:

  src_compile() {
    lndirs
    cd ${B}
    cygconf [...append configure arguments here or use CYGCONF_ARGS...]
    cygmake [...append make arguments here or use MAKEOPTS...]
  }

lndirs is only necessary for a project which doesn't allow to be built
outside the source tree.  If you have a fairly generic autoconf based
project, you can omit src_compile entirely.  For more complicated cases,
just do something along the lines of the above.

> >trying to take up cygport sequence:
> >cygport ... install
> >getting message
> >make: *** Keine Regel, um =C2=BBinstall=C2=AB zu erstellen.  Schluss.
> >*** ERROR: make install DESTDIR failed
> >=E2=87=92 what is this? should I provide a DESTDIR? the manual says:
> >install into a DESTDIR, and run post-installation steps
> >this is quite unclear, what is "a DESTDIR"? something I need to provide
> >or cygport would pick?

DESTDIR is the default variable used in many projects to define
an installation directory.  This is pretty common, really.  E.g.

  configure --prefix=3D/usr; make; make install DESTDIR=3D/tmp

will configure the project to install into /usr, but the final
`make install DESTDIR=3D...' will install the files under /tmp/usr
for packaging.

Cygport's default installation routine is called cyginstall.  That's
what is called by default if you don't specify your own src_install()
function.  The default behaviour of cyginstall is to call the pretty
common

  make install DESTDIR=3D[your-project-dir/inst]

> >if I provide it myself, how would the subsequent step "cygport ... packa=
ge"
> >know which DESTDIR I used? I could provide it again, but this is not
> >mentioned in the manual

You don't have to define DESTDIR by yourself.  See above.

> >=E2=87=92 very obscure

Did you look into the cygport files of other projects?  That may be a
good help.  There are many hundreds of them in all kinds of
complexities from dead easy to almost too much to handle.  Also, when
you're in trouble packaging a project, there's the cygwin-apps list
which can be used by the maintainers to ask questions.  I don't know the
answer to all packaging problems myself, so when I'm in trouble, I ask
on the cygwin-apps list.  So far this always got me over the packaging
bumps.  As far as I'm concerned, asking the ML for help is much better
than complaining.


Corinna

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--/Uq4LBwYP4y1W6pO
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)

iQIcBAEBAgAGBQJSCLrqAAoJEPU2Bp2uRE+gunoP/179bXfuS2Og1Gj0JAbDsIum
XXl/mMZKZvF9E1yAweB7efSVo3qJipmoYiyID5nU8bPEGiGN5l+WDa1DRUBaS/RC
EtKeTaK0hQpIUNMzGabP2ApRvRP60DfWaGqEUwByrI6Sbaalx9W+gPKvr1Vc1DcK
qnp4QhH52rvkvv3PP80W+l9cq64H1boiCm3jTpEJ+TY36rIfm3YSY5RVOwt5SDFS
lP4blu2KptJe7qhJuFKdKqpgQgrNesX2Vhaf+6tEVXnTHbxhPRRya0Fm/baF8pfR
zDgFYXhDSmUo9W/7YkdQh4H4SvefMVhdTXygrtFUzxz1rc1QrsB2vwpHnQYW9e/q
v4wwNFygI4F4fpYwmLzcqDF6/WWLmewi9nCIWpJudCbagfkjZuQZPnBdl9yk+5XN
TB5JNLM5gPA2+VLpJ5IiVRvlpI9GIZBxOEHBiTdoCemAbTiMg39RyU77k2N3u8he
8fCip0C4trA1ODsqmLY5FPAvU4gHoYR10xbffRyWaZGDzmtZJopwwcyGPX9v44zq
WIYlVP/2q/+fG3H0FyFgfREB9csG5B0kQrvEB2xLbhnADNcQ1i8Y82LUPrTKO8ej
11qOuCoorZ6kxBK3LpGG2PrPtExEGjAnvg3oMGoUDfqvyBmaMuKtS0lGO7wU5hMZ
9DRa1oMDBoAnZmy3xUhr
=PiNg
-----END PGP SIGNATURE-----

--/Uq4LBwYP4y1W6pO--