Ah ok, makes sense. What about opencv2 on Mac OS X? How is that handled?
.hc On Dec 27, 2012, at 10:03 AM, Antoine Villeret wrote: > the default make install command from git repo install gem into > /usr/local/include > -- > do it yourself > http://antoine.villeret.free.fr > > > 2012/12/27 Hans-Christoph Steiner <h...@at.or.at>: >> >> What installs the headers into /usr/local/include/Gem? The Gem package in >> Debian/Ubuntu installs into /usr/include/Gem, so -I/usr/include/Gem needs to >> be there. If some standard installer installs into /usr/local/include/Gem, >> then I'd keep -I /usr/local/include/Gem in CFLAGS_linux, otherwise I'd leave >> it to people to edit the Makefile to add their custom Gem header install >> locations. >> >> .hc >> >> On Dec 27, 2012, at 9:30 AM, Antoine Villeret wrote: >> >>> hi, >>> >>> thansk for that, >>> >>> i had to change the CLAGS_linux variable (line 39) to : >>> CFLAGS_linux = -I/usr/local/include/Gem `pkg-config --cflags opencv` >>> >>> to make it >>> but I don't know if I should or not push it to the SVN ? >>> >>> -- >>> do it yourself >>> http://antoine.villeret.free.fr >>> >>> >>> 2012/12/27 Hans-Christoph Steiner <h...@at.or.at>: >>>> >>>> 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. >>> >>> really easy why not, but how ? >>> if I should make it myself I need a little more help... >>> the links on the page : http://puredata.info/dev/DebianPackagingStructure >>> are not broken but doesn't point to the right discussion... >>> anyway, I found the discussion and others but can't find anywhere a >>> good step by step howto build debian package >>> sorry, this will be my first debian package :-) >>> >>> >>>> >>>> * 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. >>> >>> I forgot this one... >>> I placed it in the examples/ folder for now >>> but working on optical flow externals is in my todo list (with gpu and >>> opencl) >>> >>>> >>>> * 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? >>> >>> yes, most of recent and future externals take advantages of the new >>> C++ API of OpenCV 2.x >>> OpenCV 2 releases are distribute as a tarball for Linux/OSX, there is >>> no Framework on the download page http://opencv.org/downloads.html >>> and a quick search lead to multiple posts over the internet on how to >>> build it by hand (which very easy since the new cmake system) >>> and also a precompiled package : >>> http://vislab.cs.vt.edu/~vislab/wiki/images/4/44/OpenCV2.0.dmg >>> found here : http://opencv.willowgarage.com/wiki/Mac_OS_X_OpenCV_Port >>> but it's obsolete >>> >>> ++ >>> a >>> >>>> >>>> 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/Resource >>>> >>>> .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 <h...@at.or.at>: >>>>>> >>>>>> On Dec 13, 2012, at 12:21 PM, Antoine Villeret wrote: >>>>>> >>>>>>> 2012/12/13 Hans-Christoph Steiner <h...@at.or.at>: >>>>>>>> >>>>>>>> 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 GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
