Windows build #1327

peterbud · 2016-10-24T16:33:58Z

First of all I know the question of a Windows build has been controversial, and generated a lot of emotion in the past. All I'm asking is to look into this PR in an objective way, setting emotions aside.

In the last 2 months I have been working on creating a decent Windows port of darktable. I believe this software is brilliant, and would deserve to reach a broader (but less fortunate) audience who are still only familiar with Windows.
For the port I have used the MSYS2 Mingw64 environment, which enabled to use the existing build system without any major change. The resulting code is native 64-bit, no dependency on propriatery libraries, only what comes with Windows.

To see the whole effort, please note that first I had to port to Windows the following libraries (as no ports were available on MSYS2 or on Windows at all):

PugiXML
osm-gps-map
libgd
libgphoto2
LUA was available, but a newer version, so I had to build the 5.2 version myself

The other libraries have been already ported and were available.

Also I have realized that there is no decent GTK3 binary distribution so I have also contributed to a project which now can deliver a solid binary distribution for GTK3

Along the way I have added all the necessary Windows specific code, where I have tried to make as few surgical changes as possible, and not interfering with the existing code. During the port I had to add a few functions which were missing from MSCRT. I have tested the current PR is still building properly on Ubuntu.
I have documented the necessary steps to prepare the Windows build in the /packaging/windows/BUILD.txt file in detail.

The current version is a fully functional darktable which runs nicely on Windows, supports all basic lighttable and darkroom functionality + OpenCL, lensfun, tethering, slideshow and map.

What is missing is the printing and color management functionality, that is more complex and requires more time.

Finally I'm planning to create a decent installer package using cmake and NSIS later, as users are expecting a binary distribution format.

Any constructive feedback is welcome.

…nto windows-build Resolving conflicts: # src/CMakeLists.txt # src/common/collection.c # src/dtview/main.c # src/external/rawspeed/CMakeLists.txt # src/external/rawspeed/rawspeed-identify.cpp

…nto windows-build

LebedevRI · 2016-10-24T16:52:12Z

It's hard to keep disscussion constructive when the questions are being ignored :)

Finally I'm planning to create a decent installer package using cmake and NSIS later, as users are expecting a binary distribution format.

Since you will ignore our words anyway, i'm gonna go forward right now and state the same as with, parta: you must specify really clearly that that is not darktable and is not related to the darktable in any way, and no one should report anything about it's brokenness to us.

Let's try this again.
This mail did state the view on the subject of at least some of the developers: https://www.mail-archive.com/darktable-dev%40lists.darktable.org/msg00344.html

Now, tell us: how exactly does this not go exactly against the points raised there,
in particular, about new pile of bugs and no developer to handle it?

TurboGit · 2016-10-24T17:11:02Z

I have to agree with Roman. The Windows port is long story and we do not want only a port but a group of highly motivated people around to fix issues specific to this platform.

This is the third, fourth, fifth... I don't count anymore... Windows port from different people. Let's try to create a group, come discuss on IRC, stay around...

TurboGit · 2016-10-24T17:12:50Z

To be even clearer, we do not want a build today and nothing tomorrow. This will be very bad for darktable reputation. Do you see all those users left in the void with an old buggy version?

peterbud · 2016-10-24T17:26:05Z

Dear Roman and Pascal, this is my first contribution to the darktable community, so I don't have any history of ignoring words.

I clearly see the risks you mentioned, and I trust your experience. I was thinking hard before submitting this PR (You saw the first sentence...): Nobody knows how many bugs will surface. Nobody knows how many people would contribute and maintain this part of the code. I don't have a team and I can only speak for myself. As you have seen in the last two months I have spent quite some time to understand the code and the software, and put a lot of energy to build a foundation and reach this state. I would happy to do that in the future as well, as it was fun and rewarding.

It's a collaborative effort, and we need to start somewhere. I believe all software (I guess also darktable) started small with a lot of bugs, and with a few people to participate. But with the time bugs are getting less and more people are joining. I'm happy to continue discussing it on IRC or some other forum in a smaller group.

Peter

boucman

Ok, so i'm the one that is not against a win port, so I did actually look at the code

this is a very clean code that mainly updates the existing (limited) support that we already have and adds what's needed to actually get it to work.

it also adds a readme that would allow other people to work with that. So i'm all in favour of it

You have a few (mainly cosmetic) changes here and there that could be made into a separate patch

