On 29 Dec 2013, at 19:17, Markus Hitter <m...@jump-ing.de> 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. _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev