"non standalone app bundle" builds on Mac

[René J.V. Bertin]

On Tuesday November 08 2016 12:17:23 Jaroslaw Staniek wrote:

> 
> I hope special cases in a cmake buildsystem would not be a problem. I've
> worked with cmake-based build systems that support Makefiles generator
> (JOM/NMake) and VS generators in the same cmake scripts. The later is a
> multi-generator so it adds so much extra work since it's different than the
> Makefiles gen. For now I have not checked if the current xCode generator is
> as complex in use as the VS in this regard. Thoughts?

I have no idea how it compares to the VS generator. It's been improved recently and I've checked a few projects, but haven't gone much beyond that. I think manual tuning of the project would be required, esp. if you want to do things that you cannot really achieve directly with CMake.

> or large apps were packaged using scripts. I'd appreciate some info on how
> do you see the current situation (of xCode cmake generator?) if we don't
> want to require manual mouse clicks in xCode to prepare builds.

See above, Xcode projects are like MSVC projects in that you maintain them manually ("what you see is all you get" ...). I actually have little experience with the current Xcode versions as I've drifted away from development requiring its use since I'm no longer using OS X 10.6 . However, as with MSVC there is usually little more you have to do than simply adding new files to targets.
Once you have a project though you can build it from the commandline, there's an xcodebuild utility that knows quite a few tricks for that.

> 

> >
> 
> Nope, really, clang shall build them ​just fine and they should work; only
> plugin paths are most probably something to test if we want to use non-Unix
> approach to paths.

Yes, QStandardPaths is a problem. Qt folks may disagree, but I have the impression it wasn't designed with much regard for the potential special needs of complex software like KDE's on platforms that don't use XDG-compliant locations (that's what we're really talking about here).
It's also a pity that there is nothing (in the ECM for instance) that determines the install locations from the QStandardPath locations, that should remove the need for a lot of hacking and additional testing.

> ​As programming frameworks, so programmers can pick up them as they pick up
> parts of KF5 or some other extra Qt modules for they project. In a

I repeat, "framework" is a term that's already taken in the Mac universe :)
One habit that I see which stands in the way of building KF5 libraries (including those with framework status) as a Mac framework is the way headers are included.
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>

this tells the compiler to search for {/System,}/Library/Frameworks/Foo.frameworks/Headers/Foo in addition to /usr{/local,}/include/Foo/Foo plus any in other paths you may have specified. You'd have to add the individual .framework/Headers directories to include them if you don't use the "rich" specification. Not the easiest thing to do in Xcode (the interface is a bit clunky).

A bit of a missed chance: most all of KF5's framework headerfiles install in a way that would make them accessible using the Foo/Foo notation...

R