Thanks IOhannes, this answers my questions perfectly. I understand the reasoning behind the design of the Makefile now.

In this specific case, I think the best solution is to probably use my own Makefile, of which I already have several rather than the standard template one Hans added to the pluginhost~ tree. 

Jamie

On 17 March 2015 at 14:20:07, IOhannes m zmölnig (zmoelnig@iem.at) wrote:

>
> 1. A single external is built for each C source file specified in the SOURCES list
> 2. Additionally multiple sources can be linked in a single shared library if specified in the SHARED_SOURCE list. The external object is then linked dynamically to this shared library, so we get two files: e.g. myext.dylib myext.pd_darwin
>
> So the questions:
>
> - Does anyone know the reasoning behind “2”? It seems unnecessarily compllicated creating the shared library

i think you misunderstood the reason for the shared library.
it is really for sharing code among a *number of externals*.
think of a (hypothetical) Gem, that is broken into one-object-per-file
externals: all Gem objects need to share a significant amount of code,
so how would you like to create the externals:
- make each object self contained (that is: have multiple copies of the
shared code, one copy for each external)
- enforce the user to load a "Gem-core" library first that provides the
shared code
- dylink all externals with a shared library that provides the shared code

approach #1 is not really feasible: unstripped, the Gem binary
(containing all objects) on linux is about 33MB (stripped it's still
5MB); iirc both on w32 and OSX it's even bigger. if we leave out all the
objects to get the core library (containing all the shared code), this
reduces to 11MB (1.9MB stripped).
given that Gem has 500+ objects, statically linking the shared code into
each external is not really an option (5GB installation data?)

approach #2 is impractical and doesn't really differ much from having a
monolithic library containing all the objects, so what's the point?

approach #3 is like #2, but with the loading of the core-library being
handled automatically by the runtime linker. so that's why this rather
elegant solution has been chosen.

Gem is a hypothetical example (as it is not split into
one-object-per-file externals), but it illustrates the use-case.

a real-world example that makes use of the shared library is iemnet.


> - Is there any way to use the template as it stands, to create a single external from multiple sources (without the additional shared library being created)? It seems like make LIBRARY_NAME should do it, but on OS X, this gives me the following error:

well, your use-case is actually outside the scope of the template
Makefile :-)
you could either:
- adapt your sources to fit the template/Makefile workflow (cram all the
code needed for a single external into a single file)
- rethink your design: if you really need multiple source files for a
pd-object, it's probably feature-bloated anyhow. try splitting the
functionality into multiple Pd-objects, each fitting into a single
C-file; probably with some shared functions in a dylib.

OR

- use '#include "more_stuff.c"' stanzas in your *main* C-file to
virtually cram all code needed for the external into a single file. it's
ugly, but if the code is nicely written (that is: no symbol clashes),
it's probably the easiest fix.

- hack the template Makefile to fit your needs; that Makefile is a
suggestion; no-one forces you to use it as it is provided.
you might even extend the Makefile in a generic way to allow specifying
multiple C-files on a per-object basis, something like:

SOURCES = mycobject.c
mycobject_XTRA_SOURCES = more_stuff.c less_staff.c


> make: *** No rule to make target `libmyext.o', needed by `myext'

seems like a bug (that is very unlikely to be fixed, as it is an edge case).
an easy workaround is to provide a (dummy) file libmyext.c:
$ touch libmyext.c

mgfet
IOhannes



_______________________________________________
Pd-dev mailing list
Pd-dev@lists.iem.at
http://lists.puredata.info/listinfo/pd-dev