X-Recipient: archive-cygwin AT delorie DOT com DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:message-id:date:from:mime-version:to:subject :content-type:content-transfer-encoding; q=dns; s=default; b=JaR Cs0tdekS8THmpf+4xloeoPyfm+FXOD/0gjwvUPl4x/KbEoCddABNNdtKYrCSolOz NTvK3O3Y0xvnkbHE1fMKw+A6917P3GvmF4wmiYnKKxaHC0kOlbes+CI1h12VwaRY EhIUudDKG509+i9zHkuAGq+WSbSMtOMceIQMeeCg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:message-id:date:from:mime-version:to:subject :content-type:content-transfer-encoding; s=default; bh=HZVbAOugM VGyXQm+hPpXVTA1jEI=; b=gF5k9qpxtQWy57hHNR03JFkupDxzTnzs1m5Mbd+Rk yeMup6TMfBhqRT017nZV8Q6UdrAUPfQuMbHl3EF4+lkOG1efL3/URWBTrbQpLYxj eH40gnwJHaIugzpslxwaNQp0XKddjN4Ygx+AqBHfEunLTeAL8endMiCS2adUgD4M Xg= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE,SPF_HELO_PASS autolearn=ham version=3.3.2 Message-ID: <5207C654.2020401@towo.net> Date: Sun, 11 Aug 2013 19:13:56 +0200 From: Thomas Wolff User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: hassles with cygport Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Note-from-DJ: This may be spam 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? 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 ... now archive already downloaded, so cygport [almost]all not desired ⇒ look up sequence of commands (prep, compile, install, package) I couldn't remember 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 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 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"? ⇒ thinking again, not likely to succeed 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?? ⇒ giving up, ignoring this detail for now repeat cygport ... prep cygport ... compile getting message which: no autopoint in ($PATH) cygport hangs ⇒ giving up running configure and make manually 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? 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 ⇒ very obscure attempt: mkdir inst; DESTDIR=inst cygport ... install ⇒ fails, same error –––––– Thomas -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple