Re: Creating "Additional" makefiles

[Stephen Brandon]

On Tuesday 27 Nov 2001 12:57 pm, Nicola Pero wrote:
> It's quite possible that you don't need Additional makefiles at all.
> Even if you need them, try keeping them as simple as possible ...
>
> If your libraries require other libraries to work, a considerably
> interesting approach is to link your libraries against the other
> libraries.  That makes sure when your libraries are loaded, the other
> libraries are dragged in as well by the dynamic linker.
>
> You do this by specifying
>
> LIBRARIES_DEPEND_UPON = -lshout -lmp2lib
>
> in the GNUmakefile for your library/framework ... when the library is
> compiled, you can check with ldd that the library is linked against those

ok, will do.

> external libraries ... anything linked against your library will be
> automatically linked against those external libraries ...
>
> all this works so happily on gnu/linux ... and I think on other unices as
> well ... but I've no idea if it works on windows ... but it's worth trying
> it before writing additional makefiles.

Hmmmmm... I think that Win32 might have been the problem in the first 
instance. I'll try again (amazing how trying again can make things work!).

> > Eg all SndKit programs need -lshout -lmp3lib, unless the target platform
> > is MINGW32;
>
> might be solved by linking the library itself against -lshout -lmp3lib
>
> > and at present I conditionally compile SndView.m into the SndKit
> > ONLY on non-win32 platforms (it's the only AppKit subclass, and there are
> > problems getting AppKit subclasses to be recognised at runtime on
> > GNUstep/Win32).
>
> well this customization is only used when compiling the SndKit ... I don't
> see what this has to do with additional makefiles.

Well, it's a bit messy at the moment. The reason I have put this in a couple 
of tools' makefiles is that SndKit.h #includes SndView.h. Since SndView is 
not compiled in on Win32, I needed to ensure that its header would not be 
imported either (by user apps being compiled against SndKit), so I used an 
#ifndef NO_IMPORT_SNDVIEW around the #import, and then toggled 
NO_IMPORT_SNDVIEW in the tools' makefiles. It's pretty bad :-) The aim of 
doing it this way was to not have to duplicate the logic for whether it was 
to be included or not in the SndKit.h and also in SndKit's makefile - I 
thought that making a DEFINE would help to keep the logic together. 
Unfortunaltely it meant having to duplicate it in every singe tool's 
makefile. That's why I thought that putting in an Additional makefile would 
be useful.

> > Is there somewhere that documents what to put in the Additional makefiles
> > and how to use them? What I want to do is to be able to automatically
> > identify which of the frameworks/libraries are being used
> > (MKPerformSndMIDI, SndKit, MKDSP, MusicKit) and add -l and -D flags
> > accordingly.
>
> Identifying which framework is being compiled is going to be painful ...
> you don't want to do that.

OK!

> -D flags are preprocessor define flags ... you'd better create a
> XXXConfig.h.in file in each framework/library, and generate a XXXConfig.h
> when the library/framework is configured (putting in XXXConfig.h all the
> preprocessor defines you need), then install that header file and have it
> automaticallly included by the framework/library headers ... in this way
> any project including the headers for that framework/library will
> automatically have the correct symbols defined.

OK, that sounds right.

> -l flags are used to link against external libraries ... my preferite
> solution is the one above with linking the libraries themselves
> ... otherwise well you can create an additional makefile, and define the
> required flags there -
>
>  SNDKIT_LIBS = -lshout -lmp3lib
>
> a project wanting to use the SoundKit then will have to add -
>
>  ADDITIONAL_TOOL_LIBS += $(SNDKIT_LIBS)

Aha! That explains the use of the Additional makefiles better - now I 
recognise the construct you've used above. I like that. But I'll try the 
LIBRARIES_DEPEND_UPON thing first.

> in the same additional makefile you can set up all the flags for all the
> libs you need, projects using different frameworks/libraries will add the
> flags for different frameworks/libraries.
>
> now - I don't like this solution too much, because to install an
> additional makefile you have to be root ... it would be nice if you could
> install and use the SoundKit without having to be root.

Mmmmm... yes I suppose so. But most people are going to need authentication 
to write the frameworks into /usr/GNUstep/Local/ in any case, aren't they? 
(they would if *I* was running the network). OK, so maybe people should be 
able to install the frameworks into their own home directory, and in that 
case the extra makefile would be a pain. But does the Makefile system not 
also look into ~/GNUstep/Makefiles/* or something like that for user-specific 
customisations? Maybe that would solve the problem.

> you could install a shell script/tool instead, which outputs the lib flags
> required when it's called ... say that you call it SoundKit-config ...
>
> the end-user makefile will then do
>
> ADDITIONAL_TOOL_LIBS += $(shell "SoundKit-config")
>
> (it's precisely what gtk-config and similar script do ... and it's a good
> idea :-)

Yes, excellent. I'll do that if LIBRARIES_DEPEND_UPON doesn't work 
satisfactorily on Windows.

> Any other suggestions welcome.
>
> Still, try keeping flags to a minimum ... you *at most* need -l flags for
> the external libraries, and -L flags for the same.  No -D flags - those go
> into header files directly.

I stand admonished.

> > NOTE: although I'd love to be able to avoid using autoconf/configure to
> > set up some of these things, the fact that developers and users are going
> > to have to have certain 3rd party libraries installed means that we've
> > got to be able to ensure that they're there, and configure accordingly.
> > If anyone has got any suggestions to get around this, I'd be happy to
> > listen.
>
> Yes - you certainly need to use autoconf/configure in the configuration
> steps of your frameworks to detect and locate the required external
> libraries.

Cheers Nicola - brilliant reply. Thanks.

Cheers,
Stephen Brandon
stephen@brandonitconsulting.co.uk