Re: Cross-compiling GNUstep?

[Richard Frith-Macdonald]

On 30 Dec 2013, at 00:19, Markus Hitter <address@hidden> wrote:

> Am 29.12.2013 23:11, schrieb Fred Kiefer:
>> On 29.12.2013 20:17, Markus Hitter wrote:
>>> Am 29.12.2013 19:47, schrieb David Chisnall:
>>>> I'd be more inclined to move to CMake, which has the advantage of not 
>>>> being a complete usability disaster and being able to generate XCode 
>>>> projects.
>>> 
>>> While I have no experience with CMake, I wouldn't mind either.
> [...]
>>> How could backward compatibility work? I already see "it has served us
>>> well for 15 years and I don't want to re-write all my projects" ...
>> 
>> Should I step in here?
> 
> You do and, wow, what a lengthy one.
> 
> 
>> The first question that we should be asking us is what GNUstep make
>> actually offers
> 
> This is exactly the question to answer. And also, wether these
> advantages are important enough to justify maintaining a distinct build
> system. Because at the bottom line and unless I'm totally mistaken,
> Obj-C is compiled the same way as C, C++ and most other compiled
> languages. Accordingly, many other build tools should work just as fine.
> 
> Could you elaborate a bit on these advantages of GNUstep Make?

GNUstep-make is really just gnumake plus some additional structure/conventions 
(encapsulated in a set of make file fragments included into your project's make 
file) ... rather like the relationship between ObjC and C.  So you can put 
anything from a 'normal' makefile into a gnustep make file.

What makes it special are the conventions/knowledge built into it;
knowledge about the different project types (command line tools, apps, 
libraries, frameworks), what is included with them plists etc, where they 
should be installed all that sort of stuff.
All this knowledge is like the build-in rule in standard make that tells it how 
to make a .o file from a .c file (invoke the compiler with certain flags using 
the correct fiel names), but deals with correct linker commands, libraries, 
resources and where everything should go and how it should be installed.

It means that the vast majority of projects essentially need to do no more than 
declare a few variables listing the source files used.

Other projects mostly might want to add dependencies on external libraries etc, 
so there are variables for plugging those into all the standard rules.

For the very few cases (eg libobjc2) where you are actually building something 
almost completely outside gnustep, then it makes sense to fall back on vanilla 
make rules, just using the gnustep-make rules to decide where to install the 
result.  In these cases gnustep-make offers very little of course.


>> Writing great software is hard, writing great software that works in
>> environment that you yourself normally don't use is even harder.
> 
> Unlike libobjc2 four years ago, CMake is written already and known to
> work well. Accordingly, it should not be an additional burden, but a
> relief from some hard work. Once setup, others maintain all the build
> tools, GNUsteppers can concentrate on Obj-C.

If only that were true.
I guess CMake is known to work well, but that's in the same sense that 
autoconf/automake is known to work well.
When they don't do what you want, both are horrid.  In my experience CMake is 
far more of a burden because it doesn't have the years of documentation 
development that autoconf has, and (more importantly to me) because its a 
monolithic C program.  You need to get the source and figure out what it's 
doing, and that's just easier to do with the configure script and macros in 
autoconf.  I guess in both cases, if you are familiar enough with them they are 
fine, but I don't spend all my time hacking configuration systems, so I'm 
perpetually unfamiliar with either.

I'm also dubious about CMake's ability to integrate to GNUstep at the makefile 
level;
With autoconf/automake we simply don't use automake, and have autoconf generate 
.h and .make file fragments to use in the build process.
With CMake the configure/build processes are more tightly coupled ... if we 
can't do a similar solution then we'd probably need to hack on the CMake 
program itsself and maybe fork it ... making it far more work to maintain than 
what we have now.

It's hard to see how CMake could possibly help letting us concentrate on ObjC 
rather than build tools, when the maintainers of CMake are no more likely to 
cater for GNUstep than the maintainers of autoconf/automake are.  We'd just 
have a different project we need to supply patches to.

But I guess that was Fred's point really.