On Thu, Mar 14, 2013 at 1:26 PM, John E. / TDM <tdra...@tdragon.net> wrote: > On 3/14/2013 1:00 PM, NightStrike wrote: >> On Thu, Mar 14, 2013 at 11:27 AM, Corinna Vinschen <vinsc...@redhat.com> >> wrote: >>> On Mar 14 10:53, NightStrike wrote: >>>> 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. > > Just to throw another data point out there, I use top-level configure > for TDM-GCC (i.e. an x86_64-w64-mingw32 native bootstrap). It seems to > work and is far easier than building each sub-tree individually.
How do you use it? What I am finding is that there is a fundamental difference in how AC_CONFIG_SUBDIRS works, and how we would like it to work. Let's say we have two packages, p1 and p2. Both need to be configured, made and installed (c/m/i for short). Let's say further that we want to build p1 and p2 serially such that we would do c1/m1/i1 followed by c2/m2/i2. What AC_CONFIG_SUBDIRS does instead is c1/c2, m1/m2, i1/i2. This means that in the case of the headers/crt packages, we will be forcing all work on the headers to be done at configure time. Translation -- we can't actually "build" the headers. This is not ideal. Now, currently, we do a lot at configure time, but we do three things at build time: Create _mingw_directx.h Create _mingw_ddk.h (Optional) Run widl to convert from .widl to .h You could argue that those three things don't need to happen before you configure the crt, but currently, we don't have such a limitation in place. It's really not my place to create that limitation without input from the people working in those areas. I have no idea what's planned for the future (ie, a future situation where the dependency does exist.) I'm open to ideas. I'm also open to making the top level configury smarter. I looked at the gcc top level configury to see how that gets so smart. This works more like what I would expect -- serialize the c/m/i process for each sub package. It's also insanely complicated, and I guess hearkens back to what people used to call the "cygnus tree". I am remembering now why I abandoned the top level idea :P That said, it does work pretty well for the libs and tools, which have no crazy dependencies. ------------------------------------------------------------------------------ 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
