Hi,
Is there complete information for compiling the latest Windows 10 dev versions of DT along with the ability to maintain the latest versions as the become available?
Can’t help with the compilation. Place the ‘stable’ and the ‘dev’ build in different directories, and use command-line options to keep config, cache and database separate. You may want to disable writing XMP files in the ‘dev’ build, otherwise it will introduce changes to your XMPs that the ‘stable’ build won’t be able to handle.
--configdir <user config directory>--cachedir <user cache directory>--library <library file>
You are aware of the weekly builds by @wpferguson , right? E.g. darktable windows insider program 10/8.
This is the “official” instructions for compiling on Windows.
I didn’t know about the XMP issue between dev and stable. That said I would prefer to stay with stable versions only. Are the weekly builds by @wpferguson considered to be stable whereby I could write XMP without issue?
The dev version is, in general, also stable. I’ve been using daily builds for years.
I don’t know if Bill simply builds e.g. Sunday night, or if he reviews what changes are included.
Up until now, I have been using his weekly builds. It would interesting to know what @wpferguson is thinking when he creates these builds. What got me thinking about compiling was a Aurelien Pierre video on optimizing DT by compiling it. Maybe not necessary after all.
DT website is generating nightly builds now…
I used to build it all the time but now I often get lazy and use these…
They weekly builds from Bill are from current master. There should be considered a development build.
Like Kofa, I run current master as my daily driver. I know the risks and I’m ok with them. I also build PR versions to test new features.
The nightlies use an always up to date msys2 build environment. Bill updates his environment less frequently AFAIK. That’s it.
Likely similar unless Bill has a custom build setup… Likely he builds generic versions to be sure that they work widely across various hardware… I assume the ones generated on the DT git would also be generic… If your cpu has properties that can be leveraged your own build might be able to access that but in the end I am not sure how much you get in terms of speed or stability by doing your own over using one of the pre build ones…
1 Like
So, writing to XMP should not be feared with either of these two builds?
I think the issue is that you often can’t go back so if you open your images from a common source and use the dev version and then decide you want to open it back up in the current release it might not open as a new module might be used or other change… so its easy enough to use it for a bit not writing … rely on the database and if you are then happy you can turn xmp writing on as you have essentially moved on to the updated software… or just keep a copy of images that you want to work on separate but that can be hard to keep track of… at least that is my 2 cents on what the issue would be
1 Like
Where can I see what changes have been made since the previous build when I go here?
He’s thinking “how much longer is this going to take” 
. Builds on windows are slow.
The weekly builds are just a snapshot of where dev is. I usually wait until later in the day, where I am (GMT-5), to build figuring that Pascal will probably be asleep and thus not merging anything.
I agree with @kofa about dev generally being stable. I compile daily and use it for my daily driver.
As far as knowing what changes are included in the weekly build, I’m generally aware, but there is also a link included that will give all the changes since the last weekly build. I don’t usually say anything about the weekly builds until we are a feature freeze, which is when we really need testing to make sure we drive out the bugs.
@kmilos described my build setup accurately. Since my build setup is used to build the distribution packages I try not to ride the bleeding edge. Also, some packages (pango) are kept frozen at the last known working version (correct rendering of cyrillic characters). I usually update my setup after release so that it gets plenty of testing before the next release.
2 Likes
Poke around Git… 
Another summary of activity is here…
1 Like
depends on the changes made for existing modules or database updates.
There was an database update already done, so you need to use different data.db and library.db for release and dev. Some modules got improvements - if you use them, that will have impacts on the xmps.
You need to have a look at Comparing release-4.4.2...master · darktable-org/darktable · GitHub to check.
Even usually new modules or module improvements are quite stable so working with the dev version (if you aren’t need it to pay your bills) is quite reliable. But keep a backup of your darktable config and also of your xmps …
1 Like
If you build dt for your own computer you can get a better optimisation : you can get a build tailored to your CPU, but chances are that such a build won’t run on older CPUs or CPUs from a different brand (thus is not suitable for a general release). It shouldn’t have any effect on openCL though, those kernels are already compiled for your local system.
So I’m not sure that home compiling for optimisation is really worth it, when you use openCL. For anything interactive, the slowest part is at the other side of the keyboard/mouse.
1 Like
Thank you all for the great advice. I will continue to use dev releases, but with a back up of my AppData file along with XMP’s
Is there a way to reverse the date list sort order?