<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 8 November 2016 at 13:09, René J.V. Bertin <span dir="ltr"><<a href="mailto:rjvbertin@gmail.com" target="_blank">rjvbertin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tuesday November 08 2016 12:17:23 Jaroslaw Staniek wrote:<br>
<br>
><br>
> I hope special cases in a cmake buildsystem would not be a problem. I've<br>
> worked with cmake-based build systems that support Makefiles generator<br>
> (JOM/NMake) and VS generators in the same cmake scripts. The later is a<br>
> multi-generator so it adds so much extra work since it's different than the<br>
> Makefiles gen. For now I have not checked if the current xCode generator is<br>
> as complex in use as the VS in this regard. Thoughts?<br>
<br>
</span>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.<br>
<span class=""><br>
> or large apps were packaged using scripts. I'd appreciate some info on how<br>
> do you see the current situation (of xCode cmake generator?) if we don't<br>
> want to require manual mouse clicks in xCode to prepare builds.<br>
<br>
</span>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.<br>
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.<br>
<span class=""><br>
><br>
<br>
> ><br>
><br>
> Nope, really, clang shall build them ​just fine and they should work; only<br>
> plugin paths are most probably something to test if we want to use non-Unix<br>
> approach to paths.<br>
<br>
</span>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).<br>
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.<br>
<span class=""><br>
> ​As programming frameworks, so programmers can pick up them as they pick up<br>
> parts of KF5 or some other extra Qt modules for they project. In a<br>
<br>
</span>I repeat, "framework" is a term that's already taken in the Mac universe :)<br></blockquote><div><br><div style="font-family:monospace,monospace;font-size:small;display:inline" class="gmail_default">​I know that so let's use 'Mac Frameworks' term for that :)<br>​</div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
KDE software mostly uses the form<br>
<br>
#include <Foo><br>
<br>
whereas on Mac you'd include the main header of a Foo.framework with (presuming it's not ObjC)<br>
<br>
#include <Foo/Foo><br></blockquote><div><br><div style="font-family:monospace,monospace;font-size:small;display:inline" class="gmail_default">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().<br><br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
this tells the compiler to search for {/System,}/Library/Frameworks/<wbr>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).<br>
<br>
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...<br>
<span class="HOEnZb"><font color="#888888"><br>
R<br>
</font></span></blockquote></div><br><div style="font-family:monospace,monospace;font-size:small" class="gmail_default"><br>​I'd like to see the headers portable across platforms...<br></div><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">regards, Jaroslaw Staniek<br><br>KDE:<br>: A world-wide network of software engineers, artists, writers, translators<br>: and facilitators committed to Free Software development - <a href="http://kde.org" target="_blank">http://kde.org</a><br>Calligra Suite:<br>: A graphic art and office suite - <a href="http://calligra.org" target="_blank">http://calligra.org</a><br>Kexi:<br>: A visual database apps builder - <a href="http://calligra.org/kexi" target="_blank">http://calligra.org/kexi</a><br>Qt Certified Specialist:<br>: <a href="http://www.linkedin.com/in/jstaniek" target="_blank">http://www.linkedin.com/in/jstaniek</a></div>
</div></div>