On Thu, 2008-08-21 at 18:07 +0200, js_bach@xxxxxxxxxx wrote: > Well till i get things running, i dont want to get anyone fiddle around with > the build system, that's all. After that, i'd appreciate if anyone comes up > with a patch, change whatever it is. Help is always welcomed to give > and take. This is just a friendly suggestion: Include your configure.in, configure.ac, Makefile.am and some script named 'autogen.sh' to reproduce the build system (i.e. invoking aclocal, automake, autoconf, etc). Tracking 'configure' itself in your repository presents problems: 1 - Its un-needed clutter 2 - People updating their svn / git / hg from your's may actually have to solve merge conflicts in configure itself, which is a __major__ pain in the butt. This happens if they have run 'autoreconf' themselves, or similar. 3 - People will pick patches to configure, but ignore the underlying changes to configure.in / configure.ac and wonder why it breaks. 4 - People with commit access to your repository will also have to resolve merge conflicts in configure, no fun :( So now we realize that we actually have several versions of the source code, each one slightly different: * The 'trunk' or bleeding edge code requires developers to generate the build system themselves. * The 'source tgz' downloads contain configure, Makefile.in plus all of the files needed to re-generate them. This is likely the file OS packagers will use to package your program in the future. * Branches of the repository might contain either / or, depending. The GPL requires only that you make the source code available with all files needed to complete the build. So, in essence, you could exclude the things needed to rebuild the build system, but you would alienate anyone who is willing to help you 'properize' it. It sounds like, to me, you wish to exclude these files because you are unsure of their correctness? The fastest and easiest way to fix that is to publish them, even if broken then ask someone to try to reproduce the build and send patches. > Autotools are great (but a bit unbendable :} ) , and again many thanks ! Please realize that your trying to wrap your head around two very complex tools at once, Autoconf and Automake. You are not going to become an overnight 'guru' with either. In fact, the first time I used Autoconf, I spent more time messing with Autoconf than I did writing the program in the first place. The best thing to do is publish it all, even if its broken and invite others (even on this list) to tell you why its broken and how to fix it. Best of luck with your project :) --Tim -- Monkey + Typewriter = Echoreply ( http://echoreply.us ) _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
