Here's a simple Gem Makefile for pix_opencv:
http://pure-data.svn.sourceforge.net/viewvc/pure-data/branches/by-author/eig...
They are using autoconf now because they want to support different versions of opencv. But the above Makefile might be enough for your needs.
.hc
On Oct 16, 2009, at 3:34 AM, IOhannes m zmölnig wrote:
Jaime Oliver wrote:
Hi all,
Is there a makefile for a pix_external somewhere? OR could someone give me some pointers on how to make one?
interesting coincidence, as i had in mind to do something like that in the last few days.
the reason is, that i would like to move out some of the objects that pull in external dependencies (like [pix_artoolkit]). these "extra" objects (which are technically externals for Gem), live in Gem/src/extra/
just yesterday i submitted the M$VC project for building [pix_artoolkit] as a single object external. there should be a simple autoconf based build system as well, which might work for you just fine.
(after doing a quick check, i think it won't work as i stripped down the configure to the bare essentials)
i'm currently looking for a non-existing Gem-object without any dependencies that could be included as a skeleton for new objects (mainly focusing on the build-system).
I am looking for something I can put in a folder with the .cpp and .h files and run make...
I suppose I would have to link to GEM somehow...
just like you have to link against Pd...usually you don't :-)
So far, I can only think of the output of compiling gem pix_ in osx and start from there:
i would recommend looking at pix_opencv
if you external does not have any dependencies, would you consider adding it as an example to the Gem/extra section? in this case, it ought to be GPL.
fgmasdr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
----------------------------------------------------------------------------
"Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you." - Richard M. Stallman