| 01:19.35 | brlcad | starseeker: you still have to check if BU_EXPORTS is defined, else you can end up with a double-definition error |
| 01:19.55 | brlcad | er, BU_EXPORT |
| 01:22.37 | brlcad | the plural naming convention you pulled from opennurbs doesn't really apply to C code too (wasn't even necessary for opennurbs really, they're all the same macro) |
| 01:23.23 | brlcad | that one's not a big deal, of course, just not necessary |
| 01:24.20 | brlcad | maybe better to keep it consistent with opennurbs, that's fine too |
| 01:44.19 | CIA-61 | BRL-CAD: 03brlcad * r47605 10/brlcad/trunk/include/bu.h: make sure BU_EXPORT isn't already defined (so callers have some means to override), and error out if caller tries to import and export simultaneously. |
| 01:45.28 | CIA-61 | BRL-CAD: 03starseeker * r47606 10/brlcad/trunk/src/other/clipper/CMakeLists.txt: tweak clipper dll CMake logic. |
| 01:46.12 | starseeker | brlcad: this still feels funny to me somehow - explicitly calling out the import with a library specific flag, rather than using the more "global" BRLCAD_DLL seems to complicate the build logic quite a bit... |
| 01:46.14 | brlcad | that template should work well, how's it look? |
| 01:48.24 | brlcad | it does complicate matters some given each library has to be listed now, that was to be expected |
| 01:48.43 | brlcad | the problem and benefit of BRLCAD_DLL is that it was global |
| 01:48.59 | starseeker | brlcad: don't we still need that last else case with the empty BU_EXPORT ? |
| 01:49.03 | brlcad | it effectively meant *_IMPORT_DLL |
| 01:49.23 | starseeker | nods - finding myself thinking that wasn't such a bad idea, really... |
| 01:50.17 | brlcad | it's not a terrible idea but there are some downsides |
| 01:50.39 | brlcad | can't make a target that both exports and imports (plugins, libraries) |
| 01:51.22 | starseeker | brlcad: the "check for both definitions" case - will the logic ever get there? |
| 01:51.26 | brlcad | also means that there's cross-library pollution which prevents core library components from standing on their own |
| 01:51.29 | starseeker | shouldn't we be checking for that first? |
| 01:51.34 | brlcad | e.g., a libbu distribution akin to apr |
| 01:52.27 | brlcad | yeah, you're right |
| 01:52.31 | brlcad | on both counts |
| 01:52.57 | starseeker | one sec.. |
| 01:53.40 | brlcad | already fixed |
| 01:53.43 | CIA-61 | BRL-CAD: 03brlcad * r47607 10/brlcad/trunk/include/bu.h: starseeker right on both counts, need the empty BU_EXPORT so preprocessor makes the symbol go away and the error case needs to be tested first |
| 01:53.52 | CIA-61 | BRL-CAD: 03starseeker * r47608 10/brlcad/trunk/src/other/clipper/clipper.hpp: Upgrade the export macro logic for clipper (hopefully)... |
| 01:54.46 | starseeker | do we need BU_DLL_IMPORTS for a library that just links to librt? |
| 01:56.15 | brlcad | I don't remember the dll import/export rules that closely but I believe it depends how the library is defined |
| 01:56.38 | starseeker | mm. Well, I guess there's always the "try it and see" approach... |
| 01:56.41 | brlcad | if librt imports bu/bn and exports it's symbols, then I *think* it'll look for their dll when librt is loaded |
| 01:56.55 | starseeker | guess I'll be playing with the windows build again tomorrow (joy...) |
| 01:57.08 | brlcad | if it doesn't import, they get linked static and have to be resolved at compile time |
| 01:57.50 | starseeker | is trying to decide if librt should define an RT_DEFINES variable that holds BU_DLL_IMPORTS, BN_DLL_IMPORTS, etc... |
| 01:58.51 | brlcad | to do it "proper", I believe so |
| 01:59.25 | brlcad | rather, it needs to have them defined when librt is compiled .. but not necessarily when rt is compiled |
| 01:59.45 | brlcad | (but can) |
| 02:00.54 | brlcad | it needs them when rt is compiled if librt doesn't import them or if it also uses bu/bn too (which it does) |
| 02:02.08 | starseeker | needs to think tactically about how to set this up... would *really* suck to have to specify defines for executables per-exec instead of per directory |
| 02:03.53 | starseeker | probably need to for exec targets in the same directory as a library (test apps, etc.) since I can't go defining both, but (say) in util I would prefer to "define 'em all and let the compiler sort it out", so to speak |
| 02:12.14 | brlcad | starseeker: how about in a/the exec wrapper macro, have it look for variables matching the provided prefix -- then it's a naming convention all our libs use to define their vars in one place |
| 02:12.43 | starseeker | you mean use the library list to go after the variables? |
| 02:13.07 | starseeker | might work, except when we send in libraries that aren't ours... |
| 02:13.14 | brlcad | something like BUILD_MY_EXEC(rt, LIBRT LIBBN LIBBU) |
| 02:13.38 | starseeker | nods - BRLCAD_EXEC already has most of that |
| 02:13.46 | brlcad | which would then look for LIBRT_LIBS, LIBRT_CPPFLAGS, LIBRT_CFLAGS, LIBBN_LIBS, LIBBN_CPPFLAGS, LIBBN_CFLAGS, etc |
| 02:14.01 | starseeker | come to think of it... |
| 02:14.30 | starseeker | yeah, there might be a way to handle it there |
| 02:14.39 | starseeker | will look into it tomorrow |
| 02:14.51 | brlcad | LIBRT_LDFLAGS might be different from LIBRT_LIBS |
| 02:15.07 | brlcad | -lrt vs deps -lbn -lbu -ltcl ... |
| 02:15.19 | starseeker | cmake uses full paths for most things |
| 02:15.37 | starseeker | I can recognize when I'm looking at a full path (do so for the distcheck logic) |
| 02:15.49 | brlcad | path isn't the issue |
| 02:16.09 | brlcad | it's what libraries are added to the link line (and in what order if you want to get pedantic) |
| 02:16.26 | starseeker | I was thinking to use the list of libraries passed to BRLCAD_EXEC |
| 02:17.09 | starseeker | couple ideas, actually |
| 02:17.10 | brlcad | right, but then if libraries are self-aware of their dependencies (and they are) |
| 02:17.31 | brlcad | then you wouldn't need to specify all the (potential) dependencies any time a library is used |
| 02:17.58 | brlcad | like my example above -- kind of silly to list libbn and libbu since librt requires them |
| 02:18.11 | starseeker | oh, I see... |
| 02:18.14 | starseeker | different issue |
| 02:18.16 | brlcad | I couldv'e queried a var set by librt that told me bn, bu, etc |
| 02:18.36 | brlcad | that could greatly reduce redundancy throughout the build files |
| 02:19.06 | starseeker | nods... again less explicit though |
| 02:19.55 | brlcad | yet less error-prone too |
| 02:20.20 | brlcad | most devs don't think very long about what the actual libs are, they copy-paste another similar and add libs until it compiles |
| 02:20.40 | starseeker | true... the way we're trending here though, I'm going to *have* to write up some sort of detailed overview of what we're doing and why |
| 02:21.42 | starseeker | granting there are usually good reasons for what's being done, the further we get from "vanilla" the greater the hurdles become for a newbie to figure out what's happening and why |
| 02:22.08 | brlcad | already warranted with any custom macro -- it's obvious to you now because you wrote it and you still remember |
| 02:22.19 | starseeker | right |
| 02:22.38 | starseeker | in fact, for a lot of reasons I'd *better* do it now |
| 02:22.51 | starseeker | 's memory is... quirky |
| 02:23.13 | brlcad | might let you clean out some unnecessary macros too if you attempt to document them :) |
| 02:23.24 | brlcad | "oh yeah .. no longer need this one" |
| 02:23.48 | starseeker | heh - one of the fundamental arguments for literate programming, actually - "if I have to explain to a human what I'm trying to do, it's hard to hide the stupid parts :-P" |
| 02:24.00 | brlcad | it actually looks like you already do some sort of lib dependency expansion in BRLCAD_ADDEXEC |
| 02:24.32 | starseeker | uh... where are you looking? |
| 02:24.45 | brlcad | just looking at some binaries |
| 02:24.53 | brlcad | src/rt/CMakeLists.txt for example |
| 02:25.04 | brlcad | no mention of libbu, but guarantee they all use it |
| 02:25.29 | starseeker | actually that's probably just dumb luck |
| 02:25.35 | brlcad | heh |
| 02:25.53 | brlcad | enfeeds |
| 02:26.43 | starseeker | that list is passed pretty much as-is to target_link_libraries - did it mainly because it cut a few hundred add_executable/target_link_libraries/install triplets down to a one-liner |
| 02:27.10 | starseeker | s/a one-liner/one-liners/ |
| 02:27.20 | starseeker | yeah, gotta get outta here |
| 02:34.59 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) |
| 03:14.39 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) |
| 04:13.23 | CIA-61 | BRL-CAD: 03brlcad * r47609 10/brlcad/trunk/NEWS: nick added a new -r orientation option for the obj-g importer so you can specify 1/2/3 as values for unoriented, ccw, and cw orientation. |
| 05:26.30 | brlcad | starseeker: then I'd wonder if cmake is doing some expansion for us since the libs deps are listed with the libs and it expands correctly |
| 05:26.48 | brlcad | either way, somehow it's happening now, so that's a good sign |
| 05:27.12 | brlcad | installs cmake on gcc12 (openbsd sparc64) |
| 06:26.23 | *** join/#brlcad milamber (~devlin@d118-75-244-176.try.wideopenwest.com) |
| 07:42.45 | *** join/#brlcad merzo (~merzo@193.254.217.44) |
| 11:50.28 | CIA-61 | BRL-CAD: 03erikgreenwald * r47610 10/brlcad/trunk/include/bu.h: add missing #endif |
| 12:12.02 | ``Erik | hm, anne mccaffrey passed |
| 12:13.06 | ``Erik | doom3 source released, too |
| 13:36.21 | *** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net) |
| 16:37.07 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) |
| 16:37.07 | *** join/#brlcad 77CAA2ALN (~Technicus@DSLPool-net208-2.wctc.net) |
| 16:59.53 | CIA-61 | BRL-CAD: 03brlcad * r47611 10/brlcad/trunk/HACKING: gentoo folks moved brl-cad from sci-misc to media-gfx |
| 17:32.32 | brlcad | starseeker: any technical reason for the lack of blank lines in the cmake files? |
| 17:33.17 | starseeker | uh... not really |
| 17:33.31 | brlcad | k |
| 17:34.04 | starseeker | can't think of any offhand, although there may be a few cases where it matters (messages can't have stray end-of-line characters, for example...) |
| 17:34.29 | starseeker | or rather, they can but it messes with the formatting of the printed result |
| 17:41.19 | brlcad | that's fine, it's more whether there was some reason the logic or macros prohibited it |
| 17:42.37 | brlcad | like a C file without blank lines, a bit of a readability hindrance |
| 18:12.40 | CIA-61 | BRL-CAD: 03brlcad * r47612 10/brlcad/trunk/misc/CMake/ (BRLCAD_CompilerFlags.cmake CompilerFlags.cmake): relax the comparisons to substring matches |
| 18:14.22 | CIA-61 | BRL-CAD: 03brlcad * r47613 10/brlcad/trunk/CMakeLists.txt: similar, relax string comparisons. makes the unknown value test a little more robust |
| 18:18.12 | CIA-61 | BRL-CAD: 03brlcad * r47614 10/brlcad/trunk/misc/CMake/ThirdParty_TCL.cmake: trying to make some sense of the logic, add ws for readability |
| 18:29.43 | CIA-61 | BRL-CAD: 03brlcad * r47615 10/brlcad/trunk/misc/CMake/ThirdParty_TCL.cmake: simplify logic with relaxed substring searching |
| 18:41.02 | CIA-61 | BRL-CAD: 03brlcad * r47616 10/brlcad/trunk/misc/CMake/ThirdParty_TCL.cmake: more logic simplification. reorder IF/ELSE to avoid needing NOT, eliminate need for multiple comparisons by using substring comparison. reword cache string to indicate what action is being taken. |
| 18:42.44 | CIA-61 | BRL-CAD: 03starseeker * r47617 10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: |
| 18:42.44 | CIA-61 | BRL-CAD: Make an initial stab at support for library-wide usage of <LIB>_DLL_IMPORTS |
| 18:42.44 | CIA-61 | BRL-CAD: approach to building with MSVC. This is just hte macro logic and (for the |
| 18:42.44 | CIA-61 | BRL-CAD: moment, until the rest of this is worked out) the Windows build is almost |
| 18:42.44 | CIA-61 | BRL-CAD: certainly well and truly busted. |
| 18:48.13 | CIA-61 | BRL-CAD: 03starseeker * r47618 10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: remove debug prints for now. |
| 18:48.38 | CIA-61 | BRL-CAD: 03brlcad * r47619 10/brlcad/trunk/misc/CMake/ThirdParty.cmake: |
| 18:48.39 | CIA-61 | BRL-CAD: big restructuring in support of better reporting for whether bundled or sys libs |
| 18:48.39 | CIA-61 | BRL-CAD: are being used (and why). few cases weren't being handled and the string |
| 18:48.39 | CIA-61 | BRL-CAD: STREQUAL testing was causing cmake to report warnings. simplify string |
| 18:48.39 | CIA-61 | BRL-CAD: comparisons to substrings where applicable, reduce/reorder logic for clarity, |
| 18:48.39 | CIA-61 | BRL-CAD: and reword messages for consistency. |
| 18:52.33 | CIA-61 | BRL-CAD: 03starseeker * r47620 10/brlcad/trunk/misc/CMake/ThirdParty.cmake: stray duplicate comment line |
| 19:01.05 | CIA-61 | BRL-CAD: 03brlcad * r47621 10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: |
| 19:01.06 | CIA-61 | BRL-CAD: sync up with the same that was done for ThirdParty_Tcl.cmake using consistent |
| 19:01.06 | CIA-61 | BRL-CAD: printing statements (e.g., they might not be libs), relax to substring matching |
| 19:01.06 | CIA-61 | BRL-CAD: and reduced logic where we can. inject blank lines, separators, and comments |
| 19:01.06 | CIA-61 | BRL-CAD: for improved readabaility. |
| 19:09.19 | CIA-61 | BRL-CAD: 03starseeker * r47622 10/brlcad/trunk/include/ (22 files): Convert all the include headers to the <LIB>_DLL_IMPORTS format |
| 19:15.34 | CIA-61 | BRL-CAD: 03brlcad * r47623 10/brlcad/trunk/misc/CMake/ (33 files): |
| 19:15.34 | CIA-61 | BRL-CAD: as these are build system infrastructure and not actual build rules, they should |
| 19:15.34 | CIA-61 | BRL-CAD: include the requisite license headers and footers like any other source file. |
| 19:15.34 | CIA-61 | BRL-CAD: CMakeLists.txt don't need the wrapping, but macro files should |
| 19:26.11 | starseeker | brlcad: uh... - a lot of those Find* cmake macro files are based on other macro files, might want to be careful |
| 19:26.43 | starseeker | I'd have to dig back to make sure, but I think at least FindGL, FindX11 and FindYACC are based off of other macros |
| 19:27.02 | starseeker | I was waiting until things settled to do a thorough review of all of that |
| 19:38.47 | CIA-61 | BRL-CAD: 03brlcad * r47624 10/brlcad/trunk/autogen.sh: given the magnitude of impact, add a massive deprecation notice to begin our requisite deprecation notification process. refer them to the INSTALL file for now since there's not (yet?) an equivalent step |
| 19:39.23 | ``Erik | is seeing tons of cmake breakage right now, http://paste.lisp.org/display/126045 |
| 19:39.48 | brlcad | legally, that needs to happen asap and should have happened before a release was made with them |
| 19:40.17 | starseeker | k - I'll do a scan-through |
| 19:41.21 | brlcad | if they are mererly bundled for convenience, our header should be pulled or appended after theirs |
| 19:41.36 | starseeker | most of them are tweaked |
| 19:41.52 | starseeker | maybe all of them |
| 19:45.34 | brlcad | if it's not significant (like no logic changes, just additions of paths, removal of code, or just a couple lines) then our header is arguably not necessary |
| 19:47.19 | brlcad | ``Erik: your build failure looks related to r47617, work in progress .. though my build curiously worked, maybe I need to wipe cache to hit it |
| 19:47.58 | CIA-61 | BRL-CAD: 03starseeker * r47625 10/brlcad/trunk/misc/CMake/ (BRLCAD_Util.cmake CheckCFileRuns.cmake): Add the full license text for ChechCFileRuns.cmake - need to fix up the rest of the Kitware-based files to have the full BSD license txt. |
| 19:51.05 | brlcad | starseeker: do they use the same 3-clause license? |
| 19:53.03 | brlcad | if they do, there can just be 2 copyright lines instead of two copies of the text |
| 19:53.07 | starseeker | I believe so, give or take some minor wording and formatting... |
| 19:53.19 | starseeker | take a look at CheckCFileRuns.cmake, it's got both |
| 19:54.06 | CIA-61 | BRL-CAD: 03starseeker * r47626 10/brlcad/trunk/misc/CMake/CheckPrototypeExists.cmake: CheckPrototypeExists.cmake is from KDE, flesh out their BSD license and add a link to the file origin |
| 19:59.30 | CIA-61 | BRL-CAD: 03brlcad * r47627 10/brlcad/trunk/autogen.sh: move the deprecation section down so we're more sure echo -n work. still before anything is printed. |
| 20:00.51 | CIA-61 | BRL-CAD: 03starseeker * r47628 10/brlcad/trunk/misc/CMake/FindLEMON.cmake: FindLEMON was originally based on FindBISON - note that fact. Trying to stay close to the formatting of 'standard' CMake modules for those that we might have a hope of getting accepted into CMake proper at some point. |
| 20:03.11 | CIA-61 | BRL-CAD: 03starseeker * r47629 10/brlcad/trunk/misc/CMake/FindLEX.cmake: FindLEX.cmake is basically FindFLEX.cmake slightly generalized, and we already had ourselves listed in the 'standard' CMake BSD license. We may not even need this at all once the perplex/re2c/lemon work is complete... |
| 20:04.07 | starseeker | mutter... looks like I got some of them "properly" containing the full license, but missed a few |
| 20:04.44 | starseeker | I think in the GL/X11 case I might have been hoping to get the changes accepted back... ah well, no matter |
| 20:08.22 | CIA-61 | BRL-CAD: 03starseeker * r47630 10/brlcad/trunk/misc/CMake/ (FindGL.cmake FindX11.cmake FindZLIB.cmake): Add the rest of the 'full' licenses for the Kitware stuff - was hoping to commit these changes back to Kitware, but either way we'll have to hang on to these until we can require a modern enough CMake with the changes. |
| 20:15.29 | CIA-61 | BRL-CAD: 03brlcad * r47631 10/brlcad/trunk/configure.ac: add a similar massive deprecation notice with an annoying pause to configure. |
| 20:18.38 | CIA-61 | BRL-CAD: 03brlcad * r47632 10/brlcad/trunk/configure.ac: put a deprecation notice in the summary too since most people actually read it. |
| 20:23.06 | CIA-61 | BRL-CAD: 03brlcad * r47633 10/brlcad/trunk/Makefile.am: last one, repeat the deprecation warning when they run autotools make too. |
| 20:58.01 | CIA-61 | BRL-CAD: 03brlcad * r47634 10/brlcad/trunk/src/rt/view.c: |
| 20:58.01 | CIA-61 | BRL-CAD: can't compile due to cmake errors, but add an ambOffset parameter so you can |
| 20:58.01 | CIA-61 | BRL-CAD: control how far we pull away from a surface before shooting ambient rays. this |
| 20:58.01 | CIA-61 | BRL-CAD: is intended to help 'smooth out' shots against polygonal models where you get |
| 20:58.01 | CIA-61 | BRL-CAD: artifacts from hitting nearby/neighboring polygons. |
| 20:58.09 | starseeker | reflects that with the new open source SCL activity, he's probably going to need to beef up the FindSCL macro... |
| 21:02.04 | CIA-61 | BRL-CAD: 03brlcad * r47635 10/brlcad/trunk/src/rt/view.c: reduce the code duplication in ambient occlusion. pulling the branch out of both loops is inconsequential to performance in the long term. |
| 21:02.45 | CIA-61 | BRL-CAD: 03starseeker * r47636 10/brlcad/trunk/ (9 files in 9 dirs): This should get the build working again on non Windows platforms... also, start the process of clearing out BRLCAD_DLL |
| 21:04.18 | starseeker | brlcad: something else is busted - LEMON_EXECUTABLE is set to NOTFOUND |
| 21:06.10 | starseeker | and the global BRLCAD_BUNDLED_LIBS flag being set to bundled isn't turning everything on anymore |
| 21:20.18 | brlcad | curious, I didn't modify FindLEMON |
| 21:21.15 | brlcad | the BRLCAD_BUNDLED_LIBS isn't too surprising, couldn't test it with the breakage and the logic in BRLCAD_Util seems quite a mess.. |
| 21:40.14 | brlcad | looks like the problem is actually in ThirdParty, fix forthcoming |
| 21:42.22 | CIA-61 | BRL-CAD: 03bob1961 * r47637 10/brlcad/trunk/include/ged.h: Added gdps_scale to ged_data_polygon_state. |
| 21:52.05 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) |
| 21:58.59 | CIA-61 | BRL-CAD: 03brlcad * r47638 10/brlcad/trunk/misc/CMake/ThirdParty.cmake: getting a feel for how the aggregate BRLCAD_BUNDLED_LIBS was implemented. this makes ccmake report proper propagation of the parent BUNDLED (AUTO) setting (but still keying off AUTO at higher precedence than BUNDLED). |
| 22:35.56 | CIA-61 | BRL-CAD: 03brlcad * r47639 10/brlcad/trunk/misc/CMake/ThirdParty.cmake: |
| 22:35.57 | CIA-61 | BRL-CAD: this seems to get things back to working for the parent BRLCAD_BUNDLED_LIBS |
| 22:35.57 | CIA-61 | BRL-CAD: option. wasn't accounting for a stray STREQUAL in the parent logic and wasn't |
| 22:35.57 | CIA-61 | BRL-CAD: setting the ON/OFF variable consistently with the statements being printed |
| 22:48.01 | CIA-61 | BRL-CAD: 03brlcad * r47640 10/brlcad/trunk/misc/CMake/ThirdParty.cmake: |
| 22:48.01 | CIA-61 | BRL-CAD: if BRLCAD_BUNDLED_LIBS is set to SYSTEM and system-installed libs aren't |
| 22:48.01 | CIA-61 | BRL-CAD: available, it's not our problem -- let them proceed as if it was installed and |
| 22:48.01 | CIA-61 | BRL-CAD: found since that's what they asked for. perhaps useful for distribution |
| 22:48.01 | CIA-61 | BRL-CAD: debugging. |
| 22:52.34 | CIA-61 | BRL-CAD: 03brlcad * r47641 10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: mark BRLCAD_LIBS as advanced |
| 23:16.09 | CIA-61 | BRL-CAD: 03brlcad * r47642 10/brlcad/trunk/src/other/ (re2c/CMake/FindLEMON.cmake step/CMake/FindLEMON.cmake): sync top-level cmake file |
| 23:46.32 | CIA-61 | BRL-CAD: 03starseeker * r47643 10/brlcad/trunk/misc/CMake/ThirdParty.cmake: LIBRARY->EXECUTABLE |