On 3/2/07, Chris Frey <[EMAIL PROTECTED]> wrote: > On Fri, Mar 02, 2007 at 03:58:20PM -0800, troy engel wrote: > > Surely -- when I get time I'll cook it up and submit, it will of > > Sounds great, thanks!
(long winded here, sorry) OK I played around last night and took some notes; the short comment here is that "btool/bcharge et. al are a no brainer, gui/ creates some options how to do it". So I'd like to get some feedback on which way you want to go before wasting time. All code is 'DESTDIR' install friendly which makes it great for us RPM/DEB people. Basically out of my notes it works like this: tools/ is just a generic compile that requires libusb(-devel) and g++, alone and by itself run from the top level ./configure it'll install cleanly and I could package that alone in minutes. (NOTE: udev/ and hotplug/ aren't installed by make install, is it supposed to be that way?) Now comes gui/ - in order to compile it realtime without libbarry installed you have to do a little voodoo with gui/configure, like so: cd gui/ export PKG_CONFIG_PATH=../; export CXXFLAGS=-I../..; export LDFLAGS=-L../../src; ./configure (option option option option, tons of --options) This allows the subconfigure to find all the parts that were previously built for tools/; I can then do a normal make/make install without problems. The compile of this, however, requires a litany of dependencies; lemme just paste my "yum install" output for various pieces I had to go get: ==snip== yum install gtkmm24-devel: Installing: gtkmm24-devel Installing for dependencies: cairomm cairomm-devel glibmm24 glibmm24-devel gtkmm24 libsigc++20 libsigc++20-devel perl-XML-Parser perl-libwww-perl yum install libglademm24-devel: Installing: libglademm24-devel Installing for dependencies: libglademm24 yum install libtar-devel: Installing: libtar-devel ==snip== (NOTE: libtar-devel was not checked for during ./configure, I had to compile-and-fail to discover that it was needed. bug? If so I'll report.) OK that's the picture; the question is now how should we approach it? There are several options, each with it's pluses and minuses: A) Create one SPEC file to rule them all. The spec file would require optional parameters passed into it like so: 'rpmbuild -ba barry.spec --with gui --with opensync' Internally the spec file would then dynamically adjust it's BuildRequires: and Requires: lines and so forth to tighten up the needs on the fly. Positive: one file to maintain, one command builds everything as desired Negative: you have to "know" to pass in --with gui, etc. Not n00b friendly. B) Create separate SPEC files for each piece, since there are actually 3 different, separate, unique ./configures within the barry tarball. barry.spec, barry-gui.spec, and barry-opensync.spec. gui and opensync would require libbarry-devel.rpm installed, etc. Positive: able to release separate compiles of sub-pieces, can have different maintainers, distributions, etc. Negative: three files to maintain (which might be a positive), have to compile pieces separately, etc. C) Break apart the original barry tarball, and not distribute gui/ and opensync/ as part of the main ball of joy. barry-tools.tar.gz, barry-gui.tar.gz, barry-opensync.tar.gz. Positive: distro maintainers can more easily maintain and patch (do a "yum list libopensync* for example to see other opensync plugins). Code could be easier to add unique developers to (i.e. only opensync coders). Compile problems could be addressed uniquely. Negative: more work for barry project to maintain and release. Possibly introduce out-of-sync problems (but not likely). D) Rework the top level ./configure to integrate the subprojects, one SPEC file and one ./configure. This doesn't much change from (A) above, but is cleaner all around. All positive/negative are pretty much the same. E) Go drink beers and watch hockey. Personally I'm a fan of (E) being the choice made, but I'm sure the Barry project won't go for it. :) Or maybe they will! Let's fly to Waterloo/Mississauga and take RIM out (or let them take us out, heelllooo). Seriously, I'd love some input. -te PS: gmail caught that I misspelled Mississauga. tight. :) -- some live, some die in the way of the samurai ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
