On 8 November 2016 at 13:09, René J.V. Bertin <rjvber...@gmail.com> wrote:
> 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 :)
>
I know that so let's use 'Mac Frameworks' term for that :)
> 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>
>
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
linking against respective library that the headers belong too. Then
linking errors (or worse, runtime errors) happen. With <Foo> you're just
sure that if you used the cmake tools that find libraries (packages) for
you, you get much nicer preprocessor error if you missed certain entry in
target_link_libraries().
> 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
>
I'd like to see the headers portable across platforms...
--
regards, Jaroslaw Staniek
KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
