"non standalone app bundle" builds on Mac

Tue Nov 8 11:17:23 UTC 2016

On 8 November 2016 at 10:36, René J.V. Bertin <rjvbertin at gmail.com> wrote:

> On Monday November 07 2016 18:14:35 Jaroslaw Staniek wrote:
>
> Hi Jarek,
>
> >Thanks for the interest!
> >In addition Kexi-specific things can be discussed at a kexi-devel list :)
> >There were enthusiastic people interested in contributing Mac builds of
> >Kexi but they disappeared so this task is open for maintainer. Bundling or
> >discovering server installation(s) (pgsql, mysql), bundling dependencies
> --
> >these are all task for adoption.
> >
> >
> >In my opinion Kexi fits to a standalone path, just like on Windows, to
> >become as native as possible, well, but not more native than that. For
>
> Right, then there was Kexi too :) It that has been split off the rest of
> Calligra it's likely to be much smaller. It's also much more unique in its
> approach - if I'd discovered a use for it myself I would have started
> working on a port a while ago (port in MacPorts speak; ideally that's just
> a build script, Portfiles, that tells CMake where to install and get
> dependencies from).
>
> I've never been against making more-or-less standalone app bundles for
> Mac, though I do feel that for an application family like KDE it would make
> sense to put as much of the shared resources as possible into something
> that's installable independently, e.g. a "meta framework" (a bundled
> collection of libraries, for which Apple used the term before KDE, the
> confusion is not on me ;)). It'd be an interesting exercise for a more
> seasoned Mac developer than I am in this aspect, but it ought to be
> possible to bundle all KF5 frameworks that way into an object that can be
> installed into /Library/Frameworks. That'd be a perfectly native approach
> too, with a priori significant maintenance advantages, but out of scope in
> this conversation.
>
> Either way, I've always felt that making applications really work well on
> OS X was a higher priority than the kind of ribbon you wrap it up with. If
> you want to know what's feasible to preserve in a feature set used on a
> different platform you start by working in conditions that are as close as
> possible to those on that platform. In this case, installing shared
> resources into a prefix much like pkgsrc and gentoo prefix do, as well as
> MacPorts, Fink and HomeBrew on Mac (which some consider "nice for linux
> refugees" which isn't untrue but completely beside the point).
>
> Anyway, it's an approach I've been following for about a year now, and
> it's allowed me to contribute back quite a few improvements to KDE. The
> thing is that even if I were personally motivated to move on to tweaking
> the build system to make nicely wrapped-up autonomous app bundles where
> each app ships with yet another copy of all those Qt and KF5 libraries, I'd
> still have enough hay on my fork maintaining those MacPorts packages.
> Adding to that collection is a lesser and to me more satisfying investment
> than changing course.
>
> In short, I'll try to look into Kexi soonish, but I think I shouldn't be
> be getting involved while it's still undergoing review (remember, hays and
> forks).
>
> FWIW, as I wrote to Boudewijn, I think it'd make sense to investigate
> dumping cmake as the build system for "really native Mac" builds. Figure
> out once how to invoke cmake so that a project is built and installs as
> much as possible the way it should end up inside an autonomous app bundle
> (i.e. using Contents/MacOS and Contents/Resources, those are the only
> imperative folders I know of). Then use the CMake Xcode generator to create
> an Xcode project. Use the Xcode project from there on for Mac "bundled
> build"s, and cmake for everything else.
>

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?

In some pre-CMake times (qmake times) I've worked with bundling Mac
binaries and once we have tools that work in batch mode we were OK. Medium
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.

>example KFileWidget being very Plasma-oriented is close to be removed on
> >Windows and could be also removed on Mac, in favour of a Url field + [..]
> >button (KUrlRequester).
>
> I have mixed feelings towards the KDE file widget. It's not uncommon that
> applications provide a non-stock file widget (in fact that's almost exactly
> what Qt's file dialog is) and KDE's has a number of very useful features
> that are missing in the Mac file dialog (like tree view). Put it into
> directory-selection mode however and it's really feels out of place (I much
> prefer the Mac approach here).
>

Yes, first motivation is, not to be worse than competition.
Mostly UX-wise; under the mask we're rather safe.

> >I've also not seen Mac builds of Kexi-derived projects: KDb, KReport,
> >KProperty. These are general-purpose frameworks and Kexi dependencies. If
> >they are missing for Mac it would be nice to see them available too as
>
> If? Is there reason to suspect that building them on Mac is going to
> require patching?
>

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.
Would be also nice to have nightly builds one day. I'd like to add the same
for Windows.
For now having someone who prepares binaries before release and runs tests
is sufficient minimum.

>
> >frameworks for general use.
>
> Framework in which sense? :)
>

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
realistically easy way within their preferred IDE.
That's a side topic from Kexi, if you have some interest. For Kexi these 3
frameworks would be rather bundled.

Thanks for the good work.

PS: Home page of any Mac-related notes is https://community.kde.org/
Kexi/Mac.
Feel free to use that space.

-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-mac/attachments/20161108/c8c56fa3/attachment.html>