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 > >⇒ 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 > >⇒ bothersome > > > >with SRC_URI="http://.../${P}.tar.gz"; trying > >cygport ... almostall > >⇒ *** 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 > >⇒ 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 > >⇒ likely, the patch fails, of course, because sources have changed, > >so why is there not a step "unpack" after which I would check the patch? > > > >trying to adapt patch > >⇒ searching for patched files first, somewhere among a bunch of > >directories; > >"origsrc" good guess, but tried "src" first anyway > >⇒ bothersome > > > >trying to remember correct tuning of diff to produce patch; > >adapted patch > >⇒ have to unpack again, with cygport ... prep > >⇒ 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 > >⇒ 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'" > >⇒ 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. > >found R_CONFIGURE_ARGS for "flag(s) to be passed to the configure script > >used by module packages containing native code" > >⇒ 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 > >⇒ 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 »install« zu erstellen. Schluss. > >*** ERROR: make install DESTDIR failed > >⇒ 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=/usr; make; make install DESTDIR=/tmp will configure the project to install into /usr, but the final `make install DESTDIR=...' 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=[your-project-dir/inst] > >if I provide it myself, how would the subsequent step "cygport ... package" > >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. > >⇒ 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 -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
pgph0NfQHcx2j.pgp
Description: PGP signature
