-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/22/2011 19:58, NightStrike wrote: >>> >>> I think you misunderstand my intention (and are bound to not answer my >>> question, it seems). All I need is a description of what is done by the >>> build system (ie what files are compiled into what and which files end up >>> where). Extracting this from autotools is almost impossible, so a short >>> description is pretty much all I'd need. > > Almost impossible? It's not even slightly hard. The Makefile.am > file lists ONLY what goes into each library. There are src_libx and > x_SOURCES variables for every target lib "x" that needs sources. > There are very basic, rudimentary, normal make rules for the .o files > that make up the crt. > > For instance, here's all the sources in lib32/libshell32.a and > lib64/libshell32.a: > > lib32_libshell32_a_SOURCES = $(src_libshell32) > lib64_libshell32_a_SOURCES = $(src_libshell32) > src_libshell32=libsrc/shell32.c > > Here's a basic make rule to build crt1.o: > > lib64/crt1.o: crt/crtexe.c > $(COMPILE64) -c $< -o $@ -D__CRTDLL__ -U__MSVCRT__ > > Exactly what part of this is "almost impossible" to understand? > >>> In the ideal future, Clang has its >>> own linker, which would make the MinGW runtime the only thing needing Bash >>> for anything, which would be pretty lame. I'm not asking you to do any work, >>> just give a description of what goes where. That would be awesome. > > You've read Makefile.am, right? >
Right, There is nothing to extract, the details are all in configure.ac and Makefile.am files. For CRT .def -> .a, some .c are compiled and merged into the def generated .a, some into libmingw32/libmingwex, other .c startups are left as .o. libmath.a is built from a generated dummy .c. As for headers, its mostly copying, except for some sed generated .h files based on user options. I do not think moving the requirement from bash to cmake would do much good. >>> Second, some irrelevant arguments pro Cmake: >>> 1. It can glob for certain files, and I'm confident "maintaining" the Cmake >>> files will be painless (because once the general rules are set up, the >>> wildcard '*' will take care of new files. > > I've tried to go this route before -- using * instead of our giant > list of x.def > libx.a conversions. It will cause you trouble, I'm > sure. Especially once you see that some libs have defs, some don't, > some have defs + sources, some just have defs. It's not > straightforward. If it was, we would have done it. You can see all > of my discussions about it with the Automake team on their mailing > list. > Wildcards work fine for GNU make rules, but we specifically chose to use explicit rules instead. >>> 2. Clang does not require a Bash shell, meaning that there is no reason to >>> use Bash (which translates to slow MSYS/Cygwin on Windows). This is the >>> exact reason I'd like to get this set up. > > According to our buildbot, configuring the crt takes 1 minute. > Building it takes 8. You'd only be getting a speed gain on the first > part -- hardly worth the time it takes for you to keep up to date with > our changes. But, that's your decision of course. Just one that > everyone on this project would recommend against :) :) > > The issue isn't bash... it's the fact that creating processes on > Windows is a slow endeavor. Windows is built for fewer processes with > many threads, whereas linux and most unixes are built for many single > threaded processes. Switching to CMake doesn't fix that. In fact, I > tried to use CMake before creating our current build system -- there > was no real difference in build times, just a lot of headaches with > cross compiling. I still do not understand why it is necessary to have another build system just because it is claimed to be slow, when it only takes a fraction of the time to run compared to the actual compile time. Just use the configure -C option if you want something akin to a cmake answers file. Any changes will be updated in the cache. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) iEYEARECAAYFAk2xci0ACgkQp56AKe10wHfzQQCggfYSXBtmPCk+5eKSlQ678m1g HeIAn0+aXn3A3fwXvR7Ybn5sNryjJfwz =uPaj -----END PGP SIGNATURE-----
0xED74C077.asc
Description: application/pgp-keys
------------------------------------------------------------------------------ Fulfilling the Lean Software Promise Lean software platforms are now widely adopted and the benefits have been demonstrated beyond question. Learn why your peers are replacing JEE containers with lightweight application servers - and what you can gain from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
