Am 30.12.2013 07:34, schrieb Richard Frith-Macdonald:
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.
Thanks for the opinion. My first impression of CMake actually aligns
with this: while it has quite a number of interesting features, it's
also close to be overengineered.
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.
At the bottom line, packaging does just four things:
1. Run the projects' prefered configuration procedure (in case of
GNUstep this is ./configure).
2. Run the projects' prefered build procedure (in case of GNUstep this
is "make").
3. Install into a OS installation as virgin as possible (just the
dependencies installed), using the projects' installation procedure.
4. Tar up the files installed by 3.
Accordingly, if this doesn't work, it's very likely it doesn't work when
doing the same steps manually, either. What makes packaging complicated
is their insistence on working in release cycles (there's room for
improvement) and the fact you always install into a virgin system (which
is a good thing).
BUT, as said in that other email I was probably just confused by the way
tests/checks are run. They build & run when invoked from Tests/, but not
when invoked from (e.g.) Tests/gui/NSCell. And the lack of visible
messages isn't a bug, but a feature :-}