| 00:14.01 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/src/librt/.cvsignore: ignore brep_test |
| 01:03.27 | CIA-7 | BRL-CAD: 03erikgreenwald * 10brlcad/src/ (21 files in 21 dirs): use the -fexception flag when necessary (osX/x86) |
| 01:06.14 | brlcad | bizzare.. I don't see why would those need -fexecption |
| 01:06.54 | brlcad | and I've been building successfully on osx/x86 |
| 01:08.41 | ``Erik | they broke on mine *shrug* |
| 01:08.46 | ``Erik | do you have opennurbs built into your librt? |
| 01:08.54 | brlcad | yep |
| 01:09.00 | ``Erik | hum |
| 01:09.12 | ``Erik | must have something different in the env or something |
| 01:10.48 | brlcad | but I mean even the need for the flag doesn't make sense .. exception handling code can only be generated by the c++-compiled code .. maybe if libtool is for some reason linking in librt and/or open nurbs static, I could see |
| 01:11.11 | brlcad | was there a correllation? was that everything that linked RT or something? |
| 01:11.15 | ``Erik | *shrug* I read the docs on the flag, ummm |
| 01:11.36 | ``Erik | I wasn't paying attention to that, I know some of them had only some stuff in the dir needing it |
| 01:11.55 | *** join/#brlcad IriX64 (n=mario_du@bas3-sudbury98-1168050142.dsl.bell.ca) | |
| 01:12.19 | ``Erik | a couple things are getting the flag when they don't need it because 25 of the 28 things needed it and I figured keeping the automake file cleaner was more important *shrug* |
| 01:13.36 | brlcad | i mean more along the lines of if it's opennurbs propagating the need via some libtool behavior, it could also be stuffed into the OPENNURBS symbol |
| 01:14.16 | brlcad | but to date, I hadn't seen a single failure other than linking static binaries |
| 01:14.29 | ``Erik | once autogen.sh finishes and I get it configured up again, I'll look into that |
| 01:15.28 | brlcad | linking static made total sense .. almost implies that openNURBS compiled static or something (or libtool thought it needed to resolve, or something) |
| 01:15.49 | brlcad | not really complaining, just would like to understand it |
| 01:15.57 | brlcad | to avoid it |
| 01:29.02 | brlcad | I should have the COPYING/INSTALL clobbering (re)fixed again here shortly too, f'ing automake |
| 01:35.26 | ``Erik | phark, I musta had and old binary of librt or opennurbs or something :/ |
| 01:39.03 | Maloeran | Eh cool. A chunk of Survice's fire modelling code is written in Java, and that chunk of code is windows only |
| 02:06.40 | IriX64 | dm-ogl has issues. |
| 02:07.52 | IriX64 | ogl_choose_visual ogl_open ogl_close exist elsewhere man. |
| 02:08.32 | brlcad | ``Erik: make sure my recent src/librt/Makefile.am change didn't accidentally disable g_brep/OBJ_BREP .. looks like it's on here, but I haven't tried a run-time test yet |
| 02:09.23 | IriX64 | rename those 3 bwish will compile just fine. |
| 02:09.30 | brlcad | the next release will likely be --disable-opennurbs just to keep things consistent so it's not a big deal either way |
| 02:10.13 | brlcad | IriX64: is there any cohesion to your thought processes? what ARE you talking about?? |
| 02:10.58 | IriX64 | the file dm-ogl has functions in it that clash with others |
| 02:11.04 | brlcad | seriously, it sounds like you're on weed .. and I can't tell if you've got a compilation error with 4.1.2 or are fooling around |
| 02:11.24 | brlcad | with others in what? |
| 02:12.03 | IriX64 | whatever library youre linking against in bwish, its gone noew or id tell you. |
| 02:12.11 | IriX64 | the fix is to fix dm-ogl |
| 02:12.50 | brlcad | that might make the problem "go away", but I'm not going to change those function names without knowing what the problem is |
| 02:13.03 | IriX64 | multiple definitions. |
| 02:13.28 | brlcad | and that's where you need to say .. where ;) |
| 02:13.33 | IriX64 | at link time of bwish |
| 02:13.42 | brlcad | not the symbols, and not *when* |
| 02:13.45 | IriX64 | ok ;) |
| 02:14.01 | IriX64 | ill learn :) |
| 02:14.25 | brlcad | there are symbols from N multiple places, according to what you said .. what are those places (which files) |
| 02:14.33 | brlcad | it could be a simple linking issue |
| 02:14.40 | brlcad | or an issue with your configure arguments |
| 02:14.47 | brlcad | or an issue with code assumptions |
| 02:14.54 | brlcad | or some combination thereof |
| 02:15.22 | brlcad | somehow I suspect you've got a static debug build going or something |
| 02:15.26 | IriX64 | dm-ogl and i lost where they're first defined, thought it was just this code so i didn't note it, ill try again if this compile finishes. |
| 02:16.30 | IriX64 | how about this show stopper sdi_dep.c device.h, no such file or directory. |
| 02:16.46 | brlcad | sdi_dep.c ?? |
| 02:16.52 | IriX64 | sgi |
| 02:17.41 | brlcad | in which dir? |
| 02:18.08 | IriX64 | src/fbed |
| 02:19.15 | brlcad | er.. you have HAS_SGIGL defined?? |
| 02:19.25 | IriX64 | just a sec ill check |
| 02:19.36 | brlcad | grep HAS_SGIGL include/brlcad_config.h |
| 02:20.03 | IriX64 | yes |
| 02:20.16 | brlcad | it should NOT be defined for you .. so either the configure check detected incorrectly, or you've been messing with something.. |
| 02:21.21 | IriX64 | all i messed with was the presence/not presence of ogl. |
| 02:21.36 | IriX64 | i have it and it was coming up false. |
| 02:26.51 | brlcad | sounds like you might have forced the wrong thing on |
| 02:27.58 | brlcad | i can't imagine you having a -lgl that has getvideo() |
| 02:45.45 | IriX64 | but it has gl_enable(). |
| 02:47.04 | IriX64 | but im probably all wet, ill revisit it later, now im compiling my first love gcc. |
| 02:47.13 | IriX64 | right now i mean. |
| 02:47.31 | brlcad | there are multiple gl libraries |
| 02:47.39 | IriX64 | true |
| 02:47.45 | brlcad | it sounds like you forced on the wrong ones |
| 02:47.56 | brlcad | you don't have the sgi gl library |
| 02:48.02 | brlcad | hence the error |
| 02:48.10 | IriX64 | quite probably you're right |
| 02:48.53 | IriX64 | gotta test my new baby, BRL-CAD comes to mind ;) |
| 03:01.53 | *** join/#brlcad louipc (n=louipc@bas8-toronto63-1096669659.dsl.bell.ca) | |
| 03:41.47 | brlcad | heh |
| 03:43.51 | IriX64 | somebody says... so put them in :) |
| 04:06.18 | louipc | Britney_Spears was going to talk to me in ##freebsd. I had to uh kind of go to that level yeaah |
| 04:06.59 | louipc | *kind of had to go.. |
| 04:11.03 | louipc | you have to do little bits of many tasks at a time |
| 04:11.28 | IriX64 | heh i get stuck on the first little bit |
| 04:11.31 | louipc | I seem to have trouble making sentences now |
| 04:11.43 | IriX64 | get in line |
| 04:11.59 | Maloeran | This may trash your brain's cache memory though, better use fairly large time chunks |
| 04:12.48 | IriX64 | the brain is the spark of our faith |
| 04:13.21 | IriX64 | we're all born with it, it's just that somehow some of us lose it. |
| 04:14.16 | brlcad | louipc is really just a teenager girl in disguise |
| 04:14.52 | brlcad | irc: where the men are men, the women are men, and little girls are fbi agents |
| 04:17.13 | IriX64 | actually have a relative named brandy. |
| 04:17.22 | IriX64 | my cousins wife |
| 04:18.33 | PrezKennedy | irix... wasnt that an SGI workstation from the 80's? |
| 04:20.05 | Maloeran | Close, it's the name of the operating system |
| 04:20.36 | PrezKennedy | still around? |
| 04:21.00 | IriX64 | 70's :) |
| 04:21.37 | IriX64 | Silicon Graphics Inc, you remeber? |
| 04:21.45 | IriX64 | remember too. |
| 04:22.22 | Maloeran | I think Irix is fairly dead these days |
| 04:22.26 | PrezKennedy | before my time... but i played Doom and dogfight when i was young |
| 04:22.45 | IriX64 | still have a copy of doom |
| 04:22.58 | IriX64 | son played it a lot |
| 04:23.03 | Maloeran | Actually, Irix 6.5 came out in 1998, latest stable release 6.5.30 August 2006 |
| 04:23.24 | PrezKennedy | i have doom for PC now |
| 04:23.25 | IriX64 | the fount of all knowlede spoke ;) |
| 04:23.28 | ``Erik | the name of the OS, actually, not the workstation |
| 04:23.33 | PrezKennedy | and i have the windows port of dogfight for PC |
| 04:23.47 | IriX64 | man i don't know squatt about Irix. |
| 04:24.17 | ``Erik | and the first irix was a bsd 4.3 variant in '88 according to http://en.wikipedia.org/wiki/Irix |
| 04:24.32 | Maloeran | Poor SGI, how is it doing these days? |
| 04:24.41 | ``Erik | sysV+bsd43 rather |
| 04:24.49 | ``Erik | pink listing last I heard, mal... |
| 04:24.58 | Maloeran | Pink listing? What's that? |
| 04:25.05 | IriX64 | Maloeran, I would know this how? |
| 04:25.50 | PrezKennedy | i thought they were being delisted |
| 04:26.00 | brlcad | Maloeran: it's an invite to a Britney Spears birthday party |
| 04:26.22 | louipc | Britney Spears uses FreeBSD |
| 04:26.48 | PrezKennedy | Britney Spears uses Windows 3.11 for Workgroups |
| 04:26.54 | PrezKennedy | and i use the term "uses" loosely |
| 04:27.22 | brlcad | netcraft doesn't confirm it |
| 04:27.28 | brlcad | says she's running linux :) |
| 04:27.59 | ``Erik | pink listing is the 'probationary' before being delisted... looks like sgi went into chap11 and back out, hopefully their recovery stays on track o.O |
| 04:28.25 | brlcad | the reorg and focus on altix was a good decision |
| 04:28.42 | brlcad | it's their only remaining niche that they haven't sold off the intellectual rights to at this point |
| 04:28.58 | brlcad | but still a long shot |
| 04:29.01 | ``Erik | heh, unfortunately the altix uses itaniums :) |
| 04:29.24 | ``Erik | if they'd gone with opterons, they'd probably be a bit better off |
| 04:30.36 | brlcad | for that niche, it probably doesn't matter too much |
| 04:30.42 | Maloeran | Intel really made a mess with their Itaniums, several companies believed in this new architecture |
| 04:30.45 | brlcad | the single-image scalability is their bread winner |
| 04:31.13 | brlcad | the first crop of itaniums was horrid, I2 was much better |
| 04:31.40 | Maloeran | Even Microsoft created this interpreted C# thing for windows binaries to work equally on ia32 and ia64, which of course is now useless with ia32/amd64, although they got a lot of people hooked to it somehow |
| 04:31.48 | ``Erik | if intel would've sold 'em cheaper (loss-leader style instead of high markup 'premium' at first), things robably woulda been different :) |
| 04:32.33 | Maloeran | Yes, Itaniums were way too expensive, totally out of range of ordinary mortals |
| 04:34.33 | Maloeran | Even later, I don't understand why they didn't cut price by 70-85% when Opterons came around, the outcome was getting really obvious |
| 04:35.04 | Maloeran | The instruction set was great, the architecture was neat, I really wish we could have moved away from this x86 cludge |
| 04:41.45 | IriX64 | err athlon/xp |
| 04:42.01 | PrezKennedy | gnight folks |
| 04:42.14 | IriX64 | knight :) |
| 04:42.19 | IriX64 | ah well. |
| 04:44.58 | IriX64 | if ibm had selected motorola instead of intel, none of the segment stuff woulda ever been necessary. |
| 04:45.52 | IriX64 | pdp11 on a chip, gotta love it. (6502) |
| 04:46.52 | IriX64 | anybody remeber the NEC v20? |
| 04:47.06 | IriX64 | z80 and 8088 on one chip. |
| 05:00.56 | ``Erik | 6502 was MOS, not motorola |
| 05:01.48 | IriX64 | err? |
| 05:02.37 | IriX64 | lemme check my cpu reference :) |
| 05:02.44 | ``Erik | the dudes who made teh 6800 quit motorola, started their own co and started making new chips |
| 05:03.04 | ``Erik | and commodores used the 6502 and it's family for the vic, c64, c128, .... |
| 05:03.10 | IriX64 | 6502 was put out by motorola |
| 05:03.32 | IriX64 | atari line also used 6502 |
| 05:03.44 | ``Erik | motorola chips are 68* |
| 05:03.53 | IriX64 | now yes |
| 05:04.10 | ``Erik | 6501 was pin compatible with the (older) 6800, then there was a lawsuit, the 6502 was a pin incompatible version |
| 05:04.24 | ``Erik | according to http://en.wikipedia.org/wiki/MOS_Technology_6502 |
| 05:04.31 | IriX64 | dude... |
| 05:05.17 | IriX64 | wikipedia.... pfffffft |
| 05:05.19 | ``Erik | http://en.wikipedia.org/wiki/Atari_2600 points to MOS, too |
| 05:05.21 | ``Erik | heh |
| 05:06.41 | IriX64 | first one though was an ohio scientific endeavor. |
| 05:07.35 | IriX64 | addiction calls, bbiab :( |
| 06:36.11 | *** join/#brlcad cad94 (n=51df8a12@bz.bzflag.bz) | |
| 07:36.22 | *** join/#brlcad IriX64 (n=mario_du@bas3-sudbury98-1168050142.dsl.bell.ca) | |
| 07:46.53 | brlcad | my spidey sense tingles |
| 09:31.00 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/autogen.sh: (log message trimmed) |
| 09:31.00 | CIA-7 | BRL-CAD: major update. this change adds support for protected recursive build |
| 09:31.00 | CIA-7 | BRL-CAD: preparations, saving copies of all the relevant COPYING/INSTALL files that might |
| 09:31.00 | CIA-7 | BRL-CAD: get stomped on by automake/autoreconf (EVEN WHEN USING AC_CONFIG_SUBDIRS). the |
| 09:31.00 | CIA-7 | BRL-CAD: files are even still stashed into memory too by using tricksy path-specific |
| 09:31.02 | CIA-7 | BRL-CAD: variables. this fix will restore the files correctly regardless of whether |
| 09:31.04 | CIA-7 | BRL-CAD: autoreconf or manual steps are taken. t'is a royal hassle just to compensate |
| 11:01.46 | *** join/#brlcad docelic (n=docelic@212.15.177.198) | |
| 11:35.57 | *** join/#brlcad rossberg (n=rossberg@bz.bzflag.bz) | |
| 11:50.10 | CIA-7 | BRL-CAD: 03d_rossberg * 10brlcad/include/vector.h: the spezialization is friend, not the template |
| 11:59.28 | CIA-7 | BRL-CAD: 03d_rossberg * 10brlcad/include/ (vector.h vector_fpu.h vector_x86.h): VC++ 6.0 does not like the (redundant) struct keyword in connection with a template |
| 13:08.04 | brlcad | rossberg: sorry, i missed the connection that it was the basename() code that started the strlcpy() .. |
| 13:08.12 | brlcad | i thought you had used strlcpy somewhere |
| 13:08.22 | brlcad | my confusion |
| 13:08.57 | brlcad | all makes sense now since those basename sources were pulled from openbsd iirc |
| 13:14.27 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/autogen.sh: missing the case where the number matches exactly, check patch -eq patch |
| 13:17.42 | rossberg | brlcad: i'm fine :-) |
| 13:18.58 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/autogen.sh: order |
| 13:19.19 | rossberg | btw, gcc gives a warning for vector.h about the template friend |
| 13:20.13 | rossberg | this warning can be switched off, but i don't know how to do this for vector.h only |
| 13:27.42 | brlcad | rossberg: if you know the warning number, you can add a pragma to disable it |
| 13:29.45 | brlcad | e.g. #if defined(_MSC_VER) && _MSC_VER >= 1100 #pragma warning(disable: ####) #endif |
| 13:30.14 | rossberg | brlcad: ok, i'll have a look at this ... next week |
| 13:30.48 | brlcad | should be used sparingly of course, but if it causes problems, that should do the trick |
| 13:32.43 | rossberg | the warning is about the programmer might want a different beahvior, however i want exactly the current behavior |
| 14:09.09 | ``Erik | strlcpy() might be a good idea, but migrating our usage of strcpy to it might take a fair bit of 'grunt' effort |
| 14:09.17 | *** join/#brlcad Elperion (n=Elperion@p548767EF.dip.t-dialin.net) | |
| 14:13.57 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/autogen.sh: |
| 14:13.57 | CIA-7 | BRL-CAD: be extra careful about clearing out variables when we're done with them and |
| 14:13.57 | CIA-7 | BRL-CAD: utilizing even less space when encoding string chars.. we're right up against |
| 14:13.57 | CIA-7 | BRL-CAD: the ARG_MAX limit on irix and (some) bsd systems where keeping two copies of our |
| 14:13.59 | CIA-7 | BRL-CAD: COPYING file in memory is turning out to be too much, but everything is fine if |
| 14:14.01 | CIA-7 | BRL-CAD: we only ever have just one copy of the file retained in memory. ahh, such |
| 14:14.03 | CIA-7 | BRL-CAD: abusive fun with environment variables. |
| 14:39.33 | brlcad | meh, seems like busy work and somewhat politically charged |
| 14:42.29 | *** join/#brlcad cad23 (n=db444236@bz.bzflag.bz) | |
| 14:55.23 | ``Erik | ok, strncpy() *shrug* |
| 15:13.10 | ``Erik | heh |
| 15:13.51 | ``Erik | on "make dist" |
| 15:13.51 | ``Erik | make[4]: Entering directory `/some/path/src/other/tcl/unix' |
| 15:13.51 | ``Erik | make[4]: *** No rule to make target `distdir'. Stop. |
| 15:17.05 | CIA-7 | BRL-CAD: 03erikgreenwald * 10brlcad/src/irprep/ir-sgi.c: include bu.h for bu_fgets |
| 15:18.27 | CIA-7 | BRL-CAD: 03erikgreenwald * 10brlcad/src/irprep/Makefile.am: reduce LDADD libs to minimal. Add deps info. |
| 17:28.38 | CIA-7 | BRL-CAD: 03erikgreenwald * 10brlcad/src/tclscripts/mged/help.tcl: Added help for reset/bv_reset (fixes bug 1219087) |
| 18:33.32 | IriX64 | just realized something, sorry i won't do it again. |
| 18:38.44 | ``Erik | I don't think this channel is intended for getting your hand on someones nozzle. O.o |
| 18:39.19 | IriX64 | heh I'm male but thanks for the offer ;) |
| 18:39.46 | brlcad | ``Erik: yeah, I noticed that too -- all of the automake targets aren't in tcl's makefile since they only use autoconf |
| 18:39.54 | brlcad | e.g. make etags too |
| 18:40.37 | brlcad | have to provide similar recursion halts in src/other/tcl/Makefile.am |
| 18:41.11 | brlcad | maybe make it not be a SUBDIRS, and just do a cd && make manually |
| 18:41.27 | brlcad | so that the other rules can be removed too |
| 18:41.50 | brlcad | strncpy cleanup is a great idea |
| 18:42.17 | brlcad | i was going to focus on that as part of the Pedro's security scan cleanup |
| 18:42.32 | brlcad | still a release or two away |
| 18:42.37 | ``Erik | that might be a 'jr developer' task |
| 18:43.16 | ``Erik | dist/distcheck is kinda, uh, important... though... |
| 18:45.15 | brlcad | the security cleanup isn't necessarily, but yeah on the gruntage |
| 18:49.56 | brlcad | IriX64: you ever get to testing those geometry conversions? or plan/hope to? really would be helpful |
| 18:50.09 | brlcad | moreso that compilation testing :) |
| 18:51.01 | IriX64 | dont have the patience, but your team should be able to do: g-dxf followed by a dxf-g and likle wise for all of them, you darn well better get back what you started with. |
| 18:51.57 | brlcad | you're talking to the team, we're working on other aspects of the project |
| 18:52.11 | IriX64 | heh maybe ill tackle it then. |
| 18:52.27 | IriX64 | start with g files i better get back a proper g file :) |
| 18:52.55 | ``Erik | "the team" is kinda 2-3 people with 'todo' lists measured in au's O.o |
| 18:53.11 | brlcad | you won't end up with what you started with as dxf is a different representation, but it should resemble the original just in polygonal form |
| 18:53.19 | IriX64 | heh break the light speed barrier then :) |
| 18:53.51 | IriX64 | dxf-g tested it works. |
| 18:54.07 | IriX64 | and not just starting with a g file. |
| 18:54.15 | IriX64 | got a holt of a real dxf |
| 18:59.31 | CIA-7 | BRL-CAD: 03erikgreenwald * 10brlcad/src/other/openNURBS/Makefile.am: tuck openNURBS headers into a subdir instead of polluting include/ (should these be noinst?) |
| 19:05.09 | CIA-7 | BRL-CAD: 03erikgreenwald * 10brlcad/src/libbu/parallel.c: malloc.h was superceded by stdlib.h no later than c89, so try stdlib.h first |
| 19:07.07 | ``Erik | hm, openbsd really doesn't like the mixing of c and c++ |
| 19:14.56 | brlcad | README.BSD << "On OpenBSD, compile with ./configure CC=g++" is a perfectly viable punt for the short term too if there's only one or two like that |
| 19:18.47 | IriX64 | http://www.pastebin.ca/387972 < another project I play with :) |
| 19:23.48 | IriX64 | but for a real treat I prefer brlcad ;) |
| 19:28.57 | *** join/#brlcad clock_ (i=clock@84-72-89-40.dclient.hispeed.ch) | |
| 19:29.15 | clock_ | Funny message on OpenBSD |
| 19:29.33 | clock_ | When compiling Ronja. Cannot fork, try again. Checked processes, didn't find any excess number of processes |
| 19:31.13 | ``Erik | cool, I'm not seeing that on my obsd box :) |
| 19:34.09 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/autogen.sh: avoid the square brackets |
| 19:48.33 | ``Erik | stupid square brackets *shakes fist* </homersimpson> |
| 19:49.29 | brlcad | yeah, took me a bit to realize that stupidity |
| 19:49.53 | brlcad | don't see how it worked on two platforms I tested.. but it did |
| 19:49.59 | brlcad | greedy match |
| 19:51.39 | ``Erik | hm, the CC=g++ hack can't work on OpenBSD without mods tcl refuses to compile |
| 19:52.13 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/autogen.sh: initialize from the starting directory |
| 19:53.36 | brlcad | really .. that's odd |
| 19:53.50 | brlcad | what about just linking with g++ |
| 19:54.01 | brlcad | ./configure LD=g++ or something iirc |
| 19:54.39 | ``Erik | -Wno-implicit-int makes it puke |
| 19:55.11 | brlcad | ahh, I take it that is something tcl's adding |
| 19:55.37 | ``Erik | yes, in src/other/tcl/unix/Makefile.am |
| 19:57.16 | ``Erik | er, .in, not .am, sorry |
| 20:05.40 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/autogen.sh: remove debug printing |
| 20:10.05 | CIA-7 | BRL-CAD: 03erikgreenwald * 10brlcad/src/other/blt/library/ (Makefile.am dd_protocols/Makefile.am): remove the pkgIndex.tcl (unused) and tclIndex (shouldn't ever need to be generated) targets so non-GNU make's work when builddir!=srcdir |
| 20:11.47 | *** join/#brlcad Elperion (n=Elperion@p548767EF.dip.t-dialin.net) | |
| 20:14.39 | ``Erik | [[['''']['''']['''']['''']][['''']['''']['''']['''']] |
| 20:14.41 | ``Erik | nice |
| 20:35.20 | CIA-7 | BRL-CAD: 03erikgreenwald * 10brlcad/configure.ac: try to cope with OS's that don't like dots in library names |
| 20:44.08 | clock_ | |'''' |
| 20:44.18 | clock_ | |''''|''''|''''|''''|''''|'''' |
| 20:44.39 | CIA-7 | BRL-CAD: 03jlowenz * 10brlcad/include/brep.h: rename brep_hbv to more appropriate brep_bv |
| 20:46.07 | CIA-7 | BRL-CAD: 03jlowenz * 10brlcad/src/librt/g_brep.cpp: begin implementation of rt_brep_prep: construct BVH, and precalculate cdbitems |
| 20:46.08 | ``Erik | heh, I believe what I pasted was brlcad's "extra square brackets" effect on some of my files... :) |
| 21:00.57 | ``Erik | a/det |
| 21:01.00 | ``Erik | bah |
| 21:22.43 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/src/other/ (tcl/Makefile.am tk/Makefile.am): restore make dist support by removing 'unix' as a SUBDIRS; add rules for all-am and clean-am for starters. only tested on fbsd thusfar. |
| 21:47.17 | brlcad | that doesn't fix distcheck, but does generate the dist |
| 21:47.21 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/autogen.sh: need to recursively delete the autom4te.cache directories else there can be a plethora of build problems of the "Can't locate object method "path" via package "Request" sort. |
| 21:57.02 | Maloeran | Ahahah, this is so sad - http://theflatearthsociety.org/forum/index.php?topic=11211.0 |
| 22:48.58 | IriX64 | love make -i :) |
| 22:49.14 | IriX64 | finished the build in spite of adrt. |
| 22:53.40 | IriX64 | too many undefined references though for it to be your problem. |
| 22:58.34 | IriX64 | why is python2.4 in makefile.in for adrt/isst/master? I have python 2.5 and theres no version number shown in config.log. |