On Sat, 27 May 2000, Tom Lane wrote:
> Lamar Owen <lamar.owen@wgcr.org> writes:
> > 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
Yes, this is a problem. And, yes, it needs to be taken care of in a designed,
methodical manner -- the spi.h header should only need a few things (I, like
you, have not done any SPI development yet to see what really _is_ needed....).
> Basically I feel that this is a problem that requires some actual
> thought and design judgment.
Yes, most certainly. Can someone who has actual SPI experience look at this?
> I'm just concerned about the long-term consequences of taking the
> easy way out.
I'll have to admit to taking the easy way out a little in my RPM solution --
but, it's only there so that an advertised development interface can be
actually used. Once a thorough look is taken at the whole header mess for SPI,
I still won't have to change anything, which is good both for me and for RPM
users, as I really don't keep track of every header file dependency change --
thus, RPM releases won't happen (again, as 7.0-1 was in error in this regard)
with broken header deps, requiring a bugfix package.
If no one else is forthcoming with a solution to this problem, I'll take a look
at it (possibly during the development cycle for 7.1 after the 7.0.x series has
stabilized, when the RPM cycle is at idle).
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
