Hi Hans and all, happy new year and thanks for your work
sorry for the delayed answer, I was far away from Internet in the mountain for few days... I can log through SSH on pdlab computers (not tested all for now) but I have few more questions : 1- What can I do and (more important) what should I never do on those machines (particularly about SVN checkout and installing / updating lib) 2- There is no "pix_opencv" folder in the pddev home (on macosx105-i386.pdlab.puredata.info) where could I find the up-to-date folder ? should I cd to /Users/pddev/pure-data/trunk/externals/pix_opencv (this seems to be very old) ? Where should I work ? sorry for those silly questions, but i don't want to break something... a. PS : this message should be signed with OpenPGP :-) Le 31/12/2012 18:28, Hans-Christoph Steiner a écrit : > > Hey Antoine, > > So I installed OpenCV 2.3.1 on the PdLab Macs using Fink, and fixed the > Makefile to use pkg-config on all platforms. I don't know the protocol on > editing the README, so I didn't touch it. It would make things easier for > users if there was only one build system and the README only covered that. > I'll leave that to you. Here's how to make a build on Mac OS X: > > $ . /sw/bin/init.sh (load Fink for other libs like opencv) > $ cd pix_opencv > $ make > PD_PATH=/Users/pd/auto-build/pd-extended/packages/darwin_app/build/Pd-0.43.4-extended-20121231.app/Contents/Resources/ > $ ./embed-MacOSX-dependencies.sh . > > ./embed-MacOSX-dependencies.sh finds all the dynamic libraries needed and > embeds them in the folder. Then you can tarbz the whole pix_opencv folder, > and that's the installable library. Just drop that into ~/Library/Pd or > /Library/Pd. > > For the PdLab Macs, building on macosx105-i386.pdlab.puredata.info will > include the 32-bit libraries, which is what you need for current versions of > Pd-extended for Mac OS X. Gem included in Pd-extended doesn't work for > 64-bit (Gem master does at this point, I think). Building on > macosx106-x86_64 (chaos.medien.uni-weimar.de) will make 64-bit builds. > > For someone to build this on their own machine, they'll need to do: > > fink install opencv-dev > > On a related note, if you stick with the Library Template Makefile and > layout, that it'll be trivially easy to make Debian packages for it. I can > do that too, or leave it to you. > > .hc > > > On Dec 27, 2012, at 3:36 PM, Hans-Christoph Steiner wrote: > >> >> Hey Antoine, >> >> If you are willing to maintain Mac OS X and/or Windows ports, you can get >> access to the PdLab build machines, and I'm willing to install opencv 2.4.x >> on those machines. Basically, once everything is setup, you'll just need to >> make the builds on the various platforms by doing 'make'. >> >> .hc >> >> On Dec 27, 2012, at 10:35 AM, Antoine Villeret wrote: >> >>> no idea, there wasn't any official opencv framework in the past, only >>> some make by people who needs it but never maintained nor updated... >>> so I think it still the case... >>> people have to wait for someone who wants to make a framework, or to >>> build it themselves >>> but, are the packages available for Mac OS X through a package manager >>> with automatic installation like in Debian ? >>> if no, people have to build package by hand if I understood correctly >>> so if they can build a pd package it will be very easy for them to >>> build OpenCV 2 from lastest release >>> which is I think a better idea than using an old and obsolete OpenCV >>> Framework... >>> >>> I don't have a Mac OS X machine under hand for now to test it >>> but I think it's not really hard to make a step by step tutorial to >>> make pix_opencv working on OS X with a tarball and some dev tool >>> >>> -- >>> do it yourself >>> http://antoine.villeret.free.fr >>> >>> >>> 2012/12/27 Hans-Christoph Steiner <[email protected]>: >>>> >>>> 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 <[email protected]>: >>>>>> >>>>>> 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 <[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 >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>> >> >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ GEM-dev mailing list [email protected] http://lists.puredata.info/listinfo/gem-dev