So overall, if there was not the elephant in the room of "do we want a windows port" i'd be all for including that patch

Now, I can't ignore that elephant, and i'm not sure what's the proper next step is... here are a couple of idea. Note that this is not anything official, just my personal thought on it.

maintain this patch serie as a branch, keep it up to date, rebased on master on a regular basis
DO NOT release any binary builds for windows. That might not release the torrent of bugs that the other devs fear, but it will certainly bring you a huge amount of bad karma.
do not post your port on the ML before asking and getting a positive answer from the core devs. They'll probably say no for a couple of release and until you are better known and trusted, but that's a necessary step.
Join IRC and fix bugs, offer new features, become a known devs.That was the first step in the mail stated above, and for a very good reason
Just drop any idea of getting this merged right now. You'll anger everybody and won't get anything constructive. Maintaining your unofficial branch is safer

I can't really offer you any long term advice except "become known and trusted and then we'll see" There is no predefined path for you, and as the mail stated, there is a real long-time commitement we need to be sure of.

Again, i'd really like to see a windows port, but we need a consensus within the core devs that whatever port is proposed is a long term commitment, and we can only juge that... from a long term commitement

boucman · 2016-10-24T18:05:04Z

packaging/windows/BUILD.txt

+
+    For gphoto2:
+    $ pacman -S mingw-w64-x86_64-{libusb,popt,libgphoto2}
+    Check that CAMLIBS and IOLIBS for LIBGPHOTO are available


how do you do that ?

You can check it by "echo $CAMLIBS". I made a note here as normal MSYS2 packages do not like to add env variables, but libgphoto2 needs that. So for the current mingw-w64-x86_64-libgphoto2 I have included a script which adds this to the MSYS2 environment, but this comment is more of a reminder for later that the installer needs to take care of this aspect.

Then add an export of those to the commands given later.

boucman · 2016-10-24T18:06:35Z

src/CMakeLists.txt

-  SET(CMAKE_SHARED_LIBRARY_LINK_CXX_FLAGS "-Wl,--no-undefined -static-libgcc -Wl,-O1 -Wl,--as-needed -Wl,--sort-common -s")
+  #removed the -s flag, as it has stripped the debug symbols even from debug builds
+  SET(CMAKE_SHARED_LIBRARY_LINK_C_FLAGS "-Wl,--no-undefined -static-libgcc -Wl,-O1 -Wl,--as-needed -Wl,--sort-common")
+  SET(CMAKE_SHARED_LIBRARY_LINK_CXX_FLAGS "-Wl,--no-undefined -static-libgcc -Wl,-O1 -Wl,--as-needed -Wl,--sort-common")


if this is a generic problem, you might want to make a separate PR for those

As I see these flags were used only when it was built for WIN32. The only change I made is to remove the -s flag. I guess nobody noticed that there are no debug symbols are available in the debug version, maybe there was no debug done on those early cross-compiling versions at all.

Right, stripping should be avoided, especially in these early stages where debugging crashes will be important.

boucman · 2016-10-24T18:07:49Z

src/common/darktable.c

-    } while(c != '\n' && c != EOF);
+      fputc(c, fout);
+      if(c == '\n') {break;} 
+    }


what's the problem with this code, win miss fseek ? is that something that is generic and is needed for other arch ?

fseek is there, just the original code went to an infinite loop, as the condition
if(c != EOF) was never true.
This particular code as I see is creating your default keyboardrc file if you don't have one from a template, but due to never reaching EOF condition, it has created 90MB+ size keyboardrc file until I killed the process :)

I'm not an expert, but in the fseek documentation I see that " A successful call to the fseek() function clears the end-of-file indicator for the stream" For that reason I have decided not to use here the fseek().

The updated code above was safely creating for me the keyboardrc file from the template, and I have tested that functionalty also on Ubuntu and worked well.

clears the end-of-file indicator for the stream

Can't you cache it before calling fseek() and check the cached value for EOF after calling fseek()?
Did not read the code though.

peterbud · 2016-10-24T18:38:03Z

Hi @boucman , thanks for the reply. Actually it makes a lot of sense: I'm happy to keep it on a separate branch, which we can merge/rebase from time to time. Also you have a point with the binary release, anyhow it will be a longer shot to do it properly.

LebedevRI · 2016-10-24T18:39:56Z

Just want to point out that from our point of view the code changes to build on windows, the windows port and "darktable" for windows is the same thing. And we have already stated our view on the latter.

