Lamar Owen <lamar.owen@wgcr.org> writes:
> :-) I expect no less (than to work harder, of course....). Why not do
> something like that, other than the 'out-of-sight, out-of-mind'
> problem? Or, to put it far more bluntly, the SPI installation is very
> broken if the SPI developer has to go around manually installing
> header files that make install should have automatically taken care
> of.
Agreed, but I'm worried about the 'out-of-sight, out-of-mind' aspect.
>> The more serious problem is "what else might an SPI module need besides
>> spi.h".
> What else indeed. Isn't spi.h the exported SPI itself? We seem to
> have a very poorly defined line between exported and private
> interfaces
Ah-hah, I think you and I are on exactly the same wavelength there.
My whole problem with the spi.h-imports-88-headers business is that it
exposes in gory detail the fact that *we have absolutely no idea* what
we consider an exported backend interface and what we don't. I don't
like the idea of an automatic tool that exports whatever it thinks might
be needed, because if we let ourselves go down that path we will very
soon find ourselves trying to preserve backwards compatibility with
something that should never have been exported at all.
Basically I feel that this is a problem that requires some actual
thought and design judgment. I don't want to see us substituting
a one-liner script hack for design judgment. OTOH, I don't really
want to do the legwork myself (lame excuse: never having written
an SPI module myself, I have little idea what they need to see).
I'm just concerned about the long-term consequences of taking the
easy way out.
regards, tom lane