On Sat, Mar 03, 2007 at 12:49:35PM -0800, troy engel wrote: > 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.
Thanks for spending time on this! > 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?) Yes... so far, hotplug and udev have been somewhat system specific sometimes, at least between Fedora/Debian/Ubuntu, that I've seen. I don't really care to put system specific stuff in the makefiles when, in my opinion, this stuff probably belongs in the binary packages anyway. They are there as guides for the binary maintainers and source tarball users. > 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. I'm surprised you need CXXFLAGS, etc. Does this add to the existing compile flags or replace them? For the GUI it shouldn't matter, but when compiling the library, it is important that -fno-strict-aliasing is set. Of course, I usually do a make install on the library, then set PKG_CONFIG_PATH to the installed lib directory. This tends to make binaries that are hard linked to that path (libtool uses -rpath), so that may not be desireable for a binary package. > 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== Yep, the GUI has a fair number of dependencies. :-) The main dependencies are listed in the GUI README, and those dependencies themselves (gtkmm, glibmm, etc) have fairly large subdependencies. I don't expect you'll need to depend on all of the above in your binary packages. As long as the main ones are met (see README), yum or apt-get should be able to figure out the rest. > (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.) libtar doesn't have pkg-config support on some of the systems I've put it on (Debian stable for instance), so this check would need special configure.ac logic. Currently this is only specified via command line, and it tries to guess by default. Patches are welcome of course. :-) > 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. I like this option merely for the fact that when updating things, it will be harder to forget things if it's all in one place. I'm not wedded to it though, and can see the advantage of separate spec files, especially for clarity. I'm quite open to adding a script in the rpm/ directory that shows how to build things with the proper rpmbuild command line, if that helps. > 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. This is fine too. > 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). I could see this sometime in the distant future, but I don't believe Barry is big enough to split up. Each subproject is a separate compile as well, so while you do get all the source in one tarball, there is nothing forcing users to compile it all, only what they need. For now, Barry will stay as a single source tarball. > 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. I see great value in keeping them separate. I want it to be as easy as possible for people to get started with the base library and command line tools. If it is all one big project with a huge list of dependencies for the single compile, non-programmers, or even programmers with little time on their hands, will give up as soon as they hit a compile error. The Barry library, btool, and friends should Just Work (tm). The other items should be enticing enough to those interested to handle the extra compile, while not being a barrier for those who don't need it. > E) Go drink beers and watch hockey. Isn't that the afterparty? :-) - Chris ------------------------------------------------------------------------- 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
