01:50.14 |
CIA-62 |
BRL-CAD: 03kunigami * r45751
10/brlcad/trunk/src/rt/ (do.c ext.h opt.c view.c): |
01:50.14 |
CIA-62 |
BRL-CAD: added simple support for the
multi-sample framebuffer. I'm currently using the |
01:50.14 |
CIA-62 |
BRL-CAD: scanline array to hold the partial
averages, but this is not good since it is a |
01:50.14 |
CIA-62 |
BRL-CAD: char array and many values will be
truncated when I compute the next average. I |
01:50.14 |
CIA-62 |
BRL-CAD: think we must use a dedicated buffer
to hold these averages. To test this mode, |
01:50.15 |
CIA-62 |
BRL-CAD: compile with
-DEXPERIMENTAL_MODE |
01:51.13 |
CIA-62 |
BRL-CAD: 03kunigami * r45752
10/brlcad/trunk/src/liboptical/ (liboslrend.cpp sh_osl.cpp): the
experimental mode should be used with path-tracing, turning off
ray-tracing on sh_osl... |
03:43.59 |
brlcad |
kunigami: what do you mean by "turning off
ray-tracing on sh_osl"? |
03:44.48 |
brlcad |
ah, you mean your single-ray test? |
03:46.28 |
brlcad |
mm, looks like it |
03:47.29 |
brlcad |
so question about that for loop at the end of
sh_osl.cpp .. it looks like it's basically calling rt_shootray()
over and over again unless it's a refraction ray |
03:52.12 |
brlcad |
ah, but only if reflection is being performed,
hmm |
03:57.49 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
04:37.24 |
CIA-62 |
BRL-CAD: 03bhinesley * r45753
10/brlcad/trunk/src/libged/edit.c: |
04:37.24 |
CIA-62 |
BRL-CAD: edit() will now "expand" batch
operation args, by performing a deep copy of |
04:37.24 |
CIA-62 |
BRL-CAD: every target obj's edit_arg struct,
consolidating option flags between the two |
04:37.24 |
CIA-62 |
BRL-CAD: as necessary. Added detection of
keypoints missing their matching 'TO' arg, |
04:37.24 |
CIA-62 |
BRL-CAD: since every cmd should have that
behavior. Replaced edit_arg_free_if_empty() |
04:37.25 |
CIA-62 |
BRL-CAD: with edit_arg_is_empty; a bit more
versatile that way. |
05:07.03 |
Stattrav |
can i compile the source on my computer by
suppressing the "treating warnings as errors" notification
? |
05:07.15 |
Stattrav |
for a dev machine for brlcad ? |
06:35.16 |
*** join/#brlcad Stattrav
(~Stattrav@117.213.184.103) |
06:35.16 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
06:40.15 |
*** join/#brlcad Stattrav_
(~Stattrav@117.202.27.11) |
06:52.32 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.131.187) |
06:52.33 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
07:09.33 |
bhinesley |
Stattrav, if you're using autotools, use
"--disable-strict". If you're using cmake, you can use
-DBRLCAD-ENABLE_STRICT=OFF |
07:10.41 |
Stattrav |
bhinesley: aah compiled by removing -Werror :)
thanks. i shall make a note of it for the next time |
07:11.17 |
bhinesley |
no problem |
11:27.57 |
*** join/#brlcad ibot
(~ibot@rikers.org) |
11:27.57 |
*** topic/#brlcad is BRL-CAD
Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is
participating in the ESA Summer of Code in Space! |
11:38.30 |
*** join/#brlcad brlcad
(~sean@BZ.BZFLAG.BZ) |
11:38.43 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.129.74) |
11:38.43 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
11:57.13 |
CIA-62 |
BRL-CAD: 03starseeker * r45754
10/brlcad/branches/STABLE/src/libfft/CMakeLists.txt: Add the libfft
CMakeLists.txt tweak to STABLE. |
12:18.58 |
brlcad |
there were probably a hundred places that
needed M_LIBRARY |
12:46.25 |
starseeker |
brlcad: that one specifically fell out of a
particular compile |
12:48.42 |
starseeker |
it was when I tossed in the -Wl,--no-undefined
line to CMAKE_SHARED_LINKER_FLAGS - that one, and only that one,
failed (IIRC) |
13:28.02 |
CIA-62 |
BRL-CAD: 03starseeker * r45755
10/brlcad/trunk/CMakeLists.txt: CMake doesn't currently work with
umask settings, so there's no point in setting it ahead of
time. |
14:06.34 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
14:34.31 |
*** join/#brlcad kunigami_
(~kunigami@201.53.206.27) |
14:46.10 |
abhi2011 |
Hi, while using the cmake build is there a
flag to stop treating warnings as errors |
14:46.36 |
abhi2011 |
just as with the autotools build there is
./configure --enable-all --disable-strict --with-ogl |
14:55.18 |
abhi2011 |
ah its just a simple flag :P : cmake
../brlcad -DBRLCAD-ENABLE_OPTIMIZED=ON
-DBRLCAD-ENABLE_STRICT=OFF |
15:01.22 |
brlcad |
starseeker: ah, the issue is that for some
platforms, no-undefined is the system default for ld |
15:01.35 |
brlcad |
there were two users in here that run into
that problem (with fedora, I believe) |
15:23.42 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
15:32.19 |
CIA-62 |
BRL-CAD: 03brlcad * r45756
10/brlcad/trunk/src/rt/view.c: quell variable type warnings, stub
in code for displaying progress during raytrace ... which
unfortunately kills render performance. |
15:33.33 |
CIA-62 |
BRL-CAD: 03brlcad * r45757
10/brlcad/trunk/src/rt/do.c: more type quellage (someone needs to
compile strict) .. use bu_log() instead of fprintf(). only bu_log()
supports %z for size_t types (with c90). |
17:04.47 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.146.245) |
17:04.47 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
17:38.07 |
abhi2011 |
brlcad compiled and ran successfully with
cmake under opensuse 11.4, though the gcc is old (gcc
4.5.1) |
17:38.32 |
brlcad |
that's not really an old gcc |
17:38.44 |
brlcad |
4.0 is old, 4.2 is a little old |
17:41.16 |
brlcad |
dang .. something still doesn't seem right
with cmake debug builds .. no debugging symbols in the
binary |
17:41.28 |
brlcad |
CMAKE_MODULE_LINKER_FLAGS_DEBUG:STRING= |
17:41.45 |
brlcad |
that doesn't look right, need -g during
compilation and linking |
17:41.55 |
brlcad |
CMAKE_SHARED_LINKER_FLAGS_DEBUG:STRING= |
17:41.57 |
brlcad |
too |
17:48.26 |
``Erik |
heh, rhel5 ships with 4.1.2, fbsd8 is 4.2.2,
osX xcode3 is 4.2.1 O.o 4.5 sounds pretty new to me :D |
17:49.12 |
abhi2011 |
yes true, i meant since 4.6.0 is out now
:P |
17:49.27 |
abhi2011 |
the CMAKE_MODULE_LINKER_FLAGS_DEBUG is not one
of the cmake flags is it ? |
17:49.44 |
abhi2011 |
i dont see it in CMakeLists.txt |
17:58.02 |
brlcad |
no worries, that was more a directed inquiry
towards starseeker |
17:59.31 |
starseeker |
brlcad: I haven't been doing much in the way
of setting linker flags thus far |
18:00.07 |
starseeker |
so yeah, there are probably some we'll need to
add |
18:00.09 |
brlcad |
so you've not been working in gdb very much I
take it then? :) |
18:00.28 |
starseeker |
not too much lately, but I have done so
before... |
18:01.09 |
starseeker |
never noticed anything amiss, which probably
means I wasn't doing something right... |
18:01.31 |
brlcad |
I think that's the crux of the issue,
debug/cflags used for compile aren't being used during
linking |
18:02.06 |
starseeker |
um... which issue? |
18:02.46 |
starseeker |
now remembers why he loathed
the tcl build system so much... gah |
18:02.52 |
brlcad |
I have binaries getting linked without debug
symbols |
18:03.09 |
brlcad |
and sure enough, if I make VERBOSE=1, there is
no -g on the linker line |
18:04.24 |
brlcad |
/vld/other/morrison/Applications/bin/gcc
-pipe -fno-strict-aliasing -fno-common -fexceptions -std=gnu99 -m64
-pedantic -Wall -Wextra -Wundef -Wfloat-equal -Wshadow -Winline
-Wno-long-long -Werror -m64 CMakeFiles/myapp.dir/myapp.c.o -o
../../bin/myapp -rdynamic ../../lib/libwdb.so.19.0.1 -lm
../../lib/librt.so.19.0.1 ../../lib/libbn.so.19.0.1
../../lib/libbu.so.19.0.1 -lpthread -lpng
../../lib/libsysv.so.19.0.1 ../../lib/libtcl.so.8.5.9 -lm -ldl
../../lib/ |
18:04.50 |
``Erik |
huh, mysql went cmake |
18:04.52 |
brlcad |
so it's passing a whole variety of flags, but
not -g |
18:05.19 |
starseeker |
k - that's probably a missing line in
CMake/CompilerFlags.cmake |
18:08.17 |
CIA-62 |
BRL-CAD: 03starseeker * r45758
10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: Add the debug flag
to the shared library linker line - may need to fix more than this,
but it's a start |
18:10.03 |
brlcad |
what is CMAKE_SHARED_LINKER_FLAGS_${CFG_TYPE}
? |
18:10.10 |
brlcad |
other flags don't set that... |
18:10.51 |
CIA-62 |
BRL-CAD: 03starseeker * r45759
10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: key off of the
debug option, not build type, since we might be turning on debug
flags even in a release build. |
18:11.13 |
CIA-62 |
BRL-CAD: 03brlcad * r45760
10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: setting
cflags/cxxflags is insufficient (or cmake is wrong to not apply
cflags during linking), the linker needs to have debug flags for
executables too |
18:11.28 |
starseeker |
brlcad: that's CMAKE_SHARED_LINKER_FLAGS_DEBUG
for a debug build, CMAKE_SHARED_LINKER_FLAGS_RELEASE
build |
18:12.09 |
brlcad |
but then what purpose does
CMAKE_SHARED_LINKER_FLAGS serve? |
18:12.28 |
starseeker |
if you have no build type at all set, it falls
back on that one (if I understand correctly) |
18:13.03 |
starseeker |
I'm currently making people work to NOT have a
build type set, but that's relatively recent |
18:13.04 |
brlcad |
err, I thought I saw a message during cmake
saying "build profile not set, using Debug" ? |
18:13.47 |
starseeker |
yeah - that's me turning it on if it's not set
- you can force it to stay off by specifying NONE (I think) but the
assumption is you want the build type set |
18:15.15 |
brlcad |
cmake doesn't use LD_FLAGS? |
18:15.41 |
starseeker |
um - you mean if you specify it on the command
line? not sure |
18:15.49 |
brlcad |
no, I mean internally |
18:16.04 |
brlcad |
C_FLAGS and CXX_FLAGS variables get
set |
18:16.07 |
starseeker |
oh - no, I think it uses the
SHARED_LINKER_FLAGS stuff |
18:16.20 |
brlcad |
but curiously no LD_FLAGS, which would be the
pairing |
18:16.37 |
brlcad |
is C_FLAGS a var you came up with or
cmake? |
18:17.07 |
starseeker |
I believe that one is CMake |
18:17.25 |
starseeker |
http://cmake.org/Wiki/CMake_Useful_Variables |
18:18.20 |
brlcad |
CFLAGS/CXXFLAGS/CPPFLAGS/LDFLAGS are the
historic var names |
18:18.51 |
brlcad |
er, they list CMAKE_C_FLAGS .. that's not the
same as C_FLAGS |
18:19.06 |
starseeker |
oh, yeah - sorry |
18:19.31 |
starseeker |
I've found that list to be very useful, seems
to be fairly accurate |
18:20.55 |
brlcad |
so you set C_FLAGS, and presumably down the
line, CMAKE_C_FLAGS is set to your C_FLAGS |
18:22.10 |
starseeker |
right |
18:25.24 |
starseeker |
hmm... actually, I can probably clean up that
logic some |
18:26.52 |
CIA-62 |
BRL-CAD: 03brlcad * r45761
10/brlcad/trunk/src/libbu/getopt.c: style cleanup |
18:27.56 |
CIA-62 |
BRL-CAD: 03brlcad * r45762
10/brlcad/trunk/src/libbu/getopt.c: no place for you |
18:28.11 |
starseeker |
I was using a lot of my own variables in the
earlier days, before I got a handle on what variables were used for
what |
18:36.50 |
starseeker |
brlcad: ah, right - I remember now. C_FLAGS
is actually a variable holding the name of the correct
CMAKE_C_FLAGS_* variable for the build type |
18:45.38 |
brlcad |
hm, neat trick, but sounds potentially
problematic |
18:46.11 |
brlcad |
since for some of the output targets, cmake
generates all build profiles into the output (e.g., studio or
xcode) |
18:50.51 |
starseeker |
does it? I was under the impression you had
to specify Debug or Release at CMake time, but I could be
wrong |
18:51.26 |
brlcad |
possibly, but those build systems do support
multiple configurations |
18:52.10 |
brlcad |
MSVC pretty much came up with the concept of
separate Debug and Release build configurations (named as
such) |
18:53.22 |
starseeker |
nods - the question though
is whether CMake actually generates both configurations in valid
form from a single CMake run |
18:53.27 |
brlcad |
yep |
18:58.19 |
brlcad |
this makes it sound like it does: http://www.cmake.org/pipermail/cmake/2010-January/034365.html |
19:05.53 |
starseeker |
hmm... mutter... |
19:13.06 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.146.245) |
19:13.06 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
19:15.07 |
CIA-62 |
BRL-CAD: 03starseeker * r45763
10/brlcad/trunk/ (CMakeLists.txt misc/CMake/CompilerFlags.cmake):
More refinement of the compiler flags logic. May have to go one
step further for MSVC project files... |
19:22.34 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
19:51.16 |
CIA-62 |
BRL-CAD: 03starseeker * r45764
10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: Have a go at
setting compiler flags for all configurations. |
19:51.28 |
starseeker |
brlcad: that might do it |
19:52.39 |
CIA-62 |
BRL-CAD: 03starseeker * r45765
10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: whoops,
typo |
20:05.16 |
CIA-62 |
BRL-CAD: 03starseeker * r45766
10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: Some cleanup and
typo fixes, make the ADD_NEW_FLAG macro a bit more
flexible |
20:07.25 |
starseeker |
huh, cool: http://chiselapp.com/user/andreas_kupries/repository/crimp/home |
21:28.07 |
*** join/#brlcad dtidrow
(~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) |