[ITP] mingw-w64

[JonY]

On 7/7/2010 04:26, Charles Wilson wrote:
> 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.
>

OK, I've updated the cygport in the mingw64-tc64-gcc4 source file, no 
changes to the other files. I've added the cd ${S}/libojc autoconf calls.

I'll be away for about a week, so do take your time to review too. 
Yaakov can also give his opinions.