> 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. _______________________________________________ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
