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 <[email protected]>: > > 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 <[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
