On Fri, 2012-10-19 at 11:21 +0200, Corinna Vinschen wrote: > On Oct 18 12:20, Yaakov (Cygwin/X) wrote: > > None; should I also move the other setup.exe prerequisites for > > i686-w64-mingw32? Would you also like x86_64 versions of any of those? > > If it's not asked too much, sure on both accounts!
Done. > The theory is that cygwin will continue to co-exist with mingw and > w32api for a while, but cygwin does not build or use mingw and w32api. > However, winsup/configure.in adds mingw and w32api subdirs to SUBDIRS > based on the mere existence of the dirs. > If we want to make Cygwin independent of mingw/w32api and vice versa, > I'd suggest the following patch to winsup/configure.in instead: > > This builds cygwin, cygserver, lsaauth, utils and doc dirs > if the target is Cygwin, mingw and w32api otherwise. I'll incorporate that into my next draft. > Just as a note for the future, we don't have to fix that immediately: > > Given that the lsaauth modules don't call any Cygwin function but rather > only use a few Cygwin datastructure, and given that we now require a > mingw compiler to build the native utils anyway, I'm wondering if we > shouldn't simply require the x86 and x86_64 targeting mingw compilers to > build the lsaauth modules as well. > > If we do that, we could already build the 32 and the 64 bit versions > of the lsaauth module today, right from the Makefile. That sounds > like a much better solution than the make-64bit-version-with-mingw-w64.sh > script and keeping the 64 bit DLL as a binary blob in the repo, doesn't > it? Agreed, I'll add that too. > A very minor nit: Personally I feel better if variables are braced in > such a scenario. From my POV it's also easier readable: > > AC_CHECK_PROGS(MINGW_CXX, ${target_cpu}-w64-mingw32-g++ > ${target_cpu}-pc-mingw32-g++) Fine. > Other than that, I think it's good to go in after the 1.7.17 release. > I'll try to do the release at some point between now and Monday. I'll include those changes and post a new patch then. Yaakov