| | <<<Back 1 day (to 2018/05/13) | 20180514 |
| inflex | Is there a way to build the GLUT (gl-main.c) version on Windows? Mine keeps picking up the X11 sources (even with 'make build=release NOX11=yes' ) rather than the gl-main.c source | 03:05.00 |
| | Looks like at this stage I'm just going to have to replicate functionality additions between gl/main-gl.c and x11/win_main.c | 04:37.21 |
| Tamir_Evan | inflex: MuPDF does not currently support using the Makefile to build the FreeGLUT based viewer (mupdf-gl) for the Windows target, but you should be able to build it with the Visual Studio solution file (platform/win32/mupdf.sln ). | 12:58.24 |
| | inflex: If you're interested, I have a fork of MuPDF (https://github.com/TamirEvan/mupdf ) that aims to be build-able with MinGW (cross-)compilers, and can build a mupdf-gl.exe as well. You can download binaries of my '1.13.0-mingw' release (including mupdf-gl) from http://tamirevan.com/downloads/mupdf-1.13.0-mingw-bin.zip . | 12:58.34 |
| inflex | Thanks Tamir_Evan, I've just spent the night working my way through the gdi version trying to adapt my changes in to it, but I would certainly prefer to be able to stay with the GL only version simply so I don't have to maintain multiple parallel sets of changes :) | 13:07.27 |
| | ( doesn't help that for some reason my mingw make/gcc process seems painfully slow ) | 13:08.28 |
| | Tamir_Evan, do you have a github repo too (not that it matters directly, but I thoguht i'd check ) | 13:10.13 |
| Tamir_Evan | inflex: The one I mentioned above: https://github.com/TamirEvan/mupdf | 13:11.26 |
| inflex | My apologies, I didn't see that, too busy with a cat on the lap and coding across multiple machines | 13:11.59 |
| | ...and just then I get the win32 one to do the first feature I needed. Typical. | 13:12.24 |
| | I'll check your codebase and hopefully it shouldn't take me much to implement my small changes | 13:12.47 |
| | Many thanks btw, hopefully with your work, I'll have only lost a day with the GDI version :) | 13:14.41 |
| Tamir_Evan | inflex: Be aware, though, that I currently 40-odd commits behind the upstream repo, taking some time to merge in the Makefile changes they recently. | 13:17.16 |
| | inflex: That should have been: "Be aware, though, that I'm currently 40-odd commits behind the upstream repo, taking some time to merge in the Makefile changes they recently made." | 13:18.50 |
| inflex | I'll see how I end up. A question; how do I specify the making of the gl version in windows? just "make" ? | 13:19.07 |
| | From what I saw of the 1.13 release, I was able to drop in my mupdf-gl and a modified stext-search (I think it was) and everything lined up | 13:22.02 |
| Tamir_Evan | inflex: if you're building from mingw.org's MSYS shell then just 'make XLIBS+=-static-libgcc' should build for you mupdf.exe, mupdf-gl.exe and mutool.exe. | 13:23.31 |
| inflex | thanks | 13:40.20 |
| | oddly, it built without me doing any of that. | 13:40.59 |
| | looks like my version of the code worked great when dropped in to your build. | 13:49.31 |
| | Side/perhaps-dumb question; in linux, when you open files within the program (ie, fopen()), it's relative to the $pwd, but in Windows, it doesn't seem to be --- is there a specific location things go, or is it undefined? | 13:50.44 |
| | Thanks Tamir_Evan, it works--- http://pldaniels.com/mugl-on-win.png | 13:58.26 |
| | Now to tear down my github clone and base it off yours. | 13:59.13 |
| pink_mist | what makes you say it's not relative to the current working directory? | 13:59.29 |
| | (it's cwd, not pwd ... pwd is "print" working directory I think) | 13:59.46 |
| inflex | sorry, I appreviated "present working directory" | 14:00.29 |
| | if I let the program poll or write the data files it's expecting, they do not appear in the directory/folder I launch it from (or the one that the binary is in) | 14:01.06 |
| pink_mist | how are you launching the program? all programs have a working directory, but it might not be where you'd expect it to be | 14:01.45 |
| | depending on how you're launching it | 14:02.02 |
| inflex | that's what I'm thinking (that it's not what I'm expecting it to be). In this case, I'm launching from the bash shell in the windows env | 14:02.13 |
| pink_mist | oh, that I would -expect- to have the working directory the same as your bash shell, but I've never used WSL | 14:02.59 |
| inflex | ie, ~/development/mupdf$ ./build/release/mupdf-gl.exe | 14:03.04 |
| pink_mist | I'd expect cwd there to be ~/development/mupdf | 14:03.44 |
| inflex | That's what I'd have anticipated too. | 14:03.52 |
| | It could be an issue in my code, could be something simple I'm overlooking. | 14:04.07 |
| | for now, I'm just extremely relieved that I can now run this mupdf-gl.exe | 14:04.23 |
| | Tamir_Evan, when I git clone --recursive your project in windows, it works as expected, but for some reason when I do it in linux, it asks me a username/pass for every thirdparty repo submodule (and fails each time); any idea? If not no biggie | 14:09.07 |
| avih | inflex: try running it as: winpty ./build/release/mupdf-gl.exe | 14:15.20 |
| Tamir_Evan | inflex: No, I have no idea. How does doing a normal git clone, cd'ing into mupdf, and then doing 'git submodule update --init' go? | 14:15.37 |
| avih | it's possible that the app sees some bash-like paths, and winpty could fix then to be proper windows paths | 14:15.50 |
| | also, try launching it from normal windows command prompt rather than bash | 14:16.18 |
| inflex | I must apologies, it seems with the -gl version, it's behaving as I would expect | 14:19.14 |
| | Same problem Tamir_Evan , suspectin something about not having access rights to the repo host that they're from? | 14:20.03 |
| | just strange that it works fine in windows git :scratches head: | 14:20.17 |
| | mmm... might do it in windows, then copy the folder | 14:20.26 |
| Tamir_Evan | inflex: I'll try and check this out, and hopefully get back to you with a solution. | 14:24.50 |
| inflex | Okay, works in win and linux if I'm git clone --recursive'ing _your_ repo, but if I fork it, it fails with that problem | 14:26.47 |
| | I noticed the same with the master mupdf too | 14:27.08 |
| | something goes wrong with the way the submodules are handled in the github forking process perhaps, or it's a permissions issue. No matter, I've got enough to work on here now, thanks to your great work. | 14:28.06 |
| Tamir_Evan | inflex: This is probably because the submudule's repos are given as relative URLs in the '.gitmodules' file. I had to mirror upstream's thirdparty repos on my GitHub account in order for it to work for me, and probably so will you have to (at least for now). The only other solution, is if I change to absolute URLs in '.gitmodules', which I'm considering doing. | 14:52.53 |
| inflex | Nothing urgent anyhow, since it's working without faults afaik at this point anyhow. | 14:53.42 |
| | Tamir_Evan, all working the same as it is in linux now - https://www.youtube.com/watch?v=5UwiXCPqSBk | 15:26.34 |
| | Forward 1 day (to 2018/05/15)>>> | |
Log of #mupdf at irc.freenode.net.
