Compiling darktable .dmg: A bump in the tracks

darktable for Mac does not seem to be a priority here. Movin’ on…

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.

4 Likes

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.

You chose the free model, not me.

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.

2 Likes

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).

1 Like

Do you need an apple dev subscription for the signing cert?

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.

Hi.

  1. 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.
  2. 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.
  3. 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 :slight_smile:

I volunteer to help with the chaining up in the basement.

2 Likes

Ahem, cough, cough… “hideously slow” eh? Hmm. And what degree of slowness is it that which we’re currently experiencing? :confounded:

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.

Instead of complaining and demanding the DMG, (which nobody owes you)
why don’t you spend this energy either updating macport for darktable,
or dunno, talk to homebrew about packaging dt? :slight_smile:

3 Likes

That’s incorrect, offensive and not at all helpful, Roman. I fully understand how this works and thus, no demands were ever made. Rather, just like a few others, I’ve tried to provide suggestions.

spend this energy either updating macport for darktable…

Absolutely! There’s no problem in spending more energy to get this resolved. It should be clear that I and others would be quite happy to do so. However, there’s no point in “demanding” that we go down this mysterious and unfamiliar path without a bit (a lot) of the guidance that we’ve been respectfully requesting.

3 Likes

DISCLAIMER: Anything I write along these lines should only be considered as the “Severely visually-impaired leading the blind (or likewise visually-impaired)”

What finally got me to the point of where I am was closely watching the Terminal and referring to the few lines above whichever Error message (frequently) appeared. They usually provide a fathomable clue as to what went wrong and how it should be corrected. Whenever this wasn’t (frequently) enough, “DuckDuckGo is your friend”.

As noted way above in this thread, I was eventually able to transmogrify the source files into something workable. However, my apparently-mangled .dmg wasn’t able to load an actual App. So far, DuckDuckGo hasn’t been helpful in this regard :thinking:

Thanks. I am not a complete ignorant, I have been a professional software programmer in the past, unfortunately not on OSX/Linux so this is still terra incognita for me. Last time I got stuck somewhere in the build process where the transcript was complaining about some library that did not build. I did some searching with Google but didn’t find a clue that was working for me. Maybe I’ll give it another try then. I’ll post here if I do.