gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cross-compiling GNUstep?


From: Fred Kiefer
Subject: Re: Cross-compiling GNUstep?
Date: Sun, 29 Dec 2013 23:11:38 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

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.
> 
> I just see my shiny new Debian packages don't allow me to build -base
> without debian/rules. configure insists to run on a normal make and
> falls back to the non-fhs layout. The whole testsuite ignores
> messages=yes, apparently all the checks fail silently. Building a single
> one doesn't work either, "Testing.h" not found. Have yet to investigate
> what actually happens, but it's obvious GNUstep Make isn't exactly
> bullet-proof.
> 
> 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? Looks like a nice trap, doesn't it? Oh yes, I
will try it.

In you last mail you wrote "My impression is, GNUstep make tries to
offer a very similar level of abstraction at runtime of what autoconf
does at ./configure time.". No this is not what GNUstep make is trying
to do. This is what we use autoconf and the generate configure file for.
cmake seems to be addressing both the functionality of autoconf and
GNUstep make at once. Maybe this is a good approach, I don't know and I
wasn't able to find out. I skimmed over the FAQ at the cmake web site to
find out about the features cmake is offering, but it didn't tell me
that much.

The first question that we should be asking us is what GNUstep make
actually offers and how this could be replaced if we really want to
replace it. GNUstep make is a tiny expansion of GNU make that allows to
write more compact make files for Objective-C applications. It doesn't
try to save the world and it surely has a few bugs.

Now I had a few problem myself over this weekend with GNustep make. What
did I do to resolve them? Suggest to switch to some new software? Or
just go don't into the GNUstep make stuff and fix things? GNUstep make
definitely isn't perfect. We left it to bit rot for some time. Still it
is doing a lot of useful stuff which is hard to replace.

I am rather sure that it would be possible to reproduce most of the
features of GNUstep make with cmake and my question is not so much about
the few missing case. But who would be willing to rewrite the whole of
GNUstep make in cmake and guarantee full functionality?

About four years ago David started to write a new libobjc based on code
that was already in Etoile and with the old GNU libobjc as guideline. I
would say that he is an extraordinary programmer. Still only about now
would I suggest to use it on ARM or MIPS platforms. What does this tell
us? Writing great software is hard, writing great software that works in
environment that you yourself normally don't use is even harder.

Yes, I totally agree that GNUstep make plus our configure files are very
hard to use in a cross compilation case. Requesting that we throw it
away and replace it by cmake would at least require a proof of concept
implementation of a cmake configuration for the GNUstep core components
that works flawless on let's say three Linux, two BSD and one Windows
platform. If you are willing to provide that. I am going to help with
testing and correcting it. And maybe in four years time we have
something to replace GNUstep make. Up to then I will have to keep on
fixing GNUstep make.

Fred

PS: The error you are getting with "Testing.h" suggest that you either
did not install GNUstep make or didn't source the GNUstep.sh file. And
"messages=yes make check" followed by "less tests.log" should give you
more output that you ever would like to read through.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]