On Thu, Jul 30, 2009 at 06:04:40PM -0400, Martin Owens wrote: > On Thu, 2009-07-30 at 16:01 -0400, Chris Frey wrote: > > > git clone git://repo.or.cz/barry.git > > mkdir scripts > > cd scripts > > git clone ../barry > > git checkout scripts > > cd ../barry > > ../scripts/snapshot.sh 0 15 master > > > > You can use any branch or tag you like... master is probably the most > > common. > > Is there any way you could push all that into a Makefile? something like > `make build`? It does seem rather convoluted compared to just grabbing > the source and replacing the debian changes files. > > Thoughts?
I can't put git clone in a makefile (chicken and egg), but I could eliminate the second clone by moving the snapshot script into maintainer/, which I offered a couple of emails back. I put those scripts in their own branch because a lot of them were more "meta" and didn't really fit in Barry proper. They didn't need to be included in the tarball release, but I used them every day. There's a lot of things that the makefiles don't do, for various reasons. For example, udev and hal scripts are not installed by default, because this could be built on a non-linux system. That's best left to the binary packages. Autoconf does support targets that attempt to build a release tarball, but I build two tarballs: one for everything (bz2), and one as a debian package (gz). It was just easier to do that in a script. In the latest distros, such as Fedora 11, autoconf got even more picky about how it wants configure created, and that knowledge is stored in the buildgen.sh script. Over the years, the usual "autoreconf" command drifted in and out of the "trusted" state, and currently it is out! This means that buildgen.sh is the safest way to create configure, but debian/rules does not call it on a freshly checked out tree. The documentation generation stage (both www and doxygen) could be added to the makefiles though. Documentation should probably be added as a doc package as well. Patches thoughtfully considered. :-) Note that any change to the build system must pass the test/buildtest.sh script. After all that, snapshot.sh doesn't look so bad to me. :-) > I've also become less than impressed by git, which seemed last night to > want to thwart my every effort to checkout or revert. Well, I keep CVS on sourceforge up to date too, if that's easier. I do find that git is one of those technologies that require daily dedication for a while before it clicks, but then I found that with CVS too. There were many years where I felt stupid at the CVS command line only because I used it about twice a year. So if you have git questions, feel free to ask. I'm a fan, and am quite happy to answer if I can. - Chris ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
