Ok, I committed a Makefile based on the Library Template. It does not build pix_opencv_contours.cc pix_opencv_matchshape.cc, they both gave a big dump of roughly the same errors.
The template Makefile will handle a lot of things automatically for you, the trade-off is that its strict about certain things: every object must have a help patch, all example files must go into examples/, etc. The template Makefile is really easy to make a Debian package from too. * is pix_opencv_opticalflow.pd an example or an abstraction? If its an example, it should go into examples/ with of.frag. If its an abstraction, it should have a help patch. Or if its just a text patch, it can be left out of the Makefile and left as is. * pix_opencv_blobtrack.cc seems to require opencv2, does that mean both opencv 1.2 and opencv 2.x need to be installed? Is there an OpenCV2 framework for Mac OS X? On Mac OS X, I was building against Pd-extended 0.43 since pix_opencv uses some new Gem headers that aren't included in Pd-extended 0.42. The template Makefile automatically looks in Pd-extended if its in /Applications. If you want to choose which version of Pd-extende to build against: make PD_PATH=/Applications/Pd-0.43.4-extended-20121223.app/Contents/Resources .hc On Dec 26, 2012, at 3:11 PM, Antoine Villeret wrote: > hello, > > I made an update today on pix_opencv with an improvement of > pix_opencv_contours which is now a complete replacement of other > pix_opencv_contours_* objects > > and I sent a private mail to Lluis even if I found some old mails on > this list by him and i never get any answer > so maybe you can go ahead according to the "one week consensus" ? > > there is actually one strange make rule, its for a custom blobtracker > but I will change this as soon as i have time > > merry chrismas to all > > cheers > > a > -- > do it yourself > http://antoine.villeret.free.fr > > > 2012/12/13 Hans-Christoph Steiner <[email protected]>: >> >> On Dec 13, 2012, at 12:21 PM, Antoine Villeret wrote: >> >>> 2012/12/13 Hans-Christoph Steiner <[email protected]>: >>>> >>>> On Dec 13, 2012, at 3:43 AM, IOhannes m zmoelnig wrote: >>>> >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA1 >>>>> >>>>> On 2012-12-12 19:42, Antoine Villeret wrote: >>>>>> i've already tried to make a C++ external from the template but i >>>>>> never reach something which works so if you have a working template >>>>>> please let me know >>>>> >>>>> pix-opencv depends on external libraries, and afaik often needs >>>>> specific versions thereof. >>>>> i think it is a perfect candidate to *not* use a template Makefile but >>>>> instead use something more intelligent like autotools, scons, >>>>> cmake,...which reminds me that it already does use autoconf >>>> >>>>>> and what about including it in Gem ? as it depends on it (and it >>>>>> may depends on very new feature such as ROI soon) i think it's a >>>>>> better choice >>>>> >>>>> pix-opencv is developed by different people than Gem. i think it is >>>>> good to keep the repositories (and user-management) separate. >>>>> so: i'd rather not have pix-opencv be "part" of Gem. >>>>> >>>>> but: >>>>> >>>>> i agree that pix-opencv could be made more readily available to users. >>>>> it might be a good idea to distribute it together with Gem-releases. >>>>> >>>>> so: >>>>> >>>>> the build-system needs little changes to build a pix_opencv found in >>>>> extra/ (basically, uncomment the relevant lines at the end of >>>>> extra/configure.ac and add a line to extra/Makefile.am) >>>>> >>>>> >>>>> >>>>> we could then create a script that pulls in pix-opencv to >>>>> extra/pix_opencv before the builds are actually started. >>>> >>>> autotools are very useful for detecting platform differences and making >>>> the build system respond differently based on that, like handling multiple >>>> optional dependencies like in Gem. For the case you describe, that works >>>> well with the template Makefile. For an object that requires a specific >>>> library, add it to LDFLAGS. If that library not installed, it'll throw an >>>> error, which is what you want since the object requires that library. >>>> pix_opencv requires opencv, and does nothing without it, so no autotools >>>> necessary. >>> >>> I don't know anything about autotool and it looks like quite dark for >>> me so if i can avoid another headache it's better :-) >>> >>> >>>> >>>> As for version differences, I generally find it way too much work to >>>> support building against various versions of the API and just choose one >>>> and standardize on it. Then, once this lib is widely distributed it could >>>> be worth building against different versions of opencv if there is demand. >>>> First get it out there for the majority of users, then deal with any >>>> relevant edge cases, otherwise you are likely to spend lots of time >>>> dealing with edge cases that might not really be relevant. >>>> >>>> My problem with autotools is that very few people know how to modify it, >>>> so the build system then rots because its not maintained and other issues. >>>> I've seen this happen to a lot of autotools build systems in Pd projects >>>> over the years. For example, Gem's autotools setup has gotten so complex, >>>> its almost impenetrable for me, and I've done a fair amount of autotools. >>>> This is one reason to not include every object in Gem. >>>> >>>> The Makefile that's there is already quite close to working. I'm happy to >>>> commit fixes to get it working if that's OK with the maintainers. I've >>>> committed to pix_opencv before. Indeed I did this work back in 2009 but >>>> sevy objected so it was reverted and abandoned: >>>> >>>> http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/pix_opencv/Makefile?r1=12563&r2=12571 >>> >>> I think we should ask Lluis for that >>> with the current Makefile in the SVN man should have opencv >= 2.3 >>> (some externals won't compile with previous OpenCV version) but there >>> is not check about that I think >>> and I can build with >>> ./configure --with-pd=<PATH> --with-gem=<PATH> >>> make >> >> The Makefile equivalent of this is: >> >> make PD_SRC=<PATH> GEM_SRC=<PATH> >> >> Otherwise it'll look in the default installed locations for the headers. >> >>> but only tested on Ubuntu >>> I don't know if it could build on other linux distro and even less on >>> Mac OS X and Windows >>> Should fixing that Makefile.in be a starting point to distrute the package ? >> >> Let me know and i'll do it. Is Lluis on this list? Yes, I can include >> 'make osx_tarball' so its easy to make the tarball for releases. >> >> .hc >> >> _______________________________________________ GEM-dev mailing list [email protected] http://lists.puredata.info/listinfo/gem-dev
