| 01:19.13 | *** join/#brlcad infobot (ibot@rikers.org) |
| 01:19.13 | *** topic/#brlcad is BRL-CAD and open source CAx discussion ! Also @ http://brlcad.zulipchat.com ! Logs @ http://infobot.rikers.org/%23brlcad/ |
| 03:07.25 | starseeker | DenisP: there are examples in share/db in the BRL-CAD build directory |
| 03:07.53 | DenisP | Okay, thanks, I will check it out. |
| 03:08.50 | starseeker | they run from simple to complex, although there aren't any that are really big by modern cad standards |
| 03:25.35 | brlcad | DenisP: that looks like a fantastic scattering of random primitives! |
| 03:27.32 | brlcad | try havoc.g (havoc object) or tank_car.g (tank_car and track objects together) |
| 03:28.06 | starseeker | brlcad: yeah, r70782 removed the CMAKEFILES(${public_hdrs}) call - that was the call that let the CMake build know about the header files |
| 03:34.14 | starseeker | brlcad: it's probably my fault - I was trying to reduce the dependency on the _<command> overriding mechanism in our build after I found out it wasn't originally intended to be a supported feature, so the raw CMake commands no longer append automatically to the cmakefiles list |
| 03:34.47 | starseeker | brlcad: most of the time it is handled either by our target function wrappers or by the src/other file lists |
| 03:35.19 | starseeker | the headers are one of a few cases where that change necessitated an explicit call to CMAKEFILES |
| 03:38.11 | starseeker | IIRC, it's functionally similar to the autotools EXTRA_DIST feature... |
| 03:39.11 | starseeker | probably silly to worry about that mechanism, since we do still fundamentally need it for several things |
| 03:39.19 | brlcad | hm, yeah I recall the header change but didn't associate cmakefiles with doing that (or needing to do that) |
| 03:40.35 | starseeker | may have been accidentally removed - looks like I stuck it after the list, and if it's the cmake version of EXTRA_DIST it should probably go at the bottom of the CMakeLists.txt file... |
| 03:40.50 | brlcad | diff with extra_dist being you never had to extra_dist something the build knew something about -- it there no way to get a list of install() files? |
| 03:41.29 | brlcad | something with the install manifest file maybe |
| 03:41.55 | starseeker | obviously CMake knows about it internally, but I don't recall it being exposed to the user in CMake script land |
| 03:42.28 | starseeker | it was related to the discussions a few years ago triggered by their wondering why we were overriding with the _<function> mechanism |
| 03:42.50 | starseeker | I did get one patch in, but by itself it wasn't enough and the other changes stalled out |
| 03:43.17 | brlcad | definitely mistakenly removed -- now seeing the patch, I remember thinking that was probably even a mistake since we only CMAKEFILES() in other dirs things that don't get installed/built, at least that was the notion |
| 03:43.51 | starseeker | nods - that was a reasonable though given our past behavior |
| 03:44.43 | starseeker | is open to revisiting those changes - there's no point in moving away from that mechanism unless in preparation to be fully "clean" of the _function mechanism, and we can't without some work on the CMake side |
| 03:45.20 | starseeker | among other things, our comprehensive logging and target lists still need it |
| 03:46.44 | starseeker | would like to make the CMake changes, but that's about ~306 on the TODO list... |
| 03:47.18 | brlcad | we directly call install() in surprisingly few places |
| 03:47.20 | starseeker | not to mention the subsequent wait for the necessary version to become standard or bundling CMake... |
| 03:47.44 | starseeker | nods - I think that was what decided me to go ahead and remove the CMAKEFILES call from the function override |
| 03:48.20 | starseeker | but should have been discussed - your expectation with r70782 was completely reasonable given past behavior |
| 03:49.32 | starseeker | it's relatively rare for us to call raw install because usually things going into the install dir also need to go into the build dir (to get the "build dir matches install dir layout" effect) |
| 03:50.02 | brlcad | what about using the install_manifest.txt file |
| 03:50.22 | starseeker | that's managed by our wrappers - in principle we should also put the headers in the appropriate locations in the build dir, but since there aren't any runtime requirements we don't bother currently |
| 03:50.46 | starseeker | (it is a problem if an external program wants to target a build dir for compilation, but I think that's rare...) |
| 03:51.23 | starseeker | I think install_manifest.txt only gets generated at the end of the CMake run, which is too late |
| 03:54.29 | starseeker | we need to know in time to define the scripts for the distcheck logic |
| 03:55.15 | brlcad | but the scripts could just read the file |
| 03:55.41 | starseeker | that's a possibility |
| 03:56.10 | starseeker | I hadn't considered that in the original design |
| 03:57.03 | brlcad | that would eliminate the need for any cmakefiles() on anything installed -- only on things not built and not installed |
| 03:57.21 | starseeker | nods - which would match the EXTRA_DIST behavior? |
| 03:58.51 | starseeker | I'm not seeing an install_manifest.txt file... |
| 04:00.13 | starseeker | looks like cmake_install.cmake files |
| 04:02.06 | starseeker | ah ha! - there's the magic bit I was talking about earlier - file(RPATH_CHANGE ...) ! |
| 04:03.17 | starseeker | and that's probably why that trick can't be worked on 3rd party libs - it looks like the OLD_RPATH has to match the string length of the new one |
| 04:04.06 | starseeker | so any build we did of an ExternalProject where we wanted to suck in the output and manage it we'd have to make sure their build did the same thing as CMake for rpath |
| 04:04.28 | brlcad | looks like install_manifest.txt is not written until after install |
| 04:05.11 | starseeker | might be able to suck up all the cmake_install.cmake files and hunt up the paths, but that could be a bit of a messy parsing job... |
| 04:06.11 | brlcad | the rpath failures I run into happen on our own libs |
| 04:06.56 | starseeker | so "/usr/brlcad/dev-7.27.0/lib:$ORIGIN/../lib" must not be the right form somehow |
| 04:07.07 | starseeker | (for Linux anyway - I know Mac is different) |
| 04:07.16 | brlcad | agua:.build morrison$ bin/mged |
| 04:07.17 | brlcad | dyld: Library not loaded: @rpath/libtermio.20.dylib |
| 04:07.30 | brlcad | not the best example |
| 04:07.44 | starseeker | so @rpath isn't the right choice? |
| 04:09.30 | starseeker | hmm... that wouldn't work regardless - it either needs to know about the lib subpath from that location, or ../lib if it's treating ./bin as the rpath |
| 04:11.33 | starseeker | brlcad: in misc/CMake/RPath_Setup.cmake we set CMAKE_INSTALL_RPATH for APPLE - is that wrong? |
| 04:11.58 | starseeker | notes we're using a semicolon isntead of a colon for a path separator in the APPLE case... |
| 04:16.19 | brlcad | i'm not familiar with what exactly is conventional, only that there are several possible ways it can be set up |
| 04:16.28 | brlcad | lots of ways for it to not work ;) |
| 04:16.52 | starseeker | <snort> - sounds like opengl |
| 04:17.24 | brlcad | from what little I know, if @rpath is going to be used, then the rpath has to be set the right way to find the resource |
| 04:17.57 | brlcad | typically setting something like @executable_path/../lib |
| 04:18.20 | starseeker | nods - I think that's why we tried @loader_path |
| 04:19.03 | starseeker | but your binary showed @rpath - surprising |
| 04:19.21 | starseeker | unless that's from the build dir |
| 04:22.02 | starseeker | fwiw: https://cmake.org/Wiki/CMake_RPATH_handling |
| 04:22.02 | gcibot | [ CMake RPATH handling - KitwarePublic ] |
| 05:00.50 | *** join/#brlcad gabbar1947 (uid205515@gateway/web/irccloud.com/x-zjxnvizrlcgajpdb) |
| 06:57.59 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) |
| 08:35.44 | *** join/#brlcad KimK (~KimK@2001:579:d00c:800:4509:5129:54cd:48d0) |
| 08:40.52 | *** join/#brlcad merzo (~merzo@165-43-133-95.pool.ukrtel.net) |
| 13:33.10 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) |
| 13:45.56 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 13:47.48 | *** join/#brlcad yorik (~yorik@2804:431:f720:76fa:290:f5ff:fedc:3bb2) |
| 14:06.31 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 16:38.42 | *** join/#brlcad gabbar1947 (uid205515@gateway/web/irccloud.com/x-gyoymffsqdqwtyzp) |
| 16:53.42 | *** join/#brlcad DenisP (d40d70a2@gateway/web/freenode/ip.212.13.112.162) |
| 20:37.40 | *** join/#brlcad LordOfBikes (~armin@dslb-088-066-130-164.088.066.pools.vodafone-ip.de) |
| 22:57.01 | *** join/#brlcad Lletfrix (96f417fc@gateway/web/freenode/ip.150.244.23.252) |
| 23:01.08 | *** join/#brlcad Radicarian (~Radicaria@cpe-72-231-246-183.buffalo.res.rr.com) |
| 23:30.29 | *** join/#brlcad Notify (~notify@104.225.5.10) |
| 23:33.27 | *** join/#brlcad Notify (~notify@104.225.5.10) |
| 23:38.37 | Notify | 03BRL-CAD:starseeker * 70716 brlcad/trunk/src/nirt/main.cxx: Ah, that's right - we need to help bu_brlcad_root out explicitly. |
| 23:39.16 | Notify | 03BRL-CAD:starseeker * 70710 brlcad/trunk/regress/CMakeLists.txt: Add depends_list not just to overall regress target but to the specific regression target in question as well. |
| 23:39.26 | Notify | 03BRL-CAD:starseeker * 70713 brlcad/trunk/src/nirt/main.cxx: right, jumps don't like crossing initializations... |
| 23:40.17 | Notify | 03BRL-CAD:starseeker * 70712 brlcad/trunk/src/nirt/main.cxx: initialize |
| 23:55.42 | Notify | 03BRL-CAD:starseeker * 70719 brlcad/trunk/src/libanalyze/nirt.cxx: don't report gaps with gap_los <= 0 |
| 23:55.52 | Notify | 03BRL-CAD:starseeker * 70720 brlcad/trunk/regress/nirt.sh: Ah, that's what the GAP bits were in the regression diff - zero length reporting. |
| 23:56.23 | Notify | 03BRL-CAD:starseeker * 70721 brlcad/trunk/src/libanalyze/nirt.cxx: start stubbing in nirt diff command |
| 23:56.27 | Notify | 03BRL-CAD:starseeker * 70722 brlcad/trunk/src/libanalyze/nirt.cxx: allow comments |