On Fri, Nov 30, 2012 at 12:49 PM, Pau Garcia i Quiles <[email protected]> wrote: > > > On Fri, Nov 30, 2012 at 3:29 PM, NightStrike <[email protected]> wrote: > > [...] > >> >> In the cmake world, to do the same thing, Dave has to be a lot more >> knowledgeable of the internals of our project. He needs to know what >> languages we use, what compilers we need, how to call them, how to set >> them up, what the differences are between them, what specific options >> they'll need, etc etc. It won't "just work". > > > No, actually not. Dave only needs to configure one of those cross-compile > configuration files *ever* and use that for *every* CMake project. > > http://www.vtk.org/Wiki/CMake_Cross_Compiling > > And that's only in case CMake is not able to autodiscover the triplet.
I read that wiki page a while ago. I re-read it now, and it seems even more complicated. Maybe I'm completely misunderstanding it. Please explain how our project can be as easy for Dave as: ../configure --host=triplet knowing that we need to identify the properly canonicalized tools for: gcc g++ as ar ranlib strip dlltool sed install It seems to me that *somebody* has to do the work to find those programs (and in the case of sed, find a posix-compatible one). I don't think that cmake will, so it's either us or Dave, neither of which is desirable. But maybe you know how to make cmake work harder for us. If so, I'm open to it, because I don't have to do anything to get autotools to find all of those tools, test them, verify that they work, and provide them to the makefile. And yes, you can substitute cl in there for gcc :P If you do, please share how I can also get cmake to automatically create these targets: dist check distcheck install uninstall install-strip installcheck installdirs clean distclean maintainer-clean ...and about half a dozen others related to documentation....... >> all without me or Dave having to do any work whatsoever. I would hope that at least the basics (install, check) come for free. install-strip is a very important one, though. Also, what automatic testing does cmake provide? autotools provides a lot... automake tests, autoconf tests, autotest tests, dejagnu support built-in, along with custom test drivers. I am asking this not to pick a fight..... Honestly, we haven't chosen the regression tester for ironcrate yet. Last I saw on irc, kai was leaning towards dejagnu, but there are a lot of choices. What does cmake natively handle? When I say native, I mean something as easy as this: check_PROGRAMS = test1 test2 test3 That one line will build and run those tests from test[123].c, include them in the various *check targets, monitor outputs, create logfiles, write html output for a build website, handle color, parallelism, **re-test comparisons** << (that's a big one).... Does cmake do any of that? I see that there's something called CTest. How does that compare? >> Now of course, we could >> try to provide these system-specific files that cmake should be giving >> us for free, but then we'd have to maintain (thus somehow be able to >> test) every conceivable system that our users might have or want to >> use. >> > > No, you don't. Either you have not used CMake enough or you have not > understood how it works. It's either CMake's or the user's mission to take > care of "every coneivable system", not the developer's (at least, no more > than in autotools). What host triplets does cmake support by default without any additional work on the part of Dave? You said it's either cmake or Dave. I don't want it to be Dave, so what does cmake give me for standard canonical system names, and how does it determine what system you are trying to target? configure is pretty dumb about it... it just prepends $(host)- to common tool names and sees if the exe exists. It probably tries to run it, I guess... been a while since I read a configure script. Anyway, it's nothing fancy. Does cmake do any discovery magic? >> [Please tell me if this next section has since changed.] >> What I have also found is that cmake places a glaring silly dependency >> on the user. while autotools requires sh, a posix-compatiable shell, >> cmake requires.... cmake. To build, not to just prepare the >> makefiles. Here's why this matters -- autotools projects don't >> require autotools to *build* the project. They require a generic tool >> that is already required to have a posix system up and running. cmake >> requires cmake, which is a specific tool that a user would not >> ordinarily have or need or want. >> > > I fail to see why that is a problem. > > When I want to compile a C project, I need a C compiler, preprocessor and > linker. > > When I want to compile a Java project, I need a JDK. It's the difference between specific vs generic. On a posix system, certain generic tools are guaranteed to be available: sh, cc, cpp (pre-proc, not ++), make, and a lot more. We can say that our minimum requirements are "posix", which is very simple. Requiring some 3rd party build tool like cmake is in a very different category. I would get behind cmake if cmake generated scripts at release time that could run on a more generic system. For instance, say we did something like "make dist", where the dist target created and packed in some cmd.exe shell scripts that built things on a windows machine. That would be wonderful. But nothing out there on the market is that cool, so instead, we use a tool that generates files that will build the project on a posix system. On windows, you have a choice of 3 posix subsystems to achieve this -- msys, cygwin, and interix (sfu, sua). Those are generic frameworks that are reasonable to require. cmake is not. IMO, cmake has to provide a lot of niceties that I can't get elsewhere to make that worthwhile, and I just don't see what the bells and whistles are. Is there a good feature comparison list somewhere that shows the benefits that are unique to cmake (as opposed to just doing the same thing differently)? > When I want to compile an autotools project, I need sh, which as you have > already said, is only half-legged available on Windows. And that's the whole > point of CMake, especially when Visual C++ is in the middle. Sure, you can > generate makefiles which call cl.exe, link.exe, etc, but in the end, > debuggin, profiling, distributed compilation will be a pain, whereas they > will work perfectly fine in projects using CMake. Yes, cmake pumping out project files is nicer for a VS IDE user than dealing with "legacy" makefiles. > Oh, and there is one more nicety about CMake: there is a GUI for users to > configure optional dependencies, this-or-that option, etc. I can see the usefulness there when there are a lot of options. "make menuconfig" for the kernel comes to mind. I wish I knew how to use THAT build system. Really, I haven't seen any build system that I think is wonderful. autotools works for us, but it's not great. I've used a lot... even scons. I haven't really found any super stellar ones. What I'd really love would be for something to be in pure make... no configure step. I like automake a lot, but it requires configure. I'd love to have automake without configure. I like being able to have a makefile generator that takes care of tons of redundancy between projects, and even within a project. I like not having to worry about dependency generation, or testsuites, or installing things properly, or command line length limits, or incompatibilities with other systems. I like being able to write: bin_PROGRAMS = hello and getting a 75843758457394 line Makefile from that one line that does it all. Anyway...... yeah. I'm not saying the door is closed for cmake. I'm just saying that it needs to make things easier for Dave first, and us second... and not harder. ------------------------------------------------------------------------------ Keep yourself connected to Go Parallel: INSIGHTS What's next for parallel hardware, programming and related areas? Interviews and blogs by thought leaders keep you ahead of the curve. http://goparallel.sourceforge.net _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
