| 00:46.55 | *** join/#brlcad kunigami_ (~kunigami@201.53.206.27) | |
| 01:39.59 | LainIwakuraX | starseeker: I can build BRL-CAD as a whole, if you check my patch it's the environment |
| 01:40.28 | starseeker | LainIwakuraX: what behavior do you see if you try the above? |
| 01:40.43 | LainIwakuraX | 1 sec |
| 01:41.00 | LainIwakuraX | yeah I get that too |
| 01:41.19 | starseeker | hrm |
| 01:42.12 | LainIwakuraX | how do I track down that sort of thing? =/ |
| 01:42.26 | starseeker | LainIwakuraX: gdb to start with |
| 01:42.52 | starseeker | figure out which call is producing the error, examine the data being fed in and why it's wiping out |
| 01:43.41 | LainIwakuraX | ah okay..first time working with gdb, I'll try to get this sorted |
| 01:43.56 | starseeker | it's a good skill to have :-) |
| 01:44.05 | starseeker | bt (backtrace) is quite useful |
| 01:44.44 | LainIwakuraX | ah I think I know what may be causing this bug, I can go fix it in source |
| 01:59.29 | LainIwakuraX | It looks like somewhere a std::string is being assigned to NULL when it probably should be "" |
| 01:59.43 | LainIwakuraX | this might take a few minutes to hunt down |
| 02:00.00 | starseeker | yeah, I thought it might be something like this: http://stackoverflow.com/questions/2407711/avoiding-improper-stdstring-initialization-with-null-const-char-using-g |
| 02:00.15 | starseeker | possibly SCLstring tolerated NULL as an initialization input... |
| 02:01.13 | LainIwakuraX | mhm. I found a few spots where I said "new std::string" and I changed those to initialize with "" for sure...but that didn't fix it |
| 02:01.29 | LainIwakuraX | I'll look around |
| 02:01.33 | starseeker | LainIwakuraX: I probably added a few of those myself... |
| 02:01.45 | LainIwakuraX | =x |
| 02:06.12 | CIA-62 | BRL-CAD: 03bhinesley * r45628 10/brlcad/trunk/src/libged/edit.c: |
| 02:06.12 | CIA-62 | BRL-CAD: Tracked down an issue where the last object wasn't being added, and the last |
| 02:06.12 | CIA-62 | BRL-CAD: node in the linked list was empty. Added support for numeric args (as abs coord, |
| 02:06.12 | CIA-62 | BRL-CAD: rel pos, or obj offset). Added/renamed constants for specifying coordinates, so |
| 02:06.12 | CIA-62 | BRL-CAD: that significance goes from left to right: |
| 02:06.13 | CIA-62 | BRL-CAD: '%s/EDIT\([[:upper:]]\)_COORD/EDIT_COORD_\1/g'. Several smaller, |
| 02:06.14 | CIA-62 | BRL-CAD: formatting/comment corrections. |
| 02:20.07 | LainIwakuraX | starseeker: If you find the spot where it's being initialized to null let me know, I haven't found it yet =( |
| 02:21.08 | starseeker | LainIwakuraX: it might even be a function of what it's parsing... my C++ foo is a bit weak, unfortunately |
| 02:21.38 | starseeker | probably very simple once we figure it out |
| 02:22.43 | LainIwakuraX | yeah, I know that when I see it I'll know it lol it's just finding it |
| 02:23.04 | LainIwakuraX | gdb gives me some info.. |
| 02:23.14 | LainIwakuraX | STEPWrapper::load(std::basic_string<char, std::char_traits<char>, std::allocator<char> >&) () |
| 02:23.28 | LainIwakuraX | I can't find STEPWrapper::load anywhere though |
| 02:24.42 | starseeker | wonders if ddd might be helpful... |
| 02:25.51 | bhinesley | spent about a hour wrestling ddd crashes today |
| 02:26.57 | bhinesley | LainIwakuraX: when in doubt: `find . -name "*.cpp" -exec grep "STEPWrapper::load" --with-filename {} \;` |
| 02:28.26 | bhinesley | or use ctags (even better) |
| 02:31.00 | LainIwakuraX | doesn't bring up anything =( |
| 02:31.22 | LainIwakuraX | I usually use: grep -H -r "<thing to search for>" . | grep -v svn | less |
| 02:32.42 | LainIwakuraX | oho...may have found it |
| 02:33.17 | LainIwakuraX | ugh it was in a different directory! I forgot two were involved in my editing process...this should be easier now |
| 02:43.36 | LainIwakuraX | starseeker: I've found the offending code I'm in the process of debugging it |
| 02:45.27 | starseeker | Registry::AddType, clstepcore/Registry.inline.cc:221 ? |
| 02:45.33 | LainIwakuraX | No |
| 02:45.44 | starseeker | nmm |
| 02:45.53 | LainIwakuraX | conv/step/STEPWrapper.cpp |
| 02:45.56 | LainIwakuraX | the load function |
| 02:45.57 | starseeker | ah |
| 03:15.06 | LainIwakuraX | okay the "offending" code was sort of offending, after travelling to 4 different functions I found the real offending code =P working on it.. |
| 03:36.04 | LainIwakuraX | starseeker: I fixed that bug, but now we get a segfault |
| 03:36.13 | LainIwakuraX | Reading Data from ../brlcad/src/other/step/data/ap203/cube1.p21... |
| 03:36.16 | LainIwakuraX | segfault |
| 03:38.20 | brlcad | starseeker, probably a little premature on the cross-post, no? :) |
| 03:39.00 | brlcad | best when collaborating to announce after we've fully vetted/tested ourselves |
| 03:41.04 | brlcad | interesting that I didn't run into a failure on my test |
| 03:41.27 | brlcad | tests that particular p21 file |
| 03:41.31 | LainIwakuraX | yes, it is curious but the bug I found would have indeed failed on something eventually =P |
| 03:41.35 | LainIwakuraX | the line said |
| 03:41.43 | LainIwakuraX | std::string schmn = NULL |
| 03:41.53 | LainIwakuraX | that won't work |
| 03:44.16 | brlcad | nods |
| 03:44.22 | brlcad | hm, BAD cmake rebuild |
| 03:48.55 | LainIwakuraX | Uhh |
| 03:49.05 | LainIwakuraX | I got it to work without a segfault |
| 03:49.20 | LainIwakuraX | it says Reading Data from ../brlcad/src/other/step/data/ap203/cube1.p21... |
| 03:49.33 | LainIwakuraX | Then it says basic_string::_S_construct null not valid |
| 03:49.38 | LainIwakuraX | then the program exits normally... |
| 03:49.45 | LainIwakuraX | (according to gdb) |
| 03:53.34 | bhinesley | brlcad: what gcc do most devs use? |
| 03:53.51 | brlcad | yeah, my test of the patch was quite flawed, two build systems got in the way of each other |
| 03:53.54 | bhinesley | I figured I'd install a lower version so I can use strict |
| 03:54.12 | brlcad | bhinesley: a pretty wide variety, actually |
| 03:54.20 | brlcad | just nobody on gcc 4.6 yet (except you ;) |
| 03:54.26 | bhinesley | heh |
| 03:54.35 | ``Erik | uses 4.2 (fbsd standard) and 4.1 (apple standard) mostly |
| 03:54.36 | brlcad | it's been out for about a month |
| 03:54.54 | brlcad | bhinesley: have you rebuilt lately? |
| 03:55.15 | bhinesley | doing so now, but strict is off |
| 03:55.20 | brlcad | I fixed a slew of the ones abhit reported over the weekend, about a thousand issues |
| 03:55.27 | bhinesley | nice |
| 03:55.28 | brlcad | save a full build log |
| 03:55.46 | brlcad | make 2>&1 | tee build.log |
| 03:56.02 | bhinesley | okay, in just a bit |
| 03:56.29 | bhinesley | I just did a svn update... you guys were busy over the weekend :) |
| 03:56.38 | brlcad | I'm sure I didn't get everything since I don't have the compiler warning if I missed anything, but it should be far better |
| 03:56.51 | bhinesley | nods |
| 03:56.57 | ``Erik | brlcad: I put gcc4.7 on crit if you get the urge to play |
| 03:56.59 | bhinesley | I saw the logs |
| 03:57.09 | brlcad | most oft he things it's warning about are really trivial to fix |
| 03:57.26 | brlcad | vars not being used, print specifier consistency |
| 03:57.37 | brlcad | ``Erik: good to know, thanks |
| 03:57.51 | brlcad | reproduces the step-g failure |
| 03:58.23 | LainIwakuraX | brlcad: I have that fixed to not crash, cleaning up some things and submitting a patch |
| 04:01.44 | brlcad | LainIwakuraX: okay, great .. so I shouldn't go debugging |
| 04:08.36 | LainIwakuraX | brlcad: Patch is submitted...like I said in the notes though even though there isn't a crash I still don't know if it "works" |
| 04:08.54 | LainIwakuraX | If you could test that it'd be great =) I haven't used this program before, I don't know what to expect from it |
| 04:11.32 | brlcad | LainIwakuraX: what was the issue with STEPWrapper::load() ? |
| 04:12.06 | brlcad | changing from a std::string& to a std::string merely makes it make a copy (alloc) |
| 04:12.27 | brlcad | if that fixes a crash, some further investigating is probably warranted |
| 04:12.35 | LainIwakuraX | brlcad: Uh, that shouldn't have been changed- that was a test |
| 04:12.46 | brlcad | starseeker: debugging is not enabled by default? |
| 04:13.30 | brlcad | patch files are text, you should review them before posting .. just like you should review the diff before a commit too |
| 04:13.42 | brlcad | svn revert will restore a file to an unedited state |
| 04:14.09 | brlcad | "svn diff | less" and you can manually inspect what changes are getting included |
| 04:14.41 | LainIwakuraX | brlcad: if you give me two seconds I'll upload a better patch file |
| 04:14.45 | brlcad | k |
| 04:15.20 | brlcad | also make sure you're up-to-date (svn up) so the line offsets are correct |
| 04:17.20 | LainIwakuraX | hm |
| 04:17.36 | LainIwakuraX | I put my &'s on string, not the variable name.. |
| 04:18.05 | LainIwakuraX | it was string &step_file but now it's string& step_file..that's fine though |
| 04:18.20 | brlcad | they are equivalent |
| 04:18.24 | LainIwakuraX | I know |
| 04:18.31 | LainIwakuraX | that's why I said it's fine =P |
| 04:18.36 | brlcad | heh |
| 04:19.22 | brlcad | convention is usually to bind the type together with c++ but separate them for c |
| 04:19.34 | brlcad | so string& is peachy for scl |
| 04:19.39 | LainIwakuraX | ah |
| 04:19.48 | LainIwakuraX | k the better patch is up there |
| 04:20.06 | brlcad | gets |
| 04:21.54 | LainIwakuraX | I'll brb in ~10 mins, let me know how it goes |
| 04:22.25 | brlcad | testing now |
| 04:23.18 | brlcad | so it no longer hard-crashes, but it still exits due to a NULL string |
| 04:24.06 | brlcad | looks like it's maybe on a static |
| 04:25.46 | brlcad | will have to debug more tomorrow.. because *somebody* thought defaulting to no debug symbol compilation was a good idea *ahem* :) |
| 04:26.41 | brlcad | basically, every place a std::string is instantiated, it needs to be initialized to be compatible with what it was assuming |
| 04:32.02 | CIA-62 | BRL-CAD: 03brlcad * r45629 10/brlcad/trunk/src/other/step/src/ (5 files in 2 dirs): |
| 04:32.02 | CIA-62 | BRL-CAD: apply sf patch 3377904 (fixed a bug with step-g and null strings) from Zach |
| 04:32.02 | CIA-62 | BRL-CAD: Easterbrook ( lainiwakurax ) which indeed fixes the step-g crash, but still |
| 04:32.02 | CIA-62 | BRL-CAD: doesn't restore it to a functional status. aborts with a message about a NULL |
| 04:32.02 | CIA-62 | BRL-CAD: std::string. |
| 04:32.23 | LainIwakuraX | I'm back |
| 04:32.59 | LainIwakuraX | brlcad: How can we test this if it's failing without...uh, any issues? |
| 04:33.09 | LainIwakuraX | I can't do a backtrace in gdb |
| 04:33.51 | brlcad | for one, step-g produces a ton of output when it's working correctly ;) |
| 04:34.31 | brlcad | you can put a breakpoint on main (b main) and step forward ('n' command for "next instruction") |
| 04:34.51 | brlcad | or "b whatever" to break on any arbitrary function |
| 04:35.08 | brlcad | it'll take me a while to get a rebuild with debugging enabled myself |
| 04:36.43 | LainIwakuraX | brlcad: Is it cool if we tackle this tomorrow then? It's 12:30a.m here and I have a few more things to do before bed =x |
| 04:37.55 | brlcad | we're apparently on the same coast, sounds good to me |
| 04:38.50 | LainIwakuraX | k, see you then. I'm usually awake in the afternoon lol |
| 04:42.03 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 04:55.02 | bhinesley | brlcad: build.log http://paste.pocoo.org/show/446487/ |
| 04:56.03 | bhinesley | er, you probably wanted me to use 'make -k' |
| 05:00.42 | bhinesley | 'make -k' build log: http://paste.pocoo.org/show/446495/ |
| 05:34.01 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:26.18 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 07:10.26 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 08:47.51 | CIA-62 | BRL-CAD: 03Abby Moss 07http://brlcad.org * r3037 10/wiki/Main_Page: |
| 08:47.59 | CIA-62 | BRL-CAD: 03d_rossberg * r45630 10/brlcad/trunk/src/libbu/CMakeLists.txt: Windows MSVC: because of GetMappedFileName() in fchmod.c link with psapi.lib |
| 08:50.13 | *** join/#brlcad Stattrav (~Stattrav@122.167.229.132) | |
| 08:50.13 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 09:33.19 | *** join/#brlcad DarkCalf (DC@173.231.40.98) | |
| 11:42.12 | starseeker | brlcad: yeah, premature. Was going on your initial report that it worked |
| 11:47.55 | starseeker | starseeker: I'll hold off until we have it working next time |
| 11:47.59 | starseeker | er brlcad rather |
| 11:48.05 | starseeker | is talking to himself |
| 11:58.57 | brlcad | mm, you sent the message before I'd even started testing :) |
| 12:01.07 | brlcad | 2pm, didn't test and commit till 5pm .. but even if if it was golden, I'd suggest we send them revision numbers at stepping points |
| 12:01.17 | brlcad | bhinesley: thanks |
| 12:20.58 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r3038 10/wiki/Main_Page: Reverted edits by [[Special:Contributions/Abby Moss|Abby Moss]] ([[User talk:Abby Moss|Talk]]); changed back to last version by [[User:Sean|Sean]] |
| 12:21.20 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Abby Moss]] with an expiry time of infinite (account creation disabled, e-mail blocked) |
| 12:27.48 | CIA-62 | BRL-CAD: 03brlcad * r45631 10/brlcad/trunk/src/ (CMakeLists.txt libbu/CMakeLists.txt): set PSAPI_LIB variable so we can consolidate into the same since MSVC block |
| 12:30.28 | d_rossberg | brlcad: setting of the MSVC libraries isn't very consistent in the cmake files, see e.g. librt |
| 12:34.54 | brlcad | nods |
| 12:35.57 | CIA-62 | BRL-CAD: 03brlcad * r45632 10/brlcad/trunk/src/other/step/src/ (62 files in 7 dirs): |
| 12:35.57 | CIA-62 | BRL-CAD: eliminate all of the __OSTORE__ sections. considered dead code because there |
| 12:35.57 | CIA-62 | BRL-CAD: was no managed way to enable those code sections. appears to be a binding to a |
| 12:35.57 | CIA-62 | BRL-CAD: commercial API (Progress Software Corp's ObjectStore product), so remove in |
| 12:35.57 | CIA-62 | BRL-CAD: favor of simplified code maintenance and reduced complexity. removes almost 3k |
| 12:35.58 | CIA-62 | BRL-CAD: lines of code. |
| 12:36.08 | brlcad | d_rossberg: I know, the evils of letting a "platform" identifier in for a few things makes it really easy to abuse/reuse in more places than it should |
| 12:36.51 | *** join/#brlcad kunigami_ (~kunigami@201.53.206.27) | |
| 12:41.00 | CIA-62 | BRL-CAD: 03brlcad * r45633 10/brlcad/trunk/src/ (CMakeLists.txt librt/CMakeLists.txt): similar to libbu, consolidate the msvc library settings into the same place where winsock gets set, consistently just use library names in ADDLIB |
| 12:49.09 | brlcad | I'm sure the intention was to go back one day, some day, and fix them proper when they were first written... ;) |
| 12:53.18 | CIA-62 | BRL-CAD: 03brlcad * r45634 10/brlcad/trunk/CMakeLists.txt: typo? |
| 12:54.10 | d_rossberg | OK |
| 13:00.31 | CIA-62 | BRL-CAD: 03brlcad * r45635 10/brlcad/trunk/CMakeLists.txt: |
| 13:00.31 | CIA-62 | BRL-CAD: consistently default all builds (particularly fresh svn checkouts) to a system |
| 13:00.32 | CIA-62 | BRL-CAD: install into /usr/brlcad using rel- for releases and dev- for developer builds. |
| 13:00.32 | CIA-62 | BRL-CAD: could probably even just key off of the patch number but leave as-is for now. |
| 13:00.32 | CIA-62 | BRL-CAD: this will probably require windows to set the install prefix given there usually |
| 13:00.32 | CIA-62 | BRL-CAD: is no /usr path but that is needed for windows anyways for release builds. |
| 13:01.29 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 13:01.46 | CIA-62 | BRL-CAD: 03brlcad * r45636 10/brlcad/trunk/TODO: remove all of the MSVC platform sections in the CMakeLists.txt files |
| 13:01.49 | brlcad | abhi2011: application received! |
| 13:08.44 | CIA-62 | BRL-CAD: 03brlcad * r45637 10/brlcad/trunk/TODO: demote a lot of tasks that won't likely be completed by next month. leave most of the build-related tasks since we're moving towards eventual autotools removal. |
| 13:09.37 | CIA-62 | BRL-CAD: 03brlcad * r45638 10/brlcad/trunk/TODO: cp command now redraws once again, along with a slew of other ged commands. if one of the argv parameters is displayed, it gets redrawn. |
| 13:14.57 | CIA-62 | BRL-CAD: 03brlcad * r45639 10/brlcad/trunk/BUGS: rt displays output once again, button bindings should be fixed, and rt after cd in mged on windows should work once again |
| 13:34.45 | CIA-62 | BRL-CAD: 03brlcad * r45640 10/brlcad/trunk/src/conv/step/step-g.cpp: ws style |
| 13:39.02 | CIA-62 | BRL-CAD: 03brlcad * r45641 10/brlcad/trunk/src/conv/step/ (6 files): |
| 13:39.02 | CIA-62 | BRL-CAD: got step-g to crash with a couple input test files, one crashing on Surface.h:48 |
| 13:39.02 | CIA-62 | BRL-CAD: implying some stack corruption or memory issue. so add protections all the way |
| 13:39.02 | CIA-62 | BRL-CAD: up the stack to make sure we didn't run out of memory or dereference a null |
| 13:39.02 | CIA-62 | BRL-CAD: pointer at some point. probably doesn't get to the heart of the crash, but |
| 13:39.02 | CIA-62 | BRL-CAD: should help isolate it and help halt sooner (and hopefully more gracefully than |
| 13:39.03 | CIA-62 | BRL-CAD: a crash). |
| 13:40.34 | CIA-62 | BRL-CAD: 03brlcad * r45642 10/brlcad/trunk/src/other/libpng/depcomp: depcomp is generated, remove from checkin |
| 13:42.35 | CIA-62 | BRL-CAD: 03brlcad * r45643 10/brlcad/trunk/src/other/libpng/config.h.in: autoheader made config.h.in, also remove |
| 13:42.44 | abhi2011 | thanks brlcad :) |
| 13:50.51 | CIA-62 | BRL-CAD: 03brlcad * r45644 10/brlcad/trunk/TODO: libpng needs backported fixes for autotools |
| 14:30.38 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 14:35.28 | starseeker | brlcad: ah, right - I thought they might want to play with the patch at that point. Was hoping they might do some of the work for us :-P |
| 14:36.48 | starseeker | brlcad: you really want to go into /usr/brlcad for dev builds by default? |
| 14:36.57 | starseeker | was very intentionally staying out of system dirs |
| 14:47.00 | CIA-62 | BRL-CAD: 03starseeker * r45645 10/brlcad/trunk/CMakeLists.txt: Wasn't a typo - to do what that previous edit looked like it wanted to do, ELSEIF (I think) is what is needed. Instead of that, just turn on DEBUG_BUILD for everything except Release |
| 14:47.26 | starseeker | isn't even sure how to test for Microsoft system libraries... |
| 14:49.16 | CIA-62 | BRL-CAD: 03starseeker * r45646 10/brlcad/trunk/misc/enigma/enigma.c: clang didn't like argc not having a type |
| 14:52.13 | starseeker | isn't sure he agrees with making the MSVC specific stuff into tests - that'll just lengthen the configure process even further, and the probability is very high that those options will be useless everywhere else (or even worse, might mean something altogether different, given how foreign MSVC is to other environments) |
| 14:58.22 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 15:04.02 | CIA-62 | BRL-CAD: 03starseeker * r45647 10/brlcad/trunk/src/other/libpng/CMakeLists.txt: Add the new, improved libpng CMakeLists.txt macros from our 1.4.x build - this is what should go back to libpng as a proposed patch. |
| 15:21.22 | CIA-62 | BRL-CAD: 03starseeker * r45648 10/brlcad/trunk/src/other/ (3 files in 2 dirs): OK, I think we've gotten rid of 'em now - try again to remove scl_string |
| 15:33.24 | brlcad | starseeker: having a default checkout that doesn't perform a system install breaks convention in itself, /usr/local is usually the default which is where our /usr/brlcad becomes preferred so we're protected |
| 15:35.50 | brlcad | there's also a portability issue for some platforms (like aix, hpux, some linux, and few others) where binaries are not relocatable by default, so if you installed into your home directory, you can't just copy that (e.g., into /usr/brlcad) and have it work, have to set library paths and our brlcad root/data paths in the environment |
| 15:36.57 | starseeker | right, but I had figured when doing a debug (e.g. development) build installing in /usr/brlcad was less likely to be important (I personally never install there while doing development) |
| 15:36.59 | brlcad | plus it matches our project history, we consistently install into /usr/brlcad by default -- others can set a prefix |
| 15:37.40 | brlcad | to a user checking out from svn, there is a surprise that I just did a checkout, compile, install ... and it's not installed |
| 15:37.57 | brlcad | at least not where I'd expect it, not in a system location |
| 15:38.26 | starseeker | well... I suppose I could go back to defaulting to /usr/brlcad if CMAKE_BUILD_TYPE is not set... |
| 15:38.38 | brlcad | and you should be installing into /usr/brlcad ... else we end up with mysterious path problems when mged is attempting to load :) |
| 15:39.11 | starseeker | <snort> I would have thought installing somewhere other than /usr/brlcad would be MORE likely to highlight path problems, not less |
| 15:39.31 | brlcad | release going to /usr/brlcad/rel-VERSION and non-release going to /usr/brlcad/dev-VERSION is actually a nice consistency |
| 15:40.10 | brlcad | it did highlight problems.. the /usr/brlcad one didn't work :) |
| 15:40.16 | starseeker | nods - I can live with it, I just liked the idea of doing a checkout/build/install for development purposes without having to worry about system permissions |
| 15:41.39 | brlcad | end-user convenience should always take priority over developer convenience |
| 15:41.48 | brlcad | i'm a stout believer in that stance |
| 15:42.03 | starseeker | end users use RPMs or package managers :-P |
| 15:42.05 | brlcad | users get the shaft WAY too often in open source |
| 15:42.14 | brlcad | end users include anyone that's not a developer |
| 15:43.57 | brlcad | which includes users that checkout from the repository, or that would pick up a nightly source tarball... |
| 15:44.47 | brlcad | still, it's more just about not *intentionally* making things more difficult or compilicated when it's just a matter of convention or a few keystrokes more or a few more lines in build files to help make it easier |
| 15:48.34 | starseeker | shrugs. OK, I can live with dev-VERSION. |
| 15:49.29 | brlcad | so next topic? :) |
| 15:49.41 | brlcad | I'd expect microsoft system libs are tested for like any other library, no? |
| 15:49.49 | starseeker | hmm... idea. If I look for a BRL-CAD_build_settings.cmake file early in the CMakeLists.txt and load it if found, that would provide a way for a developer to customize things without disturbing end-users - would that be OK? |
| 15:50.35 | starseeker | brlcad: I suppose there might be a way to test for Microsoft librarys - I have no idea if the standard CMake mechanisms will do it though. |
| 15:51.12 | starseeker | Maybe we can wrap that set of tests in in MSVC conditional in the toplevel so we don't waste time with them on Mac/Linux at least? |
| 15:51.28 | brlcad | the issue is really what happens to a default user -- if someone actively sets up their config, that's akin to setting -Dvar=val or --prefix options and it's peachy keen |
| 15:51.54 | starseeker | awesome - I mainly want a way to minimize the number of config options/flags I have to pass over and over |
| 15:52.01 | brlcad | nods |
| 15:52.06 | brlcad | perfectly reasonable |
| 15:52.18 | brlcad | when was the last time you built the linux kernel (by hand)? |
| 15:52.24 | starseeker | the configure wrapper helps some there, but not really enough |
| 15:52.46 | brlcad | they had a pretty neat setup |
| 15:52.46 | starseeker | brlcad: define by hand - using their grapical config tool, or item-by-item? |
| 15:52.55 | brlcad | either really |
| 15:53.00 | brlcad | so you config the kernel, right? |
| 15:53.07 | brlcad | it ends up with a config file with all your settings |
| 15:53.16 | starseeker | yeah - usually whenever I get a new machine, so the gentoo kernel has the right modules |
| 15:53.20 | starseeker | right |
| 15:53.23 | brlcad | so even after config is done, you can go in, edit it, and run with those new settings |
| 15:53.37 | brlcad | something like that would be awesome |
| 15:53.58 | starseeker | nods - CMakeCache.txt does some of that, but not "up front" before a configure is run |
| 15:54.13 | brlcad | "cmake path" resulting in a .GLOBAL would be fun :) |
| 15:54.43 | starseeker | brlcad: in case I haven't mentioned it - you can hand edit the CMakeCache.txt file in the toplevel build to change options |
| 15:54.44 | brlcad | I think linux uses .CONFIG? |
| 15:55.20 | brlcad | it's configurable iirc, but defaults to something like that |
| 15:55.23 | starseeker | for post configure settings caching, CMakeCache.txt should have everything you could want |
| 15:56.03 | brlcad | so common use case that comes to mind .. we have all these tests for opengl |
| 15:56.12 | brlcad | user runs cmake, it fails the test |
| 15:56.16 | brlcad | but they know they have it |
| 15:56.58 | brlcad | sure enough, "make" just skips our ogl code; so they go in and edit the build config file, turn ogl on, re-run make .. and it builds |
| 15:57.04 | brlcad | something like that doable? |
| 15:57.21 | starseeker | yeah - that's what I usually do if I forget to turn something on |
| 15:57.44 | brlcad | so maybe just a better name than CMakeCache.txt :) |
| 15:58.01 | brlcad | or is that literally every function/header/feature test? |
| 15:58.37 | starseeker | brlcad: heh - hardwired, I think. But my point wasn't that I want that ability AFTER running cmake - I want to always pass (say) BRLCAD-ENABLE_ALL_LOCAL_LIBS=ON without having to type it every time, and without having to edit the cache file |
| 15:59.01 | brlcad | blocking the MSVC-only tests would be fine -- that's what I was thinking -- it's more that they should still be tested for like any other feature since they're just as ephemeral as any of the other libs |
| 15:59.25 | brlcad | winsock2, for example, is one of several incarnations of the windows networking interface |
| 16:00.41 | brlcad | starseeker: right, I got that -- but I figured that should just be a matter of (re-)loading it during cmake for defaults as well as during make to drive compilation |
| 16:01.08 | brlcad | so if CMakeCache.txt is hardwired, maybe we could output just the high-level options we care about to a different config file |
| 16:01.15 | starseeker | nods |
| 16:01.16 | brlcad | basically, the summary items |
| 16:01.21 | starseeker | let me experiment a bit |
| 16:01.59 | brlcad | likes the .GLOBAL/_GLOBAL inside "joke" |
| 16:02.02 | starseeker | this is over and above anything autotools ever provided (unless you count storing a configure line in a .sh file) so it's probably not a high priority - I'm just lazy about typing options :-P |
| 16:02.18 | brlcad | it is above it |
| 16:02.27 | brlcad | something I thought about adding a few times, though |
| 16:02.29 | starseeker | winces a little - maybe BRL-CAD_CONFIG.GLOBAL |
| 16:03.15 | brlcad | users already know they're in a brl-cad checkout, no need to remind them in all the file names :) |
| 16:03.38 | brlcad | even just CONFIG would probably be fine |
| 16:03.59 | starseeker | hadn't envisioned putting it in the checkout or even the build dir - this would be something that could be stored (optionally) in the parent directory |
| 16:04.28 | brlcad | I didn't mean put it in checkout |
| 16:04.40 | brlcad | file generated by cmake, reused by cmake and make |
| 16:05.00 | starseeker | shakes his head - I want to be able to use this to set options before I ever run CMake at all |
| 16:05.36 | brlcad | nothing I've said precludes that ??? |
| 16:06.00 | starseeker | cmake can't generate a file in the parent directory - oh, wait |
| 16:06.08 | starseeker | hmm. |
| 16:06.30 | brlcad | I presume by parent you mean user's home dir or something? |
| 16:06.35 | starseeker | basically |
| 16:06.49 | starseeker | one config file to rule them all :-P |
| 16:07.14 | starseeker | I guess we can check for and read that in, then generate something in the build directory for subsequent use in that run |
| 16:07.23 | brlcad | hm, that's a little odd |
| 16:07.45 | starseeker | brlcad: might be odd, but it would be completely harmless unless someone specifically sought it out and set it up |
| 16:08.08 | brlcad | sure, but it can be turned into a proper feature and achieve the same result |
| 16:08.48 | starseeker | uh... I guess I'm not following |
| 16:09.13 | brlcad | still thinking to the linux kernel as a model to follow |
| 16:09.44 | brlcad | I can craft up my own CONFIG file and specify it to the build (from wherever really) |
| 16:10.01 | brlcad | or I can run the interactive build (cmake .) and it'll dump out a CONFIG file for me |
| 16:10.15 | brlcad | which I can subsequently reuse if I wanted (from anywhere) |
| 16:10.21 | brlcad | edit to heart's content |
| 16:10.32 | brlcad | or ignore and the build just uses it for settings |
| 16:11.12 | brlcad | familiar, time tested, pretty simple |
| 16:16.42 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:26.45 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:34.55 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.146.20) | |
| 17:09.59 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 17:34.55 | CIA-62 | BRL-CAD: 03starseeker * r45649 10/brlcad/trunk/CMakeLists.txt: |
| 17:34.55 | CIA-62 | BRL-CAD: Add a dirt-simple way to allow developers to inject their own default settings |
| 17:34.55 | CIA-62 | BRL-CAD: into the CMake process - eventually we may want to do something more |
| 17:34.55 | CIA-62 | BRL-CAD: sophisticated, but this is a simple way to do things like enable all local |
| 17:34.55 | CIA-62 | BRL-CAD: libraries by default. |
| 18:34.40 | brlcad | starseeker: what does it mean to be a release build? |
| 18:35.03 | brlcad | is that merely synonymous with non-debug? .. or what if I wanted a debuggable release build? |
| 19:30.47 | brlcad | starseeker: so unexpected behavior .. cd brlcad ; mkdir .cmake ; cd .cmake ; cmake .. ; echo "why aren't there any build files output here?" |
| 19:56.43 | *** join/#brlcad kunigami_ (~kunigami@201.53.206.27) | |
| 20:08.40 | *** join/#brlcad tharis20_ (~tharis@2.83.244.20) | |
| 21:10.19 | starseeker | starseeker: right now it's mostly /usr/brlcad/rel* paths and turning on optimization by default |
| 21:11.20 | starseeker | formally acknowledges not outputing build files in expected directory if there is a CMakeCache.txt file in the source dir is Not Good |
| 21:11.33 | starseeker | brlcad: right now it's mostly /usr/brlcad/rel* paths and turning on optimization by default |
| 21:11.38 | starseeker | is talking to himself again |
| 23:29.45 | *** join/#brlcad LainIwakuraX (~yuki@d24-57-80-191.home.cgocable.net) | |
| 23:32.42 | LainIwakuraX | brlcad: I see a lot of updates to step stuff in the latest rev. sorry I wasn't here in the afternoon to help =( |
| 23:46.28 | tharis20 | brlcad: in the expectations it is said that it is expected students to work 40 hours a week, the same as a full-time job |
| 23:46.50 | tharis20 | but SOCIS extends until the end of October and classes begin in mid-September |