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:
- A single external is built for each C source file specified in the SOURCES list
- 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