On Tuesday November 08 2016 13:20:37 Jaroslaw Staniek wrote:
> > KDE software mostly uses the form
> >
> > #include <Foo>
> >
> > whereas on Mac you'd include the main header of a Foo.framework with
> > (presuming it's not ObjC)
> >
> > #include <Foo/Foo>
> >
>
> Maybe that can be seen as misfeature of Xcode and related tools because a
> point <Foo/Foo> is that the header is _silently_ found even if you're not
No, I don't think you can say that. Support for this (and frameworks bundles)
has even made it into gcc (on Linux too); I doubt that would have happened if
there were anything wrong with the principle.
I'm fairly certain that Qt also use the <Foo/Foo> notation in their code and
examples (#include <QtCore/WhatEver>).
I see your point about protection, but it's simple enough to avoid that. How
can you pick up the wrong Foo/Foo headers but pick the right corresponding
libFoo or Foo.framework, or vice versa? If that happens there's something wrong
with your install.
The KF5 framework headers all live under ${prefix}/include/KF5, meaning that
even with a <Foo/Foo> notation you still have to point the compiler to the
appropriate parent directory.
As a bonus you do not end up with endless compiler command lines on which you
can no longer find relevant information (or which might even lead to issues
when they become too long).
> you, you get much nicer preprocessor error if you missed certain entry in
> target_link_libraries().
I don't think the preprocessor cares what cmake did or didn't do :)
R.