getting rid of mkproto.sh from Samba3

[tridge at samba.org]

Jerry,

 > Autogenerated headers are like sharp knives.  They can be
 > use and have their place in some areas.

err, I think not generating as much as you can is like running with a
sharp knife (or the proverbial scissors).  The examples I gave are not
just philosphical, I gave real examples of where it has saved our
bacon. 

Can you point to any large C project which doesn't automate this stuff
and doesn't have the sort of errors I mentioned? 

 > 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.

yes, we have a libbigballofmud, and that's bad, but I hardly see how
you can pin the blame on auto-generating prototypes. As we've
demonstrated in Samba4, you can generate and still have nicely
separated headers and separated libraries, so blaming it on
auto-generating headers makes no sense.

The way Samba3 does it now is bad, sure, but it makes no more sense to
blame the idea of generating headers than to blame C.

 > 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.

which is why we've put so much effort into making Samba4 very clean
and have really good, maintainable interfaces.

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

because ldb and tdb are both incorporated directly (as source trees)
into other projects, and I don't want to dictate my coding approach on
those other projects. Those projects may not even be able to run perl,
or may not be unix based.

 > 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.

How? The generator doesn't look at static functions, and findstatic.pl
ensures you make all functions that can be static be static.

 > 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.

oh come on! Jelmer has already done it (look for is_public in
mkproto.pl), and do you seriously compare the half dozen lines of perl
written once in mkproto.pl versus every programmer having to get this
right for every function for the rest of the life of the project? Even
worse, when they don't get it right, no tool to tell them they have
screwed up?

 > So in summary, your points are not technical,  only philosphical.

nope. If we do it manually we will screw up, just like every other C
project has screwed it up. Maybe there is a perfect team of
programmers somewhere in the world, but we are not it. It's not
philosphy to realise that we are fallible.

Cheers, Tridge