On 7/6/2010 11:59 AM, JonY wrote:
On 7/6/2010 23:36, Charles Wilson wrote:
Now, in this case you do NOT want to run autoreconf. The gcc codebase
requires "careful handling" if you want to update the auto* generated
files; autoreconf is not smart enough.
I did this too with the libstdc++-v3, libgomp and etc, but only
libobjc-2 is having trouble?
Correct. The reason is because the relevant changes are in Makefile.am
and Makefile.in (or configure.host) for those other libraries. For
libobjc, the change is in configure.ac/configure.
What's even trickier, is that cygport's heuristic for determining
whether to exclude Makefile.in relies on the design of the *top*
directory of the source. For a number of odd reasons, the top level gcc
directory doesn't cause the "exclude Makefile.in" logic to fire -- but
it DOES cause the "exclude configure" logic to fire.
So, you end up with the patches to Makefile.am and libobjc/configure.ac
(and configure.host) as expected. You ALSO end up with the Makefile.in
patches (because the "exclude Makefile.in" logic in cygport did not
fire), but you miss the libobjc/configure change because the "exclude
configure" logic DID fire.
Perhaps the simplest is an extra command in src_build:
(cd ${S}/libobjc && autoconf)
to just force the end user to "fixup" THAT configure script only,
without mucking with any other auto* generated files.
Right now, libtool version difference prevents that from going smoothly.
Err...I didn't have any problems running *autoconf* in that directory (I
did NOT run "autoREconf). But I didn't think this was the best option
anyway...
Another option (one that I've had to use on occasion) is to give up on
letting cygport handle the patch generation for .src.patch. What you do,
is you just don't HAVE a .src.patch. Instead, you make your OWN patch,
ensure it contains all the files you want to include, like
libobjc/configure, and name that patch ANYTHING but ${P}.src.patch.
Then, add this to your cygport:
PATCH_URI="the-name-of-my-custom-patch"
Just use diff -ur origsrc src right? I have not actually edited any
files other than the autotool stuff.
Yes (*) -- but not without manually editing the result, because you'd be
quite likely to pick up a lot of cruft that you don't want. That's why
cygport goes to such trouble to build an exclude list.
However, when I use this option...that's exactly what I do:
diff -urN origsrc src > foo.patch
and then edit foo.patch to remove those bits I *know* should not be
included.
(*) If you know you added some files to src/*, then also use -N. Also,
for the ".src.patch replacement", you'll want to use -x CYGWIN-PATCHES.
However, before you modify your .cygport recipe to rely on un-official
cygport patches, let's make sure Yaakov actually accepts the patch. (I
know from long painful experience that you do NOT want to get ahead of
Yaakov's patch-acceptance process).
I can see his hesitation about accepting the .cygport file, it won't
build cleanly on another machine unless its patched too.
Well, let's be clear: it's not Yaakov that accepts your package .cygport
file. He is in charge of the cygport tool, nothing more (well,
actually, a WHOLE GIANT PILE more of additional packages, but that's not
relevant here).
In the VAST majority of cases, we'd prefer that any package in the
distro that purports to use 'cygport' to build, actually uses THE
official cygport. But there have been exceptions in the past; these
exceptions caused a lot of extra list traffic and pain for the provider
(me!) of the package whose cygport required the modified tool.
So...there will be pain; I advise you to avoid that pain; but...I
*think* you can do it (rely on a custom cygport tool with minor
modifications) if you really think it is necessary. Final decision on
that rests with the consensus of other package maintainers on this
list...not JUST Yaakov (and not just me, either).
Given all that, this remaining issue where libobjc/configure is not kept
in sync with libobjc/configure.ac is the only remaining problem with
rebuilding the mingw64-gcc packages. With that corrected, it rebuilds
fine from source.
Alright, thanks for the review, I'll get a new upload as soon as possible.
No, no...please slow down. You're doing a lot of extra work and
honestly, I can't keep up. Let's "bundle" changes an only update the
cygwin packages on sf.org when it makes sense to do so. That would save
you a lot of extra unnecessary work, I think.
I think right now, we're waiting on a verdict -- or alternate suggestion
-- from Yaakov about what patches he will accept in (a soon to be
released version of) cygport, the tool.
--
Chuck