Re: [Barry-devel] build system, nested packages, and debian directory
On Thu, Sep 06, 2007 at 12:57:56AM -0400, Simon Ruggier wrote: If you build the gui as a standalone package, in a script perhaps, you should still be able to build it with no extra -I flags. The above change only affects the build of the main library (specifically, the src directory), and the flags that are exported in the configure script don't get applied when the gui package is built by itself. Yep, that's what I'm doing for now in the release scripts under maintainer/. If I do that regularly, I should be able to catch header bugs like that. Another possible solution may be to maintain an explicit list of files you expect to be installed, and use a script to check that they're present on the system and in the packages. Lintian does some of this when I build Debian packages, but doesn't check header stuff. I think the release scripts should be enough of a check for now. Thanks, - Chris - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
Re: [Barry-devel] build system, nested packages, and debian directory
On Tue, Sep 04, 2007 at 10:01:41PM -0400, Simon Ruggier wrote: Ok, I've fixed the inaccurate help string, removed the extra build dep, and made the make dist warning into an error :) Patch applied, thanks! This change introduced something that I didn't notice the first time: --- src/Makefile.am 18 Aug 2007 05:06:06 - 1.23 +++ src/Makefile.am 5 Sep 2007 21:07:52 - @@ -25,9 +25,9 @@ # Only ever increment the first 2 numbers in this version: LIB_BARRY_VERSION = 0:9:0 -# Disable the default -I. -I$(srcdir) -I$(topdir), etc, as our includes -# are proper anyway. :-) -DEFAULT_INCLUDES = +# Disable the default -I. -I$(srcdir) -I$(topdir), etc, but $(top_builddir) is +# needed for config.h +DEFAULT_INCLUDES = -I$(top_builddir) Since the gui build is now part of the main build (or can be), this removes one of the built-in checks I had, which always built the GUI based on a make install of the root directory. Thus, any bugs in the headers that would prevent a proper build (e.g. including config.h in a published header, or forgetting to install one) would be shown by the GUI build. I think the only way around this is to make sure the maintainer/ scripts always build in a two-stage manner, although it would be nice to catch these kinds of bugs as soon as possible. If you have any suggestions on how to keep this automatic header checking, I'm all ears. :-) I forgot to mention it until now, but my autotools have a newer INSTALL file than the one that is in cvs, so it's been appearing in all of my diffs. It would make sense not to track it in cvs. Thanks, I've removed them. - Chris - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
Re: [Barry-devel] build system, nested packages, and debian directory
On 9/5/07, Chris Frey [EMAIL PROTECTED] wrote: On Tue, Sep 04, 2007 at 10:01:41PM -0400, Simon Ruggier wrote: Ok, I've fixed the inaccurate help string, removed the extra build dep, and made the make dist warning into an error :) Patch applied, thanks! This change introduced something that I didn't notice the first time: --- src/Makefile.am 18 Aug 2007 05:06:06 - 1.23 +++ src/Makefile.am 5 Sep 2007 21:07:52 - @@ -25,9 +25,9 @@ # Only ever increment the first 2 numbers in this version: LIB_BARRY_VERSION = 0:9:0 -# Disable the default -I. -I$(srcdir) -I$(topdir), etc, as our includes -# are proper anyway. :-) -DEFAULT_INCLUDES = +# Disable the default -I. -I$(srcdir) -I$(topdir), etc, but $(top_builddir) is +# needed for config.h +DEFAULT_INCLUDES = -I$(top_builddir) Since the gui build is now part of the main build (or can be), this removes one of the built-in checks I had, which always built the GUI based on a make install of the root directory. Thus, any bugs in the headers that would prevent a proper build (e.g. including config.h in a published header, or forgetting to install one) would be shown by the GUI build. I think the only way around this is to make sure the maintainer/ scripts always build in a two-stage manner, although it would be nice to catch these kinds of bugs as soon as possible. If you have any suggestions on how to keep this automatic header checking, I'm all ears. :-) If you build the gui as a standalone package, in a script perhaps, you should still be able to build it with no extra -I flags. The above change only affects the build of the main library (specifically, the src directory), and the flags that are exported in the configure script don't get applied when the gui package is built by itself. Another possible solution may be to maintain an explicit list of files you expect to be installed, and use a script to check that they're present on the system and in the packages. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
Re: [Barry-devel] build system, nested packages, and debian directory
On 9/4/07, Chris Frey [EMAIL PROTECTED] wrote: Thanks for the patch! I've taken a look at it, and there are a couple things I'm not keen on. If you send me a patch that addresses these issues, I'll probably apply it. :-) You've fixed a number of configure problems and made it more robust, which is great. First, in the debian/rules makefile, you changed: - $(MAKE) distclean - (cd gui $(MAKE) distclean) + -$(MAKE) distclean + -(cd gui $(MAKE) distclean) I'd rather fix the cause of the make errors than ignore them. Why did you need the - prefixes? This is actually standard practice with command make distclean, because it only works when the makefiles are present. The clean target shouldn't fail because configure hasn't been run yet, or because the target was run twice. Second, the --enable-opensync switch doesn't work for me. I had to use --enable-opensync-plugin which was different from the --help output. Third, if you're adding a build dependency to the debian scripts for libopensync-dev, I'd like it to match version 0.22 or greater. What system are you testing this on, btw? oops, I thought I took that out - I added it while adding the gtkmm and glademm deps, even though it shouldn't be there until the debian package actually builds an opensync plugin. I'm testing this on Ubuntu 7.04, but I can test that builds work on other versions of debian using pbuilder. There are two things I'm not happy with: I had to put a set of variable exports in configure.ac when a subdirectory is enabled, so that they build and link against the source tree - I couldn't find a more elegant way to get that behaviour. I'm not sure either, but I suspect the answer might be in other projects that have a library portion to them. I couldn't find any other way to pass information to the nested configure scripts. The only other thing I can think of would be to split them up into separate source trees, but I don't see the point of doing that. It may be hard to find projects with a similar layout and dependency structure. The other thing is that when the subdirectories aren't enabled (and they aren't by default), they won't be included in make dist. I figure this is ok since you don't use make dist to generate your release tarballs anyway, but I added a check that will warn prominently when the conditionally enabled subdirectories are missing from the dist. According to the documentation, the only other workaround is to manually include them in the dist instead of echoing a warning. A hard failure would be better, along with the warning. Something that stops the build process, so that it never accidentally gets run in some automated build process. I considered that, but I figured that since make dist will only ever get used to generate release tarballs, (and right now, you seem to be using a script to do that instead) a warning would be ok as long as it's very visible. I'll change it though. I'll send a revised patch sometime in the next day. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
Re: [Barry-devel] build system, nested packages, and debian directory
Here, test this out - everything should work the same, except that there are --enable-gui and --enable-opensync flags that will configure those directories and include them in all the recursive targets. I also fixed all the Makefiles so that make dist generates a tarball similar to the release ones, and got out of source tree builds to work. There are two things I'm not happy with: I had to put a set of variable exports in configure.ac when a subdirectory is enabled, so that they build and link against the source tree - I couldn't find a more elegant way to get that behaviour. The other thing is that when the subdirectories aren't enabled (and they aren't by default), they won't be included in make dist. I figure this is ok since you don't use make dist to generate your release tarballs anyway, but I added a check that will warn prominently when the conditionally enabled subdirectories are missing from the dist. According to the documentation, the only other workaround is to manually include them in the dist instead of echoing a warning. Index: Makefile.am === RCS file: /cvsroot/barry/barry/Makefile.am,v retrieving revision 1.5 diff -u -r1.5 Makefile.am --- Makefile.am 6 Jan 2007 04:42:56 - 1.5 +++ Makefile.am 3 Sep 2007 16:07:49 - @@ -1,14 +1,36 @@ -EXTRA_DIST = COPYING ChangeLog README +EXTRA_DIST = COPYING ChangeLog README \ + buildgen.sh \ + data \ + doc \ + hotplug \ + maintainer \ + rpm \ + udev SUBDIRS = . src tools examples man +# conditionally configured nested subdirectories are listed in $(subdirs) +SUBDIRS += $(subdirs) pkgconfig_DATA = libbarry-0.pc all-local: - rm -f barry - ln -s src barry + rm -f $(top_builddir)/barry + ln -s $(top_srcdir)/src $(top_builddir)/barry clean-local: - rm -f barry + rm -f $(top_builddir)/barry +# these directories will be tested for during make dist to warn if they are +# missing +CONDITIONAL_SUBDIRS = gui opensync-plugin +dist-hook: + rm -rf `find $(distdir) -name CVS` + @for subdir in $(CONDITIONAL_SUBDIRS); do \ + if test ! -d $(distdir)/$$subdir; then \ + echo ###; \ + echo WARNING: The $$subdir subdirectory has been omitted!; \ + echo rerun configure with --enable-$$subdir, then run make dist again; \ + echo ###; \ + else :; fi \ + done Index: configure.ac === RCS file: /cvsroot/barry/barry/configure.ac,v retrieving revision 1.18 diff -u -r1.18 configure.ac --- configure.ac 18 Aug 2007 19:45:41 - 1.18 +++ configure.ac 3 Sep 2007 16:07:49 - @@ -108,5 +108,20 @@ examples/Makefile man/Makefile libbarry-0.pc]) -AC_OUTPUT +# nested packages +AC_ARG_ENABLE([gui], [AC_HELP_STRING([--enable-gui], [build the gui])]) +if test $enable_gui = yes; then + AC_CONFIG_SUBDIRS([gui]) +fi +AC_ARG_ENABLE([opensync-plugin], [AC_HELP_STRING([--enable-opensync], [build the opensync plugin])]) +if test $enable_opensync_plugin = yes; then + AC_CONFIG_SUBDIRS([opensync-plugin]) +fi +if test $enable_gui = yes || test $enable_opensync_plugin = yes; then + export CXXFLAGS=-I`pwd` $CXXFLAGS + export LDFLAGS=-L`pwd`/src $LDFLAGS + export PKG_CONFIG_PATH=`pwd`:$PKG_CONFIG_PATH +fi + +AC_OUTPUT Index: debian/control === RCS file: /cvsroot/barry/barry/debian/control,v retrieving revision 1.4 diff -u -r1.4 control --- debian/control 8 Jun 2007 18:45:23 - 1.4 +++ debian/control 3 Sep 2007 16:07:49 - @@ -2,7 +2,7 @@ Section: misc Priority: optional Maintainer: Chris Frey [EMAIL PROTECTED] -Build-Depends: debhelper (= 4.0.0), libusb-dev, libssl-dev, libboost-serialization-dev, libtar-dev +Build-Depends: debhelper (= 4.0.0), pkg-config, libusb-dev, libssl-dev, libboost-serialization-dev, libtar-dev, libgtkmm-2.4-dev, libglademm-2.4-dev, libopensync-dev Standards-Version: 3.6.1 Package: libbarry Index: debian/rules === RCS file: /cvsroot/barry/barry/debian/rules,v retrieving revision 1.8 diff -u -r1.8 rules --- debian/rules 14 Jun 2007 21:19:48 - 1.8 +++ debian/rules 3 Sep 2007 16:07:49 - @@ -63,8 +63,8 @@ rm -f build-arch-stamp build-indep-stamp #CONFIGURE-STAMP# # Add here commands to clean up after the build process. - $(MAKE) distclean - (cd gui $(MAKE) distclean) + -$(MAKE) distclean + -(cd gui $(MAKE) distclean) dh_clean --exclude ./src/Makefile.orig Index: gui/Makefile.am === RCS file: /cvsroot/barry/barry/gui/Makefile.am,v retrieving revision 1.1 diff -u -r1.1 Makefile.am --- gui/Makefile.am 13 Jan 2007 07:43:12 - 1.1 +++ gui/Makefile.am 3 Sep 2007 16:07:50 - @@ -1,5 +1,5 @@
Re: [Barry-devel] build system, nested packages, and debian directory
On Sun, Sep 02, 2007 at 12:08:59AM -0400, Simon Ruggier wrote: Is it intentional that the gui and opensync plugin directories need to be manually built? I can fix the build system and update Debian packaging to automate this if it makes sense. Yes, this was intentional. The more subprojects you build, the bigger the dependency list becomes, and I wanted a base that was relatively easy to build and install. It can be automated with a script, and I could drop a build-all style script in the root directory if this is a major problem. - Chris - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
Re: [Barry-devel] build system, nested packages, and debian directory
On 9/2/07, Chris Frey [EMAIL PROTECTED] wrote: It can be automated with a script, and I could drop a build-all style script in the root directory if this is a major problem. How about building them conditionally with a configure flag like --enable-opensync? - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
Re: [Barry-devel] build system, nested packages, and debian directory
On Sun, Sep 02, 2007 at 12:32:09PM -0400, Simon Ruggier wrote: On 9/2/07, Chris Frey [EMAIL PROTECTED] wrote: It can be automated with a script, and I could drop a build-all style script in the root directory if this is a major problem. How about building them conditionally with a configure flag like --enable-opensync? Well, one of the issues you'll have to overcome is that I do like the build system the way it is. :-) I don't see a major advantage to putting it all together into one, besides the simple part of typing configure / make a few more times. That can be scripted easily. The advantage to keeping them separate is that they can be split into separate source tarballs someday if needed. Not that it's likely, but might be handy someday. Are there real advantages to having things in one configure setup? I don't think I'd change the build process if it is just an aesthetics thing. One thing we do need, though, is a binary package for the opensync plugin, so I am interested in that. If you do decide to convert things, I'd like to keep the behaviour we have now. Specifically: - the plugin and gui are each enabled / disabled separately - if disabled, their dependencies are not required for build, and won't stop the build - keep the configure scripts relatively simple and straightforward (this is a challenge) - Chris - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
Re: [Barry-devel] build system, nested packages, and debian directory
On 9/2/07, Chris Frey [EMAIL PROTECTED] wrote: The advantage to keeping them separate is that they can be split into separate source tarballs someday if needed. Not that it's likely, but might be handy someday. Are there real advantages to having things in one configure setup? I don't think I'd change the build process if it is just an aesthetics thing. I have good news :) It's possible to have the best of both worlds with the AC_CONFIG_SUBDIRS macro, which will recursively call configure in the subdirectories. It looks like I can add this without breaking any of the above use cases. The biggest change would be that when autoconf is called from the top, all of the configure scripts are generated at once, but that looks like a good thing. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
Re: [Barry-devel] build system, nested packages, and debian directory
On Sun, Sep 02, 2007 at 01:29:35PM -0400, Simon Ruggier wrote: I have good news :) It's possible to have the best of both worlds with the AC_CONFIG_SUBDIRS macro, which will recursively call configure in the subdirectories. It looks like I can add this without breaking any of the above use cases. The biggest change would be that when autoconf is called from the top, all of the configure scripts are generated at once, but that looks like a good thing. That's an interesting feature, thanks. It's only a good thing if the separation of dependencies is maintained, though. For example, if you don't have gtkmm installed, you should still be able to build the base library, the command line tools, and the plugin, just not the GUI. - Chris - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
