Re: Creating "Additional" makefiles

[Nicola Pero]

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
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.

 
> 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.


> 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.


Exactly which -l and -D flags you want to set ?

-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.

-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)

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.

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 :-)

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.


> 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.