On 7/13/2010 1:36 AM, Yaakov (Cygwin/X) wrote: > On Mon, 2010-07-12 at 22:45 -0400, Charles Wilson wrote: >> I don't really care either way about that one. What about things >> associated with $sysconfdir and $localstatedir? (e.g. /etc and /var are >> usually "outside" of $prefix). For cross (clients), suppress >> prep_etc_defaults, and assume $sysconfdir and $localstatedir are >> underneath $prefix? > > IIUC /etc and /var only belong outside of $prefix when $prefix == /usr. > Any other $prefix and they go back underneath, so that's what I'm doing.
That's what I figured. >> Hm. A 64bit version of setup.exe; interesting. I don't mind providing >> the additional packages for that; the list of setup's dependencies isn't >> THAT long. > > No, I said i686-mingw64. You're right; I misread. > I easily cross-built setup's deps for that > toolchain then tried to build setup, but the mingw64 DDK headers are > clearly not up to the task; they #include headers which do not exist and > apparently some headers are missing. setup.exe needed some adjustments > as well even as far as I did get. To be continued. There is an "add-on" component that can be treated as part of the mingw64-crt-* build. You download it separately from reactos or wine, I don't remember, drop it in (a specific) place, and THEN configure and compile. Anyway, I wonder if the "missing" files are expected as part of this add-on? >> Technically, the mingw.org folks say the only cross compilers they >> support are ones built using this tool: >> >> http://sourceforge.net/projects/mingw/files/Cross-Hosted%20MinGW%20Build%20Tool/x86-mingw32-build-1.0.1-rc1/x86-mingw32-build-1.0.1-sh.tar.bz2/download >> >> but...we probably would provide support for "our" cross compiler right >> here, anyway. And we can probably coordinate "our" build closely enough >> with the mingw.org folks that they would likely "bless" our version, too. > > We should definitely be coordinating patches and configure options so > that our compiler is actually compatible to theirs. Whether or not they > "bless" is up to them. Oddly, I'm not at all sure that the native mingw.org gcc-4.5.0 is identical to the cross-built one generated by this script. For instance, the cross script ensures that the target libs are built using -mms-bitfields. It's not clear to me that the native one does that, unless it happens automatically. So...they (may) have their own issues, in that regard... >> E.g. I want to have a package: >> >> chucks-tools-VER-REL that has >> requires: mingw64-i686-libstdc++6 >> >> Why is this verboten, when all it takes is a little cygport magic no >> different that any of our other 500 native cygwin packages, or your >> other 2000 cygwin ports packages? > > IOW you want to make a mingw mini-distro driven by setup.exe. No, I want to locally extend my team's toolkit, currently based on cygwin, by providing a few local native tools they can install within that same cygwin core installation. This is not a mingw distro. > That's > IMO not within the realm of the *Cygwin* distribution, nor should it be. And naturally these extensions would be inappropriate to ITP, so I'm not trying to add them to Cygwin's actual distribution. >> Again, this boils right back down to the fact that here, our Host >> platform can simultaneously execute applications (and libraries) from >> both the $host and the $target. > > So therefore we should change the distro into some Cygwin/MinGW hybrid > where anything goes as long as it's PE? So why not put the DLLs > in /usr/bin? Hey, throw in DJGPP while you're at it. You could even > convince GCC to treat them all like a m32/m64 multilib... Now you're just setting up a strawman, and not doing a very good job of it, either. I never said anything like that. ALL I'm saying is that I think we ought to split out the gcc language runtime DLLs into separate packages, JUST like we do for every OTHER DLL in the entire distro. And furthermore, for those cross-compiled packages that are ALREADY part of the distro, and which ALREADY split the DLLs into separate packages, that they should continue to do so. Nothing more. And I never suggested anything like "Cygwin/MinGW hybrid anything goes as long as it's PE"; nor did I ONCE in thousands of words in these related threads suggest that mingw DLLs should go in /usr/bin (except maybe mingwm10.dll 'cause it's already there, but I wouldn't mind its disappearance either). Argue against what I actually said, not some strawman creation of your own. > ... Wait, sound familiar? It was called "-mno-cygwin". Yes, we used to > do just that, and IT DIDN'T WORK. And even worse, people got confused. > So now we're moving *away* from that, and for good reason. No, what I actually said doesn't sound anything like -mno-cygwin. Jeez. How you get there from a simple discussion about whether libgcc-1-sjlj.dll goes into its own package, or gets folded into the main cross-gcc package...is a mystery beyond mortal ken. > Sorry, but no thanks. MinGW's place within the distro should be for > cross-compiling. Well, hell's bells, I suppose we shouldn't include any of the actual RESULTS of cross compiling at all. I'll just mosey over to sourceware and delete mingw-zlib, mingw-bzip2, mingw-libgpg-error, mingw-libgcrypt, and mingw-xz then. After all, they are not part of the actual mechanics of cross-compiling, are they? People should just USE the MinGW cross tools we provide and always compile everything from scratch. Because there's no place for MinGW stuff except the cross compiler itself within cygwin. That's ridiculous. (Now THAT's how you do strawmen!) >> cygwin != linux -- *especially* when it comes to runtime interactions >> with win32. > > From the website: "Cygwin is a Linux-like environment for Windows." Linux-like. Not a linux clone. Otherwise, we should remove /proc/registry. And regtool. And cygrunsrv. > The point is that Cygwin should strive to be like Linux wherever > possible. Focusing on running MinGW instead of building it is doing the > exact opposite. BS. We are ALREADY providing all of the necessary items, in exactly the necessary location to allow "mingw" items to execute from within sys-root. You are attempting to enforce your idea of the "proper" use of cygwin by unnecessarily bundling an 84k DLL into a 12MB toolchain, so that only *developers* using mingw-gcc are "allowed" to execute cross-compiled tools installed within sys-root. But those lesser mortals who don't actually compile those apps themselves are not allowed to execute them within sys-root, unless they download 11.9MB of crap they don't need. Maybe we should just switch cygwin over to a pure gentoo ebuild system, since we are apparently required to hate people who don't compile everything for themselves. I don't have the words...and THAT's saying something. >> Fortunately, I don't have to convince you of this; I only have to >> convince JonY of the utility of splitting the language runtime DLLs into >> separate packages. That's purely the decision of the maintainer, and >> how he writes the final cygport(5) and has little to do with the >> cygport(1) script. > > That's the unfortunate result of having few, if any, policies wrt to > packaging; everyone just does whatever they want, and as a result we > have almost no consistency or adhesiveness in the distro. No, that's called freedom -- and, surprising as it may seem, not everyone agrees with you in every particular. You are not Linus -- and not even he gets to dictate how Red Hat assembles their distro. > My views on > packaging come from a bigger picture, based managing thousands of > packages over years, together with observing how other distros do > things. No, you don't get to play that game with *me*. Suffice it to say that my experience is even more long-term, and just as extensive, and my opinions are JUST as valid as yours. > I suppose we'll need cgf and Corinna's opinion on this one. Right. I can see it now: Contrary to all prior and existing examples, for cross-compiled packages for $host mingw, and cross compilers $targeting mingw, we will not accept ITPs in which the the relevant DLLs have been placed in separate tarballs. Also, existing cross-compiled packages must be repackaged to meet the new guidelines. No matter what the poor sap volunteering to actually do the work wants, or has done historically with pre-existing packages like mingw-xz. Because We Control The Horizontal And The Vertical, and We Have Decided. And this sudden and radical departure from the current relatively laissez-faire regime of ITPs is necessary because...Yaakov thinks putting *some* DLLs into separate packages is icky. But not *other* DLLs. -- Chuck
