On 30 Jan 2015, at 07:34, David Chisnall <[email protected]> wrote: > > On 29 Jan 2015, at 09:10, Richard Frith-Macdonald > <[email protected]> wrote: >> >> Different worlds ... on FreeBSD that's roughly 2:1 cmake to autotools, but I >> guess it looks different in non-bsd systems. > > No. This is the FreeBSD *ports* collection (i.e. third-party code, most of > which originated on Linux and other *NIX systems). KDE is not a FreeBSD > project, for example, neither is MySQL. According to OpenHub, CMake has 129 > developers - that's more people working on *a build system* than on GNUstep.
No offence intended, but it seems that you don't really get this at all ... sionce you keep trying to compare gnustep-make with cmake in some way and they are actually doiing very different things. gnustep-make is a relatively high-level tool to make it easy for people to build/install gnustep apps/tools ... it sits above two other tools (autoconf and make) and provides a consistent higher level structure to those tools for use building gnustep apps, tools, frameworks etc ... things which have a particular directory structure etc. It does this by providing makefiles which are used to build/install everything in a certain layout. As far as I know cmake is a lower level tool (much more comparable to autoconf). While it may be possible to configure cmake in some way so that the makefiles it produces duplicate the functionality of the makefiles from gnustep-make, I have no idea how and have never seen a cmake advocate describe how it could actually be done, let alone volunteer to do it. > Rather than build on their work, we continue to maintain something that: > > - Conflates configuration with building. autoconf/configure does configuration, make does building ... the separation seems a bit cleaner/clearere than with cmake. > - Locks you into a single build mechanism (no XCode project generation, for > example, so I have to maintain two build systems for anything that I want to > use with GNUstep and Cocoa). Any system 'locks you in' in the sense that, if you use that system then you aren't using another one. There's no special extra lock-in with gnustep-make other than the fact that it makes things easy for people (so they are less likely to put a lot of work into doing things a harder way) to just have everything built/installed in the right places on a GNUstep system. You can build on OSX with gnustep-make, but it lacks the integration/ease of use of the native tuools, in the same way that building in a gnustep environment with cmake lacks the integration/ease of use there. > - Has no well-defined extension mechanism. I suspect this comment is from the point of view of using cmake, which needs a special extension mechanism since it's inherently opaque and fixed (being compiled code). Where we are working always with interpreted source code rather than compiled code, things are easier to extend. So while there are specific config/extension options you also have the generic mechanisms of simply adding new autoconf tests and adding new makefile fragments. I guess these are not 'well defined' in the sense that they are implicit in the documentation of the macro language and make language rather than explicitly stated as extensions. > - Has no uses outside of the GNUstep ecosystem. Well that's kind of the point really ... making it easy to build/install GNUstep apps to live in the GNUstep ecosystem. Anyway, I really, really didn't want to get drawn into the old cmake/autoconf argument (since I consider autoconf the lesser of two evils rather than anything actualy good). Rather, I'd like to encourage people to discuss how best to support both traditional and objc2 style builds in gnustep-make (in the absence of any realistic proposal to reproduce all the gnustep-make ease of use and functionality using something other than autoconf/make). _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
