| 00:21.59 | *** join/#brlcad rqsjpjkemuxnrxjz (~armin@dslb-088-065-187-184.088.065.pools.vodafone-ip.de) | |
| 00:52.11 | brlcad | starseeker: it's a default cmake .. build, so mixed |
| 00:52.19 | *** join/#brlcad yorik (~yorik@2804:431:f721:d5eb:290:f5ff:fedc:3bb2) | |
| 00:54.42 | brlcad | starseeker: http://pastebin.ca/3723654 |
| 00:55.20 | brlcad | LEMON_FOUND:STRING=LEMON-NOTFOUND |
| 01:03.12 | starseeker | brlcad: that's OK - what's LEMON_TEMPLATE set to in the cache? |
| 01:04.45 | starseeker | mine is /home/user/brlcad/misc/tools/lemon/lempar.c |
| 01:05.45 | brlcad | unset |
| 01:05.55 | brlcad | grep returns no matches |
| 01:06.59 | starseeker | O.o |
| 01:08.55 | starseeker | line 71 in misc/tools/CMakeLists.txt should be setting it |
| 01:11.25 | brlcad | hm, only gets there if line 70 has BRLCAD_BUNDLED_LIBS=BUNDLED and it's set to "AUTO" |
| 01:11.46 | starseeker | BRLCAD_LEMON should end up set to BUNDLED though |
| 01:11.49 | starseeker | since you're building it |
| 01:12.30 | brlcad | where's that set? |
| 01:12.37 | brlcad | grep returns empty |
| 01:13.43 | starseeker | should be in the THIRD_PARTY_EXECUTABLE macro |
| 01:17.18 | brlcad | okay, so I see THIRD_PARTY_EXECUTABLE in ../misc/tools/CMakeLists.txt for lemon |
| 01:17.39 | starseeker | right - the macro definition is in misc/CMake/ThirdParty.cmake |
| 01:19.06 | starseeker | my guess is 503 should be setting BRLCAD_LEMON |
| 01:21.29 | brlcad | 403? |
| 01:22.03 | starseeker | sorry - line 503 in misc/CMake/ThirdParty.cmake |
| 01:23.08 | brlcad | that's what I meant too |
| 01:24.04 | brlcad | 403 block should be setting BRLCAD_LEMON_BUILD=ON, LEMON_DISABLE_TEST=1, LEMON_MET_CONDITION=5 |
| 01:25.34 | starseeker | that's if we have an explicit BUNDLED request for lemon, which we don't unless you're setting it |
| 01:25.42 | brlcad | that means it won't get to line 503, because of line 481 |
| 01:26.33 | starseeker | our line numbers are slightly different - for me 481 is a blank line |
| 01:26.35 | brlcad | ah, I see .. it's auto |
| 01:29.48 | brlcad | okay, so it got there for LEMON |
| 01:30.34 | starseeker | so if BRLCAD_LEMON is set to BUNDLED, the next question is why that didn't work for the misc/tools/CMakeLists.txt:71 test |
| 01:31.33 | brlcad | checking to make sure the var makes it there |
| 01:31.48 | brlcad | GOT HERE for LEMON, BRLCAD_LEMON="BUNDLED (AUTO)" |
| 01:32.25 | starseeker | but you said LEMON_TEMPLATE isn't set in the cache? |
| 01:33.17 | starseeker | what version of CMake? (maybe there's something funny about the MATCHES test...) |
| 01:35.49 | brlcad | aha, couldn't this be the problem |
| 01:36.44 | brlcad | misc/tools/CMakeLists.txt:72 is where LEMON_TEMPLATE is set and line 71 is where we check BRLCAD_LEMON |
| 01:36.59 | brlcad | and line 74 ... is where BRLCAD_LEMON is set |
| 01:37.23 | starseeker | the include? |
| 01:37.35 | starseeker | include(${BRLCAD_CMAKE_DIR}/FindLEMON.cmake) |
| 01:38.01 | brlcad | oh noes ... you know what, these sources are out of date! |
| 01:38.19 | starseeker | wondered... line numbers appear to be one off... |
| 01:38.46 | brlcad | yep, that's it .. fixed in current source |
| 01:38.57 | brlcad | thanks for helping track that down |
| 01:39.02 | starseeker | phew - that's why I can't reproduce it :-) |
| 01:39.03 | starseeker | np |
| 01:39.14 | brlcad | I must have missed svn upping that one... i'm compiling on four separate machines |
| 01:39.19 | brlcad | four separate failures... |
| 01:39.28 | starseeker | winces |
| 01:40.05 | starseeker | that's ironic - I was just running Windows builds and distcheck on linux and things were looking good... |
| 01:40.06 | brlcad | bsd is still failing because of cmake not adding a -L/usr/local/lib |
| 01:40.15 | starseeker | hmm |
| 01:40.32 | brlcad | that was one of the linux failures, but clearly false positive |
| 01:40.54 | starseeker | tries bsd build |
| 01:41.29 | brlcad | another linux succeeded build, but is failing make test |
| 01:41.40 | starseeker | you mean make check? |
| 01:41.45 | starseeker | make test is expected to fail... |
| 01:42.09 | brlcad | a particular test is failing that shouldn't |
| 01:42.13 | brlcad | the parallel test |
| 01:42.17 | starseeker | ah |
| 01:42.32 | brlcad | looks like a genuine catch though, found a problem scaling to tons of cpus |
| 01:42.51 | brlcad | on a 160 core box, it blows out our 1024 MAX_PSW limit |
| 01:42.58 | starseeker | :-) |
| 01:43.01 | brlcad | ~160*160 |
| 01:43.01 | infobot | 25600 |
| 01:43.05 | starseeker | that's fun |
| 01:43.28 | brlcad | it's trying to kick off that many threads :) |
| 01:43.59 | starseeker | erm. what's the preferred/correct behavior for a case like that? |
| 01:44.02 | brlcad | I fixed the book-keeping limit, but then pthread_create() fails with that many probably due to OS limit |
| 01:44.23 | starseeker | so we need a configure time test to find the practical upper limit? |
| 01:44.40 | starseeker | ah, the uuid_generate function |
| 01:45.18 | brlcad | I think bu_parallel might be able to throttle the work more intelligently so more than MAX_PSW many aren't created in the first place |
| 01:45.33 | starseeker | nods |
| 01:45.36 | brlcad | it's all in how it is handling recursive parallelism |
| 01:46.17 | brlcad | probably needs some sort of worker pool instead of just dispatching everyone |
| 01:46.31 | brlcad | yeah, so I know what the problem is on BSD .. just not how to fix it |
| 01:46.41 | starseeker | is looking into it now |
| 01:46.52 | brlcad | it correctly finds uuid_generate in uuid/uuid.h |
| 01:48.02 | brlcad | but the BRLCAD_CHECK_LIBRARY() call in top-level CMakeLists.txt:1874 for uuid_generate in uuid fails because there's no -L/usr/local/lib on the link line |
| 01:48.32 | starseeker | yeah, may need a FindUUID.cmake along these lines: https://github.com/PositronicsLab/reveal/blob/master/cmake/Finduuid.cmake |
| 01:48.45 | starseeker | hang tight, I'll see if I can get it working |
| 01:48.52 | brlcad | CMAKE_PREFIX_PATH does have /usr/local in it, but the CHECK_LIBRARY_EXISTS macro it's using in BRLCAD_CheckFunctions.cmake:260 doesn't use that |
| 01:50.40 | brlcad | yeah, that guy's find script will probably work .. it uses find_library() instead of check_library_exists(), which respects the CMAKE_PREFIX_PATH |
| 01:50.47 | starseeker | nods |
| 01:51.02 | brlcad | is there a reason we use check_library_exists(), haven't looked up what the diff is |
| 01:51.14 | starseeker | I think just convenience/convention |
| 01:51.32 | starseeker | I'm not sure find_library looks for a specific function |
| 01:54.30 | brlcad | ahh, good point |
| 01:58.04 | brlcad | woot, that worked |
| 01:58.19 | brlcad | I think I have a simple fix, can you check it? |
| 01:58.22 | starseeker | sure |
| 01:58.34 | starseeker | a way that doesn't use FindUUID? |
| 01:59.35 | Notify | 03BRL-CAD:brlcad * 68953 brlcad/trunk/misc/CMake/BRLCAD_CheckFunctions.cmake: make CHECK_LIBRARY_EXISTS() respect the CMAKE_PREFIX_PATH during linking like find_library() does |
| 02:01.12 | starseeker | brlcad: that will work only so long as CMAKE_PREFIX_PATH contains only one path |
| 02:01.38 | starseeker | it is set at the toplevel CMakeLists.txt:673, and it's currently set up to be a list |
| 02:02.14 | starseeker | it appears to contain only /usr/local currently, but unless we want to guarantee that there may be a problem |
| 02:02.22 | brlcad | looking |
| 02:03.40 | starseeker | also isn't quite following how -L/usr/local/lib ends up in the build logic for libbu just from adding it there... |
| 02:05.27 | Notify | 03BRL-CAD:brlcad * 68954 (brlcad/trunk/CMakeLists.txt brlcad/trunk/misc/CMake/BRLCAD_CheckFunctions.cmake): check_library_exists() already respects cmake_required_flags, so let it get set when the cppflag is set. |
| 02:09.20 | starseeker | shakes his head - still fails to build libbu from a clean build with r68954 |
| 02:09.24 | brlcad | of course you're right ... I'm surprised setting it globally doesn't |
| 02:09.25 | starseeker | one sec... |
| 02:16.03 | starseeker | grr... |
| 02:16.03 | brlcad | ooh, think I might have found it |
| 02:17.04 | brlcad | looks like it worked |
| 02:17.52 | Notify | 03BRL-CAD:brlcad * 68955 brlcad/trunk/CMakeLists.txt: need to call LINK_DIRECTORIES() to set the ldflag search dir |
| 02:18.23 | starseeker | brlcad: I just got the FindUUID working. Is the LINK_DIRECTORIES solution preferable? |
| 02:19.11 | starseeker | avoids special casing UUID, and definitely less code |
| 02:19.15 | brlcad | and confirmed, -L/usr/local/lib is in the link list |
| 02:19.24 | starseeker | tries it, but this time stashes his patch rather than blowing it away... |
| 02:19.31 | brlcad | :) |
| 02:20.07 | brlcad | honestly, your call .. don't know enough to answer |
| 02:20.11 | brlcad | it's definitely working |
| 02:20.35 | starseeker | that's find then - FindUUID would only be justifable if we wanted to be robust beyond /usr and /usr/local |
| 02:20.44 | starseeker | which I don't think is an issue for uuid |
| 02:21.18 | starseeker | confirmed, works |
| 02:21.22 | starseeker | good |
| 02:21.31 | starseeker | votes for that - simple and effective |
| 02:22.20 | starseeker | blinks |
| 02:22.27 | starseeker | wait a minute - a clean build failed again... |
| 02:22.33 | starseeker | what the bleep... |
| 02:22.44 | starseeker | OK. clear build dir... |
| 02:22.48 | starseeker | done |
| 02:22.50 | starseeker | cmake .. |
| 02:23.13 | brlcad | just looking at it, the FindUUID logic might do a better job at finding more variants if it were upstream proper and kept improving |
| 02:23.17 | brlcad | taking that guy's particular version, though, doesn't look to have an advantage I see |
| 02:23.31 | starseeker | nods |
| 02:24.45 | starseeker | test_bu_uuid fails to link for me |
| 02:24.59 | starseeker | make test_bu_uuid |
| 02:25.34 | brlcad | looks |
| 02:26.54 | brlcad | curious, working for me, has the -L |
| 02:27.01 | starseeker | try clean build dir? |
| 02:27.06 | brlcad | doing that now |
| 02:34.47 | starseeker | fwiw, I just got a full successful build with the finduuid approach... |
| 02:38.47 | Notify | 03BRL-CAD:starseeker * 68956 (brlcad/trunk/CMakeLists.txt brlcad/trunk/src/libbu/CMakeLists.txt): This seems to give a reproducible successfull build on BSD. May be overkill, but checkpoint in working state so I don't lose the patch again... |
| 02:41.07 | brlcad | working approach wins |
| 02:43.05 | brlcad | why run BRLCAD_CHECK_LIBRARY() and find_package? |
| 02:43.44 | brlcad | uuid_library and uuid_libraries is now listed in libbu's link btw, presumably only want one right? |
| 02:45.07 | brlcad | the bigger problem still remains for /usr/local/lib libraries, that they won't be searched |
| 02:45.49 | brlcad | looks like what happened .. LINK_DIRECTORIES didn't actually work .. must have been pulling a cached value |
| 02:46.09 | brlcad | because BRLCAD_CHECK_LIBRARY(UUID uuid uuid_generate) failed/fails |
| 02:46.55 | brlcad | that might also be why it's working, if it's not actually using uuid_generate now |
| 02:49.03 | brlcad | yeah, that's what's happening .. it's not using libuuid |
| 03:01.39 | Notify | 03BRL-CAD:starseeker * 68957 brlcad/trunk/src/libbu/CMakeLists.txt: only use pubic var UUID_LIBRARIES |
| 03:02.28 | brlcad | I think I have a fix |
| 03:02.38 | brlcad | retesting clean |
| 03:05.04 | Notify | 03BRL-CAD:starseeker * 68958 brlcad/trunk/misc/CMake/FindUUID.cmake: Add full license text |
| 03:05.59 | Notify | 03BRL-CAD:brlcad * 68959 brlcad/trunk/CMakeLists.txt: check for uuid_generate only after we're sure we found the lib |
| 03:07.20 | Notify | 03BRL-CAD:brlcad * 68960 brlcad/trunk/misc/CMake/BRLCAD_CheckFunctions.cmake: if we have the lib, conduct a different test that doesn't rely on searching for the library (since CHECK_LIBRARY_EXISTS doesn't respect required library flags). check for the function in the library specified via check_function_exists() |
| 03:07.25 | brlcad | that seems to do the trick, sanity check? |
| 03:08.25 | brlcad | now only problem is that it runs FindUUID every time |
| 03:41.53 | Notify | 03BRL-CAD:brlcad * 68961 (brlcad/trunk/misc/CMake/BRLCAD_Options.cmake brlcad/trunk/misc/CMake/FindBRLCADTCL.cmake brlcad/trunk/misc/CMake/ThirdParty.cmake): consistent case |
| 03:45.16 | Notify | 03BRL-CAD:brlcad * 68962 brlcad/trunk/src/libbu/parallel.c: not an end-state, but slight improvement on machines with greater than 128 cores. with recursive parallelism, the number of subthreads is technically unbound, so we'll need some a better method for tracking ever-increasing quantities of threads (and how to do so while ensuring MAX_PSW containers remain consistent). |
| 03:45.29 | starseeker | brlcad: sorry, goofing off |
| 03:45.58 | starseeker | re-calling find_package shouldn't be an issue... it will run once, then should skip repeating if it's found what it wants |
| 03:47.29 | starseeker | brlcad: I think that looks OK |
| 03:53.20 | brlcad | looks like it's calling it repeatedly here |
| 03:53.27 | brlcad | (and finding it) |
| 03:53.36 | starseeker | ah - it might be printing messages repeatedly |
| 03:53.39 | starseeker | checks |
| 03:53.57 | brlcad | next issue is make check is failing hard... :) |
| 03:54.04 | starseeker | urk |
| 03:54.06 | brlcad | rtwizard --no-gui is hanging |
| 03:54.10 | starseeker | on BSD? |
| 03:54.17 | brlcad | and spdi/shaders/.. are failing |
| 03:54.21 | brlcad | yeah |
| 03:54.24 | starseeker | winces |
| 03:54.25 | brlcad | .bz |
| 03:55.02 | starseeker | growls... can I stuff the rt/rtedge logic into librender? |
| 03:55.28 | starseeker | actually, that wouldn't do it... also need to add image filters to icv |
| 03:56.18 | starseeker | well, fwiw, can confirm clean builds on both Linux and bz |
| 03:56.58 | brlcad | heh, now that's quality .. trying to attach to rtwizard with gdb, gdb crashes :) |
| 03:57.09 | starseeker | O.o |
| 03:57.23 | brlcad | which then causes rtwizard to crash |
| 03:57.40 | starseeker | beautiful |
| 03:59.17 | brlcad | (the latter is not rtwizards fault) |
| 03:59.38 | starseeker | nods - suggests I did something really evil though to make gdb croak |
| 03:59.43 | brlcad | the fact that spdi and shaders are failing means something else is wrong/changed |
| 03:59.50 | starseeker | nods |
| 04:00.01 | starseeker | trying to think what that might be... |
| 04:03.10 | Notify | 03BRL-CAD:starseeker * 68963 brlcad/trunk/misc/CMake/FindUUID.cmake: Don't keep reporting we've found the lib if we already reported it once. |
| 04:03.20 | starseeker | brlcad: I think that should do it for the repeating message |
| 04:04.11 | starseeker | has to call it a night - be back in the morning |
| 04:09.52 | brlcad | okie okdokie |
| 04:10.01 | brlcad | thanks for your help, that was huge |
| 04:12.40 | brlcad | just fyi, seeing cross-platform shader spdi solids test failures, so will have to investigate |
| 05:50.10 | *** join/#brlcad KimK (~Kim__@2600:8803:7a85:6d00:458d:eff6:6dd3:17a2) | |
| 06:56.23 | *** join/#brlcad amarjeet (~amarjeet@202.164.53.117) | |
| 09:14.28 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 09:41.00 | *** join/#brlcad amarjeet (~amarjeet@202.164.53.117) | |
| 11:34.02 | *** join/#brlcad Caterpillar (~caterpill@unaffiliated/caterpillar) | |
| 14:20.08 | starseeker | just as a data point, make check succeeds on Linux Mint, gcc 4.8.4 |
| 14:26.56 | *** join/#brlcad merzo (~merzo@47-3-133-95.pool.ukrtel.net) | |
| 14:29.24 | starseeker | seeing three failures here - solids, shaders and spdi |
| 14:34.16 | starseeker | (on bz) |
| 15:02.48 | starseeker | brlcad: the failure appears between r68704 and r68717 |
| 15:08.46 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 15:34.54 | starseeker | got it - it was r68707 |
| 15:46.01 | Notify | 03BRL-CAD:starseeker * 68964 brlcad/trunk/src/libbu/booleanize.c: revert r68707 until we can determine why it's breaking the spdi, solid and shader regression tests. |
| 15:46.53 | starseeker | brlcad: I'm not quite sure what the tests are unhappy about, unless the interpretation of 0/1 as false/true isn't working for some reason... |
| 15:59.43 | starseeker | just as a point of interest: make -j12 check seems to have a decent chance of tests wiping out (I've seen dsp, dem and bot fail) but if I back off to (say) make -j5 things complete successfully (on bz) |
| 16:07.45 | starseeker | brlcad: here's what I'm seeing with rtwizard from gdb when it hangs: http://paste.lisp.org/display/327536 |
| 16:09.57 | starseeker | and info threads says there's just the one thread |
| 17:42.50 | *** join/#brlcad merzo (~merzo@139-66-133-95.pool.ukrtel.net) | |
| 19:09.44 | starseeker | brlcad: was Bmesh what you were talking about with Blender? https://wiki.blender.org/index.php/Dev:Source/Modeling/BMesh/Design |
| 19:10.02 | starseeker | if so, it looks like it is GPL: https://developer.blender.org/diffusion/B/browse/master/source/blender/bmesh/ |
| 19:31.25 | starseeker | this sounds kinda neat: http://www.pcworld.com/article/3118264/security/orwl-pc-the-most-secure-home-computer-ever.html |
| 19:47.57 | Notify | 03BRL-CAD Wiki:Jacquesmasso * 0 /wiki/User:Jacquesmasso: |
| 23:12.14 | brlcad | starseeker: that's what I saw in gdb for rtwizard yesterday too, not very helpful |
| 23:13.11 | brlcad | only thing of interest is it is using tcl 8.6 and a system pthread lib, maybe some dependency issue there |
| 23:14.15 | brlcad | on the surface, it seems that tcl eval failed on something (that's the important part) and it gets stuck trying to figure out / report the error |
| 23:14.18 | brlcad | Tcl_GetChannelError() |