It may be better to go help out some other free software project that already had the misfortune of working on that platform, from what i gather gimp is seriously lacking help and they are much more friendly and welcoming :)

Otherwise, the 'last' part of the mail explained the way quite clearly.

houz · 2016-10-25T10:11:00Z

I didn't look at the changes in this PR (yet) but I would like to state some general things, all of which are my personal view, not representative of the darktable team and I might change my mind anytime I feel like it. So here we go:

In general I am for a Windows port. There, I said it. That's also why I worked on that in the past.
I do understand that there are people with fundamental problems of porting Free software to a non-free system like Windows is. I however am not a dogmatic person (even if i claim to be every now and then).
Over the past few weeks I had mails exchanged with another person working on a Windows port, Jan Ingwer Baer. We tackled some of the problems like the fseek() (hint: it's the r mode instead of rb when opening the file which results in problems on Windows due to line endings and makes seeking impossible there, so reading until the newline is found is the right fix. Opening in binary mode isn't as it would break once someone edits the file in an editor with Windows line endings).
I see that both of them (Jan Ingwer and peterbud) spent quite some time and effort on their changes which sets them apart from earlier "#ifdef everything out that doesn't compile for me" approaches.

So as my personal conclusion barring a look at the actual changes is that a joint effort of the two would make me more or less happy with the prerequisites for approving a Windows port. Even if it's just something handed to a few people we know at the beginning as a closed test phase to see what bugs surface and how our then-windows-maintainers handle them.

LebedevRI · 2016-10-25T14:18:54Z

@peterbud

Dear Roman and Pascal, this is my first contribution to the darktable community, so I don't have any history of ignoring words.

Right, now that i have actually checked, in #1327 (comment) "It's hard to keep disscussion constructive when the questions are being ignored :)" was said because i just assumed you were the same person who started last thread about this https://www.mail-archive.com/darktable-dev@lists.darktable.org/msg01242.html
As you see, i did ask the same question, and IIRC did not get an answer..
Sorry.

But as others said, the mail more or less summed up the steps (at the end of the mail), not sure there is anything for me to add right now.
Do talk to us, do help with the normal issues, and maybe with some time..

LebedevRI · 2016-10-25T14:29:39Z

data/CMakeLists.txt

@@ -186,6 +186,12 @@ if(USE_XMLLINT)
  add_dependencies(darktablerc_file validate_darktableconfig_xml)
 endif(USE_XMLLINT)

+if (WIN32 AND EXISTS ${CMAKE_CURRENT_BINARY_DIR}/darktablerc)
+  #make sure line endings are UNIX like even on Windows
+  configure_file(${CMAKE_CURRENT_BINARY_DIR}/darktablerc ${CMAKE_CURRENT_BINARY_DIR}/darktablerc.tmp NEWLINE_STYLE LF)


I'd be surprized to learn that you can not pass that to normal configure_file() call.
I.e. this should be done when configuring ${CMAKE_CURRENT_BINARY_DIR}/darktablerc

My understanding is that darktablerc is a result of an xsltproc custom command.

add_custom_command( DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/../tools/generate_darktablerc.xsl ${CMAKE_CURRENT_BINARY_DIR}/darktableconfig.dtd ${CMAKE_CURRENT_BINARY_DIR}/darktableconfig.xml OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/darktablerc COMMAND ${Xsltproc_BIN} ${CMAKE_CURRENT_SOURCE_DIR}/../tools/generate_darktablerc.xsl ${CMAKE_CURRENT_BINARY_DIR}/darktableconfig.xml > ${CMAKE_CURRENT_BINARY_DIR}/darktablerc )

I tried to change the xsl file to make sure darktablerc have LF only at the line ends but did not find a good solution, and ended always with CRLF line ends. Any suggestion would be helpful here.

Ugh, ok.
But even then, it creates kinda-circular dependency chain for ${CMAKE_CURRENT_BINARY_DIR}/darktablerc.
I really doubt having 2 different targets providing the same output file is correct.

I'm not a cmake guru, so I might be wrong, but the added section is not interfering with the darktablerc output or creating circular reference.
For the configure_file there is the parameter called COPYONLY, which according to the documentation, "Copy the file without replacing any variable references or other content". So I beleive thats the reason that we have only one target (the original), the added configure_file is not defining any additional target IMHO

