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 23:36, Charles Wilson wrote:
On 7/6/2010 1:10 AM, JonY wrote:
I had a thinko, thanks for the patch. Yeah, cygport moves the libtool
dlls around.

I will recheck on the README file and libobjc-2, I thought I patched up
the configure file.

You did, but...


Alright, I repackaged binutils to add the /etc/profile.d scripts

I'll look at mingw64-binutils again later. But right now I'm looking only at mingw64-gcc:

and
repackaged gcc to get rid of the wrongly installed objc dll.

With the new libtool restrict, no more moving needed. I can also confirm
that libobjc-2.dll goes into bin32 and bin64 on cygport install.

I found the problem: configure.ac is patched, but there's no mechanism to ensure that the corresponding change to configure is included in the patch (by default, cygport *assumes* you will run autoreconf, and so explicitly excludes configure, Makefile.in (for automake projects), etc from the diff.)

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?


So, there are a couple of ways around this. All are pretty ugly.


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.



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.



But...this cygportism has bugged me for a while. So, I tried to create a generic facility where you could, for instance, do:

DIFF_NO_EXCLUDES="configure Makefile.in *.m4"

and then cygport would ensure that, even if it ordinarily would exclude
a file from the diff, if that file name (or pattern) appears in
$DIFF_NO_EXCLUDES then it would avoid doing so. But that got to be
really hard, what with all the word expansion and shell metacharacter
worries. (Plus, it would have slowed down ALL cygports in a pretty big
way during __pkg_diff, for the benefit of only a few.)

So, instead, I whipped up a different patch to cygport which only tells
cygport to avoid automatically adding the autoconf, automake, and
aclocal-generated files to the diff excludes list. To use it, add this
to your cygport:

RESTRICT+=" autoreconf-diff-excludes"

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.



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.



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