I think you will be in your user folder which is where you want to be … no??
It starts here
Bill Martz@DESKTOP-U6S1FBL MINGW64 ~
Is that command
pacman -S base-devel intltool git
you do the pacman stuff in msys2. THe rest in mingw64…did you follow all the steps when you set up your build environment for the packaging folder for Windows on the DT git?? It would be included by the second line in the screenshot…
My build environment was set up based on method. A here seems to work as advertised for me…
I thought you were referring to when I run mingw64.
If so, what is my user folder?
Do you mean in msys2
pacman -S base-devel
pacman -S base-devel iniltool git
pacman -S mingw-w64-x86_64-{toolchain,cmake,ninja,nsis}
pacman -S git
pacman -S mingw-w64-x86_64-{exiv2,lcms2,lensfun,dbus-glib,openexr,sqlite3,libxslt,libsoup,libavif,libwebp,libsecret,lua,graphicsmagick,openjpeg2,gtk3,pugixml,libexif,osm-gps-map,libgphoto2,flickcurl,drmingw,gettext,python3,iso-codes,python3-jsonschema,python3-setuptools}
pacman -S mingw-w64-x86_64-gmic
lensfun-update-data
And also update .bash_profile with
# Added as per http://wiki.gimp.org/wiki/Hacking:Building/Windows
export PREFIX="/mingw64"
export LD_LIBRARY_PATH="$PREFIX/lib:$LD_LIBRARY_PATH"
export PATH="$PREFIX/bin:$PATH"
# This would use 6 cores.
export CMAKE_BUILD_PARALLEL_LEVEL="6"
# gphoto2
export CAMLIBS="/mingw64/lib/libgphoto2/2.5.30/"
export IOLIBS="/mingw64/lib/libgphoto2_port/0.12.1/"
We are circling the bowl here… So as for your comment you don’t have ninja…you should if you followed all the pacman steps and you do that in msys2. Do this from the opening prompt. The user folder I mentioned is home but its under the “home” directory structure so I was trying to clarify the actual directory… So if you do cd ~ it will go to home aka /home/Bill Martz this is where your darktable folder should be or at least by default…
I have
Lot of topics going through each other now.
You are building a version from the current gl_version_v4 branch, which isn’t in main darktable yet.
So as I see it, you are temporarily making a custom build for one certain feature. The moment that feature gets accepted into Darktable, you should switch to using normal Darktable builds again (otherwise you would miss stuff as pointed out).
Maybe also good to point out that there are builds around for Windows with this code alreadyt in it. You don’t have to build yourself. Maybe safes you the hassle. If you want to learn, then bite through it 
.
Now, as you start a mingw64 session, you end up in your homefolder.
If you do the commands as I said
rm -rf darktable
git clone https://github.com/jenshannoschwalm/darktable.git
cd darktable
git checkout gl_recovery_v4
pwd
you get a ‘darktable’ folder in that home folder, and you ‘cd’ into the new darktable folder.
The ‘pwd’ command will show you what the current directory is.
You can then start doing the build commands (starting with a git submodule init), since you are already in the darktable folder.
If you want to stop and continue later, you need to go back to the darktable folder. That is why I gave pwd and told you to note the directory you are in at that moment.
The moment the highlight-recovery code is accepted and in the main darktable repository, you should change the git clone command to make a clone from the official darktable repo, and you then can forget about the git checkout command to switch branches, it’s not needed at that point.
But for now, the most simple way to get up and running from scratch is to install msys2, do all the pacman commands as stated in the build instructions, change the .bash_profile file as stated in the build instructions… now close the mingw64 session, start it again, and start typing the commands I listed.
Since your level of git understanding, this seems to be a perfectly valid and simple way to get the highlight recovery code locally and build it. Since you are just building it a few times, this is fine. In my opinion.
I have been using the windows insider updates to update to the latest version each week, but that won’t have the hl recovery. So I wanted to build my own until it does or until the master branch has it.
Once I start building, I work until it is completed.
@priort said:
second line should have been
git pull https://github.com/jenshannoschwalm/darktable.git gl_recovery_v4
You split it. Who’s right?
Hi all, please do not give advice to mess with ~/.bash_profile. It’s properly set up by the MSYS2 installer and everything works OOTB.
1 Like
We have also established last year when Bill tried this once already that he should not have and should not use a user folder with a space in it. Let’s avoid the deja vu please and try to actually learn something and not just blindly repeat shell commands ad infinitum.
There are instructions in the Darktable build docs to change some things. If they are not needed , you are right and the file should not be touched. But I always work with those changes still in there , so i don’t know.
If they aren’t needed anymore, maybe a PR or GitHub issue would be in place to change the docs.
I didn’t know what problems using a user name with a space in it would cause, but by changing some commands, we got it all to work.
I’m building right now. Let’s see what comes out of it.
$ cmake -G "MSYS Makefiles" -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/opt/darktable ../.
-- Is the target platform supported: 1
-- Found little endian system. Good.
-- Building SSE2-optimized codepaths: ON
-- Win32 build detected, setting default features
-- Performing Test C_COMPILER_UNDERSTANDS_-Wno-error=varargs
-- Performing Test C_COMPILER_UNDERSTANDS_-Wno-error=varargs - Success
-- Performing Test CXX_COMPILER_UNDERSTANDS_-Wno-error=varargs
-- Performing Test CXX_COMPILER_UNDERSTANDS_-Wno-error=varargs - Success
-- Performing Test C_COMPILER_UNDERSTANDS_-Wno-error=address-of-packed-member
-- Performing Test C_COMPILER_UNDERSTANDS_-Wno-error=address-of-packed-member - Success
-- Performing Test CXX_COMPILER_UNDERSTANDS_-Wno-error=address-of-packed-member
-- Performing Test CXX_COMPILER_UNDERSTANDS_-Wno-error=address-of-packed-member - Success
-- Looking for external programs
-- Found perl
-- Missing intltool-merge
-- Missing desktop-file-validate, problems in darktable.desktop might go unnoticed
-- Test-compilation of OpenCL programs is disabled.
-- Found jsonschema
-- Found xsltproc
-- Found xmllint
-- Missing exiftool
CMake Error at CMakeLists.txt:411 (message):
Some external programs couldn't be found
-- Configuring incomplete, errors occurred!
See also "C:/msys64/home/darktable/build/CMakeFiles/CMakeOutput.log".
See also "C:/msys64/home/darktable/build/CMakeFiles/CMakeError.log".
Maybe I’ll start over with building msys2 and follow BUILD.md exactly.
I would just wait a month or so for the PR to be merged into master or use the CI build from PR if there is a need to use a feature in development.
If it’s only a month, I can continue to use the build @priort supplied. I thought it was going to be December. Although, I would like to figure this out.
Maybe both right. I don’t know the syntax that shows , but any command in git can do many, many things :).
Coming from commercial work, i don’t work with multiple remotes that often. Everything gets proposed, merged and pulled in the same repo. I know my set wof commands would work and give you the recovery code. Doesn’t mean this one is wrong though 
.
I appreciate everyone’s help. As I said, I’ll start over following BUILD.md exactly and proceed from there. There were lots of errors with today’s build, so I will see if I can fix them one at a time.
I have to run now. Thank you all very much.
@Underexposed I am no expert Bill I could only share what works for me. I found that code as a suggestion for a simple way to use a remote branch…so I did it … I then build from that new branch that gets merged.
You had it building DT last night but I think you entered line 2 incorrectly…
You can always also reset your master if you think you fouled it up…
Perhaps a brute force approach that might work for you is not to delete your darktable folder but actually clone @hannoschwalm darktable repo into another folder. Then you can build it from in there with the exact same directions that you use to build DT…
It might not be in sync at any one time with the official master but it will allow you to try out the feature and as of now I don’t think you would be missing much…later you can just delete the whole folder…
Its crude but might be easier to wrap your head around…
I started over, and in building msys64 I got this message:
Note that ‘C:/msys64/mingw64/share’ is not in the search path
set by the XDG_DATA_HOME and XDG_DATA_DIRS
environment variables, so applications may not
be able to find it until you set them. The
directories currently searched are:
- C:\msys64\home\Bill Martz.local\share
- /usr/local/share/
- /usr/share/
Does that mean I should add C:/msys64/mingw64/share to the Windows environment path variable?
You meant “updating msys2”?
You can ignore that particular message.
1 Like