I'd prefer fixing the parsing of the file to ignore the line endings. People might edit it in an editor later and then all bets are off anyway.

Better fix parsing the rc file to accept both line endings.

I have followed your suggestions:

reverted back the CMakeLists.txt to the original

updated dakrtablerc habdling. Actually it was much simpler than I thought: opening with "r" instead of "rb" fif the trick. Also saving darktablerc has been updated from "wb" to "w". On linux there s no difference, but on Windows this was the trick.

LebedevRI · 2016-10-25T14:30:00Z

packaging/windows/BUILD.txt

@@ -0,0 +1,106 @@
+How to make a darktable windows installer (64 bit Intel only):


Intel? So no amd?

Actually no intel specific there, should work both, will update.

LebedevRI · 2016-10-25T14:33:53Z

src/common/opencl.c

@@ -1631,7 +1645,15 @@ int dt_opencl_build_program(const int dev, const int prog, const char *binname,
          char dup[PATH_MAX] = { 0 };
          g_strlcpy(dup, binname, sizeof(dup));
          char *bname = basename(dup);
+          #if defined(_WIN32)


Spaces before #if.
You really should follow https://github.com/darktable-org/darktable/blob/master/CONTRIBUTING.md, in particular https://github.com/darktable-org/darktable/blob/master/CONTRIBUTING.md#coding-style
Just set up clang-format hook and never worry about it again.

LebedevRI · 2016-10-25T14:35:01Z

src/iop/ashift_lsd.c

@@ -1914,7 +1914,7 @@ static int reduce_region_radius( struct point * reg, int * reg_size,
                                 image_char used, image_double angles,
                                 double density_th )
 {
-  double density,rad1,rad2,rad,xc,yc;
+  double density,radius1,radius2,rad,xc,yc;


What is this about?

rad1 and rad2 are unfortunately already defined numeric constants in dlgs.h - this change is basically a naming collision fix

Yes, Windows has some ugly global things.

LebedevRI · 2016-10-25T14:37:20Z

src/win/getdelim.c

+getline (char **lineptr, size_t *n, FILE *stream)
+{
+  return getdelim (lineptr, n, '\n', stream);
+}


Newline, modelines

I have now installed clang, and I'll make a change to getdelim.c and getdelim.h to see that the format is OK (will also add header comments). If yes, I'll update the other files I have modified.

LebedevRI · 2016-10-25T14:37:27Z

src/win/getdelim.h

@@ -0,0 +1,7 @@
+#ifndef __GETDELIM_H__


header, Newline, modelines

LebedevRI · 2016-10-25T14:38:37Z

src/win/getrusage.c

-
-// modelines: These editor modelines have been set for all relevant files by tools/update_modelines.sh
-// vim: shiftwidth=2 expandtab tabstop=2 cindent
-// kate: tab-indents: off; indent-width 2; replace-tabs on; indent-mode cstyle; remove-trailing-spaces modified;


LebedevRI · 2016-10-25T14:38:56Z

src/win/rlimit.c

@@ -0,0 +1,211 @@
+//////////////////////////////////////////////////////////////
+//
+// Sample implementation of getrlimit() and setrlimit() for Win32.


LebedevRI · 2016-10-25T14:39:10Z

src/win/rlimit.c

+        dwWritten = _write( handle, buffer, count );
+    }
+    return dwWritten;
+}


Newline, modelines

LebedevRI · 2017-03-28T17:41:23Z

Try this version - https://olgabatalina.ru/dt/darktable-2.3.0-win64-generic.exe (All processors)

Where can we see the code diff? :)

Lirein · 2017-03-28T17:42:56Z

The main difference in this versions are compilation flags (native or generic) for CPU optimisations and Multibyte code character sets (see code snippet in my post above).
Sorry for my English.

LebedevRI · 2017-03-28T17:44:43Z

As i hope you understand, that did not answer my question.

Lirein · 2017-03-28T18:00:31Z

You answer for this one?
https://olgabatalina.ru/dt/darktable.patch
https://olgabatalina.ru/dt/rawspeed.patch

houz · 2017-03-28T18:00:51Z

Try this version - https://olgabatalina.ru/dt/darktable-2.3.0-win64-generic.exe (All processors)
Or this (Xeon and top Core i7 CPU models) - https://olgabatalina.ru/dt/darktable-2.3.0-win64.exe
The best way to get debug output is run darktable like this:
darktable -d all > debug.log

