This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ITP] mingw-w64


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]