getting rid of mkproto.sh from Samba3

[James Peach]

On Jun 3, 2007, at 7:51 PM, tridge at samba.org wrote:

> James,
>
>>>> mkproto.sh promotes lazing programming, leads to bad interfaces
>>>> and to monolithic code.
>>
>> This is the basic reason why I don't like mkproto.sh. I'd also add  
>> that
>> 	- it makes it impossible to do incremental builds
>> 	- it makes it harder to find existing interfaces, raising the
>> barrier to contributions
>> 	- it makes it harder to document existing interfaces
>> 	- leads to false sharing, forcing trivial tools to link most of lib/
>
> This is not a result of mkproto. In Samba4 we do automatic prototype
> generation for many of our subsystems but not for all, yet it doesn't
> suffer from any of the above problems:
>
> - we do incremental builds, as each subsystem gets its own
>    proto.h. So for example, the libcli/raw library gets
>    libcli/raw/raw_proto.h. Only subsystems that need that library
>    include that header
>
> - it is not hard to find existing interfaces, as we separate the
>   headers for each interface. The generated headers are short, and
>   are located in the same directory as the library code that are for
>
> - I think it makes it easier to document interfaces as the interfaces
>   to the library are conveniently located next to the code
>
> - it doesn't lead to false sharing, as we separate the headers
>
> - the samba4 code is not monolithic
>
> - the samba4 code doesn't have bad interfaces.
>
> The problems you are seeing are due to my original design of mkproto
> which do it all as one big proto.h. Jelmer re-designed our mkproto to
> split up the generated headers, and that got rid of all of the
> problems you mentioned. Jelmer also did a much faster and cleaner
> mkproto in perl.
>
> We control which subsystems get automatic prototype generation using
> options like this:
>
> [SUBSYSTEM::LIBCLI_RAW]
>  PRIVATE_PROTO_HEADER = raw/raw_proto.h
>  PRIVATE_DEPENDENCIES = LIBCLI_COMPOSITE
>  PUBLIC_DEPENDENCIES = samba-socket LIBPACKET gensec LIBCRYPTO
>  LDFLAGS = $(SUBSYSTEM_LIBCLI_SMB_COMPOSITE_OUTPUT)
>  OBJ_FILES = raw/rawfile.o \ (etc etc)
>
> If you have a read through the generated prototypes, I think you'll
> find them clean, and easy to read.
>
> So you can use prototype generation without the problems you
> mention. It just takes a bit more work upfront to get it right.

In general my view is that code written by humans should also have a  
declaration written by humans. I've never found adding prototypes to  
be a burden, so I have difficulty understanding the point of view that  
maintaining header files is such an imposition.

Yes, the autogenerated headers in Samba4 are done much better than in  
Samba3, but the cost is additional complexity in the build system. My  
view is that the gain is trivial.

And you still can't read the headers without getting past configure  
(ie. having a working toolchain installed).

--
James Peach | jpeach at samba.org