Thanks for the offer, but I am not really interested in using darktable on Windows but getting this PR merged. And in order to do that I need to find the problems and help figuring out where they come from and how to fix them.

peterbud · 2017-03-29T05:31:37Z

I'll have more time later today, I'll check on running DT on VMs. Surely I have a Win 10 VM somewhere (but so far have not tried running DT on that), and will check on a Windows 7 VM, but will take more time (as I don't have it at hand)., My gut feeling it has to do something with OpenCL, but one never knows.

peterbud · 2017-03-29T05:39:08Z

@houz : also a short update on an earlier suggestion of you: have been testing the cmake BundleUtilities, and it is working (almost) perfectly. Actually when I have called fixup_bundle on the plugins directory, it has detected additional dependencies which I was not aware of before! Nevertheless we'll need to keep parts of the cmake scripts which are installing pixbuf libraries, adwaita, gphoto cameralibs etc. as these are not detected by fixup_bundle, and they have to be a specific location and not just in a bin directory. This approach will simplify things definitely.

LebedevRI · 2017-03-29T06:18:15Z

You answer for this one?
https://olgabatalina.ru/dt/rawspeed.patch

That if you C++-ify the code, and add a unittest; which fails without, and passes with the patch, i'd consider merging it.

PS: once there is 'official' win build, everyone who wants to help with that (currently by providing their own build), ideally, should cooperate. In other words, 3rd party builds would be, ... unwanted?.
Thankfully, so far @peterbud appears to fully qualify to all the ridiculous criteria which were specified in the Mail / first few comments of this PR.

houz · 2017-03-29T08:02:06Z

@peterbud that's good news. Having some special cases hard coded in the cmake files to be installed is fine. I am mostly worried about constantly chasing after specific DLL names, scripts breaking with every update of msys, …
As a test I commented out the -mwindows -Wl,-subsystem,windows lines to get the terminal window. That way I am able to see debug output. I will try to get my hands on the Windows laptop next weekend and see if I can find out where it hangs.
PS: I guess for now we should comment out these two lines in git, too, to make initial debugging feasible. Would that be ok for you? Final releases can have it reintroduced.

peterbud · 2017-03-29T08:48:23Z

@houz: On Windows 10 VM (Hyper-V) darktable just installs fine, and starts properly.

peci1 · 2017-03-29T09:15:49Z

If you'd appreciate more testing on real Windows, I offer one machine with Win 10 and one with Win 7 64 bit (both Intel Core i7).

For sure I can test pre-built binaries. If it'd help a lot, I can also try to prepare the build environment on these machines.

peterbud · 2017-03-29T10:53:43Z

@houz : I have managed to install darktable also on Windows 7 VM. In fact these are the very same debug builds which I have in my windows-build branch, just a week old (since then I'm trying to massage the BundleUtilities to make it work). So the bottom line is that I have not changed any CPU specific optimizations just used what we already have in the source. Later I might look into installing a release build on these VMs to see whether there is any difference.

peterbud · 2017-03-29T11:44:54Z

@houz : now I have finished the first pass with cmake BundleUtilities. Here is my summary and questions:

It works passing by an executable or folder plus the names of plugins. I'm passing darktable bin folder, plus the lib/darktable/plugins library. It detects all the shared libraries which either the executables or the plugin libraries linking to, and adds them to the bin folder, and installs them along with the dt binaries. BTW the fixup process is very time consuming, alone that has doubled (!) the build time, on a pretty powerful machine. Also it packs these shared libaries together into the installer package nicely.
fixup_bundle works only if all files are installed. In cmake its rather difficult to force something to run after install (ideas are welcome), at the end I have added a CMakeLists.txt into a packaging directory, and the fixup_bundle code is in that file.
The problem is that if a shared libary is using another shared libary in a plugin style, as those are not detected. Example: libGraphicsMagick-3.dll is detected as a dependency, and is being added, but neither libGraphicsMagick++-12.dll nor libGraphicsMagickWand-2.dll. Maybe these two are not used by darktable, but those are part of the GraphicsMagick package. So I guess we still need to install them if we want to make sure that darktable works properly. Similar example is libharfbuzz-0.dll is detected, but neither libharfbuzz-gobject-0.dll nor libharfbuzz-icu-0.dll

Do you have any suggestion for these? So far I can keep them on the manual list as before which I have compiled by hand using package dependency tree and package content list.

This means darktablerc is always using Unix style line endings, but also makes possible proting darktablerc files between platforms

parafin · 2017-03-29T12:35:40Z

These libraries you mention are not plugins, and therefore aren't needed in the package. You can take a look at https://github.com/darktable-org/darktable/blob/master/packaging/macosx/make-app-bundle and https://github.com/darktable-org/darktable/blob/master/packaging/macosx/darktable.bundle as the reference - gtk-mac-bundler does something very similar to BundleUtilities and you can see which extra files I have to add to Mac bundle.

houz · 2017-03-29T13:24:59Z

They are not dt plugins, but still needed at runtime by things we link against. Maybe we can use some wildcards and glob from cmake to get the files we want? That would at least make our scripts somewhat robust against system updates.

parafin · 2017-03-29T13:39:30Z

Hmm, and what doesn't work without these files? Because I might have to adjust Mac packaging too then.

parafin · 2017-03-29T13:40:09Z

By plugins I meant for example gphoto drivers, those are separate dynamic libraries and indeed are needed.

Removing DTDependencies component

cullub · 2017-03-29T21:45:03Z

The installer works on the Windows 10 machine I built in on, but not on my Windows 7 machine. (Rephrase: the installer works on Windows 7 but not DT itself.)

@Lirein 's generic build works on my Windows 10 machine as well (the i7 build didn't work).

Oh, and that red circle: there seems to be a bug in the rounded corner for that side - it is mostly rounded, but has a ~2px square jutting out from the corner.

His generic build also works on my Windows 7 machine.

Maybe it has to do with compilation flags for CPU optimization...

houz · 2017-03-31T07:47:40Z

I just tried your latest changes, however, when trying to build the installer package it fails with an error about the filename of one file being too long. The interesting bit being that it's something not needed at all. a regular make install doesn't try to add dumpbin.exe btw.

[...]
Run CPack packaging tool...
CPack: Create package using NSIS
CPack: Install projects
CPack: - Run preinstall target for: darktable
CPack: - Install project: darktable
CPack: -   Install component: DTApplication
CMake Error at C:/msys64/mingw64/share/cmake-3.7/Modules/GetPrerequisites.cmake:816 (message):
  C:/Program Files (x86)/Microsoft Visual Studio 12.0/VC/bin/dumpbin.exe
  failed: Der Dateiname oder die Erweiterung ist zu lang



Call Stack (most recent call first):
  C:/msys64/mingw64/share/cmake-3.7/Modules/GetPrerequisites.cmake:943 (get_prerequisites)
  C:/msys64/mingw64/share/cmake-3.7/Modules/GetPrerequisites.cmake:943 (get_prerequisites)
  C:/msys64/mingw64/share/cmake-3.7/Modules/GetPrerequisites.cmake:943 (get_prerequisites)
  C:/msys64/mingw64/share/cmake-3.7/Modules/BundleUtilities.cmake:575 (get_prerequisites)
  C:/msys64/mingw64/share/cmake-3.7/Modules/BundleUtilities.cmake:848 (get_bundle_keys)
  C:/Users/houz/Desktop/darktable-win/build/packaging/cmake_install.cmake:36 (fixup_bundle)
  C:/Users/houz/Desktop/darktable-win/build/cmake_install.cmake:36 (include)


CPack Error: Error when generating package: darktable
make: *** [Makefile:84: package] Error 1

peterbud · 2017-03-31T14:00:33Z

Strange, I have not had similar problem, but I don't have Visual Studio installed on my machine :)
I did a bit of google, and found this

BundleUtilities looks for a suitable tool and on Windows prefers dumpbin over MinGW
objdump. In my case even though I am using MinGW for builds, I have MSVC
installed too.

It looks like it can be forced to use objdump, will try later.

This will prevent using VS dumpbin tool when Visual Studio is also installed Keep in minfd that objdump is SLOW Also removing unnecessary install step in CI

peterbud · 2017-04-11T11:08:06Z

@houz is there anything needed from my side to merge the remaining changes and close this PR?

houz · 2017-04-12T09:28:12Z

I'll have access to the Windows 8/10 laptop this weekend for further tests. If that doesn't show major issues I will merge then.

houz · 2017-04-18T18:23:04Z

After some more tests I think this is good to go. I have some local fixes ontop of this, and some more issues to tackle afterwards, but keeping these few changes left over in a PR won't help anyone.

peterbud added 12 commits September 14, 2016 20:16

Initial changes to make a Windows build with MSYS2

49b7ee2

merged conflicts

0e5bc60

Adding openmap & lua & libgphoto fixing opencl

8c456d9

Merge branch 'master' of https://github.com/darktable-org/darktable i…

42c1579

…nto windows-build Resolving conflicts: # src/CMakeLists.txt # src/common/collection.c # src/dtview/main.c # src/external/rawspeed/CMakeLists.txt # src/external/rawspeed/rawspeed-identify.cpp

Added getrlimits support, adjusting fro gphoto2

774454c

Added getline support

24d0ce7

Tidy up the code

8baf332

Merge branch 'master' of https://github.com/darktable-org/darktable i…

20c745b

…nto windows-build

Added Windows support to dt_print_mem_usage

61bf3ae

Fixed statvfs

9ccf94a

Cleaning up CMakeList.txt

8057547

Cleaning up BUILD.txt for Windows/MSYS2

4b93770

boucman reviewed Oct 24, 2016

View reviewed changes

LebedevRI reviewed Oct 25, 2016

View reviewed changes

src/win/getdelim.h Outdated

@@ -0,0 +1,7 @@

#ifndef __GETDELIM_H__

Copy link

Member

LebedevRI Oct 25, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

header, Newline, modelines

LebedevRI reviewed Oct 25, 2016

View reviewed changes

src/win/rlimit.c Outdated

dwWritten = _write( handle, buffer, count );

}

