Mail Archives: cygwin/2008/11/18/18:03:02
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/
- Raw text -