On Thu, Mar 14, 2013 at 11:27 AM, Corinna Vinschen <[email protected]> wrote: > On Mar 14 10:53, NightStrike wrote: >> On Thu, Mar 14, 2013 at 5:13 AM, Corinna Vinschen <[email protected]> >> wrote: >> > On Mar 13 16:18, NightStrike wrote: >> >> On Wed, Mar 13, 2013 at 7:22 AM, Corinna Vinschen <[email protected]> >> >> wrote: >> >> > Hi, >> >> > >> >> > I'd like to resurrect a patch which has been refused last year, but >> >> > I think it's still helpful and maybe the opinions have changed a bit. >> >> >> >> Sorry.. did I refuse it? Can you link to the mailing list archive (I >> >> understand that the SF interface blows for that...) >> >> No link? I tried to find it and could not. > > Do we really need that? I didn't keep a local copy and searching the > ML archive sucks.
I just thought maybe there was more enlightening discussion. >> >> I'm a little confused here. What we require, ie, the only situation >> >> that we support, is when the version of the headers is the same >> >> version of the crt. Ie, svn checkout revision. Anything outside of >> >> that will probably work, of course, but nobody tests it. >> > >> > Sure, I'm not claiming anything else, nor am I trying to do anything >> > else. I want to build a full mingw tree, without having to have >> > anything installed outside the source or build tree. >> >> When you say "full mingw tree", do you mean that you are building crt, >> headers, and tools using the top level configure/make, as opposed to >> building each thing you want independently? > > Exactly. Doing that is a fairly typical scenario, isn't it? Actually, no. Pretty much nobody uses the top level configure. It was an idea that I had that nobody really wanted, and so it fell into disuse and doesn't really work (which I guess is what you are seeing). If you want top level configure to work again, give me some time and I'll work on it to make it useful. There's actually numerous problems with it, not just the hokiness of trying to stage a headers install. >> >> Now, in terms of the configure test that errors out in the case of not >> >> finding _mingw_mac.h, that is due to the fact that the headers are >> >> required to build the crt. We don't care where they are, we just care >> >> that they exist. If they don't, the crt build will be all fouled up. >> > >> > I'm puzzeled. That has nothing to do with my patch. >> >> Your patch changed when it errored out. > > Sorry? When did my patch change? When did it error out? I realy don't > understand what you're talking about. Your patch moved the criteria for erroring out on the non-existence of mingw_mac.h: -AC_CHECK_HEADER([_mingw_mac.h], [], [AC_MSG_ERROR([Please check if the mingw-w64 header set and the build/host option are set properly.])]) +AS_CASE([$with_headers], + [yes],[], + [AC_CHECK_HEADER([_mingw_mac.h], + [], + [AC_MSG_ERROR([Please check if the mingw-w64 header set and the build/host option are set properly.])])]) After your patch, configure won't always verify that the headers are usable for building crt. >> >> The default, of course, is for the headers to exist in the sysroot >> >> that the crt is getting installed into. This is a fairly common usage >> >> pattern, and modeled after the gcc build. If they're somewhere else >> >> instead, you can just use --with-sysroot=some/wheres/else >> >> >> >> In fact, the help text for with-sysroot even says this: >> >> --with-sysroot=DIR Search for headers within DIR/include >> >> >> >> So if you for whatever reason want to stage a build of >> >> mingw-w64-headers in /tmp/my/dir, you just build the crt with >> >> --with-sysroot=/tmp/my/dir >> >> >> >> Does that not work for you? >> > >> > Sorry, but I'm really confused about the unnecessary complexity. I don't >> > want to "stage" anything. I would like to be able call >> > >> > configure --prefix=... >> > make >> > make install >> >> Which configure are we talking about in all of this? I thought you >> were always asking about the crt configure, but I'm getting the >> feeling that you're really asking about the top level configure. > > The crt configurey needs a change to be able to build a full mingw > tree from top level. I thought that was clear. Only building crt > without the headers makes only marginal sense. My below example > shows that: Well, it's clear now. Although note that until now, every user always does configure/make/install of headers and crt independently. Mostly because top level doesn't really work :) So at least now I understand your use case.... I'll look into it from a different perspective and see what I can see. ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
