| 00:20.51 | *** join/#brlcad infobot (ibot@rikers.org) |
| 00:20.51 | *** 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:30.11 | *** join/#brlcad gtltzrngxxidxarc (~armin@dslb-088-066-138-030.088.066.pools.vodafone-ip.de) |
| 02:37.14 | *** join/#brlcad gabbar1947 (uid205515@gateway/web/irccloud.com/x-atsujarjxjycoftd) |
| 02:39.06 | starseeker | brlcad: could we consider a version reporting mechanism that, rather than compiling in the number of configure runs, pulls it from a file in the data dir somewhere? |
| 02:39.38 | starseeker | really isn't digging having to rebuild so much of the package every time there's a tweak to the config file that bumps that number... |
| 02:41.42 | starseeker | DaRock: what OS version are you trying to build on? |
| 02:41.55 | starseeker | might be able to set up a VM and give it a shot |
| 02:44.38 | starseeker | DaRock: fwiw, we're considering shifting to a simpler build logic that assumes installed 3rd party components and then maintains src/other as a separate "build and install all of this to get everything needed" convenience |
| 02:45.25 | starseeker | reliable cross platform detection is unfortunately a very hard problem, as your experiences are indicating |
| 02:46.52 | starseeker | fwiw, the diagrame on pg. 18 (pdf page 26) of this report tries to document the logic behind the design of the ThirdParty macro: http://www.arl.army.mil/arlreports/2013/ARL-TR-6475.pdf |
| 02:46.53 | gcibot_ | [ Access Denied ] |
| 03:31.24 | DaRock | starseeker: thats fine, I think the idea is sound, but the code hasn't been tested as thoroughly I don't think; so when I come and turn everything off it goes bang! and we uncover a lot of issues that probably haven't been touched due to inconvenience. eg the common fix is to enable all the builtins. |
| 03:31.51 | DaRock | if I could get my head around it, I could probably sort some of it, but.... |
| 03:34.48 | DaRock | right now, I think what I'm seeing is that even if the system libs are discovered and sorted - and set to be used - the cmake system still turns around and insists on using the builtin. i'm trying to figure out what would be needed to make this an if/else logic, where if the system libs are set, then use those, but only set the local(?) includes on if not. Right now it says in the comments to guarantee the builtins come first - no matter what |
| 03:38.08 | DaRock | the detection stuff I've seen appears to be sound - its the natural insistence on the builtins which means a lot of this ends up being wasted/ignored. Its not just "falling back" as advertised, its ignoring the system mostly |
| 03:38.45 | DaRock | maybe I'm just focused on a few modules though :) |
| 06:08.08 | DaRock | Ok, I have it figured - just need to work on a fix. The forced use of the builtin tcl uses the builtin header tcl.h. But that does not force the use of the builtin tk header. So the current tk/tcl is 8.6, and so the tk.h is newer than the builtin, which then errors because the builtin tcl header is set for 8.5.9, hence the cross pollination... |
| 06:09.33 | DaRock | the file is src/libtclcad/CMakeLists.txt |
| 08:26.32 | *** join/#brlcad elpea (~chatzilla@dsl-hkibrasgw5-58c04d-211.dhcp.inet.fi) |
| 11:18.06 | DaRock | could anyone inform me if the initial cmake variables of the build are carried through? Or is it a new environment for each dir? Some variables, but not all? |
| 13:43.49 | *** join/#brlcad Caterpillar (~caterpill@unaffiliated/caterpillar) |
| 13:57.08 | *** join/#brlcad caen23 (~caen23@79.112.48.210) |
| 14:09.07 | *** join/#brlcad caen23 (~caen23@79.112.48.210) |
| 14:23.11 | DaRock | does anyone know where the itcl/itk includes are set in cmake? |
| 14:34.07 | DaRock | I got past the tk.h error with this (I know it won't be right, but this was to test a theory and I know very little about cmake): if("${BRLCAD_TCL}" MATCHES "SYSTEM" AND "${BRLCAD_TK}" MATCHES "SYSTEM" AND "${BRLCAD_ITCL}" MATCHES "SYSTEM" AND "${BRLCAD_ITK}" MATCHES "SYSTEM") |
| 14:34.07 | DaRock | <PROTECTED> |
| 14:34.07 | DaRock | <PROTECTED> |
| 14:34.07 | DaRock | <PROTECTED> |
| 14:35.00 | DaRock | But it hasn't seemed to have set the itcl/itk include dirs, and I have no idea where |
| 15:03.52 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 17:13.08 | *** join/#brlcad d_rossberg (~rossberg@104.225.5.10) |
| 17:34.40 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 17:37.14 | starseeker | DaRock: that FindTCL.cmake module we have is a bit of a nightmare - it's one of the oldest pieces of CMake logic in the code, and it was written early in the conversion process from automake |
| 17:37.24 | starseeker | i.e. before I knew what I was doing |
| 17:38.12 | starseeker | we're also attempting to store and reset the CMake variables when we add src/other/CMakeLists.txt |
| 17:38.24 | starseeker | that could be causing some state management problems |
| 17:39.47 | starseeker | in the tcltk86 branch I think we ditch our internal FindTCL entirely and rely on CMake's built-in - you might see if doing that helps |
| 17:43.32 | starseeker | DaRock: good catch figuring out the using tcl.h but not tk.h from built-in, btw - that's indeed a scenario that either hasn't come up much or we "got away with" when the system header ended up as compatible |
| 17:44.54 | starseeker | if we really wanted to be aggressive about doing the right thing, we would check the libraries pulled in by system versions of libraries to try and catch any conflicts (for example, a system libpng being pulled in and conflicting with an enabled build of png in src/other) |
| 17:45.32 | starseeker | I don't know of a cross platform way to do that though, so it would likely involved writing a complex new CMake module to wrap it all |
| 18:00.54 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 19:07.33 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 19:48.44 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 20:46.09 | *** join/#brlcad yorik (~yorik@2804:431:f721:afd0:290:f5ff:fedc:3bb2) |
| 21:17.59 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 21:58.15 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 23:58.23 | *** join/#brlcad chenzhe (~Thunderbi@2620:101:c040:7f7:8013:ddb5:246:2707) |