X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Message-ID: <492348E7.2090506@lysator.liu.se>
Date: Tue, 18 Nov 2008 23:59:51 +0100
From: Peter Rosin <peda AT lysator DOT liu DOT se>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Cygport fails to prep correctly
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Hi!

I'm trying to switch a couple of packages over to cygport from
some g-b-s derived djungle.

<background>
Some of these packages need to be patched with extra headers
that are missing in the w32api package in order to build
correctly. The license of these headers are incompatible with
w32api (they are LGPL) and can therefore not go upstream
without recreating them from scratch.
</background>

The problem is that cygport seems to b0rk the prep stage when
it faces the patch file it created itself when you try to
rebuild with the produced -src.tar.bz2 package. It seems that
the heuristic that tries to find the correct -p option for
patch fails when the patch applies anywhere, as is the case
with these patches as they only add files, there are no
modified files.

For reference, I have a .src.patch that has one hunk like
this, as generated by "cygport [...] package":
--- origsrc/libgii-1.0.2/include/directx/dinput.h	1970-01-01 01:00:00.000000000 +0100
+++ src/libgii-1.0.2/include/directx/dinput.h	2008-11-18 09:24:09.968750000 +0100
@@ -0,0 +1,2292 @@

After prep I get the added file, not in the expected
src/libgii-1.0.2/include/directx, but instead in
src/libgii-1.0.2/src/libgii-1.0.2/include/directx which of
course isn't working very well...

I argue that cygport should definitely try the -p option
that matches what cygport produces first, and only then fall
back and try others.

If that's not an acceptable change, what should I do to work
around this bug? Add a bogus whitespace-change hunk to some
innocent victim file to "tie" the patch to the correct strip
level and thereby help the b0rked heuristic?

Cheers,
Peter

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/