| 00:12.07 | *** join/#brlcad nmz787_i (~ntmccork@134.134.139.72) | |
| 00:18.11 | *** join/#brlcad infobot (ibot@rikers.org) | |
| 00:18.12 | *** topic/#brlcad is GSoC students: if you have a question, ask and wait for an answer ... responses may take minutes or hours. Ask and WAIT. ;) | |
| 00:34.02 | *** join/#brlcad ycvbvrmgcerrjmcc (~armin@dslb-092-074-228-132.092.074.pools.vodafone-ip.de) | |
| 01:43.51 | DaRock | found the urt knobs, but I've tried disabling all builtins and just enabling urt but it fails in the cmake tests (undefined references sysmp etc) |
| 01:44.22 | DaRock | otherwise I just get tk/tcl errors |
| 01:44.35 | DaRock | thats why I've tried disabling all |
| 05:39.54 | DaRock | can anyone tell me what I need to intone to fix the TERMLIB_INCLUDE_DIR? |
| 05:53.44 | *** join/#brlcad LoH (~lenox@173-18-41-230.client.mchsi.com) | |
| 06:56.44 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) | |
| 07:18.15 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) | |
| 08:50.29 | *** join/#brlcad teepee] (bc5c2134@gateway/web/freenode/ip.188.92.33.52) | |
| 09:34.58 | *** join/#brlcad merzo (~merzo@user-94-45-58-139.skif.com.ua) | |
| 09:56.44 | Notify | 03BRL-CAD:Bertamsu64 * 0 /wiki/User:Bertamsu64: |
| 10:04.13 | *** join/#brlcad Caterpillar (~caterpill@unaffiliated/caterpillar) | |
| 10:56.51 | starseeker | DaRock: I'm not actually sure that bit is working properly |
| 10:57.14 | starseeker | (TERMLIB_INCLUDE_DIR) |
| 10:57.30 | DaRock | so.... what? :/ |
| 10:57.56 | starseeker | I'll see if I can look into it later today, unless you want to tackle redoing it :-) |
| 10:58.05 | DaRock | I'm looking at the source, and it should fallback to curses... etc |
| 10:58.12 | starseeker | what are the symptoms you're seeing? |
| 10:58.18 | DaRock | not a clue where to begin :) |
| 10:58.28 | starseeker | I didn't have one either when I started |
| 10:58.50 | starseeker | not always sure I have one now, for that matter ;-) |
| 10:58.51 | DaRock | I'm still on the first steep learning curve :) |
| 10:59.24 | starseeker | it's actually pretty straightforward, especially compared to autotools |
| 10:59.55 | starseeker | misc/CMake/FindTERMLIB.cmake should be involved with all that |
| 10:59.57 | DaRock | so I'm building on freebsd - mangling the port - trying to disable the builtins so the tk and libpng errors go away, but keep the urt lib |
| 11:00.24 | DaRock | it fails on finding termlib |
| 11:00.40 | DaRock | although why CMake should even need to get involved.... |
| 11:00.57 | DaRock | the c file seems to handle it very gracefully |
| 11:01.17 | starseeker | CMake sets the defines |
| 11:01.26 | starseeker | (or should be) |
| 11:01.35 | DaRock | src/libcursor/cursor.c |
| 11:01.44 | DaRock | weeellll.... |
| 11:01.44 | starseeker | the main logic is in src/other/CMakeLists.txt around line 202 |
| 11:02.15 | starseeker | and the THIRD_PARTY macro that calls is in misc/CMake/ThirdParty.cmake |
| 11:02.24 | DaRock | have a look at the c file - it seems to do well enough without. Unless you specifically want the builtin |
| 11:02.58 | starseeker | which is one of the cases we need to handle (deliberately turning on the built-in) |
| 11:03.21 | starseeker | if all else fails we fall back to the built-in, which is why we need to fix the detection |
| 11:03.57 | DaRock | seems fraught with difficulties :| |
| 11:03.59 | starseeker | FindTERMLIB.cmake should be checking for curses, ncurses, etc. |
| 11:04.38 | starseeker | DaRock: it's a general principle of the BRL-CAD build - the default out-of-box build will use system libraries where it can and src/other versions where it can't |
| 11:04.55 | starseeker | you can also override to use only src/other versions and only system libs |
| 11:04.58 | DaRock | I get that, but it doesn't seem to work |
| 11:05.44 | DaRock | overrides don't always work either - but where do I tell it to override termlib then? |
| 11:06.03 | starseeker | it gets tricky when you have system versions getting pulled in and locals enabled - the most common are zlib and png being enabled due to dev packages not being installed, but other system libs pulling in the system versions as well |
| 11:06.31 | starseeker | DaRock: it sounds like it's not detecting the system version correctly, so it can't work as expected |
| 11:06.32 | DaRock | exactly |
| 11:06.40 | DaRock | exactly |
| 11:06.55 | starseeker | I'll see if I can figure out why that detection isn't working - that should be the fix |
| 11:06.58 | DaRock | I don't quite know why though |
| 11:07.26 | DaRock | but again, why isn't there a knob for it? There is for just about everything else |
| 11:07.59 | DaRock | then if it isn't working as expected, it can be overridden and we move on in the meantime |
| 11:07.59 | starseeker | did you try -DBRLCAD_TERMLIB=BUNDLED ? |
| 11:08.24 | starseeker | that's what I would expect to be the override |
| 11:08.27 | DaRock | really? Where's that? |
| 11:08.56 | DaRock | I was hoping I could do SYSTEM, but I'll see... |
| 11:09.24 | starseeker | if it can't successfully detect the system version in the first place it won't let you succeed that way |
| 11:09.36 | starseeker | the "safe" fallback is to use our termlib |
| 11:10.12 | DaRock | from the logs, I'd say it isn't even looking for anything other than termlib (which the c file could handle) and simply failing |
| 11:10.16 | starseeker | DaRock: to be honest, we haven't put a lot of energy into the termlib stuff because it's eventually all scheduled to go away - we *can't* use it on Windows without an insane amount of work, and most of the tools that need it are very old |
| 11:10.45 | DaRock | thats my thinking :) |
| 11:10.46 | starseeker | OK, so something about FindTERMLIB.cmake isn't working right - it either isn't being called at all or its not doing its job |
| 11:11.08 | DaRock | the override won't work you think? |
| 11:11.10 | starseeker | i'll see if I can dig into it later today |
| 11:11.20 | starseeker | the override -DBRLCAD_TERMLIB=BUNDLED should work |
| 11:11.28 | starseeker | it just won't use the system version |
| 11:11.47 | DaRock | why? <sigh> |
| 11:11.55 | DaRock | retorical btw |
| 11:12.10 | starseeker | because our src/other is the fallback - we can't always rely on the system to provide what we need |
| 11:12.16 | DaRock | yes I miss-spelt it |
| 11:12.24 | starseeker | if the world consisted only of Linux and BSD distributions, we probably could |
| 11:13.00 | starseeker | but Windows, OSX, etc. don't have anything to match (say) the Debian apt system |
| 11:13.06 | DaRock | yes but why can't I - the compiler - tell it and to hell with the consequences? |
| 11:13.20 | starseeker | you can - -DBRLCAD_TERMLIB=SYSTEM |
| 11:13.40 | starseeker | but it will still have to detect the correct library flags and include dirs, and if it can't find them successfully it's game over |
| 11:14.05 | DaRock | I get that - and compiling it for one's self _should_ be the option, but I should still be able (if capable) to tell it what I want, rather than automated |
| 11:14.18 | DaRock | fine - build fails |
| 11:14.58 | DaRock | if I don't know what I'm doing, then I fallback myself to the automated system. If I can resolve it, then all will eventually be ok |
| 11:15.05 | starseeker | if you REALLY want to get hardcore you can define the things the FindTERMLIB file is supposed to define as well... -DTERMLIB_LIBRARY=curses and -DTERMLIB_INCLUDE_DIR=/usr/include or something like that |
| 11:15.33 | DaRock | it sounds like its born from an out of the box mentallity |
| 11:16.04 | starseeker | so -DBRLCAD_TERMLIB=SYSTEM -DTERMLIB_LIBRARY=ncurses -DTERMLIB_INCLUDE_DIR=/usr/include may get you past it in combination |
| 11:16.44 | starseeker | very much - the goal is to have the configure step always Just Work regardless of any shortcomings of the build environment |
| 11:16.55 | starseeker | (to a point of course - we can't bundle X11) |
| 11:17.12 | DaRock | thats what I was thinking, but it doesn't seem clearly indicated - it only says the defines, and none of the acceptable options are listed |
| 11:18.17 | starseeker | well, you shouldn't be having to defined the TERMLIB_* variables yourself - that's a bug in our system |
| 11:18.18 | DaRock | and thats fair enough, but to cut out any manual stuff is sure to come unstuck in edge cases where control might be required. |
| 11:18.38 | starseeker | nods - and in those situations, you can dig down and hand set variables |
| 11:18.59 | DaRock | I'll try those defines and see how I go - now that I know whats what ;) |
| 11:19.54 | DaRock | yes, but those variable are not documented as to what values can be put, or how the variables can be used - digging down didn't help :) |
| 11:20.00 | starseeker | DaRock: fwiw, brlcad is usually more in your camp of minimizing the "magic" and requiring manual setting of things to avoid broken corner cases |
| 11:20.47 | starseeker | DaRock: that's a fair point, and we probably should update our INSTALL doc to document what variables need to be hand-set if a manual override is required |
| 11:20.58 | DaRock | starseeker: does ncurses work on windows? |
| 11:21.10 | starseeker | nope |
| 11:21.42 | DaRock | works on about all others though, I think... I thought it did |
| 11:22.49 | starseeker | the closest thing out there that I know if is a version of pdcurses: https://www.projectpluto.com/win32a.htm |
| 11:22.49 | gcibot_ | [ PDCurses modified/extended ] |
| 11:22.58 | DaRock | no don't - that should be one to search for, but update it in the FindTERMLIB cmake file. If you don't dig that far, then you probably in the wrong place :) |
| 11:23.11 | starseeker | but I think the parts of the API they implement generally aren't the ones we use |
| 11:23.23 | DaRock | does brlcad use cygwin or is it native? |
| 11:23.27 | starseeker | so we'd have to rewrite a lot of our termlib code to more properly target the curses api |
| 11:23.39 | starseeker | it's native, built with MSVC |
| 11:23.49 | starseeker | one of the reasons we use cmake |
| 11:24.18 | DaRock | so win would be the edge case :D |
| 11:24.26 | DaRock | :P |
| 11:24.31 | starseeker | yep. also, unfortunately, the most common today |
| 11:24.57 | starseeker | BRL-CAD far predates Windows, so to us it's still an annoying edge case, but the rest of the world hasn't caught up yet |
| 11:25.19 | starseeker | DaRock: insider trick - look in .cmake files for the FIND_PACKAGE_HANDLE_STANDARD_ARGS line |
| 11:25.21 | DaRock | lol tell me about it :) |
| 11:25.48 | starseeker | in fairness, Windows is a lot easier to deal with these days than in years past |
| 11:25.52 | DaRock | thanks for the tip |
| 11:26.12 | starseeker | that macro defines the "required" variables for a particular Find*.cmake file |
| 11:26.44 | DaRock | <barf>... sorry about that. Thats why I got away from it entirely over 10 years ago |
| 11:26.46 | starseeker | if hard-setting the TERMLIB variables doesn't get you past it I'll try to see what's going on with the FindTERMLIB logic |
| 11:26.56 | starseeker | heh |
| 11:27.33 | starseeker | we periodically try to eliminated special case WIN32 logic in the build and code, but there's still quite a ways to go |
| 11:27.41 | DaRock | I got jack of having to explain why I had to reinstall it because some damned virus totalled my system |
| 11:27.52 | starseeker | yep, that gets old |
| 11:28.07 | starseeker | they're doing a lot better today than the Windows 98 days though. |
| 11:28.39 | DaRock | so I gave them one last call, and switched to linux, then bsd - and run it entirely caged in a vm if I really really have to |
| 11:29.00 | starseeker | nods - virtualbox and qemu really make life easier in that regard |
| 11:29.05 | DaRock | win98 you didn't have to justify a reload though |
| 11:29.20 | starseeker | heh - true enough |
| 11:29.38 | starseeker | DaRock: OK, I've gotta run - let us know how it goes and whether you hit any other hurdles |
| 11:30.21 | DaRock | I'll have a quick look at the FindTERMLIB logic, but my time is well overrun on this project so I might not get much done - I'll let you know what if I find anything |
| 11:30.34 | DaRock | sure. Thanks for the help :) |
| 12:54.40 | *** join/#brlcad yorik (~yorik@2804:431:f721:afd0:290:f5ff:fedc:3bb2) | |
| 13:21.03 | Notify | 03BRL-CAD:starseeker * 69667 (brlcad/trunk/src/external/CREO/part.cpp brlcad/trunk/src/external/CREO/util.cpp): tweaks |
| 13:32.19 | *** join/#brlcad elpea (~chatzilla@dsl-hkibrasgw5-58c04d-211.dhcp.inet.fi) | |
| 14:15.28 | *** join/#brlcad teepee] (bc5c2134@gateway/web/freenode/ip.188.92.33.52) | |
| 14:18.14 | Notify | 03BRL-CAD:starseeker * 69668 (brlcad/trunk/src/external/CREO/assembly.cpp brlcad/trunk/src/external/CREO/creo-brl.h and 3 others): because we have to map from wchar to char, there is no guarantee that even the basic creo strings will map uniquely. Try to set up to handle this situation. |
| 14:19.00 | Notify | 03BRL-CAD:starseeker * 69669 (brlcad/trunk/src/external/CREO/assembly.cpp brlcad/trunk/src/external/CREO/main.cpp and 2 others): do subtractions if we have them. |
| 14:33.29 | Notify | 03BRL-CAD:starseeker * 69670 brlcad/trunk/src/external/CREO/part.cpp: build fix |
| 15:06.10 | *** join/#brlcad gabbar1947 (uid205515@gateway/web/irccloud.com/x-lssobxdppedzsbko) | |
| 15:46.18 | DaRock | starseeker: it seems to be ignoring any overrides. I've got TERMLIB_LIBRARY=ncurses TERMLIB_INCLUDE_DIR=/usr/include set and its still looking for termlib.h according to the logs. A quick search finds no reference to (n)curses, and worse yet its still not looking in the /usr/include |
| 15:46.41 | DaRock | I'm not making much headway on the logic I'm afraid |
| 16:01.43 | Notify | 03BRL-CAD:starseeker * 69671 (brlcad/trunk/src/external/CREO/assembly.cpp brlcad/trunk/src/external/CREO/main.cpp and 2 others): Set up for an experiment. See if we can stash the CREO version stamp as an object attribute and use it to intelligently skip redoing conversions when no changes have taken place. |
| 16:27.19 | ``Erik | starseeker: can ya prod brlcad to look at irc? I just did things and stuff to his server to avoid running out of disk O.o |
| 17:13.18 | *** join/#brlcad nmz787_i (~ntmccork@134.134.137.75) | |
| 17:49.22 | Notify | 03BRL-CAD:starseeker * 69672 (brlcad/trunk/src/external/CREO/part.cpp brlcad/trunk/src/external/CREO/shim.h): See if we can get the bounding box and use it. |
| 17:55.08 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) | |
| 19:33.44 | *** part/#brlcad nmz787_i (~ntmccork@134.134.137.75) | |
| 20:00.01 | Notify | 03BRL-CAD:starseeker * 69673 brlcad/trunk/src/external/CREO/part.cpp: encapsulate the logic specific to tessellation |
| 21:41.09 | Notify | 03BRL-CAD:starseeker * 69674 (brlcad/trunk/src/external/CREO/assembly.cpp brlcad/trunk/src/external/CREO/creo-brl.h and 3 others): various build fixes |
| 22:25.59 | *** join/#brlcad elpea (~chatzilla@dsl-hkibrasgw5-58c04d-211.dhcp.inet.fi) | |
| 23:25.19 | *** join/#brlcad merzo (~merzo@210-38-132-95.pool.ukrtel.net) | |