Re: bug in gnustep-make

[Nicola Pero]

> I think this is a bug in gnustep-make: symbolic links aren't correctly
> created, when using a temporary directory for installation. The Debian
> package usese:
> 
>         . /$(GS_ROOT)/Makefiles/GNUstep.sh; \
>             $(MAKE) install \
>                 INSTALL_ROOT_DIR=$(CURDIR)/debian/gnumail \
>                 GNUSTEP_INSTALLATION_DIR=$(CURDIR)/debian/gnumail/$(GS_ROOT)
> 
> or do I miss something?

Your code looks Ok to me - and the only broken symbolic links in
gnustep-make are the ones for frameworks ... so I infer that GNUMail.app
is using a framework somewhere ... which looks like pointless to me.  I
don't like frameworks since they are complicated to make them work, and I
always suggest to use libraries (or bundles) instead.

I got a bug report telling me that RPM building on GNUMail is broken as
well because of the broken links in frameworks ... I think I've lost the
email, anywya if whoever sent the email is reading ... thanks for your
input and we're managing your bug here :-)

Anyway - the bug is around lines 336 and similar in
Instance/framework.make on CVS.  What's happening here is that - I warn I
always rant against frameworks :-) so be prepared - a framework (by
definition of framework) holds the framework headers in a subdir of
itself, buried where the compiler will never find them ... unless you
explicitly tell him to look for headers there, but then you have to find
manually *where* the framework had been installed, and that would depend
on the machine we are building on and would be a mess.  To work around
this, we create a symbolic link from the standard header directory *into*
the framework header dir, when the header is installed.  In my opinion,
that breaks the whole interest of frameworks headers, since you can no
longer move the framework around without breaking the link and thus making
the framework unusable ... but then why just not installing the headers in
the standard header dir as everything else does ? a framework is no longer
different from a library, except libraries simply install headers where
they should be installed, while frameworks are adding additional
brain-damaging complexity (putting headers somewhere else, and building
this cross-heavens symlinks) with absolutely no gain whatsoever.  Anyway -
these symbolic links are the links which are harming your build.

Ok - stopped ranting and had a look at the actual GNUMail ... 

My personal suggestion is ... change GNUMail/GNUmakefile to read

include $(GNUSTEP_MAKEFILES)/common.make

LIBRARY_NAME = GNUMail
GNUMail_HEADER_FILES = GNUMailBundle.h PreferencesModule.h

include $(GNUSTEP_MAKEFILES)/library.make

My personal suggestion with build systems and makefiles is always the same
- take the simplest and safest route ... we just want to deliver stuff
which always compiles and works out of the box.  To install a couple of
headers, just use the simplest available project type, which is a library.

++

Anyway - said that, ranted against frameworks, suggested what in my
opinion is the only good solution, I fixed the bug on CVS by implementing
new stuff which intelligently builds relocatable symlinks for frameworks
... framework symlinks should now be properly relocatable.  (this does
*not* diminish my recommendation of using a library in the trivial case of
GNUMail.app)

In other words, I fixed creating RPMs and DEBs containing frameworks.