IRC log for #brlcad on 20080323

01:12.07 brlcad updates the ideas list http://brlcad.org/wiki/Google_Summer_of_Code/Project_Ideas
01:12.20 brlcad it's closer to a "final initial" form now
02:22.51 *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6)
04:01.54 hippieindamakin8 nice list man
04:02.47 brlcad coming together bit by bit
04:03.01 yukonbob looks
04:07.34 yukonbob brlcad: interested in my latest build issues, or should I plug away solo?
04:10.07 yukonbob http://pastebin.ca/953538
04:22.06 yukonbob that test code needs an "#include <stdlib.h>" for exit()
05:09.24 yukonbob (/me assumes introduced at 30538, configure.ac)? But seems completely ac-generated... wft?
05:09.30 yukonbob *wtf
05:10.17 brlcad yukonbob: yeah weird
05:10.43 brlcad the sanity check is missing a header it seems .. that C mode is fine with but C++ mode is adament about
05:11.00 brlcad there was a new C++ mode sanity check added just a couple days ago (right after 7.12.0
05:12.34 CIA-33 BRL-CAD: 03brlcad * r30554 10/brlcad/trunk/m4/compiler.m4: bah, need stdlib.h for exit().. C++ sanity check seems insistent on needing it.
05:12.42 yukonbob ya -- is BC_SANITY_CHECK a builtin, or user-supplied
05:13.29 brlcad all BC_'s are brl-cad macros in m4/
05:13.33 yukonbob whatever you just modded could stand to lose stdio, I believe, too -- probably somebody's finger-memory got the best of them at that point..
05:13.44 brlcad true
05:13.56 brlcad stdio was providing exit() on older glibc
05:14.46 CIA-33 BRL-CAD: 03brlcad * r30555 10/brlcad/trunk/m4/compiler.m4: don't need stdio.h
05:14.47 yukonbob doesn't remember that; if it does/did, so be it, but that won't matter on *BSD, etc. They'll need stdlib
05:15.39 yukonbob might end up learning autotools if he's not careful here
05:16.46 yukonbob does my commit-bit extend to code as well, or strictly doc?
05:17.00 brlcad to anything
05:17.01 yukonbob hasn't tried, and we've not talked about this
05:17.32 brlcad don't worry about mixing up other stuff, dive right in ;)
05:19.07 yukonbob alright; I'm still getting that itcl error that was the initial issue, but working on other stuff too (like the above c++); autogen.sh isn't liking my build env (pkgsrc), but doesn't mind a by-hand run from the shell; I'll explore that too -- (autogen itself hasn't changed, but it must include some changed files, because it used to work np)
05:19.14 brlcad all commits are reviewed anyways and announced here so it's easy enough to see what's going on
05:19.43 yukonbob nods
05:19.46 brlcad does "sh autogen.sh -v" show anything?
05:21.11 yukonbob can check; in the "environment" build, it chokes on autoreconf, then tries it's "manual config" (or whatever) and chokes on that, too.
05:21.44 yukonbob by-hand, everything works fine... which is strange to me, but I'll track down what the offending difference is...
05:22.13 brlcad -v will show the exact commands it's trying to run
05:22.29 yukonbob nods, add to wrapping-Makefile
05:22.50 yukonbob *adds
05:23.23 brlcad which is a version check for autoconf, automake, and libtool .. then something like "autoreconf -v -i -s" .. and then individual steps if that fails
05:24.22 yukonbob _has_ autoreconf, and even supplied it directly via the AUTORECONF env var, but no dice
05:25.09 yukonbob runs build
05:25.10 brlcad autoreconf can fail for lots of reasons
05:25.46 brlcad that's one of many reasons why autogen.sh exists in the first place
05:25.59 yukonbob out of comlete curiousity, how much effort do you think it'd take to replace auto* w/ cmake (for example) and what would keep one from doing that, besides the manpower?
05:26.09 yukonbob *complete
05:27.07 brlcad manpower to replicate the entire build system faithfully, I'd expect it'd take many months
05:27.16 brlcad of non-stop effort
05:27.29 yukonbob !
05:28.13 brlcad the conversion to autotools took a long time, about that long, and there wasn't really any complicated road blocks
05:28.35 yukonbob everybody likes to complain about "autohell"; what's your take on it?
05:28.42 brlcad it just takes a lot of work to specify the build rules for 400+ binary targets, the 24 or so libs, and various types of data files and subdependencies
05:30.31 brlcad autohell is the way it is for many reasons
05:31.27 brlcad it does what it does the way it does it in order to provide strict portability constraints (that really cannot be easily provided most any other way without adding dependencies)
05:32.52 yukonbob have you ever played w/ scons (python), or cmake?
05:32.58 brlcad yep
05:34.16 brlcad i actually rather like cmake, their biggest claim to awesomeness is thier ability to export the various build systems (including msvc files) from one description
05:34.50 brlcad scons is nice for small code sets but *seriously* starts to fall apart on large complex build systems -- you basically end up reimplementing autoconf
05:35.16 yukonbob ya -- /me is ready to buy the cmake manual (just released (new version)) and check it out...
05:37.29 brlcad like a lot of tools though, autotools really do work (and work well once you get over the learning curve) and it really starts to make sense why things are the way they are
05:38.31 brlcad their biggest downfall has been practical usability problems (horrible error messages, bad docs, elitist responses to usability)
05:39.17 yukonbob speaking of docs, can you recommend any? The GNU-supplied stuff isn't my cup of tea.
05:44.30 brlcad I actually recommend just reading existing build files for projects that use the autotools -- it's fairly straight-forward seeing it in other apps as there are really only two or three files types involved
05:44.35 brlcad the configure.ac and the Makefile.am files
05:45.38 brlcad the Makefile.am files don't really get *any* simpler in any of the autotools/cmake/ant/scons/whatever build systems as it's just a list of targets, sets of files, and how those sets of files relate to those targets
05:47.49 brlcad the build/feature/header tests and project identification are somewhat tricky in all the systems to replicate -- that's where configure.ac comes into play for the autotools
05:48.55 brlcad which is just shell syntax with macros
05:49.22 yukonbob nods -- will probably start poking this stuff in BRLCAD, and probably pick your brain too, where possible ;)
05:49.32 brlcad feel free to
05:50.40 brlcad I've read the GNU book and the auto* manuals, but I really never learned it until I put it to use
05:51.32 brlcad the tools are overly flexible, making it really complicated to document since you can approach things in a variety of ways (even though 90% of projects all do it about the same)
05:52.01 yukonbob that might be my problem -- the gnu manuals are drier than toast (and technical manuals don't have to be that way); maybe those in conjunction w/ some interesting "real life" work will click
05:52.29 brlcad in hindsight after you've put it to use, it does all make sense
05:52.36 brlcad even becomes somewhat overly obvious
05:52.46 brlcad but is totally opaque until you put it to use
05:56.38 yukonbob gets ready for sleep
05:56.38 brlcad usually much more effective to just look at a project that is already set up (like brl-cad or something even more simple) and follow their example
05:56.54 yukonbob nice chatting again, brlcad; probably talk tmo, or soon at least.
05:56.56 yukonbob :)
05:57.00 brlcad aiight
05:57.01 brlcad cheers
06:47.50 CIA-33 BRL-CAD: 03brlcad * r30556 10/brlcad/trunk/HACKING: the dutch cad4linux site seems to be now defunct
07:10.07 CIA-33 BRL-CAD: 03brlcad * r30557 10/brlcad/trunk/HACKING: add devmaster to the notification list
08:57.35 *** join/#brlcad homovulgaris (n=ca3fe93d@bz.bzflag.bz)
09:00.44 brlcad uploads some new images to the gallery
09:43.46 brlcad ensleeps
09:51.41 *** join/#brlcad cad22 (n=52f7631d@bz.bzflag.bz)
09:56.28 *** part/#brlcad cad22 (n=52f7631d@bz.bzflag.bz)
14:15.47 *** join/#brlcad Elperion (n=Bary@p54875E2A.dip.t-dialin.net)
15:58.51 *** join/#brlcad vedge (n=vedge@vedge.org)
16:14.45 brlcad time for a sunday feast!
16:36.04 yukonbob morning brlcad... happy Easter
16:37.06 poolio happy purim :)
16:37.30 yukonbob looks up purim
16:46.01 brlcad likewise
16:46.33 brlcad bah, can't find the original bradley rendering...
17:10.30 yukonbob would love to see that
17:17.23 yukonbob http://my.brlcad.org/gallery/gallery/s/historic/particles.jpg.html
17:18.03 yukonbob ^-- what is this, and it reminds me of a question I've had for a while: what's the 'atom' for?
17:27.23 *** join/#brlcad Elperion (n=Bary@p54875E2A.dip.t-dialin.net)
17:28.11 brlcad frankly I don't know really :) the image is an old one from bill laut .. don't know what he used it for, I'd have to ask him
17:28.27 brlcad as for the atom? which/what atom?
17:33.11 *** join/#brlcad Elperion (n=Bary@p54875E2A.dip.t-dialin.net)
17:35.53 brlcad few more images uploaded
17:39.02 yukonbob is sure he's seen an "atom" primitive
17:39.45 yukonbob also doesn't have a copy of BRL-CAD installed atm, and is heading out for easter brunch... chat later cadheads
17:41.50 *** join/#brlcad Elperion (n=Bary@p54875E2A.dip.t-dialin.net)
17:53.27 *** join/#brlcad Elperion (n=Bary@p54875E2A.dip.t-dialin.net)
20:15.48 *** join/#brlcad Elperion (n=Bary@p54875E2A.dip.t-dialin.net)
21:56.20 yukonbob http://pastebin.ca/954422
21:56.34 yukonbob ^--- build failure at g-3dm
22:03.40 *** join/#brlcad louipc (n=louipc@bas8-toronto63-1128543675.dsl.bell.ca)
22:12.44 yukonbob traces to src/conf/.deps/g-3dm.Po...
22:13.03 yukonbob ...or does he?
22:17.28 yukonbob wonders if 3dm is only in development...
22:19.02 yukonbob looks like g-3dm isn't ready, but it included (erroneosly) in build...
22:19.31 yukonbob *erroneously
22:26.51 yukonbob puts this on hold -- will return, test idea, and commit fix (if found) later.
23:14.19 *** join/#brlcad Elperion (n=Bary@p54875E2A.dip.t-dialin.net)
23:18.05 *** join/#brlcad Elperion (n=Bary@p54875E2A.dip.t-dialin.net)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.