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