return dwWritten;

}

Copy link

Member

LebedevRI Oct 25, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Newline, modelines

Windows build: Reverting back darktablerc handling

96e538d

This means darktablerc is always using Unix style line endings, but also makes possible proting darktablerc files between platforms

Windows build: Using BundleUtilities to detect dependencies

c6eecf7

Removing DTDependencies component

Windows build: forcing objdump for dependency detection

b91029e

This will prevent using VS dumpbin tool when Visual Studio is also installed Keep in minfd that objdump is SLOW Also removing unnecessary install step in CI

LebedevRI approved these changes Apr 18, 2017

View reviewed changes

houz merged commit 2312a57 into darktable-org:master Apr 18, 2017

LebedevRI added this to the 2.4 milestone Nov 18, 2017

peterbud deleted the windows-build branch December 26, 2017 15:35

		@@ -0,0 +1,106 @@
		How to make a darktable windows installer (64 bit Intel only):

Windows build #1327

Windows build #1327

Conversation

peterbud commented Oct 24, 2016

LebedevRI commented Oct 24, 2016

TurboGit commented Oct 24, 2016

TurboGit commented Oct 24, 2016

peterbud commented Oct 24, 2016

boucman left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

LebedevRI Oct 27, 2016 • edited Loading

Choose a reason for hiding this comment

