getting rid of mkproto.sh from Samba3

[Gerald (Jerry) Carter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

tridge at samba.org wrote:

> discussions like these are really good! We all have 
> things to learn about good coding practices. A lot of what
> I have learnt has come from discussions like these
> within various projects, so don't cut it short just
> because we don't agree.

I'm not tailing off because we disagree.  I just think this
is more in the area of philosophical debates.  Everything
has a tradeoff.  For example, fully autogenerated code
like VB can turn lawyers into programmers (no offense
to lawyers) and yet we would really scoff at the notion
that that VB is a good thing for large, maintainable
projects.

[note to reader, you may skip to the last paragraph now
 and avoid the boring debate...]

Autogenerated headers are like sharp knives.  They can be
use and have their place in some areas.  But they can cause
a lot of damage if used in correctly.  proto.h has caused
a lot of damage in Samba IMO.  It's has led us to the
libbigballofmud.so in the Makefile.  In fact, I would argue,
like James, that it has promoted code duplication and not
code reuse.

The turnover of the developer base on in open source means
that I value maintainable code above convenient or clever
code.  proto.h is convenient and clever, but not maintainable.

A good example of code that is reused all the time is
dlinklist.h.  not one even thinks of using any other
list implementation in Samba.  But a example of code
that everyone always searches for is the name resolution
routines.

And if autogenerated headers are so great, why are tdb.h
and ldb.h checked into the source tree?

Your points about static functions just don't hold any
convincing truth for me.  In fact, autogenerating headers
makes such functions more likely to be placed in the header
as the programmers has to consciously think about what
is placed in the public and private headers.

Here's another example.  Just because a function can
be used from a library even though its not declared in
the header does not mean that you should use it.  There
must be some reason why the author decided not to place
it there.  For example, (ironic that I'm using the MIT
krb5 libs here since I don't hold them up as a model
of great code), krb5_rc_close() is not exported in
krb5.h.  But if I grep the src/lib/krb5/ it's in there.
The function cannot be declared static because it is
used in other files in src/lib/krb5/ but it is certainly
not public.  It's intended to be be called internally when
an application closes the auth context.

You might argue that an tool to autogenerate the headers
could be smart enough to know what to do.  My point is that
once you reach that point, you have to embed so much
information in the tool or source code that you should just
be writing the header yourself.

So in summary, your points are not technical,  only philosphical.
Which is why until I have a replacement system to propose,
it is fruitless to try to get censuses on the philosophical point
of generating proto.h.  Consensus will only be possible when
reviewing specific patches.






cheers, jerry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGZqPTIR7qMdg1EfYRAndyAKDAh/AETmWs7Hj0juvLIo2k1SRUZQCgg9lJ
jIVCJo0PCUNpjKW4Tklm4Sg=
=Mxfi
-----END PGP SIGNATURE-----