(OT) On Thu, Mar 4, 2010 at 12:42 AM, Russ Allbery <rra@xxxxxxxxxxxx> wrote: > Steffen Dettmer <steffen.dettmer@xxxxxxxxxxxxxx> writes: > >> I would guess the users that forget to fix warnings are the same >> that forget to run `make warning' :) > > Well, you also have the same problem with developers who don't > remember to run the test suite. :) test-WHAT? lol - nonono, just kidding interestingly, here we have less issues with tests, it usually works (of course, there some minor things from time to time), I think because most tests that pass on any platform pass on all platforms. > The best solution, in my experience, is to have a separate > build host that periodically attempts to build the current > trunk, using make warnings, and then runs the test suite and > complains if it fails. Yes, I have some script doing something like this. It knows a bit about subpackages and generates a simple report telling which subpackages `make' and/or `make check' for which super-packages. Before writing this I tried cruise control, but it I didn't liked it (bad make integration, unit test results with errors count as OK because you successfully get an XML file with test result and you need a browser - and it has some `auto-blamer' that mails the one who checked in latest, not to the one who made the mistake :)) Do you have some suggestions what tools could help to do such nightly builds? It should be incremental, if possible, VCS is CVS, must support to run pre-configure scripts, should support autoconf subpackages and multiple variant building from the same sources. I think a generic solution had need to know about configure.in structure (i.e. AC_CONFIG_SUBDIRS) or come with some M4 macros that generate some tool.conf (that could include dirs= and other needed information). Is there something I should take a look at? >> (we have some if test $CC=CL.EXE check, but better would to run >> it and check the output text / version number to find out what >> it is, also to support options that have been renamed across the >> versions / years) > > You can, and that would be more flexible, but it would also require > researching and maintaining warning flags for whatever compilers you want > to support. Yes of course? What else would be possible? When we want to support a new version of let's say CL.EXE, we have to learn what flags to change how and implement this, sure. What do you mean? > I haven't found that to be a particularly useful way to spend > time, but then I'm mostly working on open source software where > building with vendor compilers isn't that common. If you > specifically want to support a particular vendor compiler, it > may be worthwhile to do something more complex to select > warning flags for that compiler as well. Unfortunately, most compilers we use don't have a -Werror alike function (well, maybe not `unfortunately'; personally I would not need such a flag, because vim jumps to the warning when one occures [if the error format is correctly set up etc], so I see when a warning happens, but others tell they miss the warnings in the heaps of default make output). oki, Steffen _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
