svn commit: samba r22731 - in branches/SAMBA_3_0/source: . tests

[derrell at samba.org]

Andrew Bartlett <abartlet at samba.org> writes:

> On Mon, 2007-05-07 at 21:31 -0400, derrell at samba.org wrote:
>> Andrew Bartlett <abartlet at samba.org> writes:
>> 
>> > On Mon, 2007-05-07 at 13:37 -0400, derrell at samba.org wrote:
>> >> By
>> >> consistently testing for and using the warnings-are-errors flag, the problem
>> >> is eliminated.  During a developer build, readahead() is found to _not_ exist
>> >> so the compilation works fine.  During a production build, readahead() is
>> >> found to exist and the compilation works fine since it doesn't use the
>> >> warnings-are-errors flag.
>> >
>> > This sounds like a disaster!
>> >
>> > We shouldn't be gaining or loosing features just because we are in a
>> > developer build.  That way leads to madness, particularly if a user or
>> > developer encounters a problem, then rebuilds with --enable-developer to
>> > trace it down.
>> 
>
>> IMO, it's worthwhile for developer builds to error upon missing declaration so
>> I prefer the existing implementation which enables it for all developer
>> builds.  It should not, however, be enabled at the expense of not being able
>> to do a compile with a developer build.
>
> Are you saying that no header on your system declares readahead()?

Exactly.  And some functions, like exit(), are explicitly not declared in
header files on many systems.  I believe this has to do with some
compatibility issue with C++, but I don't know the details.  

> The correct fix is to fix the missing declaration.

No.  It's not an individual user's responsibility to make changes to system
header files.  There are sometimes reasons (as with exit) that functions are
not declared in system header files.  Making manual changes will screw up
future system upgrades.  System header files should not be touched.

> The whole point of the developer build is that issues like this are
> found and fixed.

No.  The purpose of that feature (from my point of view -- I don't know who
put it in or what their intention was) is to ensure that non-declared *SAMBA*
functions are identified and declared, not to try to fix what may or may not
be broken systems on which the development is being accomplished.

On systems that provide declarations for all functions, my change will have no
effect.  It has an effect only on systems where some system functions are
missing declarations in system header files.  If you've succeeded in a
developer build and compile immediately prior to this change, you will still
succeed with no changes to what configure detects nor to your build.  Only
those (few?) systems where some functions are missing declarations in system
headers are affected, and this change allows them to compile in developer
mode whereas immediately prior to this change, they could not compile.

I'd still like to hear alternate implementation suggestions that solve the
problem.

Cheers,

Derrell