| 02:28.07 | *** join/#brlcad DTRemenak (i=0@DHCP-170-143.caltech.edu) | |
| 03:11.06 | DTRemenak | the in-tree copy of jove fails to compile for me. seems to be because _GNU_SOURCE gets defined by configure. adding an appropriate #undef to jove.h fixes it, but I dunno what you folks would prefer. |
| 03:12.31 | brlcad | hmm |
| 03:12.49 | brlcad | jove is not really a huge concern, whatever makes it work ;) |
| 03:12.54 | DTRemenak | heh |
| 03:13.09 | brlcad | it's one of the few where not even the warnings are quelled |
| 03:13.21 | DTRemenak | I'm somewhat curious why it's required, actually |
| 03:13.47 | brlcad | that's history that goes back a LONG ways |
| 03:13.55 | DTRemenak | heh :) |
| 03:14.20 | brlcad | preinternet days, pre networked machines often |
| 03:15.12 | brlcad | it was so when brl-cad was installed on a system that had no editor or at least no decent editor, there would be at least jove (some brl-cad functions require editing files, so ..) |
| 03:15.29 | brlcad | jove is basically a very stripped down version of emacs |
| 03:15.38 | brlcad | "jonathans own version of emacs" |
| 03:16.07 | DTRemenak | ah. and it's kept around why? :) |
| 03:16.25 | brlcad | these days, it's included mainly because there are a slew of old brl-cad users that grew up with it, rely on it, and expect it |
| 03:16.34 | brlcad | and try to take an editor away from a zealot.. |
| 03:17.04 | brlcad | i pulled it once, instantly heard complaints :) |
| 03:17.14 | DTRemenak | heh :) |
| 03:17.35 | brlcad | so now it builds only if it doesn't detect a jove installed (you can disable it of course too) |
| 03:17.53 | brlcad | odd that _GNU_SOURCE would be an issue |
| 03:18.36 | DTRemenak | getline is defined by stdio.h if _GNU_SOURCE is defined |
| 03:18.43 | CIA-5 | BRL-CAD: 03dtremenak * 10brlcad/src/other/jove/jove.h: jove.h conflicts with stdio.h if _GNU_SOURCE is defined. make sure it's not. |
| 03:18.44 | DTRemenak | a different getline is defined by jove.h |
| 03:18.57 | brlcad | ah |
| 03:24.11 | *** join/#brlcad DTRemenak (i=0@DHCP-170-143.caltech.edu) | |
| 04:07.27 | *** join/#brlcad DTRemenak (n=Daniel_R@DHCP-170-143.caltech.edu) | |
| 04:09.21 | DTRemenak | do_subfigs.c:38:28: ../librt/debug.h: No such file or directory |
| 04:10.58 | DTRemenak | seems to be ../../librt/debug.h |
| 04:12.04 | brlcad | eh? |
| 04:12.19 | brlcad | what system is this? |
| 04:12.58 | DTRemenak | Slackware Linux 10.2. Linux dtremenak 2.4.31 #6 Sun Jun 5 19:04:47 PDT 2005 i686 unknown unknown GNU/Linux |
| 04:13.33 | brlcad | ahh, slack -- haven't had hands on that in ages |
| 04:13.52 | DTRemenak | do_subfigs is in src/conv/iges. have to go up two levels to get to librt. |
| 04:13.57 | brlcad | and that iges directory was _just_ moved yesterday |
| 04:14.01 | DTRemenak | ahh |
| 04:14.03 | brlcad | haven't tested extensively |
| 04:14.17 | DTRemenak | "haven't tested extensively" -> "haven't built"? :) |
| 04:14.22 | brlcad | it used to be in src/iges, now in src/conv/iges with the other converters |
| 04:14.32 | brlcad | well, you know how that goes with me sometimes :) |
| 04:14.44 | brlcad | I thought I did :) |
| 04:15.53 | DTRemenak | getting the same thing from jack |
| 04:16.50 | brlcad | maybe it's cause I did a make test after the build targets were already created.. :) |
| 04:16.57 | brlcad | jack is another converter |
| 04:17.04 | DTRemenak | yup |
| 04:17.08 | DTRemenak | moved at the same time? |
| 04:17.10 | brlcad | as are all the subdirs in conv/ |
| 04:17.15 | brlcad | yep -- all of them |
| 04:17.38 | DTRemenak | those are the only two that complained. perhaps the others don't include librt/debug.h |
| 04:18.24 | DTRemenak | or maybe it's not done |
| 04:21.24 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/conv/ (8 files in 3 dirs): fix relative include paths after the move to src/conv (thanks dtr) |
| 04:21.52 | DTRemenak | heh. I knew that would happen. cvs commit: Up-to-date check failed for `iges/do_subfigs.c' |
| 04:22.00 | brlcad | hehe, sorry |
| 04:22.05 | brlcad | shoulda said something |
| 04:22.59 | DTRemenak | g-iges.c:71:29: ../../iges/iges.h: No such file or directory |
| 04:23.11 | DTRemenak | not all the relative paths are wrong :) |
| 04:23.28 | brlcad | typo :) |
| 04:24.05 | brlcad | yeah, only made that mistake once |
| 04:24.11 | brlcad | should be just ./iges.h |
| 04:24.18 | DTRemenak | ah, ok |
| 04:24.20 | brlcad | me or you got it? :) |
| 04:25.00 | DTRemenak | looks like you also missed the ones in jack |
| 04:25.21 | brlcad | i did?! |
| 04:25.31 | DTRemenak | one of them |
| 04:25.44 | DTRemenak | in g-jack.c |
| 04:25.46 | DTRemenak | I got them |
| 04:25.59 | brlcad | ah, yeah i see it |
| 04:26.04 | brlcad | missed the line in emacs output |
| 04:26.13 | brlcad | eyes are cross-eyeing |
| 04:26.31 | brlcad | probably shouldn't commit after all this wine |
| 04:26.52 | DTRemenak | heh :) |
| 04:27.16 | brlcad | but i gather if I can still type, can't be that bad ;) |
| 04:27.47 | DTRemenak | haven't noticed any bad typing mistakes yet :) |
| 04:28.04 | CIA-5 | BRL-CAD: 03dtremenak * 10brlcad/src/conv/ (iges/g-iges.c jack/g-jack.c): librt is two levels away. iges is one level away. |
| 04:28.08 | brlcad | saving a major commit of new code for tomorrow |
| 04:28.52 | DTRemenak | what fun |
| 04:28.59 | DTRemenak | anything interesting? |
| 04:29.42 | brlcad | somewhat |
| 04:30.07 | brlcad | depends on what you want, for you perhaps not :) |
| 04:30.38 | brlcad | we have access to some equipment, actually it's surveying equipment |
| 04:30.48 | brlcad | very high precision stuff, 40k pricetags and whatnot |
| 04:30.51 | DTRemenak | cool |
| 04:31.12 | brlcad | you set the system up, calibrate and have this variable length staff/pole with sensors on it |
| 04:31.44 | brlcad | the system knows where a tip of the pole is in 3-space and you can acquire highly precise 3d points with it |
| 04:32.19 | brlcad | this code lets you take sets of that point data acquired in a predetermined manner and automatically create geometry from it |
| 04:32.59 | brlcad | like for a sheet of metal, you'd collect points on the contour of the object, and then a depth point -- that is automatically converted into geometry in the cad system on import |
| 04:33.06 | DTRemenak | ah, nifty |
| 04:33.15 | brlcad | very cool, huge timesaver for reverse-modeling |
| 04:33.57 | brlcad | which is a pretty darn common need surprisingly enough |
| 04:34.51 | DTRemenak | why is it so common? do people just not keep their original design files around? |
| 04:35.40 | brlcad | huge disconnects between modelers, vendors, contractors, manufacturers, etc |
| 04:36.04 | DTRemenak | ah |
| 04:36.06 | brlcad | everyone wants major $$ to provide for whatever the other guy needs |
| 04:36.17 | brlcad | so rarely is stuff just shared |
| 04:36.37 | brlcad | especially if the terms aren't built into the contracts, which are very often the case |
| 04:36.41 | DTRemenak | so instead, they spend $$ on equipment to figure it out? :) |
| 04:37.04 | brlcad | different scale of "major" $$ |
| 04:37.27 | brlcad | a 5 digit piece of equipment is "cheap" in that context |
| 04:37.33 | DTRemenak | yeah, I know. just muttering about waste. you know me and efficiency. |
| 04:37.40 | brlcad | yeah |
| 04:58.17 | *** join/#brlcad mahesh (n=mahesh@12-217-228-178.client.mchsi.com) | |
| 04:59.32 | *** join/#brlcad mahesh (n=mahesh@12-217-228-178.client.mchsi.com) | |
| 05:24.46 | mahesh | Sean, had a question |
| 05:45.54 | brlcad | mahesh: fire away |
| 05:46.00 | mahesh | oh there you are |
| 05:46.02 | brlcad | mahesh: great to hear about the progress! |
| 05:46.10 | brlcad | sounded excellent! |
| 05:46.14 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/conv/iges/g-iges.c: just reference current dir instead of up and down to iges dir |
| 05:48.36 | mahesh | in worker.c, there is cur_pixel and last_pixel |
| 05:49.04 | mahesh | basically, do_pixel is called for each pixel from cur_pixel to last_pixel |
| 05:49.29 | mahesh | but even if i set both of them to 0, the program seems to be running fine |
| 05:49.43 | mahesh | that is, the image is being created |
| 05:49.56 | mahesh | why is that? it should not have created the image right? |
| 05:51.48 | brlcad | hmm |
| 05:53.51 | brlcad | i can see setting both to zero could be troublesome |
| 05:53.58 | brlcad | it's not meant to be called with "no work" to do |
| 05:54.16 | brlcad | so probably the per_processor_chunk lets it skip the check |
| 05:54.36 | mahesh | oh |
| 05:55.33 | mahesh | another thing i tried was |
| 05:55.42 | brlcad | test out real bounds like setting cur_pixel to half the image, and last to last pixel |
| 05:56.03 | mahesh | ok |
| 05:56.32 | brlcad | you also realize, I hope, that brl-cad uses first-quadrant image coordinates |
| 05:56.44 | brlcad | i.e. 0,0 is left bottom corner of the image |
| 05:57.44 | mahesh | where is this x and y coordinates here....cur_pixel is 0 and last_pixel is 262143 for the model i am working on |
| 05:58.28 | mahesh | per_processor_chunk number of them is being assigned to each processor |
| 05:59.06 | brlcad | cur_pixel would be bottom-left pixel at 0, 262143 would be the last pixel in the default image size in the top-right corner |
| 06:00.04 | mahesh | ok..got it |
| 06:00.35 | mahesh | do you know how exactly this code runs on smp machine |
| 06:00.48 | mahesh | say, i am running on dual processor machine |
| 06:00.59 | brlcad | pretty much, though I still read code for reference ;) |
| 06:01.37 | mahesh | is main() which is the starting point of execution run by both processors? |
| 06:01.48 | brlcad | no |
| 06:02.03 | brlcad | inside bu_parallel is where the multi-execution begins |
| 06:02.04 | mahesh | ok...because in mpi that is how it works |
| 06:02.25 | brlcad | right |
| 06:02.34 | mahesh | i have to use some conditions to make only one processor start it |
| 06:03.08 | mahesh | none of the other processors come into picture till the worker function is called right? |
| 06:03.32 | brlcad | you could let them all run with exactly the same task specification, but recognize a designated host as the controller |
| 06:04.24 | brlcad | say, for example, if you have them all check if current node == node that initiated the job (or node specified on the command line, whatever) then talk to that node for getting tasks of work |
| 06:04.56 | brlcad | the alternative, like you mention, is to have just one exec that invokes all of the mpi nodes into action |
| 06:05.15 | brlcad | i initially was thinking the latter too (and it would make for a more maintainable application) |
| 06:05.47 | brlcad | but if it's too difficult, then I'd just as quickly ditch it ;) more important to get functioning first than it is to get functioning beautifully ;) |
| 06:06.39 | mahesh | true...i really want to get some stuff working |
| 06:06.39 | brlcad | and to answer your question, yes -- none of the other processors come into the picture until worker is called (except that prepr can be performend in parallel too, but that's a minor detail) |
| 06:07.14 | brlcad | sounds like you're making progress from what you wrote |
| 06:07.48 | mahesh | little bit, i think |
| 06:08.37 | mahesh | ok, one last question for the day |
| 06:09.54 | mahesh | assume that controller gave chunks of pixels to each node. They all called do_pixel on each pixel they received |
| 06:10.21 | brlcad | okay |
| 06:11.03 | mahesh | to perform do_pixel, dont they have to have populated application structure or tree structure whatever |
| 06:11.24 | brlcad | by the way, this is sort of what I envisioned in a simplistic tutorial view of how it'd communicate to a single node for requesting work: http://www.lam-mpi.org/tutorials/one-step/ezstart.php |
| 06:12.26 | mahesh | oh wow....thanks for the link |
| 06:13.24 | brlcad | alternatively, something like http://www.lam-mpi.org/tutorials/one-step/collectives.php for distributing the full job to everyone and negotiating who works on what via the scatter/reduction |
| 06:13.48 | brlcad | one of those two should be considerably easier than the other ;) |
| 06:14.09 | brlcad | not sure which.. the first has setup issues, the other has communication issues |
| 06:14.58 | mahesh | it should be fun, i will be look into it |
| 06:14.59 | brlcad | to perform do_pixel, it will need to have performed an rt_dirbuild and a prep |
| 06:15.28 | mahesh | good. i was right..just wanted to confirm |
| 06:15.31 | brlcad | so you'll need to communicate the .g data to the remote hosts |
| 06:15.41 | brlcad | and prep each one independently |
| 06:16.19 | brlcad | that cost is pretty much fixed per model per node |
| 06:16.40 | mahesh | and once they are done with do_pixel, there will be RGB values right which they have to give it back to controller? |
| 06:16.50 | brlcad | though you can amortize that cost over multiple simultaneous frames (e.g. animations) |
| 06:17.02 | brlcad | yes, exactly |
| 06:17.26 | brlcad | the rgb values will be the result that has to get passed back to the controler so it can piece it all together |
| 06:17.47 | mahesh | and that is in a_color or something like that |
| 06:17.53 | brlcad | yep |
| 06:19.39 | mahesh | weekend will be fun with this! |
| 06:19.42 | brlcad | after every single pixel it calls view_pixel() inside do_pixel() and for each line, it calls view_eol() |
| 06:20.09 | brlcad | do_pixel is of course called by worker() |
| 06:20.30 | mahesh | do i have to take care of those things (that is view_pixel and view_eol)? |
| 06:21.02 | brlcad | no, you shouldn't have to I wouldn't think though you could |
| 06:21.13 | brlcad | i'd suggest you don't just to minimize impact ;) |
| 06:22.03 | brlcad | but what you ultimately need to get the mpi going might make that a more complicated task, dunno.. ;) |
| 06:22.47 | mahesh | well, actually speaking, i should right? because do_pixel running on remote machine means view_pixel also is on remote machine but view_pixel should be called on local machine |
| 06:23.15 | mahesh | or may be i got it wrong |
| 06:23.33 | brlcad | no you got it right |
| 06:24.01 | brlcad | but you don't necessarily need to replace view_pixel() |
| 06:24.25 | mahesh | ok |
| 06:24.32 | brlcad | maybe just do_pixel.. and do_pixel sends results back .. or buffers then and worker() sends them back |
| 06:25.30 | mahesh | yeah |
| 06:25.55 | mahesh | when do you sleep? |
| 06:26.06 | brlcad | what's that? :) |
| 06:26.11 | mahesh | ha ha |
| 06:26.19 | mahesh | its 1:25 |
| 06:26.35 | brlcad | it's 2:30am here now |
| 06:26.52 | mahesh | oh EST |
| 06:28.34 | brlcad | i'll be lively and sober again in a few hours |
| 06:28.59 | brlcad | probably 6 or 7 your time |
| 06:29.48 | mahesh | my day will be ruined if i get up at 6 or 7 |
| 06:31.23 | brlcad | well, feel free to just sit and idle -- I read the log |
| 06:31.42 | brlcad | i'll answer you directly, or to memoserv or via e-mail eventually |
| 06:31.50 | mahesh | ok |
| 06:32.03 | mahesh | thanks for clarifying all my doubts |
| 06:32.08 | brlcad | no problem |
| 06:32.13 | brlcad | great work on the progress |
| 06:32.30 | mahesh | thanks |
| 06:32.48 | brlcad | probably a good first step is to distribute the .g file from a single master to all the others via mpi |
| 06:33.08 | brlcad | and prep all of the remote using this .g |
| 06:33.45 | brlcad | or just presume they all have disk access (is it common in a cluster to have distributed filesystem access?) |
| 06:34.07 | mahesh | not necessarily |
| 06:34.36 | brlcad | so yeah, some mpi-means to transfer the .g for prep |
| 06:35.19 | mahesh | i shall do it that way |
| 06:37.26 | brlcad | probably can work out some sort of mpi tricks in that case since any peer that has the portion you need will serve just as well as the master node |
| 06:37.52 | brlcad | a broadcast scatter/gather of some sort |
| 06:38.21 | mahesh | i have ideas about that, but i want to use them only after i get this initial stuff done |
| 06:38.34 | brlcad | well, hope to hear how it goes :) |
| 06:38.36 | brlcad | good luck |
| 06:40.27 | mahesh | thanks |
| 07:58.00 | *** join/#brlcad DTRemenak (n=Daniel_R@DHCP-170-143.caltech.edu) | |
| 08:32.57 | *** join/#brlcad DTRemenak (n=DTRemena@DHCP-170-143.caltech.edu) | |
| 15:42.05 | *** join/#brlcad mahesh_ (n=mahesh@12-217-228-235.client.mchsi.com) | |
| 17:45.22 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/libtclcad/Makefile.am: revert tk back in, the lib uses tk extensively so it needs to be on the list |
| 17:48.42 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/bwish/Makefile.am: try making the libs consistent between bwish and btclsh to get around symbol and run-time issues |
| 18:58.13 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/other/libtk/Makefile.am: don't link libtk static, causes trouble in libtclcad on altix where non-PIC get included which causes an ld failure. |
| 20:05.42 | *** join/#brlcad cad155 (n=51e4c568@bz.bzflag.bz) | |
| 21:29.28 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/mged/points/ (main.c points_parse.y points_scan.l process.c process.h): |
| 21:29.29 | CIA-5 | BRL-CAD: initial files for a points file parser that reads them all in and processes |
| 21:29.29 | CIA-5 | BRL-CAD: groups of them at a time based on recognized line labels. data collected in a |
| 21:29.29 | CIA-5 | BRL-CAD: requisite order may then be automatically turned into geometry using a tclscript |
| 21:29.29 | CIA-5 | BRL-CAD: helper code. |
| 21:30.34 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/mged/points/ (count.c count.h): generic counting routines for reporting parse/scan statistics |
| 21:30.57 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/mged/points/Makefile.am: initial Makefile.am for building a utility library to be used by mged for reading point files |
| 21:31.29 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/configure.ac: generate the makefile for src/mged/points |
| 21:31.48 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/mged/Makefile.am: traverse into the points subdir too |
| 21:32.46 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/mged/ (cmd.h cmd.c): export the cmd_parse_points routine for parsing point files |
| 21:33.15 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/mged/chgview.c: comment cleanup, several functions have disappeared or been renamed |
| 21:34.24 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/mged/ged.h: there is no f_edit() |
| 21:36.39 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/mged/points/Makefile.am: wrong fast objects list, no sense just making it static -- libtool will figure it out |
| 21:39.10 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/tclscripts/mged/points.tcl: initial points tclscript for generating geometry based on sets of points being processed in certain styles, written by lee -- works in conjunction with the src/mged/points library that parses the points from a given file |
| 21:39.20 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/tclscripts/mged/Makefile.am: include the points.tcl file |
| 21:42.12 | *** join/#brlcad PrezKennedy (n=Apathy@pcp0011645240pcs.aberdn01.md.comcast.net) | |
| 23:04.44 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/mged/points/ (main.c process.h): header file is named points_parse.h now |
| 23:04.54 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/mged/points/Makefile.am: designate the BUILT_SOURCES so that they are generated first |
| 23:09.31 | brlcad | <PROTECTED> |
| 23:28.21 | PrezKennedy | hey its goin well |
| 23:28.28 | PrezKennedy | bit tired |
| 23:31.15 | brlcad | how's the site work been going? |
| 23:31.29 | brlcad | or have you been doing other stuff |
| 23:32.47 | PrezKennedy | its going ok other than all the annoying limitations at sourceforge |
| 23:33.05 | brlcad | if you've got some time, there's something else I'd like you to work on if you're interested that's not website-related |
| 23:33.14 | PrezKennedy | ok what is it |
| 23:33.51 | brlcad | remember the docs I mentioned earlier |
| 23:33.57 | PrezKennedy | yeah |
| 23:34.03 | brlcad | there are several that I'd like to make |
| 23:34.10 | PrezKennedy | ok |
| 23:34.44 | brlcad | one being a history of the package, the other a current overview of what's in the package now |
| 23:35.11 | brlcad | the latter is something that would really be useful |
| 23:35.26 | brlcad | and wouldn't be too difficult to put together |
| 23:35.36 | PrezKennedy | can i put it together using the info already up? |
| 23:36.29 | brlcad | sure |
| 23:36.41 | brlcad | it can all go onto a web page, or into a spreadsheet |
| 23:36.48 | brlcad | or even into a simple text file for that matter |
| 23:37.22 | PrezKennedy | jok ill get on that tonight |
| 23:37.27 | brlcad | it'd be a mini database of all the tools and libraries, with a short description of each one |
| 23:38.09 | brlcad | there's over 400 tools and about 2 dozen libraries to describe |
| 23:38.36 | PrezKennedy | yeah i knew there were a lot |
| 23:38.50 | PrezKennedy | where can i find out what each does? |
| 23:39.18 | brlcad | keep in mind any information that might be useful to an outsider, try to come up with a set of categories too like "image converter", "geometry converter", "geometry tool", "data processing tool", "framebuffer I/O tool", etc |
| 23:39.31 | PrezKennedy | ok |
| 23:40.05 | brlcad | you'll need a source download of the package, and perhaps a binary one too just to get a list of what's installed |
| 23:40.33 | brlcad | about 1/4th have man pages |
| 23:40.54 | brlcad | so those should be pretty easy, just copy the description line out of there, maybe clean up the engrish ;) |
| 23:41.16 | PrezKennedy | engrish is the best |
| 23:41.57 | brlcad | for the others, there's usually a line or two description at the top of their source files, or they have a usage statement |
| 23:42.09 | PrezKennedy | ok |
| 23:42.27 | brlcad | a spreadsheet or database probably will work best for being able to go back and see what's known and what's not |
| 23:48.03 | AchiestDragon | is cvs buildable at the moment , or would i be better waiting before doing a cvs up ? |
| 23:49.01 | brlcad | AchiestDragon: I'd suggest waiting just a little bit to make sure you don't get an update in the middle of a commit with the 5 hour anonymous cvs window and all |
| 23:49.12 | brlcad | but yes, it should be buildable |
| 23:49.17 | AchiestDragon | k |
| 23:49.26 | brlcad | easy enough to try ;) |
| 23:50.11 | AchiestDragon | :) just better to ask with all the commits going in , dont want to get some that need another thats ont yet entered |
| 23:51.57 | brlcad | in general, when there's a slight lull, it's safe and working ;) |
| 23:52.11 | brlcad | but not a bad idea |
| 23:53.46 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/configure.ac: |
| 23:53.46 | CIA-5 | BRL-CAD: itcl doesn't need to include the include directory, in fact it causes problems |
| 23:53.46 | CIA-5 | BRL-CAD: since it can pick up our itcl.h which picks up our tcl.h which requires common.h |
| 23:53.46 | CIA-5 | BRL-CAD: which requires HAVE_CONFIG_H to be defined which causes problems. (thanks Stefan |
| 23:53.46 | CIA-5 | BRL-CAD: Fiedler) in face, don't add include to our overall cppflags either since |
| 23:53.47 | CIA-5 | BRL-CAD: autoheader is supposed to take care of this in the makefiles |
| 23:55.49 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/NEWS: fixed itcl configuration issue |
| 23:56.23 | *** join/#brlcad DTRemenak (i=agent007@DHCP-170-143.caltech.edu) | |