00:50.03 |
starseeker |
brlcad: yow, there's a lot of perl code for
the docbook stuff |
00:50.24 |
starseeker |
do we go with that or did you want it
translated into CMake+xml? |
00:51.48 |
starseeker |
wonders how much of this
generation of pages can be done using templates and
configure_file... |
00:54.00 |
starseeker |
sets up the autotools build
to see what is being done... |
00:55.01 |
starseeker |
prefers not to rely on perl
if we don't have to... don't think there's anywhere else we need
it... |
00:57.58 |
starseeker |
brlcad: http://www.cmake.org/pipermail/cmake/2011-September/046475.html |
01:00.10 |
starseeker |
no dice :-/ |
02:22.33 |
*** join/#brlcad KimK
(~Kim__@209.248.147.2.nw.nuvox.net) |
03:15.23 |
CIA-48 |
BRL-CAD: 03tbrowder2 * r46978
10/brlcad/trunk/doc/docbook/create-book-covers.pl: allow for both
xml and fo suffixes to be recognized for generation to
work |
03:16.26 |
CIA-48 |
BRL-CAD: 03tbrowder2 * r46979
10/brlcad/trunk/doc/docbook/fop.xconf.in: correct font data to
cover font substitution warnings |
03:18.38 |
CIA-48 |
BRL-CAD: 03tbrowder2 * r46980
10/brlcad/trunk/doc/docbook/Makefile.am: add targets for testing
book covers\nexectute create-book-covers for bot fo and pdf due to
files changes with color changes for each volume |
04:01.13 |
brlcad |
starseeker: installing perl on windows
wouldn't be an unreasonable requisite if we want to make building
the pdfs on windows possible |
04:01.21 |
brlcad |
so it's really about converting the
Makefile.am logic into cmake terms |
04:02.48 |
brlcad |
if perl isn't detected, it doesn't
try |
04:02.52 |
brlcad |
just like fop |
04:06.07 |
brlcad |
starseeker: as for the find_library reply, he
sets it up for you right there at the end... "job is to find
library files" |
04:36.45 |
brlcad |
starseeker: sent you what I'd reply, not that
you have to use it.. but his response was a particularly heavy
stuffed straw-man |
04:37.17 |
starseeker |
was trying to figure out how to continue the
discussion without pissing him off |
04:37.46 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
04:38.02 |
*** join/#brlcad KimK
(~Kim__@209.248.147.2.nw.nuvox.net) |
04:38.05 |
brlcad |
he's intentionally trolling for some reason
(or is just a bit of a jerk) |
04:38.38 |
brlcad |
reminds me of one of the bz devs, hyperbole
overload |
04:41.24 |
brlcad |
left to implement tools like 'ls', you'd not
actually get a current listing of files because, well, you can't
actually detect if the disk drive failed or if the filesystem is
corrupted, so it's better if it just returns the listing that was
there at boot-up |
04:44.05 |
*** join/#brlcad dtidrow_desk
(~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) |
04:52.42 |
starseeker |
brlcad: he mentioned
/usr/lib/x86_64-linux-gnu/libc.so on ubuntu is a linker script -
would that be all <128 characters? |
04:56.40 |
brlcad |
starseeker: yep that would be, though that's
actually one of the points I'm claiming -- that's not a library,
it's a gnu linker script |
04:57.18 |
``Erik |
<PROTECTED> |
04:57.19 |
brlcad |
basically a gnu-ld-specific symbolic link of
sorts |
04:58.11 |
brlcad |
it's not a libtool archive .. they actually
gang up and use the same filename/suffix pattern -- ld reads the
file and recognizes it as an ld script |
04:58.19 |
brlcad |
f'd up |
04:58.29 |
``Erik |
that's... very.... linuxy. |
04:58.43 |
``Erik |
sorry, gnu/linuxy |
04:59.41 |
brlcad |
"special" is the word |
04:59.53 |
brlcad |
needs-a-helmet "special" |
05:00.20 |
``Erik |
meh, synonymous O:-) |
05:00.44 |
brlcad |
starseeker: that gets back to the original
point that the only real way to tell it to try and link
it |
05:01.17 |
brlcad |
if you're cross-compiling, you just don't
halt/fail/test/whatever .. though presumably I have a
cross-compiler and cross-compilation libs somewhere that will
work! |
05:02.37 |
``Erik |
that'd be an interesting experiment... install
a cross compiler from /usr/ports/, try to build BRL-CAD, then try
to run it in an emulator for that platform O.o |
05:06.38 |
starseeker |
has never tangled with
cross-compilation - scary sounding stuff from the early days of
bootstrapping computers is where I know the phrase
from |
05:08.17 |
``Erik |
I used to do it on linux to target win32, and
have fairly recently done it to generate an arm fbsd
tftp/nfsboot |
05:09.41 |
``Erik |
as far as the compiler, it's no big deal, just
CC=/usr/local/bin/gcc-mingw32 make... figuring out how to set all
the right config options and flags can expose a lot in an automatic
configuration system, though :) |
05:20.16 |
starseeker |
once more unto the breach dear friends...
http://www.cmake.org/pipermail/cmake/2011-September/046478.html |
05:48.27 |
brlcad |
thinks the glorified
fnmatch() comparison was warranted, but not too
shabby |
05:48.54 |
brlcad |
left yourself open to attack in a few places,
but the point was in there |
06:19.34 |
starseeker |
is a rather straightforward
sort, not too good at this sort of manuvering |
06:45.42 |
brlcad |
not that straighforward .. very wordy reply
:) |
06:47.27 |
brlcad |
my tort respones were direct, you're timidly
beating around the bush trying to be polite while skirting around
your point before getting to it |
06:47.38 |
brlcad |
at least that's my take, it's still
good |
06:49.30 |
brlcad |
I just suspect he'll nit pick something minor,
hemhaw on some irrelevant detail, and ignore your points (like how
he basically ignored your earlier reference to
AC_CHECK_LIB) |
06:52.42 |
kanzure |
hi brlcad |
06:52.49 |
kanzure |
thanks for the scl/step update |
07:39.13 |
*** join/#brlcad jordisayol
(~jordisayo@unaffiliated/jordisayol) |
08:08.45 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
08:26.56 |
*** join/#brlcad jordisayol
(~jordisayo@unaffiliated/jordisayol) |
10:06.54 |
*** join/#brlcad kunigami_
(~kunigami@201.82.92.180) |
10:10.56 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
10:14.23 |
*** part/#brlcad kunigami_
(~kunigami@201.82.92.180) |
10:44.18 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
11:37.46 |
*** join/#brlcad abhi2011
(~chatzilla@wlan-145-94-170-216.wlan.tudelft.nl) |
11:44.59 |
*** join/#brlcad abhi2011_
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
12:19.30 |
CIA-48 |
BRL-CAD: 03tbrowder2 * r46981
10/brlcad/trunk/doc/docbook/README: added scribus as a program for
DB authors for converting eps to svg format |
12:22.12 |
CIA-48 |
BRL-CAD: 03tbrowder2 * r46982
10/brlcad/trunk/doc/docbook/README.DB_authors_notes: add info on
pdf graphics and eps conversions |
12:29.52 |
CIA-48 |
BRL-CAD: 03tbrowder2 * r46983
10/brlcad/trunk/doc/docbook/Makefile.am: trimmed some fat; added
missing tools to dist list |
12:49.20 |
*** join/#brlcad abhi2011
(~chatzilla@wlan-145-94-196-228.wlan.tudelft.nl) |
13:36.32 |
brlcad |
kanzure: no problem |
13:41.21 |
starseeker |
yawns |
13:42.46 |
brlcad |
yawns |
13:49.15 |
starseeker |
http://www.cmake.org/pipermail/cmake/2011-September/046479.html |
13:49.23 |
starseeker |
even better, http://www.cmake.org/pipermail/cmake/2011-September/046481.html |
13:52.58 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
14:04.39 |
CIA-48 |
BRL-CAD: 03d_rossberg * r46984
10/brlcad/trunk/CMakeLists.txt: |
14:04.39 |
CIA-48 |
BRL-CAD: the current setting of compiler flags
does not work for the MSVC compiler, it results in a broken
build |
14:04.39 |
CIA-48 |
BRL-CAD: (The CMake standard for MSVC is
linking with the C-runtime-DLL, which is OK. The ridiculous gcc
flags force MSVC to use its own standards: Linking every DLL
statically with a separate C-runtime.) |
14:05.18 |
starseeker |
d_rossberg: hmm. I just built with MSVC a day
or two ago... |
14:05.49 |
starseeker |
you mean MSVC is mis-interperting a gcc
flag? |
14:07.10 |
d_rossberg |
i'm afraid it misinterprets every gcc flag
(see the compiler warnings) |
14:08.20 |
d_rossberg |
the gcc flags will only be set for the choosen
build type |
14:09.25 |
d_rossberg |
i.e. if you have choosen release for CMake but
compiling Debug with your Visual Studio the build could
work |
14:10.20 |
starseeker |
winces |
14:10.20 |
d_rossberg |
but otherwise asc2g will crash many time
during the build |
14:11.13 |
starseeker |
that business of allowing MSVC and/or XCode to
have multiple configs is a real pain |
14:11.15 |
d_rossberg |
btw: i couldn't find a way to build
libitcl.dll |
14:11.48 |
starseeker |
you mean it crashes? |
14:11.52 |
d_rossberg |
the CMake defaults are doing a good job for
MSVC |
14:12.29 |
d_rossberg |
there are undefined symbols in itcl |
14:12.55 |
starseeker |
brlcad: what's your take - should we let the
MSVC defaults ride? |
14:13.20 |
starseeker |
d_rossberg: can you post a build log for itcl?
(also, which Visual Studio? I recently built with
10...) |
14:23.16 |
d_rossberg |
do you mean something like this: http://brlcad.org/~rossberg/BuildLog.htm |
14:24.35 |
d_rossberg |
MSVC 2008 (German :) |
14:25.28 |
starseeker |
that looks right... |
14:30.22 |
d_rossberg |
all i did was making a svn checkout and
choosing an "aBuild" subdirectory as cmake working
directory |
14:30.51 |
starseeker |
what library implements sprintf in
MSVC2008? |
14:31.20 |
starseeker |
that looks like we need another MSVC library
in the linker line, but I'm not sure which one |
14:33.36 |
starseeker |
this might pertain to one of those linker
errors... http://support.microsoft.com/kb/894573 |
14:35.15 |
d_rossberg |
sprintf is part of the c-runtime
library |
14:35.31 |
*** join/#brlcad n_reed
(~molto_cre@BZ.BZFLAG.BZ) |
14:35.38 |
starseeker |
what do we feed to the linker list to get the
c-runtime? |
14:41.31 |
starseeker |
is there a /GS or /Gs flag in the build
somewhere? |
14:42.09 |
d_rossberg |
i think saying /MD or /MDd does it,
/NODEFAULTLIB would remove all defaults (in this case one had to
set the libraries all by hand) |
14:43.53 |
starseeker |
d_rossberg: go ahead and add what you need -
I'll try it on 2010 later |
14:53.08 |
d_rossberg |
1st: it looks like its a problem with the
debug configuration, release is ok (at least at the
moment) |
14:53.41 |
brlcad |
starseeker: they're obsessing over symbolic
links, but that's still ignoring the elephant in the room to me --
just looking at the file name makes it a glorified fnmatch()
wrapper |
14:54.34 |
d_rossberg |
then i could compile and link the debug too by
changing the c-runtime to debug-dll in the compiler
settings |
14:55.01 |
d_rossberg |
it looks like the is somewhere a /MD instead
of /MDd ... |
15:03.09 |
brlcad |
how are gcc flags getting added to the msvc
build? a simple compile test should ensure that they're detected
as non-functional |
15:03.20 |
brlcad |
if they're not, sounds like the compile test
is flawed |
15:03.25 |
starseeker |
hah, cool: http://www.evilmadscientist.com/article.php/visdiff |
15:04.24 |
starseeker |
brlcad: if I understood him correctly, it's
when you tell CMake one thing for build configuration and then do
the other thing in MSVC |
15:04.42 |
starseeker |
XCode probably has similar issues |
15:04.58 |
brlcad |
how would that result in it thinking that
-pipe is a valid flag? |
15:05.34 |
starseeker |
d_rossberg: what were the specific errors you
were seeing? (and what compile flags were getting passed
in?) |
15:05.59 |
brlcad |
there should have been a -pipe test (which
fails), and both debug and release configs would use $PIPE_FLAG or
whatever so it'd never get added |
15:06.30 |
starseeker |
I don't know if it was pipe
specifically |
15:06.39 |
brlcad |
his error log lists a -pipe |
15:07.03 |
brlcad |
if pipe got through, they all would probably
get through |
15:07.13 |
starseeker |
d_rossberg: do you happen to have your CMake
log handy? |
15:08.52 |
starseeker |
that's the itcl build, it's probably a lot
dumber than our mail BRL-CAD build |
15:09.44 |
starseeker |
main even |
15:10.27 |
starseeker |
did he post a build log for the original gcc
compile failure? |
15:10.45 |
brlcad |
not that I saw |
15:10.51 |
starseeker |
that'd be the one we need |
15:11.38 |
brlcad |
or examine the build log on our end with that
action, cmake as debug, change to release in studio,
compile |
15:11.44 |
d_rossberg |
unknown compile flags are ignored (what you
can see in the log) |
15:12.07 |
starseeker |
ignored and the compile succeeds?
(crud) |
15:13.00 |
d_rossberg |
the problem arise when you replace the
reasonable cmake defaults by garbage |
15:13.32 |
d_rossberg |
then you have the msvc defaults, which are not
optimal bor brl-cad |
15:13.39 |
starseeker |
clang has that same issue - it'll cheerfully
ignore unknown flags and succeed |
15:14.15 |
starseeker |
the cmake defaults shouldn't be getting
replaced by garbage though |
15:14.19 |
d_rossberg |
adding garbage is no problem, replacing the
right settings is |
15:14.44 |
starseeker |
if we need to add MSVC specific compiler tests
to make sure the right MSVC settings are there, then we should do
that in CompilerFlags.cmake |
15:16.00 |
d_rossberg |
btw, i think i found the place to chage in the
itcl configuration; there are similar settings in other tcl/tk
libraries; need some time to test it out |
15:16.15 |
starseeker |
cool, thanks |
17:29.32 |
brlcad |
yay, search crashed |
17:40.16 |
CIA-48 |
BRL-CAD: 03brlcad * r46985
10/brlcad/trunk/src/librt/search.c: prevent search from crashing if
we can't get a directory pointer to a specified path. encountered
this with an object erroneously containing slashes in the
name. |
17:50.23 |
CIA-48 |
BRL-CAD: 03brlcad * r46986
10/brlcad/trunk/src/librt/ (db_anim.c db_tree.c prep.c tcl.c tree.c
wdb.c): check other callers of DB_FULL_PATH_CUR_DIR() to make sure
we don't try to dereference a NULL pointer. |
17:56.45 |
CIA-48 |
BRL-CAD: 03brlcad * r46987
10/brlcad/trunk/src/conv/3dm/3dm-g.cpp: don't use the file path as
the toplevel object name. use its basename instead since the
slashes cause hell. |
18:10.13 |
CIA-48 |
BRL-CAD: 03tbrowder2 * r46988
10/brlcad/trunk/doc/docbook/README: add info on the saxon-he xslt
2.0 processor and news of the recent release of the DB xslt 2.0
stylesheets |
18:49.36 |
CIA-48 |
BRL-CAD: 03tbrowder2 * r46989
10/brlcad/trunk/doc/docbook/Makefile.am: current process for DB
book covers does not allow parallel make processes so using special
.NOTPARALLEL target; also requires having book pdf generation in
one recipe from xml to fo to pdf |
18:50.48 |
CIA-48 |
BRL-CAD: 03tbrowder2 * r46990
10/brlcad/trunk/doc/docbook/README: reword; add release date of new
DB stylesheets for XSLT 2.0 |
20:23.56 |
*** join/#brlcad abhi2011_
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
20:59.02 |
CIA-48 |
BRL-CAD: 03starseeker * r46991
10/brlcad/trunk/src/librt/comb/comb.c: |
20:59.02 |
CIA-48 |
BRL-CAD: Gah. Older versions of BRL-CAD are
hard-coded to look for oshader in the |
20:59.02 |
CIA-48 |
BRL-CAD: attributes when importing combs. This
makes the particular label oshader an |
20:59.02 |
CIA-48 |
BRL-CAD: actual part of the .g file format
itself, and NOT writing it out was breaking |
20:59.02 |
CIA-48 |
BRL-CAD: import of shaders when a .g file is
created in a new version of BRL-CAD and |
20:59.03 |
CIA-48 |
BRL-CAD: subsequently opened in an older
version. Need to check what other hard-coded |
20:59.04 |
CIA-48 |
BRL-CAD: assumptions got accidently messed
with. |
22:17.08 |
*** part/#brlcad n_reed
(~molto_cre@BZ.BZFLAG.BZ) |
22:26.44 |
CIA-48 |
BRL-CAD: 03bob1961 * r46992
10/brlcad/trunk/src/tclscripts/archer/images/component_select.png:
Update component_select image. |