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 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 ? > >> caveat: >> both Gem and pix-opencv are complex projects. Gem has slow release >> cycles, those of pix-opencv seems to be even more so. >> synchronizing both projects so that we can create a "stable" >> Gem-package including a "stable" pix-opencv could be impossible. >> >> so in a way it would be better if pix-opencv was distributed >> separately, but actively. > > > I agree, lumping everything into one giant package makes it into a > maintenance headache and centralizes that headache on IOhannes, since he's > the lead maintainer of Gem. Its good to avoid it. i do agree too, but I think it could be good to distribute pix_opencv with Gem whenever it's possible and not too hurting for your head :-) a. > > .hc > _______________________________________________ > GEM-dev mailing list > [email protected] > http://lists.puredata.info/listinfo/gem-dev _______________________________________________ GEM-dev mailing list [email protected] http://lists.puredata.info/listinfo/gem-dev
