Re: [Mingw-w64-public] ironCrate

[Pau G. i Q. <pgq...@el...>]

On Fri, Nov 30, 2012 at 3:29 PM, NightStrike <nig...@gm...> 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.


> 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).


> [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.

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.

Requiring CMake, a self-contained tool with no dependendies, to compile a
project using a CMake buildsystem is no big deal. It might have been 5
years ago, it is not now. Even less on Windows.

Oh, and there is one more nicety about CMake: there is a GUI for users to
configure optional dependencies, this-or-that option, etc.

But I'm tired of this discussion. I'll keep using CMake until I find
something better. So far, I have not. Neither for open source, nor for work.

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)