"non standalone app bundle" builds on Mac

[René J.V. Bertin]

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.