Hi Kevin, On 16 Mar 2014, at 11:07 , Kevin Krammer <kram...@kde.org> wrote: > I didn't mean to imply or suggest that the design was flawed or anything like > that.
ok. > Ian wrote something about build dependencies and building which kind of > didn't go > well with my mental model of Mac users. I see. > I hardly know any Mac user who would build software so they would not be > affected by build dependencies. Neither do I, personally I mean. But there are many on MacPorts! >> Also one has to point out that MacPorts DELIBERATELY does not distribute >> port binaries which use code with a licence which isn’t allowing binary >> distribution. This is good and considerate design in my eyes. > > Right. Doesn't apply to KDE software but certainly the right thing to do in > the wider scope. Hmm, it does apply also to KDE software, since it may use a library which isn’t permitting binary-only distribution. >> Yes, it’s hugely difficult to get KDE applications to build without any X11 >> deps. > > Any idea why? Most applications should not have any X11 dependency, those > available on Windows definitely don’t. Well, good question! Unfortunately I am not knowledgeable enough to answer this easily now. I am busy with all of this since about 3 years and I haven’t dived into the depths of X11 on MacOSX (XQuartz), Cocoa and the vast dependency tree of MacPorts’ ports. I just know that I did my best trying to remove all dependencies to X11 for KMyMoney back then, but had a really hard time, because some tools in these many dependencies might need some little GTK application or so… It’s a major undertaking to unwind all these dependencies and figure out where and why exactly a certain X11 lib is needed. But there is a dependency tree view possible for any application. By using that one can locate which lib needs what. An example of that can be seen in my post from March 12th @ 21:31. >> Well, their philosophy is: OFFER EVERYTHING for the usual OSX user, as >> up-to-date as possible, so that no-one misses anything later. Back then - >> when there were no port binaries distributed - this would mean hours and >> hours and hours of building X11 and Qt and KDE… A pain to get started with >> any Qt[34] application, I tell you! > > "usual OSX user" and "hours of building" just don't match in my experience. > "hours of building" and "usual user" doesn't match on any platform I know of. You are absolutely right. MacPorts doesn’t target those who can only manage to go to the AppStore and click on icons. It’s merely for geeks, I guess. But it does a pretty good job already, once you’ve understood the needed workflows. Their website explains everything sufficiently to get started - if you’re not afraid of the command line. > That assumption seemed to have been wrong with Macports actually having pre- > built software and having building as a separate option. As I said, the pre-built ports came up only a year ago or so, but MacPorts is far older. I think it just shows the evolution of the project. It was time to switch from solely port building from scratch to binary distribution wherever possible. And they made it happen. :) > My updated understanding is now that it is very much like a Linux package > repository, where users can just install and run the software without having > to care about building and dependencies. Correct, let me cite their website’s 1st sentence: <cite> The MacPorts Project is an open-source community initiative to design an easy-to-use system for compiling, installing, and upgrading either command-line, X11 or Aqua based open-source software on the OS X operating system. </cite> > Basically a FOSS app store. Yep, driven by a perhaps a dozen very active MacPorts infrastructure developers and a few hundred port maintainers. Have a look at their port repository which contains about 18000 ports! You’d find almost everything you wish for if you have a Linux background. When I switched to MacOSX I missed so many tools (Qt, KDE, MySQL, mercurial, git, cctools, boost, autojump, doxygen, xsltproc, mc, recode), but MacPorts gave them back to me almost pain-free! Your system gets updated whenever a port maintainer decides to commit an updated portfile. So, one does not need to worry about how to deinstall old software versions from the depths of your iMac’s file system, but instead can sit back and rely on MacPorts’ logic to keep everything up-to-date, which generally works fine and with very little interactive user action. The plus is that you usually have stable and up-to-date software installed. For KMyMoney 4.6 - for instance - there are two ports kmymoney4 and kmymoney4-devel. The first is always the latest release version, whereas the devel port distributes a version which I try to keep as close as possible to its git's HEAD version, i.e. is always bleeding edge. The user decides what she/he wants. And thanks to the buildbots the MacPorts infrastructure can make sure that a a new version of any committed portfile will always be build immediately and thus explicitly verify for all four supported versions of MacOSX that the port binaries can be build just fine. THAT is very close to CI, isn’t it?! I mean, it is as good as it can get with just a few build servers, two handful of core devs and dozens or up to a few hundreds of port contributors. Greets, Marko >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