peterbud commented Oct 24, 2016

LebedevRI commented Oct 24, 2016

houz commented Oct 25, 2016

LebedevRI commented Oct 25, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

LebedevRI commented Mar 28, 2017

Lirein commented Mar 28, 2017 • edited Loading

LebedevRI commented Mar 28, 2017

Lirein commented Mar 28, 2017 • edited Loading

houz commented Mar 28, 2017

peterbud commented Mar 29, 2017

peterbud commented Mar 29, 2017

LebedevRI commented Mar 29, 2017 • edited Loading

houz commented Mar 29, 2017 • edited Loading

peterbud commented Mar 29, 2017

peci1 commented Mar 29, 2017

peterbud commented Mar 29, 2017

peterbud commented Mar 29, 2017 • edited Loading

parafin commented Mar 29, 2017 • edited Loading

houz commented Mar 29, 2017

parafin commented Mar 29, 2017

parafin commented Mar 29, 2017

cullub commented Mar 29, 2017 • edited Loading

houz commented Mar 31, 2017

peterbud commented Mar 31, 2017

peterbud commented Apr 11, 2017

houz commented Apr 12, 2017

houz commented Apr 18, 2017

LebedevRI Oct 27, 2016 •

edited

Loading

Lirein commented Mar 28, 2017 •

edited

Loading

Lirein commented Mar 28, 2017 •

edited

Loading

LebedevRI commented Mar 29, 2017 •

edited

Loading

houz commented Mar 29, 2017 •

edited

Loading

peterbud commented Mar 29, 2017 •

edited

Loading

parafin commented Mar 29, 2017 •

edited

Loading

cullub commented Mar 29, 2017 •

edited

Loading