On 29 Jan 2015, at 09:10, Richard Frith-Macdonald <[email protected]> wrote: > > On 28 Jan 2015, at 18:31, David Chisnall <[email protected]> wrote: >> >> On 28 Jan 2015, at 17:49, Richard Frith-Macdonald >> <[email protected]> wrote: >> >>> When tryiung to move people over to using clang and libobjc2, everyone >>> seems to have problems with building libobjc2 because of its cmake >>> dependency :-( >> >> People who can't manage: >> >> $ mkdir Build ; cd Build >> $ cmake .. >> $ ccmake . # Optional, only do if you want to enter the curses UI to tweak >> configure options >> $ make && make install >> >> Probably are going to struggle with a lot of other things too... > > Heh ... everything is simple if/when it works. There are also people who > struggle with: > > $ configure ... # Optional ... e.g. if you want to depend on stuff installed > strangely > $ make install > >>> I can certainly help with discussions and patch integration for >>> gnustep-make to better use clang, but almost as useful would be building >>> libobjc2 without requiring cmake. >> >> You are *far* more likely to find developers familiar with CMake than >> GNUstep Make (or, in fact, pretty much any other build system). To put some >> real numbers on this, in the FreeBSD ports tree there are 1018 ports that >> use CMake, 90 that use GNUstep Make. For comparison, there are 399 that use >> autotools. > > Different worlds ... on FreeBSD that's roughly 2:1 cmake to autotools, but I > guess it looks different in non-bsd systems. > I'm dealing with people using flavours of gnu/linux. > I have no idea what typical ms-windows people do when faced with either > autoconf or cmake ... > > A
Oops ... accidentally sent too soon ... I meant to add Anyway, the relative merits or popularity of autoconf against cmake are not really the issue for building gnustep stuff (if we assume libobjc2 is built/installed somewhere). What we really need is good support for the next stage (building gnustep projects using gnustep-make) where most people want to use gcc/objc but a substantial (and rapidly growing) minority want to use clang/objc2. There's good support for the gcc/objc combination, but not for clang/objc2 so far, and the people wanting to use clang/objc2 have not yet contributed patches to do it; mostly I think, put off by the fact that we don't want patches to *switch*, we want patches which will support both old *and* new. I favour using the library-combo feature to switch between old style and new style, with the addition of a new runtime library designation (perhaps oc2 for the new runtime). So instead of gnu-gnu-gnu for gnustep-gui with fgnustep-base and the gnu runtime, we might use gnu-gnu-oc2 for building using the new runtime. In the interests of simplicity I'd favour making compiler support be tied to the runtime: So we would drop any official support for clang in conjunction with the old runtime (gnu-gnu-gnu combo) and we would make support for gnu-gnu-oc2 *require* a reasonably recent version of clang Does that make sense? --- Reply encrypted using http://keys.gnupg.net:11371/pks/lookup?op=get&search=0x3EC26D605B89D6F6 _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
