Thanks. To go from a mere end user to building the product from source, is a bit of a jump, but I think I will take up the challenge. The process looks very well documented. Wish me luck.
All you need is time, patience and a beverage.
If you’re feeling altruistic, please share your experience and where the snafoos get you most. I think I’d like to try building it myself on Windows, but have been a bit intimidated by the setup.
I have posted here a zip file of the version with the sigmoid if you want to try it…no install just unzip it and run dt via the batch file so it runs locally and uses a local config file. I will dig up the post and add it as an edit…
@OK1 Here you go if you want to try the sigmoid. And later people here can help you get sorted to build it…me included.
This is a zip file . I have posted it recently but can’t find the post.
This is easy to use with no install just unzip where you like and run dt with the batch file. This runs in in the local folder where you unzip it and uses a local config file so nothing touches your DT install
If you want 3.5 xx I can’t quite recall I think it was about v 2157 without the sigmoid then by the same logic you can use this one… or your can run both of these just download them both…
God enabling, I’ll do my best to share this.
You’ve egged me on to do something I had never considered getting involved in - Thanks a million. Highly appreciated. Progress report below.
So true, so true.
Thanks - see how far I got with the build effort below.
This will be brief, cos I’m exhausted, its early morning and I lost all sleep, which I have to now catch up on.
- Full disclosure, I was once a deeply involved techie, for at least a decade, as an admin for UNIX and Oracle databases, but it was a quite a while back, and I have since moved on to other things. So that helped, it would have been more difficult if I did not have that under my belt. Simple things like how to edit and save a file in Linux, can be a bit of a hurdle if you have no starting off point as I have.
The stuff that Linux/UNix end users/admins take for granted like basic commands, pwd, ls, man, ps, vi, can be daunting, I can imagine to died in the wool Window folks, who have never seen a command line.
I think some of the instructions on the Windows install guide do not work, for example there is a reference to downloading the git repository using a git internet protocol, that did not work at all for me. Not at all. I think someone who knows what they are doing needs to health check that Windows build guide. I had to abort one of the make steps, cos it just went on doing nothing for well over 30 minutes on the computer on which I attempted the build. And this was after the process had reached 100% completion - not sure if it actually completed that step, since I aborted it manually. Unusual.
It eventually installed (with the aforementioned issue) on my 2nd attempt. I had to reference the instructions from the 3.4 release for building on Linux, and replace some of the Windows build instructions with those on the 3.4 release (or rather from the main dev release page on github.
The app that was built ran in windows with a release number of d1f02a42e. And it was really thrilling to see that happen, my lack of sleep paid off. At least I did not lose sleep for nothing. Feel priviledged to be one of the few on WIndows who has a peek into the next version(s) of Darktable. There may come a time when Adobe may have to buy all the darktable developers and give them some shares. The pace of improvement in the suser interface of darktable within the most recent 18 months or thereabouts is frightening, its coming on in leaps and bounds. It seemed pretty quick on the computer on which I built it, albeit that’s an i5 quad core Intel 4th gen with 4 logical cores, and my workhorse is a less poweful i5 dual core intel 4th gen with 4 logical cores., which may xplain the difference in my perception of “speed”. Sadly it seems to have corrupted another instance of darktable 3.4 which was installed on the computer, but not an issue, I can easily reinstall that - and I had no images so the database can be completely zapped. Guess it is something to do with an update to the database table schemas - apologies for getting into a bit of the techie details, based on my prior work experience.
So the old 3.4 version can no longer “see” the config info/database schema which it was expecting to find , and it simply shuts down every time you run it.
So this was one huge step for my kind. So glad to have achieved this, in such as a short time frame.
What challenges remain.
While I was able to install the most current dev version of darktable, the cutting and bleeding edge version still in development, my aim was to have been able to build a stable version like 3.4 (the dev version still ran reliably in the very short time I used it, but of course I could not test that every single feature and function worked as expected). SO I’d really like to learn how to achieve this. Git was invented long way after I left the IT job. So I will need some assistance to find my way around this.
Next I will need to learn how to build the windows code from a fork of darktable, such as the one with sigmoid code in it. I’d definitely love to be able to do that, and also help others out by making available such goodies, to others who are on Windows. That would make me very happy to be able to contribute in that way. I’d definitely like to be able to make available one or two builds of the cutting edge code each month, so Windows folks can get in on the action…, and not feel left behind the Linux/Mac folks.
I’d like to be able to link up with the developers, and share any build issues I’m having so I can understand the reasons why. There were a few reported missing things as the compile and build ran.
The process looks promising, and not as daunting, now I’ve got something that does run and does process images, and with the aforementioned gaps resolved, the future could be a lot of fun, not having to stand at the back of the queue, for these most exciting innovations.
If anyone who has a clue can point me in the right direction on the outstanding challenges above, that would help me and all those whom, I’d love to assist by making a Windows build of “interesting” developments, available, at least once a month.
Now time to catch up on that sleep --------snnoooooooozzzzzzzzzzzzzzzzeeeeeeeeeeeeeeeee
I’m glad you made some progress. But perhaps in the future before you state truths based on your experience maybe ask if other struggle with the instructions. They are better and less involved than they were a couple of years back and I had no trouble. I printed the document and went step by step and it works fine.
When you make statements like this other new users may take them at face value which is wrong.
I would agree that you need some lack of fear of a command line but really no more so be careful how you present things.
If you had installed msys2 correctly and made it to line 3 you had git so cloning the repo really should not have given you any trouble. These instructions are pretty clear to me. I use method A
You need to study this. What you should have done was install it in its own directory say \DT3.5 and then you use the command line switches in a short cut to point DT to an alternate location for the database or config files or many other run time options. Then it runs in parallel to your installed version.
Using these options you can also do things like create that portable version that I sent you. You just install to a different directory than default and then manually add a new folder called config. Then write a little run batch file that uses these command lines to run dt from any relative path and to use that config file (.\bin\darktable --configdir “.\config” )… and then you just zip that directory …so you use these commands to run parallel versions or to make a portable version that you can run from anywhere…
Can a mod please split this thread? @paperdigits perhaps? The last 15 comments or so are very much about a different issue.
The startup instructions to point to an alternate database directory or maybe keep this database in memory, as I discover is possible (which is ok for a test), to avoid any conflicts with existing installations, would be interesting pieces of info to add to the guide.
If you assumed I created an installer. Not so.
I did not create an installer, and then go on to install the build in Windows as standard., in which case it would have been advisable to install in a separate directory. But this does not apply. Explanations below.
It’s right there in the instructions :
“If you are in a hurry you can now run darktable by executing the darktable.exe found in the build/bin folder, install in /opt/darktable as described earlier, or create an install image”
I ran the executable from the /opt/darktable directory - exactly as instructed, so it was not possible that I had created any mixups with my prior 3.4 version, which was installed from the binary distribution as many users on Windows, would so do.
I do also hope you can accept that, any set of instructions, like the build for Windows which I followed, might make certain assumptions of the skill level of the end user. When you follow a Google map, it does not need to tell you to move one foot in front of the other, or give you instructions on how to drive your car, it makes certain assumptions, that you have those elementary issues sorted.
There is value, as I have done, to point out to anyone, who might have wanted to follow those instructions, that there is a level of knowledge assumed, and if the experience has not been gained prior, there would be a learning curve. Especially as you are most likely addressing Windows users, who may have never seen a command line before.
Simple things like - add these statements to a user startup file, would leave some users pondering - how do I achieve this? I cannot assume any skill levels of those who read my comments, so it is fair that I pointed out these caveats. Nothing scary, better to let them know, there is a learning curve for some.
With my experience, I still had to figure out a few things, simple things like what kind of editors does linux use, when a unix typical “vi” command to edit files did not work. I never used linux professionally, only unix, but it was a relatively easy transition to google this and realise that in linux its now “vim” not “vi”.
I was also once a technology educator, who wrote teaching guides and taught a fair bit, so it’s valid to assert, the instructions can always be improved to assure their success. I hope it can become more accepted, on techie centric sites, to also see things from the point of view of non techies. When I have the time, and the mysteries of this build process are fully resolved, I’d love to enhance those build instructions, and make this available, and hopefully anyone, at any skill level, as long as they can type and move a mouse, will have ALL of the instructions, however elementary these are, to follow a set of instructions, that are a superset of what I attempted to follow, and have even more of an opportunity to succeed at the build.
I am glad that not all the instructions succeeded, I wish they had. Once I figure out why, it will be easier for the next person who follows suit.
why don’t you simply start a new thread instead of polluting a sigmoid related thread with your learning experience building darktable on windows?
There is some great educational documentation…its called readme
Section 7 building DT
Yes definitely yes, I have succeeded in building an installer on Windows, for a darktable version 3.5.0 xxxx which comes from the most current version of darktable on github.
I was also able to build the executable that runs from a bin directory within the MSYS installation directories. But this time around I did not bother to run this version, as I wished to test the final product - which is the full windows installer.
I went ahead to run the installer, being careful to use a startup parameter to ensure that this new version derived/created its startup configuration from a new directory, to avoid any corruption of the configuration of an existing version 188.8.131.52.
Install went well and I have a “stable” i.e not crashing instance of version 3.5. As expected there are some differences and possible bugs, so regard this as an experiment. Lots of interesting features, which I will not go into here.
If one studies the document carefully, there are 4 different pathways to create this installable executable, using MSYS2, as defined in the following process.
And there are additional methods, which may be possible using a cross compile on Linux. The document points to the MSYS2 site, and this has some preliminary install instructions.
For one who is unfamiliar, with the process, it is possible to inadvertently add additional steps, by following some of the instructions on the MSYS2 site, which could be surplus to requirements, which was a possible reason why my 1st attempt did not proceed as expected.
The 4 paths using MSYS2 are :
Create an installer for your own computer (which may not be installable on another computer) using “MSYS Makefiles”
This was my primary intention, same as above but the installer .exe should be able to be installed on another Windows computer. I attempted this but it did NOT succeed, so I had to go back to run option 1, above.
Same as 1 above but using “Ninja” to achieve this build.
Same as 2 above but using “Ninja” to achieve this build
It takes a while to do each of these compiles, so I did not bother with 3 and 4, having achieved what I needed in option 1.
When I do have the time, I’d love to compile a single set of instructions, of the specific instructions I followed, for option 1. Which should be sufficient for most “testing” purposes, ideally with some explanations, hints aimed at anyone who has never played around with a command line, to assure their success.
Next steps, from this success, will be learning how to creating a Windows build of custom sources, like the Sigmoid module, which is what initiated this opportunity to build Windows executables/installers, in the 1st place.
I’ll ask the developer of sigmoid, for assistance, with this build - Things I need to know are :
How to obtain a copy of the source of the “fork” which includes the sigmoid module code.
Any changes which I may need to introduce to the process, in my attempt to build for Windows.
So a working sigmoid compile is the next step.
When I succeed at this, the next step will be learning enough code development to create a Filmulator module so I can have options for raw development in the same instance of daktable (Base Curve, LUTS, Filmic, Sigmoid, and Filmulator).
A huge thanks to all contributors to my success. Thank you from a deep place in my heart.
Thanks ever so much. I was able to, thanks to the encouragement and guidance of those on the forum, to learn and build a Windows installer or executable, from the most current dev version of darktable on github.
At the appropriate time, I will still delve into Linux on a virtual machine, to make it easier to share and obtain knowledge from other contributors who are, in my estimation, developing or building on Linux, as their primary target platform.
Ask your build questions here. References from the previous thread.
I’m glad you got to a useable endpoint…
I was able to compile and build a Windows executable and also create an installer.exe, which installed ok. So I now have an instance of dt, which has the sigmoid module.
At first I gitted (if there is such a word) or rather cloned the entire repository/branch from the author of sigmoid, but compiling and building that did not yield an install which included sigmoid.
Then I found this :
And if synced with the windows build instructions I had succeeded with earlier, it was a relatively painless process.
Next frontier to conquer would be a much more involved one which is “building a filmulator module or might be modules, cos of the architecture of dt’s processing, which may require the various aspects of filmulator to be split up”
It makes sense to start the discussion on this “project”, in its own thread. My initial thoughts are , for compiled apps, this must be such a pain, to have to always compile before they could test anything.
Funnily enough I didn’t see this discussion until now.
I built a dt-trunk + sigmoid build under Win10 for the first time yesterday.
To be honest, i was surprised how easy it was. Well done DT devs for the process and documentation!
The approach I followed, provided me with a “build” of DT, which includes sigmoid, but the version of DT in this, is not in sync with the latest DT dev version. So I end up having three versons of DT.
One with sigmoid, but out of sync (I think) with the current development code on github.
One without sigmoid, but is based on the current development version on github.
And the stable release 184.108.40.206, which I simply downloaded and installed, and did not build, unlike the two above.
I wish I knew how to, every month, build a version based on the current dev code on github, and combine this with sigmoid. So I can reduce the number of instances/versions I keep on my computer, from 3 to 2. If anyone knows how to do this, kindly share.