| 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. |