| | <<<Back 1 day (to 2014/12/10) | 20141211 |
| mvrhel_laptop | hmm. with update, clean, and rebuild I am getting | 06:03.23 |
| | 1>c:\vrhel\artifex_laptop\git_gs_project\ghostpdl\gs\tiff\libtiff\tiff.h(30): fatal error C1083: Cannot open include file: 'tiffconf.h': No such file or directory | 06:03.25 |
| | in windoze | 06:03.36 |
| | with VS 2013 | 06:04.05 |
| | tired now so off to bed, but if someone can double check for me in spare time that would be great | 06:04.41 |
| kens | chrisl are you following the -sGenericResourceDir bug ? | 08:37.17 |
| chrisl | kens: I'm studiously ignoring it...... | 08:49.32 |
| kens | OK I'm going to post about using new switch types and saying 'no' very loudly. | 08:50.00 |
| chrisl | TBH, I was leaving it to Ray, as I have no clue about the history of it.... | 08:50.31 |
| kens | Nor do I,but I don't want this yahoo running off and adding new switch types. | 08:50.59 |
| chrisl | Actually, the "bug" report seems to me to be describing expected behaviour..... | 08:55.57 |
| kens | I'm too confused by the whole thing, I'd have to sit down and work through it all (again). I'm still sitting in the 'docuemtnation change' camp myself, but its Ray's bug :-) | 08:56.42 |
| chrisl | kens: I'm not convinced that simply adding the directory and file like that is enough to define a ProcSet resource | 09:00.31 |
| kens | I'm not either, but the whole concept he's outlining makes me recoil in horror | 09:00.50 |
| | It also seems to be considerably more than a 'relative path' for GenericResourceDir, which is what the report was about I thought | 09:01.38 |
| chrisl | I don't think it has anything to do with being a relative path..... | 09:02.00 |
| kens | Well it talks about enumerating relatvie GenericResourceDir | 09:02.29 |
| chrisl | But the behaviour is exactly the same if I use a absolute path, so...... | 09:03.13 |
| kens | To be honest, I'm still of the opinion this is a bonkers edge case by people who should know better using surious arguments to try and get us to conform to their warped view of the universe | 09:03.19 |
| | And I'm not inclined to do anything at all about it. | 09:03.39 |
| | My approach would be comment #6 | 09:04.00 |
| chrisl | Hmmm, GenericResourceDir does not like being a list of directories, it seems...... | 09:23.13 |
| kens | I think that's the thing the bug report is all about. | 09:23.29 |
| | THe inital comment is that if its a relative path then it should be considered a list of searches, and that doesn't work | 09:23.56 |
| chrisl | Yes, and it shows the poor quality of bug report that it's taken me this long to work it out :-( | 09:24.13 |
| kens | You and I couldn't isolate the change, because we couldn't get archaic GS versions to build for a bisect | 09:24.24 |
| | SO my feeling was 'its been 7 years, and nobody noticed, I don't believe its important' | 09:24.51 |
| | Only for Mr Flack to start arguing. Now this fellow wants to work on it, but he seems to be haring off in a different direction altogether | 09:25.40 |
| | Coffee..... | 09:25.50 |
| tor8 | avih: can you please test if the commits on tor/master fix your makefile troubles on cygwin (it's no rush, whenever you have time) | 11:06.21 |
| avih | tor8: wouldn't CC ?= cc be better? if you use clang as your defauly, it's likely that cc is already an alias for clang, else it's typically an alias for gcc .. | 12:43.45 |
| | default* | 12:43.58 |
| | and I think cc is more likely to be found on a system than CC defined | 12:45.12 |
| tor8 | avih: make CC=gcc will *always* override any settings in the makefile | 12:46.02 |
| | but I generally want to pick up clang if it exists, since it has better warnings etc | 12:46.25 |
| avih | tor8: yes, but if you don't have CC defined then make install will not work without CC=gcc | 12:46.33 |
| tor8 | CC is default set to something, so ?= won't work | 12:46.56 |
| avih | and i think it's more courteous to use the user's c compiler rather than clang if it exists | 12:47.40 |
| tor8 | I have both gcc and clang installed, cc typically points to gcc on non-macosx systems | 12:48.07 |
| avih | exactly, if the user has CC=gcc, why would you impose clang on him? | 12:48.15 |
| tor8 | because the code is tested with clang ;) | 12:48.43 |
| | make CC=gcc will override any makefile setting of CC | 12:48.53 |
| avih | u'm testing it with gcc, and most linux systems don't have clang, i'd imagine | 12:49.05 |
| tor8 | the problem is, the CFLAGS settings don't work so well on non-clang | 12:49.06 |
| avih | they do | 12:49.20 |
| tor8 | gcc for instance has broken -Wunreachable-code | 12:49.30 |
| | and completely bonkers code flow checking for uninitialized variables in the presence of setjmp | 12:49.49 |
| avih | i don't recall an unreachable code warning with the current code and gcc | 12:49.54 |
| tor8 | gcc doesn't implement unreachable code warnings | 12:50.06 |
| avih | it also doesn't say anything is wrong with this flag though | 12:50.28 |
| tor8 | I had to add workarounds for that, since I got mutually exclusive warnings about unreachable code on clang vs gcc | 12:50.51 |
| avih | would libmujs.a be compatible with gcc if the rest of the project is compiled with gcc? | 12:51.15 |
| tor8 | gcc complained about "no return value" where clang complains about unreachable code if I add a dead return at the end of a function that is unreachable | 12:51.24 |
| | it used to be a valid flag for gcc, but gcc's code is so convoluted and the warning code in gcc was so broken they took it out instead of fixing it | 12:51.59 |
| | clang and gcc generate 100% compatible binaries (not sure about C++, but that's not an issue here) | 12:52.35 |
| avih | well.. but if the user has both but has XX=gcc, then.. that's what he prefers for whatever reasons, i think it's nicer to respect it | 12:52.45 |
| | CC=gcc* | 12:52.58 |
| | and, if the user doesn't have clang installed and CC is not defined, then your new make install will not work out of the box | 12:53.41 |
| tor8 | why would it not work out of the box? | 12:54.00 |
| avih | because CC will not have a value | 12:54.14 |
| tor8 | if you don't have clang installed, CC will be left at the default value (which depends on the make binary) | 12:54.18 |
| | CC always has a value. it's one of the predefined variables in make. which is why ?= doesn't work on it (since it already has been assigned at the start of make) | 12:54.46 |
| avih | that's only if CC is defined. | 12:54.48 |
| | oh | 12:55.01 |
| | what is it assigned to by default then? | 12:55.08 |
| tor8 | system dependent. typically 'cc' | 12:55.22 |
| avih | within make? | 12:55.24 |
| tor8 | yes, within make | 12:55.33 |
| avih | hmm.. let me try it with cygwin. sec | 12:55.46 |
| tor8 | make -p will list all the default/builtin variables and rules | 12:57.59 |
| avih | works on cygwin. just making sure also on osx | 13:04.17 |
| | tor8: you forgot to remove the trailing mujs.h at: install mujs.h $(DESTDIR)$(incdir) mujs.h | 13:09.06 |
| tor8 | avih: thanks. | 13:09.43 |
| avih | tor8: you forgot to remove the trailing mujs.h at: install mujs.h $(DESTDIR)$(incdir) mujs.h9the "works" was about the CC part. didn't try make install, though it's likely to fail the same way it fails on osx with the extra mujs.h) | 13:09.49 |
| | oops :) | 13:10.00 |
| tor8 | yeat :) | 13:10.14 |
| | yeah* | 13:10.17 |
| avih | btw, i'm not sure exactly of the steps to reproduce, but i did notice few times that somwehere between make, make install and make clean, the source files get modified, sometimes to the point of not compiling again without git reset --hard | 13:15.05 |
| tor8 | some source files are generated (and zapped by make clean) | 13:15.59 |
| | one.c, astnames.h and opnames.h more specifically | 13:16.20 |
| avih_ | tor8: sorry, my irc proxy seems to be on and off... didn't notice your comment if you had any | 13:18.06 |
| kens | You can always check the logs, although it can be a few minutes till they update | 13:18.32 |
| tor8 | was it one.c or op/astnames.h? | 13:18.35 |
| | those are autogenerated by make rules, and make clean clears them out | 13:18.51 |
| avih | i think one.c is modified, as well as optnames(?) and/or "asnames ?) | 13:18.54 |
| avih_ | tor8: yes, the three of them | 13:19.58 |
| | make clean deletes them, and then make fails | 13:20.12 |
| tor8 | are you missing any of grep, sed, or awk? | 13:20.49 |
| avih_ | tiwell, if they're auto generated, then why have them as source files at the repo? | 13:20.55 |
| | and still, make fails after they're recreated | 13:21.03 |
| | i don't think i'm missing any of them | 13:21.29 |
| | they ARE regenerated, but somehow not good enough | 13:21.43 |
| | e.g. astnames.h gets space or tab before each name | 13:22.24 |
| tor8 | avih_: they're included so that you can build from source even if you are missing awk/sed/grep | 13:22.27 |
| avih_ | same goes for opnames | 13:22.56 |
| tor8 | arguably, clean should not remove them | 13:23.04 |
| avih_ | yeah | 13:23.10 |
| | and i do have grep/sed/awk on both cygwin and osx, and on both after make clean it fails to build | 13:23.57 |
| tor8 | hm, might be differences in sed or awk that the rules to autogenerate don't work | 13:24.28 |
| | that would be annoying, but not the first time it's happened | 13:24.57 |
| | awk is usually quite different, but the awk program for one.c is as simple as you can get | 13:25.31 |
| avih_ | the regeneraged opnames and apnames have speces or a tab at the begining of each line, while the original names start at column 0. is that the reason for the failures? | 13:26.08 |
| | it didn't get to one.c, because it failed on op/ast names | 13:26.48 |
| | ah, some white space instead of opening quite (") | 13:27.26 |
| tor8 | what does sed --version say? | 13:27.29 |
| avih_ | quote* | 13:27.31 |
| tor8 | could be bash quote escaping going haywire on cygwin | 13:28.38 |
| avih_ | no, actually, make clean works on cygwin (where i have sed (GNU sed) 4.2.2), but on osx sed doesn't support --version, and on osx it breaks on make clean | 13:29.22 |
| avih | would this help? http://stackoverflow.com/questions/2320564/variations-of-sed-between-osx-and-gnu-linux | 13:30.35 |
| | anyway, if ast/op names.h and one.c are part of the source three, then they probably shouldn't be cleaned on rebuild. the rebuild will most likely only be useful for developers, while most people who will install it are likely to be users of it | 13:34.47 |
| | https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/sed.1.html | 13:36.24 |
| | tor8: and you should get an osx system to test on ;) | 13:50.28 |
| tor8 | no thanks ;) | 13:51.24 |
| avih | if you look around enough, it's technically possible to run osx inside virtualbox. but not straight forward | 13:51.36 |
| tor8 | I'll try freebsd in a virtualbox, that should get me close enough I hope | 13:51.51 |
| avih | i'd think so too | 13:52.01 |
| | tor8: anyway, make and make install now work in osx and cygwin. make is broken after make clean on osx, and if clang is not available, then make displays an ugly-ish: which: no clang in (/usr/local/bin:/usr/bin: ..... long list of paths) | 14:07.59 |
| tor8 | avih: guess I'll need to bash on this some more. thanks for testing it out so far. | 14:13.19 |
| avih | tor8: np. thx for the fixes :) | 14:13.38 |
| tor8 | and you can always run make CC=gcc on cygwin without these fixes | 14:15.08 |
| | I guess I'll just cave and not set CC at all | 14:15.18 |
| | (and just set it in my local env) | 14:15.24 |
| avih | you know i'm saving you a lot of bashing and reputation from random users when i do this now instead of after we ask mpv users to install mujs ;) | 14:15.37 |
| tor8 | no amount of bashing will make me embrace autohell though ;) | 14:16.03 |
| avih | :) | 14:16.12 |
| | yeah, i can and did work around it. but many users will not try to if it fails out of the box, especially when it's just another dependency which could be skipped | 14:17.30 |
| | (mpv has tons of optional dependencies, and mujs is also optional in my patch) | 14:19.33 |
| | tor8: do you have any kind of continuous integration system for MuPDF? | 14:23.47 |
| Robin_Watts | avih: We do. | 14:24.05 |
| tor8 | we do | 14:24.05 |
| avih | and you run mujs through it too? | 14:24.16 |
| Robin_Watts | We have a cluster of machines. Whenever a change is made to mupdf, loads of files are run through it. | 14:24.23 |
| avih | which platforms? | 14:24.24 |
| tor8 | but it's geared for checking bitmap output | 14:24.31 |
| avih | oh | 14:24.38 |
| Robin_Watts | We run both mudraw and mujstest | 14:24.39 |
| avih | i see | 14:24.44 |
| Robin_Watts | mujstest just tests the javascript that is found in pdf files. | 14:25.04 |
| | and it'll all *nix. | 14:25.22 |
| avih | what does "that is found in pfd files" means? in your pds test files? | 14:25.32 |
| Robin_Watts | s/it'll/it's/ | 14:25.35 |
| avih | well, darwin is sort of *nix as well. | 14:26.02 |
| Robin_Watts | avih: PDF files can have javascript in for validating button presses etc. | 14:26.12 |
| avih | Robin_Watts: i know. but that's juvascript like any other javascript | 14:26.30 |
| Robin_Watts | The testing system simulates data entry into PDF forms/button presses etc. | 14:26.36 |
| | Thus the limit of the testing is the javascript that is exercised in such files. | 14:26.58 |
| avih | ah. so the js that's in your test files | 14:27.13 |
| Robin_Watts | Yes, our nodes are ubuntu and darwin, I think. | 14:27.16 |
| | Yes. | 14:27.18 |
| avih | tor8: then maybe worth testing also make clean? (though i doubt it'll break again after you fix it ;) ) | 14:28.05 |
| | (to make it clear, i'm far from an avid osx user and it's not my main system, but it's not a bad system, and there are enough devs which use it, so supporting osx well is probably desirable) | 14:33.19 |
| tor8 | avih: yeah, bsd sed doesn't like \t escape in character classes | 15:09.34 |
| avih | glad you could reproduce | 15:24.09 |
| tor8 | avih: okay, new commit on tor/master that works on both linux and openbsd | 15:32.19 |
| avih | tor8: your repo is the same? | 15:33.38 |
| | (as master) | 15:33.42 |
| tor8 | I don't understand your question | 15:33.58 |
| avih | oh, yeah. the changes are on your repo only | 15:34.00 |
| | it was a bad question :) | 15:34.08 |
| tor8 | yeah, I only push to my repo until they've been tested | 15:34.33 |
| | anything on my repo is not considered published, so may be nuked or rebased or amended at any time | 15:35.05 |
| mvrhel_laptop | tor8: before we rip gsview out of the mupdf repos, give me a couple weeks to get a few things in place there | 15:38.09 |
| | ok. looks like my xpswrite commit to gs is the thing that broke VS :( | 15:39.27 |
| avih | tor8: confirmed make, make install, make clean && make && make install all work | 15:39.29 |
| mvrhel_laptop | after running bisect | 15:39.45 |
| avih | tor8: however, after make clean && make, this is the git diff i see: http://pastebin.mozilla.org/7930886 | 15:39.46 |
| | tor8: ^ on osx. would you have expected the diff to end up empty? | 15:40.33 |
| mvrhel_laptop | kens: you did not see any issues with VS building | 15:41.53 |
| | '? | 15:41.55 |
| avih | tor8: actually, i see the same/similar diff on cygwin too | 15:42.11 |
| kens | mvrhel_laptop : building what ? | 15:42.58 |
| Robin_Watts | mvrhel_laptop: We did something 'funky' for crashlytics. We have a git repo with the crashlytics stuff in that includes the standard mupdf repo as a submodule. | 15:43.04 |
| | We could probably do the same for gsview. | 15:43.15 |
| | Have a gsview repo that contains both ghostpdl and mupdf as submodules. | 15:43.34 |
| mvrhel_laptop | Robin_Watts: ok | 15:43.34 |
| | kens: gs | 15:43.39 |
| kens | mvrhel_laptop : I don't use the standard GS project, I have my own | 15:43.58 |
| tor8 | avih: ahem. oops. | 15:44.01 |
| mvrhel_laptop | kens: so doing a clean and rebuild does not work. kens oh | 15:44.07 |
| avih | :) | 15:44.16 |
| mvrhel_laptop | I apparently broke it but no one noticed. will fix in a bit | 15:44.44 |
| | bbiab | 15:44.50 |
| tor8 | avih: try again, with new commit | 15:45.17 |
| | .*OP_ matches on ...GETPROP_S as well | 15:45.49 |
| kens | mvrhel_laptop : I guess nobody among us is using the standard project. I stopped using it because Git kept presenting me with a list of files htat had changed whenever I rebuilt | 15:46.02 |
| mvrhel_laptop | thats odd | 15:46.21 |
| | about git | 15:46.59 |
| tor8 | mvrhel_laptop: yes. I've got a repo with the gsview directory pulled out, but it won't build as it expects to live inside mupdf | 15:46.59 |
| | we'll need to rejig repo to include mupdf and ghostpdl as submodules, like Robin_Watts said | 15:47.20 |
| mvrhel_laptop | ok. that would make sense. | 15:47.32 |
| kens | mvrhel_laptop : its because the VS projects need to be updated to use them with VS 2008 | 15:47.34 |
| tor8 | mvrhel_laptop: http://git.ghostscript.com/?p=user/tor/gsview.git;a=summary | 15:47.56 |
| mvrhel_laptop | kens: I dont have that problem and I am using 2013 | 15:47.57 |
| kens | Well it was all a long time ago, I've been using my own project for 7 years now...... | 15:48.24 |
| | But I'm surprised Git gui doesn't tell you you've altered the project files. It does for me | 15:49.33 |
| mvrhel_laptop | tor8: so, for commits that I have here locally, where should I plan to push them in the short term? | 15:49.37 |
| | kens: just the solution file | 15:49.47 |
| avih | tor8: confirmed diff is empty. on cygwin though i think it changes EOL char on rebuild, but i wouldn't worry about it. thx | 15:49.49 |
| tor8 | avih: yeah, not much to do about that | 15:50.05 |
| Robin_Watts | mvrhel_laptop: I'd keep pushing them to standard mupdf until we're ready to extract it. | 15:50.13 |
| mvrhel_laptop | Robin_Watts: ok good | 15:50.21 |
| | that is what I was hoping you would say | 15:50.28 |
| tor8 | mvrhel_laptop: what robin said, I can redo the extraction easily enough | 15:50.29 |
| mvrhel_laptop | great | 15:50.34 |
| kens | mvrhel_laptop : yes, theat's what I mean GIt gui keeps listing the solution file as having changed | 15:50.48 |
| avih | tor8: you could skip deleting and rebuilding source files, but yeah, it's good for now. thx :) | 15:50.54 |
| tor8 | it's just a sequence of git filter-branch with subdirectory extraction and tree-rewrite commands | 15:51.00 |
| Robin_Watts | mvrhel_laptop: If tor is ready to do the extraction, then possibly we should get all your pending stuff in, then extract it, then carry on from there? | 15:51.03 |
| avih | anyway, gtg now, meeting... | 15:51.42 |
| mvrhel_laptop | Robin_Watts: if we could wait about 1 week for me to clean up a few things that would be preferred. There are several things I need to tidy up | 15:51.48 |
| Robin_Watts | fine with me. | 15:52.04 |
| tor8 | there's no rush | 15:56.30 |
| avih | tor8: in case you want to clean stuff, here's a gcc 4.8.2 on cygwin build log+warnings http://pastebin.com/0hr32VsS | 16:31.44 |
| | no warnings with clang on osx | 16:33.31 |
| | tor8: btw, re git practices, i see that you rewrote history on master few times today. it's usually considered better practice to only rewrite on wip branches, right? | 16:34.54 |
| | i mean, on your repo | 16:35.06 |
| | (i'm a git n00b.. trying to absorb best practices) | 16:36.05 |
| Robin_Watts | avih: Generally with git, it's best not to rewrite any 'published' branches. | 16:56.53 |
| | (where branches include master) | 16:57.03 |
| avih | yeah. | 16:57.29 |
| Robin_Watts | We consider the main repos (the non user ones on ghostscript.com) to be 'published'. | 16:57.30 |
| avih | but rewriting WIP branches is still a thing which happens, right? | 16:58.00 |
| Robin_Watts | But our personal repos on ghostscript.com are free for us to do what we want with. | 16:58.01 |
| | avih: Absolutely. | 16:58.09 |
| | One of the really nice things about git is that you can alter the history. | 16:58.30 |
| avih | i agree, and i understnd the issues with rewriting published branches. it's a delicate line and as i said, trying to understand good and common practices | 16:59.10 |
| | off topic, github's diff is really nice. can view unified or side by side, syntax highlighting, can be expended to show parts of the file beyond what's inside the diff... really nice. https://github.com/ccxvii/mujs/commit/9bc5fec0804381d59ef8dc62304ed6892fb7c4ca?diff=split | 17:02.12 |
| | nice shades of pleasant colors... | 17:02.57 |
| | and rounded corners for diffs inside the line :D | 17:03.33 |
| kens | OK enough for one day, night all | 17:19.46 |
| mvrhel_laptop | have I ever said how much I hate fooling around with make files. Can't quite figure out why this thing won't build. Having issues with tiffconf.h header not being found. I need the tiff stuff for the xpswrite device since all the images are stored in the package as tiff | 18:44.33 |
| | I am thinking chrisl could make short order of this | 18:44.43 |
| | I am guessing he is likely gone for the day though | 18:46.43 |
| | or night as it may be | 18:46.49 |
| mvrhel_laptop_ | ok this may just be something weird with VS | 19:13.06 |
| | and how it is searching where stuff is | 19:13.15 |
| | although, that can't be true as the bisect says it was my commit that caused the issue | 19:14.04 |
| Robin_Watts | mvrhel_laptop: Let me pull the latest version of gs and try. | 19:14.11 |
| mvrhel_laptop | Robin_Watts: ok thanks. I am just about ready to stop fooling with this and move on | 19:14.32 |
| | I just wanted to build a more recent dll to use with gsview to get the speed up of the xpswrite image stuff and spent the morning fooling with this thing | 19:15.09 |
| Robin_Watts | mvrhel_laptop: OK. I've pulled from source and I'm rebuilding gs now. | 19:16.52 |
| mvrhel_laptop | I do think gdevxps.c should have included gstiffio.h instead of <tiffio.h> and <tiffvers.h> but that did not make any difference | 19:16.54 |
| | Robin_Watts: if a clean and rebuild works for you, then it is likely some issue with VS 2013 and how the search paths are getting set up in the conversion from the older version. setting the search paths in the project solved the issue for me (I can now build at least) | 19:18.07 |
| | but I don't understand why tifsep would build and not the xpswrite device since they both have the same tiff dependencies | 19:18.40 |
| | when is tiffconf.h generated and where is it getting placed is what I would like to know | 19:26.29 |
| Robin_Watts | ok, all built fine for me. | 19:27.51 |
| mvrhel_laptop | hmm | 19:27.56 |
| | what version of VS are you using | 19:28.08 |
| Robin_Watts | 2005. | 19:28.13 |
| mvrhel_laptop | was that a release version you built? | 19:28.39 |
| | 64 bit | 19:28.49 |
| Robin_Watts | no. | 19:28.56 |
| mvrhel_laptop | just to make sure, could you do that too? | 19:29.09 |
| Robin_Watts | Release x64 build coming up. | 19:29.36 |
| mvrhel_laptop | thanks. if that builds then I will back up and try 2010 which is the oldest version I have and see if that works | 19:30.23 |
| Robin_Watts | ok, 64bit release fails for me too. | 19:34.33 |
| mvrhel_laptop | ok | 19:34.38 |
| | Robin_Watts: and tiffconf.h not found is the issue? | 19:35.24 |
| Robin_Watts | yes. | 19:35.33 |
| | d:\cvs\artifex\ghostpdl.git\gs\tiff\libtiff\tiff.h(30) : fatal error C1083: Cannot open include file: 'tiffconf.h': No such file or directory | 19:36.00 |
| mvrhel_laptop | so when is the generated and where is it getting placed is what I wanted to understand next | 19:36.01 |
| | s/the/this/ | 19:36.07 |
| Robin_Watts | so gs/base/tiff.mak is the file that creates it. | 19:38.07 |
| mvrhel_laptop | Robin_Watts: I don't want to take up any of your time on this. The issue was introduced by my commit so I will find it. At least now I know its not just VS 2013 | 19:38.11 |
| Robin_Watts | which commit? | 19:38.38 |
| | Add high level image handling to xpswrite device? | 19:39.08 |
| mvrhel_laptop | 878ef4d48a0aebc9354ccd09443a1a52ad93c9a0 yes | 19:39.13 |
| | I have the tiff dependencies in there | 19:39.26 |
| | which really should have been gstiffio.h | 19:39.44 |
| | instead of <tiffio.h> and <tiffvers.h> | 19:39.56 |
| | but it still has the same issue in this case. | 19:40.12 |
| Robin_Watts | right, but the makefile doesn't get dependencies from headers. | 19:40.26 |
| mvrhel_laptop | right . I need to add those in devs.mak | 19:40.42 |
| | and I did that and it did not seem to matter. | 19:41.08 |
| | but maybe I made a mistake | 19:41.24 |
| | let me double check | 19:41.29 |
| Robin_Watts | where has devs.mak gone? | 19:41.57 |
| mvrhel_laptop | it was moved to devices | 19:43.36 |
| Robin_Watts | OK, so I think xpswrite needs to have $(libtiff_dev) | 19:45.16 |
| mvrhel_laptop | ah ok | 19:45.38 |
| | let me get all the headers in there and add that too | 19:46.22 |
| Robin_Watts | $(DD)xpswrite.dev : $(DEVS_MAK) $(xpswrite_) $(GDEV) $(GLD)vector.dev \ | 19:46.25 |
| | $(libtiff_dev) $(MAKEDIRS) | 19:46.27 |
| mvrhel_laptop | right. ok. thanks Robin_Watts | 19:47.27 |
| Robin_Watts | still fails to build :( | 19:47.39 |
| mvrhel_laptop | hmm I added all the headers into devs.mak and am trying now | 19:50.09 |
| | Robin: the fact that libtiff_dev=$(TIFFGENDIR)$(D)libtiff.dev is defined below the xps write device does not matter in the world of make files correct? | 19:50.49 |
| Robin_Watts | mvrhel_laptop: D'Oh. That probably matters a lot. | 19:51.05 |
| mvrhel_laptop | :) | 19:51.13 |
| Robin_Watts | doesn't seem to help. | 19:51.37 |
| | I have it, I think. | 19:55.56 |
| mvrhel_laptop | ok I have it working now | 19:56.08 |
| | too | 19:56.13 |
| | I have | 19:56.37 |
| | # XPS writer | 19:56.41 |
| | xpswrite_=$(DEVOBJ)gdevxps.$(OBJ) | 19:56.42 |
| | $(DD)xpswrite.dev : $(DEVS_MAK) $(xpswrite_) $(GDEV) $(GLD)vector.dev \ | 19:56.44 |
| | $(string__h) $(stdio__h) $(libtiff_dev) $(gx_h) $(gserrors_h) \ | 19:56.45 |
| | $(gdevvec_h) $(gxpath_h) $(gzcpath_h) $(stream_h) $(zlib_h) \ | 19:56.47 |
| | $(stdint__h) $(gdevtifs_h) $(gsicc_create_h) $(gsicc_cache_h) \ | 19:56.48 |
| | $(MAKEDIRS) | 19:56.50 |
| | $(SETDEV2) $(DD)xpswrite $(xpswrite_) | 19:56.51 |
| | $(ADDMOD) $(DD)xpswrite -include $(GLD)vector | 19:56.53 |
| | $(DEVOBJ)gdevxps.$(OBJ) : $(DEVVECSRC)gdevxps.c $(gx_h) $(gdevvec_h) \ | 19:56.54 |
| | $(string__h) $(stdio__h) $(libtiff_dev) $(gx_h) $(gserrors_h) \ | 19:56.56 |
| | $(gxpath_h) $(gzcpath_h) $(stream_h) $(zlib_h) \ | 19:56.57 |
| | $(stdint__h) $(gdevtifs_h) $(gsicc_create_h) $(gsicc_cache_h) \ | 19:56.59 |
| | $(MAKEDIRS) | 19:57.00 |
| | $(XPSDEVCC) $(I_)$(TI_)$(_I) $(GLO_)gdevxps.$(OBJ) $(C_) $(DEVVECSRC)gdevxps.c | 19:57.02 |
| | after the dev of libtiff_dev | 19:57.03 |
| | not sure how best to do this though | 19:57.07 |
| Robin_Watts | just need to add $(libtiff_dev) to both the xpswrite.dev line and the gdevxps line. | 19:57.09 |
| mvrhel_laptop | ah | 19:57.21 |
| | ok | 19:57.23 |
| Robin_Watts | Ordering doesn't matter. | 19:57.25 |
| mvrhel_laptop | ok | 19:57.27 |
| Robin_Watts | (apparently :) ) | 19:57.31 |
| mvrhel_laptop | then I will move mine back | 19:57.34 |
| Robin_Watts | oh, and you need a $(tiff_i_) dependency. | 19:58.03 |
| | Let me pastebin the diff. | 19:58.06 |
| mvrhel_laptop | ok thanks! | 19:58.13 |
| Robin_Watts | http://pastebin.com/DnrnEBYs | 19:59.18 |
| mvrhel_laptop | Robin_Watts: thanks for helping me figure this out | 19:59.38 |
| Robin_Watts | no worries. | 20:09.24 |
| | Forward 1 day (to 2014/12/12)>>> | |
IRC Logs