<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Thanks IOhannes, this answers my questions perfectly. I understand the reasoning behind the design of the Makefile now.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">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. </div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Jamie</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">On 17 March 2015 at 14:20:07, IOhannes m zmölnig (<a href="mailto:zmoelnig@iem.at">zmoelnig@iem.at</a>) wrote:</div> <blockquote type="cite" class="clean_bq"><span><div><div></div><div><br>>  

<br>> 1. A single external is built for each C source file specified in the SOURCES list   

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

<br>>  

<br>> So the questions:   

<br>>  

<br>> - Does anyone know the reasoning behind “2”? It seems unnecessarily compllicated creating the shared library   

<br>

i think you misunderstood the reason for the shared library.

it is really for sharing code among a *number of externals*.

<br>think of a (hypothetical) Gem, that is broken into one-object-per-file

<br>externals: all Gem objects need to share a significant amount of code,

<br>so how would you like to create the externals:

<br>- make each object self contained (that is: have multiple copies of the

<br>shared code, one copy for each external)

<br>- enforce the user to load a "Gem-core" library first that provides the

<br>shared code

<br>- dylink all externals with a shared library that provides the shared code

<br>

<br>approach #1 is not really feasible: unstripped, the Gem binary

<br>(containing all objects) on linux is about 33MB (stripped it's still

<br>5MB); iirc both on w32 and OSX it's even bigger. if we leave out all the

<br>objects to get the core library (containing all the shared code), this

<br>reduces to 11MB (1.9MB stripped).

<br>given that Gem has 500+ objects, statically linking the shared code into

<br>each external is not really an option (5GB installation data?)

<br>

<br>approach #2 is impractical and doesn't really differ much from having a

monolithic library containing all the objects, so what's the point?

<br>

<br>approach #3 is like #2, but with the loading of the core-library being

<br>handled automatically by the runtime linker. so that's why this rather

elegant solution has been chosen.

<br>

<br>Gem is a hypothetical example (as it is not split into

one-object-per-file externals), but it illustrates the use-case.

<br>

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

<br>

<br>

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

<br>

<br>well, your use-case is actually outside the scope of the template

<br>Makefile :-)

<br>you could either:

<br>- adapt your sources to fit the template/Makefile workflow (cram all the

<br>code needed for a single external into a single file)

<br>- rethink your design: if you really need multiple source files for a

<br>pd-object, it's probably feature-bloated anyhow. try splitting the

<br>functionality into multiple Pd-objects, each fitting into a single

C-file; probably with some shared functions in a dylib.

<br>

<br>OR

<br>

<br>- use '#include "more_stuff.c"' stanzas in your *main* C-file to

<br>virtually cram all code needed for the external into a single file. it's

<br>ugly, but if the code is nicely written (that is: no symbol clashes),

it's probably the easiest fix.

<br>

<br>- hack the template Makefile to fit your needs; that Makefile is a

suggestion; no-one forces you to use it as it is provided.

<br>you might even extend the Makefile in a generic way to allow specifying

<br>multiple C-files on a per-object basis, something like:

<br>

<br>SOURCES = mycobject.c

<br>mycobject_XTRA_SOURCES = more_stuff.c less_staff.c

<br>

<br>

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

<br>

seems like a bug (that is very unlikely to be fixed, as it is an edge case).

<br>an easy workaround is to provide a (dummy) file libmyext.c:

<br>$ touch libmyext.c

<br>

<br>mgfet

<br>IOhannes

<br>

<br>

<br>

<br><hr>_______________________________________________<br>Pd-dev mailing list<br>Pd-dev@lists.iem.at<br>http://lists.puredata.info/listinfo/pd-dev<br></div></div></span></blockquote></body></html>