It would be nice, however, if I can simply have everything in the Applications directory with the rest of the apps and only enter “darktable” to fire it up. Any suggestions?
Furthermore: 2.5.0 ?? I was only looking for 2.4.0. Hopefully this bleedin’ edge version is safe to use…
Congratulations! I started down that path, but figured I would be better served spending my time working with the prerelease - assuming the official .dmg gets published soon…
It was a tough slog, David. Yet it was also an interesting and gratifying learning experience. Unfortunately, I’m still not out of the woods; my lua scripts aren’t showing up. I think that I might have to do a symlink from the existing location at ~.config/darktable (Whoa! Geek-speak and now I even know what it means!)
Has anybody sent out the hounds to track down the errant darktable Mac expert? Even though (in my case) he’s become redundant, it might not be a bad idea to ensure that he’s not been abducted by Aliens and is otherwise okay. And, of course, to politely ask him to get the freakin’ disk image published(!!) for everybody else’s sake.
I think you are misunderstanding how it all works.
No one of us (that i know of) is working on dt full-time, or actually being paid for working on dt. All of it is being done by volunteers, so we can’t chain them up in a basement and make them do their thing.
When they have time, they do stuff. DMG is no different.
Sorry. Guess I am frustrated. However, I stand by my comment re priorities. Someone, not in the basement hopefully, had to compile the .exe release, yes?
If there were more succinct instructions on compiling this would not be a problem in the first place.
Finally, if you need a few $$$ to ensure prompt release of Mac versions, that is a direction you may choose to follow. I paid $$$ for CGI raw converters like On1, when darktable is so much better.
I don’t think a few dollars would make a difference. Unfortunately, Apple hardware is expensive. You need macOS to build for macOS and you cannot easily (or legally) virtualize it.
Apart from the hardware, you could use a normal pc and go hackintosh, you also need a code signing certificate to be able to release a meaningfull dmg (afaik). And those, aren’t free aswell.
hackintosh is, afaik, in a legal grey area. Also, I’ve had mixed results with it. I have a little pet project of mine that I used to build for OSX. At some point, my hackintosh VM broke and I stopped compiling for OSX. Blame Apple, not the devs, for the fact that compiling for OSX is expensive (hardware, frequent OS upgrades, planned obsolescence, etc).
Oh, I wasn’t making a dmg - I was just compiling it for the specific hardware and releasing a zip file with the compiled binary and other assorted files.
After what was almost an excruciating exercise (not really; I exaggerate. It was actually “fun”) I’d be quite happy to make my sweat and blood-stained dmg available to those who are on the other extreme of “faint of heart”.
Hi all! What would you think about an automated OSX package generator that gives you a read-to-install DMG or ZIP file each time something is committed to the master branch on GitHub?
I have set-up such an automated packaging system using Travis CI for my PhotoFlow editor, and seems to work like a charm! The only difference is that I am using Homebrew instead of MacPorts in order to install the dependencies…
There are several advantages to this approach:
a clean, documented and transparent build environment (everything is available on GitHub, and users can inspect how the whole OSX bundle is generated, if they are interested)
builds are fully reproducible because they run on Travis virtual machines
you don’t actually need OSX in order to maintain the build environment, because all is based on GitHub and Travis. A web browser is enough.
you don’t have to rely on specific users and their availability to get the packages, as the whole process is automated
If there is some interest in this direction, I’ll be glad to help the Darktable folks to set-up the scripts and make some initial tests.
travis-ci OSX build jobs [for dt, rs] are disabled, because they are just hideously slow.
i don’t plan on re-enabling anytime soon.
having an automated packages does not solve the need for the actual maintainer,
who actually has that system, and can deal with osx-specific issues.
we only produce the source code, all the binaries are not produced by the project.
having the main ci spitting out these dmg’s, i think, would go against that.
Well, you could argue that having automated OSX (or any platform for that matter) builds would decrease the barrier for a maintainer (or contributor at least) to step in.
Of course this does not remove the need of an OSX maintainer who has an OSX system where he can compile and test things if problems arise. The idea would be more to remove the tedious burden of regular packaging from the maintainer, so he/she can have more time for testing and fixing broken stuff.
Do you have any tips for us others to follow, in addition to the build.txt instructions? I tried to build a DMG myself a few months back but I did not succeed despite several retries. I wouldn’t have a problem to try again if only I knew what I did wrong
Ahem, cough, cough… “hideously slow” eh? Hmm. And what degree of slowness is it that which we’re currently experiencing?
Surely there is a reason why we don’t have the disk image yet. Whether it’s excessive workload for the volunteer packager, disinterest, or if it’s a technical issue, I think that it’s prudent to not immediately and vehemently discount suggestions for improvement. Can we not begin with some very detailed instructions so that the source files can be compiled into a dmg? Conceivably, this could result in a plethora of Mac compilers who could do the grunt work if this is the defining issue. Yeah, yeah, it could also result in a complete mess since individual’s systems are, for the most part, unique and that problems will almost inevitably arise. However, I think that it’s reasonable to assume that after initial hand-holding and corrections, the “apprentices” can take the workload off of our current rather “quiet” volunteer.
If relinquishing some of the magic isn’t palatable to the Coding Overlords, fine. Just please help us to help ourselves so that we won’t have to bother or offend you. We’ll then use our local hacked compilations for our own use.
