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
