On Wed, 2006-12-06 at 12:49 +1100, David Chatterton wrote:
> ...
> A classic problem with cpp is that it is possible for someone else to
> introduce a header that breaks your build.
Heh, its a poor tradesman who blames his tools. :)
> By introducing a header
> called list.h, a very common name, we have exposed products whose build
> may not have strictly doing the right thing (adding /usr/include/xfs to
> their include path) to pulling in this file rather than the one they
> intended.
Well, clearly they're doing the wrong thing. We've now introduced
a half-baked scheme where one random header is inconsistent with
the rest, because of some other broken application. That's dopey.
The convention there now is such that its easy to tell what include/
files have kernel counterparts (the xfs_* prefixed ones), and the
rest are generically named (list.h, cache.h, parent.h, paths.h,
linux.h, etc). This change now makes list.h sit in no-mans-land...
please revert it back, since the app is fixed anyway (you are also,
of course, ignoring the flip side of your own argument, which is that
other equally broken apps could be using <xfs/list.h>, which moved
and hence broke their builds). You can't win by pandering to broken
3rd party applications... best you can do is keep the XFS stuff sane
and internally consistent.
> > Oh, noone is updating oss.sgi.com/projects/xfs/{news,index}.html
> > with recent changes either - seems like progress has come to a
> > halt to those of us no longer in the secret cabal, anyway ;) ...
> > just FYI.
> >
>
> Its now on my list of things to do.
>
Great - thanks!
cheers.
--
Nathan
|