Re: AC_CHECK_FUNCS and gcc with -Werror

[Steffen Dettmer]

(OT)

On Thu, Mar 4, 2010 at 12:42 AM, Russ Allbery <address@hidden> wrote:
> Steffen Dettmer <address@hidden> 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