Re: Some random thoughs and questions on the future of GNUstep

[Nikolaus Waxweiler]

> Now thats a very bad position to advocate for anything. Really. What  
> about first learning CMake and then showing a prototype on how things  
> work and would look like? :-)
> That would be a much better basis to bring up such a proposal.

Shame on me, yes, but I'm tinkering with it every now and then.

> What I miss about your proposal is outlining actual problems GNUstep has  
> and which would be solved by using cmake (and how).

CMake was just the next best example I had ("[...] or better: Moving Away  
From GNUstep Make") and there's also gsjam, but as said, I still have to  
look into that. The general idea was, as stated, to outsource as much work  
as possible to be able to concentrate on -base, -gui and -back, I then  
just listed what CMake can do. Others already stated that a switch right  
now to *any* other build system would be more work than it's worth, and  
well, I'll just continue tinkering and see what comes up :)

> What I like about GNUstep make is that its _not_ a reinvention of the  
> wheel but a very clever use of the existing stuff. In fact you could  
> possibly say that CMake is a reinvention of gstep-make? Probably around  
> much longer ;-)

Nah, CMake is a cross-platform reinvention of Autotools :P. GS-M is a  
reinvention insofar that it's a complete build system.

> I would be interested to see how a typical GNUstep make package would  
> look like in cmake.

Do you mean a GNUmakefile? In the ideal/simplest case, a CMakeLists.txt  
for an application would look like

   FIND_PACKAGE(GNUstep REQUIRED)
   ADD_EXECUTABLE(SomeApp GNUSTEP_BUNDLE source1.m source2.c source3.mm)

or maybe

   FIND_PACKAGE(GNUstep REQUIRED)
   GNUSTEP_APP(SomeApp source1.m source2.c source3.mm)

I'll see.