Re: Cross-compiling GNUstep?

[Richard Frith-Macdonald]

On 29 Dec 2013, at 19:17, Markus Hitter <address@hidden> 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 have some little experience with CMake now ... it's a replacement for 
autoconf and automake (which are pretty horrible), unfortunately it's a cure 
which is worse than the disease.
When it works, it's fine, but just like autoconf/automake, when it doesn't work 
or when you want to do something that hasn't been catered for, it's a nightmare 
and takes hours and hours  to work out how things operate.

> I just see my shiny new Debian packages don't allow me to build -base
> without debian/rules.

I'm not sure what that means, but it  sounds like a Debain packaging issue 
orthogonal to any issues in autoconf.

> configure insists to run on a normal make and
> falls back to the non-fhs layout.

I think you are talking about the case where the software hasn't been 
configured; you type make, and the configure script is automatically run.
That's nothing directly to do with either autoconf or gnustep-make.  Rather 
it's a deliberate feature provided by the makefiles of many (most?) projects 
... if you try to build a project without having run the configure script since 
it was last modified, there's a makefile rule to run configure for the project 
(keeping any existing selected options) on your behalf (another common thing 
for makefiles to do is print an error message saying you haven't configured the 
project, and then bomb out).
When you fist build a project, you are expected to run the configure script 
before building (with cmake, you do the same thing and run cmake before 
building) specifying the options you want (like the debian/fhs layout).

> The whole testsuite ignores
> messages=yes,

The testsuite doesn't have a 'messages=yes' option... that's a gnustep-make 
option, not a test framework option.

The test framework is a few header files and shell scripts and some 
documentation/examples, packaged as an add-on to be installed with gnustep-make 
so it's available anywhere you might build software using gnustep-make.  It's 
driven by the gnustep-tests shellscript/command (so it doesn't accept any make 
arguments) not a make file.
Each testsuite is then a hierarchy of directories containing code fragments to 
be built/executed to perform tests, and a files to mark which directories 
actually contain test code.
The gnustep-tests script runs the testsuite; when building a testcase from a 
fragment of source code, the script may generate a makefile to do the building, 
and you could then manually use that makefile supplying 'messages=yes' as an 
argument, but such a makefile would be so simple that it's hard to see the 
point.

> apparently all the checks fail silently. Building a single
> one doesn't work either, "Testing.h" not found.

That sounds lke you don't have gnustep-make and/or the testute installed?  Or 
don't have it installed in your PATH?
Given that you implied above that you didn't configure gnustep-base to use the 
debian filesystem layout, I expect things are installed in the gnustep layout, 
so I'm further guessing that you didn't set up your environment to point to the 
gnustep installation (sourcing GNUstep.sh is the standard way to do that), and 
your problem most likelyh is that the gnustep-tests script can't find things, 
though I'd be interested in how/where you run gnustep-tests in that case.

> Have yet to investigate
> what actually happens, but it's obvious GNUstep Make isn't exactly
> bullet-proof.

I'm sure it's not ... but none of this sounds like gnustep-make issues.
It does sound somewhat indirectly related to autoconf, in as much as it sounds 
like the problem is due to failure to configure, install, and set up the 
environment, but hard to say for sure.