Re: Announcing the availability of first Qt 3.3 packages
> > For instance, you could put #warning pragmas at the top of each
> > obsolete header so that the compiler spits out a warning when one is
> > used.
>
> I personally fail to see how this would be superior rather than
> complementary.
1. it achieves the original aim of alerting developers to their use
of deprecated headers;
2. it still alerts developers who use deprecated headers even if you need
to have compat-headers installed for some other reason (e.g., some
user on your system is building 3rd party software that uses them) -
the compat-headers solution fails completely in this scenario;
3. the errors themselves are clearer (a single "#warning: qlist.h is
deprecated" is clearer than "error: cannot find header qlist.h" followed
by a large flood of undefined types/etc);
4. it doesn't cause fatal breakages for users who just want to build
some 3rd-party app and who aren't authoring Qt apps themselves;
5. it doesn't require root access (to install compat-headers) if you
want to ignore the issue for the time being;
6. it doesn't give the impression that stuff that builds on every other
system will fail to build on debian.
So it achieves the same aim as the compat-headers split as seen in point
1, and in points 2, 3, 4, 5 and 6 it is a superior solution. I don't see
any advantages that the compat-headers split has over #warnings. You
could argue that by causing build failures it forces the issue to be
dealt with *NOW*, but aside from being rude (IMHO), it could go one of
two ways. Either the developer fixes their app, or the developer
installs compat-headers for the time being (more important bugs to fix),
at which point the errors go away and the developer forgets about it
altogether.
Anyway. This was all hashed out in some detail many months ago. I'm
basically rehashing it just to answer your question. :)
b.
Reply to: