On Fri, Apr 22, 2011 at 5:52 AM, Ruben Van Boxem <[email protected]> wrote: > 2011/4/22 JonY <[email protected]> >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 4/22/2011 16:05, Ruben Van Boxem wrote: >> > I'd like to rid the whole thing of bash, so I can build from windows >> > cmd, >> > just like clang. It should also speed things up (MSYS is very slow) >> > >> > Ruben >> >> That is hardly a reason to make and maintain two separate build systems, >> configure runs a fraction of the time required by the whole build. >> You'll likely see an improvement by running make in parallel. > > 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? > 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. > 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 hope I have made myself and my intentions a bit more clear. > > Ruben > >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2.0.16 (MingW32) >> >> iEYEARECAAYFAk2xRyEACgkQp56AKe10wHd7LwCeNUIjBtTeeskAiifZ0k0X550n >> BOQAn3He/w6lrG7XvKvixFKkizVUbbCS >> =PmPP >> -----END PGP SIGNATURE----- > > > ------------------------------------------------------------------------------ > 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 > > ------------------------------------------------------------------------------ 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
