| 02:09.21 | brlcad | starseeker: if you always do a build the exact same way every time, nothing is likely going to ever change |
| 02:09.27 | brlcad | s/change/fail/ |
| 02:09.45 | brlcad | but then that's not very flexible either, akin to coding with blinders on |
| 02:51.16 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) |
| 03:07.47 | starseeker | will be curious what you did differently... |
| 03:08.22 | jordisayol | hello |
| 03:09.13 | starseeker | howdy |
| 03:09.25 | jordisayol | when will be the 7.20.4 release out? |
| 03:09.45 | starseeker | within a couple days would be my guess |
| 03:10.01 | jordisayol | aha, thanks! |
| 03:22.58 | brlcad | starseeker: I've long since moved on with all of the other release testing |
| 03:23.02 | brlcad | jordisayol: within a couple hours |
| 03:23.15 | brlcad | last round of distchecking now |
| 03:23.30 | jordisayol | good! |
| 03:23.34 | starseeker | brlcad: ah - was figuring there was busted CMake stuff I would have to look at... |
| 03:23.48 | brlcad | starseeker: fyi, I seem to consistently run into that fontconfig failure on 10.6 |
| 03:24.11 | brlcad | something wrong with the X11 search logic |
| 03:24.28 | starseeker | k. |
| 03:24.42 | starseeker | will see if a test machine is available |
| 03:25.11 | brlcad | it ends up not searching in /usr/X11/include where fontconfig/fontconfig.h lives, no -I/usr/X11/include on the compile line either |
| 03:25.21 | starseeker | growls |
| 03:25.31 | starseeker | why did trunk succeed and stable fail? |
| 03:25.50 | starseeker | or was that a separate issue? |
| 03:26.02 | brlcad | curiously, through all my mods of misc/CMake/FindX11.cmake, it didn't even seem to be using that macro/file |
| 03:26.19 | starseeker | nods - it probably was using one of the src/other copies |
| 03:26.22 | brlcad | separate issue I think |
| 03:26.27 | brlcad | I updated all the src/other copies too |
| 03:26.42 | brlcad | (can see in the commit history) |
| 03:26.46 | starseeker | that's one of the drawbacks of doing src/other configures before ours - we get their Find*.cmake files running first |
| 03:26.53 | starseeker | k |
| 03:27.42 | starseeker | all the more reason to try and get maintainership of the ones we care about in CMake |
| 03:27.44 | brlcad | in fact, curiously -- it's finding /usr/X11R6 during cmake .. and I removed ALL of our cmake file references to /usr/X11R6 and it still found/used it |
| 03:27.53 | starseeker | O.o |
| 03:28.24 | starseeker | darn Mac anyway... |
| 03:29.13 | starseeker | needs to make another try at Aqua support... heck with X11 on Mac... |
| 03:29.17 | brlcad | the mac X11 dirs are actually set up very sane on 10.6 |
| 03:29.46 | brlcad | autotools passes no problem, something is wrong in the logic |
| 03:29.55 | starseeker | nods |
| 03:29.59 | starseeker | I believe it |
| 03:30.12 | starseeker | I'll try to take a look tomorrow |
| 03:31.31 | brlcad | as it's the last remaining release issue, I'm going to tag the release with that issue unresolved so some users might get bitten |
| 03:31.53 | starseeker | nods - yeah, CMake isn't "official" yet so I'd say go |
| 03:32.27 | starseeker | does X11R6 *exist* on your Mac? |
| 03:32.50 | brlcad | yes, it is a symlink to X11 |
| 03:33.09 | starseeker | hmm |
| 03:33.38 | starseeker | and yet -I/usr/X11R6/include doesn't work for fontconfig.h? |
| 03:33.58 | brlcad | sure that'd work, but it's not on the compile line |
| 03:34.08 | starseeker | confound it |
| 03:34.32 | starseeker | alright, I'll have to debug it |
| 03:34.55 | brlcad | that's why I started trying to just debug the find macro, but couldn't seem to get it to do anything useful |
| 03:35.04 | brlcad | spent a day working on various angles |
| 03:35.12 | starseeker | winces - sorry about that |
| 03:35.18 | brlcad | not you, cmake just was not cooperating |
| 03:35.20 | starseeker | was rather fried after the last week |
| 03:35.59 | starseeker | has done various surgeries on the FindX11.cmake file to try and account for one issue or another, may have really messed it up somehow |
| 03:36.33 | brlcad | uncovered a rather extensive bit of scary differences on the tk command line... |
| 03:36.46 | starseeker | snorts - not surprised, actually |
| 03:37.02 | starseeker | I was trying to get it working, not shooting for command line parity |
| 03:37.07 | brlcad | i'm almost surprised that tk even works... |
| 03:37.11 | brlcad | http://brlcad.org/tmp/cmake_fail.patch |
| 03:37.32 | brlcad | don't show the tk guys that :) |
| 03:38.06 | starseeker | oh, I doubt they'll care either way - when I talked to Andreas, he didn't sound especially interested in changing the existing system |
| 03:38.23 | starseeker | (unfortunately, he was making Tcl/Tk usb drives and didn't see my talk :-( |
| 03:39.15 | brlcad | package name isn't right, features off that should be on, features on that should be off, worrisome threading settings, incorrect symbol import/export settings, .. :) |
| 03:40.21 | brlcad | subtleties for sure, but definitely enough "cause for concern" if/when tk ever crashes or has odd behavior |
| 03:40.55 | brlcad | first thing I'd want to do if we ran into a serious bug is try again with stock tk |
| 03:41.06 | brlcad | (or get closer to parity) |
| 03:41.07 | starseeker | nods - I pretty much reached burn-out trying to unwind their existing build settings |
| 03:41.45 | starseeker | that stupid thing they have to do with putting all their settings on the command line instead of a config.h file made it tough |
| 03:42.05 | brlcad | I would have thought that makes things easier |
| 03:42.49 | brlcad | always have the command line, and then "sometimes" compile_line+some_unknown_number_of_files_with_magical_#defines |
| 03:43.03 | brlcad | that just eliminates the latter, one list to worry about matching |
| 03:43.10 | starseeker | prefers diffing the resulting config.h files between old and new builds |
| 03:43.28 | brlcad | but then even the compile flags don't match |
| 03:44.31 | brlcad | I *think* they're all benign, but not sure |
| 03:44.37 | brlcad | especially about __attribute__\(\(__visibility__\(\"hidden\"\)\)\) |
| 03:44.48 | starseeker | didn't know what to make of that one |
| 03:45.23 | starseeker | it was bad enough trying to figure out all the tests for the stuff I *knew* I needed - pretty much if it wasn't clearly essential it got ignored |
| 03:45.47 | starseeker | remember the original effort was a side issue, a distraction from BRL-CAD itself |
| 03:46.21 | brlcad | a distraction to you perhaps :) |
| 03:46.30 | brlcad | to me, it's all part of the effort |
| 03:46.43 | starseeker | <snort> I was worried about being called to the carpet as it was |
| 03:46.43 | brlcad | if it's worth doing at all ... |
| 03:46.49 | brlcad | knows |
| 03:47.11 | brlcad | it's fine, it obviously works fairly well enough as it is |
| 03:48.01 | starseeker | oh, I agree it's worth doing right - maybe it's a side-effect of the conference, but I do think Tcl/Tk is a nice combination of features, license and small size compared to it's feature-set |
| 03:48.12 | brlcad | there are just so many rough edges that there are going to be numerous long-term maintenance and debugging costs, obscure errors down the road that take forever to dig into |
| 03:48.36 | starseeker | unfortunately, my compiling foo is relatively weak compared to the complexities of the build |
| 03:49.30 | starseeker | half the time I didn't know if a particular flag was a hold-over from ancient history I could ignore |
| 03:49.52 | starseeker | or a flag I would need on some platform other than the current one |
| 03:50.51 | starseeker | that __attribute__ flag being one case in point |
| 03:51.07 | brlcad | that's gcc linker hinting |
| 03:52.38 | brlcad | a quick google search would have answered that one :P |
| 03:52.45 | brlcad | most of them, really |
| 03:53.27 | brlcad | http://gcc.gnu.org/wiki/Visibility |
| 03:53.28 | starseeker | maybe *what* they were, but not whether they actually mattered for thing things we care about |
| 03:53.55 | brlcad | basically, it's gcc's way to hide a symbol that needs to be extern but you don't want to be public api |
| 03:54.09 | brlcad | very similar to dll_import/dll_export in msvc |
| 03:54.16 | starseeker | retches |
| 03:54.28 | starseeker | that has caused more grief... |
| 03:55.15 | brlcad | to whom? pretty straightforward linking concepts (and not unique to msvc) |
| 03:55.38 | brlcad | most compilers have the notion, some are through much more archane methods like explicit lists of symbols in text files |
| 03:56.04 | brlcad | gcc was actually a bit late to the game, but most commercial compilers have that feature |
| 03:58.23 | starseeker | nods - OK, looking over this article I can see why it might be useful in some situations... |
| 03:58.27 | brlcad | it lets you write a function "secret_special_sauce()" used by public API in several places, say rt_brilliant() and rt_awesome(), but not actually have to expose that function in the library |
| 03:59.10 | starseeker | do we use such a mechanism? I don't recall seeing it in our own build logic... |
| 03:59.41 | brlcad | we do not, it takes a little bit of API awareness and best practice to keep things clean |
| 03:59.53 | brlcad | libged is a prime example, though .. |
| 04:00.28 | brlcad | lots of functions bob keeps adding that need to be reusable within the library .. but make for HORRIBLE public api functions, completely inconsistent with the rest of the ged api |
| 04:01.09 | brlcad | been resorting to simple naming conventions to at least remove the ged_ prefix, helps |
| 04:01.39 | brlcad | but then they still need to be declared in ged's private header, not ged.h |
| 04:01.46 | brlcad | and that takes awareness, restraint, etc |
| 04:02.01 | starseeker | nods |
| 04:02.21 | brlcad | yay, final builds completed |
| 04:02.45 | starseeker | if I ever feel like tinkering with our build system again, sit on me 'til the urge passes |
| 04:02.50 | brlcad | cept cmake of course, |
| 04:03.43 | brlcad | doing something I probably shouldn't .. comparing the two distfiles from cmake and autotools |
| 04:03.44 | starseeker | will look into that tomorrow if he can get access to a 10.6 system |
| 04:04.10 | brlcad | I can post any files you think might help |
| 04:04.12 | starseeker | I believe there is at least one step that autotools has that I haven't put in CMake |
| 04:04.31 | starseeker | brlcad: I need to do some configure-time debugging, to check what is and isn't being set at various steps |
| 04:04.44 | starseeker | basically a bunch if MESSAGE calls at various points in the file |
| 04:04.50 | starseeker | s/if/of |
| 04:05.13 | starseeker | brlcad: your CMakeCache.txt file might be informative |
| 04:06.25 | brlcad | http://brlcad.org/tmp/cmake_build_fail.txt and http://brlcad.org/tmp/CMakeCache.txt |
| 04:06.26 | starseeker | is disturbed that editing the FindX11.cmake files didn't do squat - did you erase your CMakeCache.txt file between each CMake run? (or at least clear out the X variables in it?) |
| 04:06.48 | brlcad | yep, started out just wiping out the cache |
| 04:07.04 | brlcad | then was eventually blowing away the whole dir, trying to get some changes |
| 04:08.00 | brlcad | build dir out of src dir only, parallel |
| 04:08.11 | starseeker | hmm - is there a /usr/include/X11 dir? |
| 04:09.35 | starseeker | is wondering why there seems to be both a /usr/X11/include and a /usr/include/X11 - one one a symlink to the other? |
| 04:09.43 | brlcad | there is a /usr/include/X11 symlink to /usr/X11/include/X11 |
| 04:10.03 | starseeker | and fontconfig.h is where? |
| 04:10.16 | brlcad | /usr/X11/include/fontconfig/fontconfig.h |
| 04:10.28 | starseeker | that may be what's happening |
| 04:10.34 | starseeker | /usr/include is getting checked first |
| 04:10.35 | brlcad | /usr/X11/include is the "proper" one-stop shop for X11 |
| 04:10.38 | starseeker | right |
| 04:10.50 | starseeker | but I'll bet the find routines are looking in /usr/include |
| 04:10.57 | brlcad | so #include <X11/Xlib.h> works, as well as #include <fontconfig/fontconfig.h> |
| 04:11.18 | starseeker | your cache file reports: X11_X11_INCLUDE_PATH:PATH=/usr/include |
| 04:11.39 | starseeker | and /usr/include/fontconfig doesn't exist |
| 04:11.43 | brlcad | which is true for that specific test |
| 04:12.56 | starseeker | let me check... it's now looking like there needs to be a specific fontconfig_include_dir var set... |
| 04:13.16 | brlcad | fontconfig is one of a half-dozen entities in /usr/X11/include |
| 04:13.29 | brlcad | GL, cairo, freetype2, ... |
| 04:14.02 | starseeker | yeah, but unless we convince the FindX11 routines to not look in /usr/include (or at least, not until after /usr/X11/include) the X11 includes aren't going to get fontconfig |
| 04:14.55 | brlcad | the problem isn't fontconfig -- the failure is 1) assuming that the dir containing X11 also contains those deps and 2) not checking /usr/X11/include first .. and maybe 3) not having the equivalent of --with-x=/usr/X11 :) |
| 04:15.47 | starseeker | did you try moving /usr/include below /usr/X11/include in the X11_INC_SEARCH_PATH variable in FindX11.cmake? |
| 04:17.05 | brlcad | so here's another mystery .. when I first started editing FindX11.cmake .. /usr/include was at the BOTTOM of the X11_INC_SEARCH_PATH list .. which is why my commit comments asserted that the list seemed to be processed in reverse order |
| 04:17.26 | brlcad | I had trouble believing that, even with the evidence, so I reverted and resorted back |
| 04:17.52 | brlcad | that's what I meant about not getting that list to make one bit of difference |
| 04:18.28 | starseeker | what about reducing that list to *just* /usr/X11/include - does that work? |
| 04:18.38 | starseeker | (take the order out of it, for the moment) |
| 04:19.06 | brlcad | I'll give that a quick test |
| 04:19.41 | brlcad | my earlier test was to remove X11R6 since that's what most of the X11-related tests actually detect/use |
| 04:19.55 | brlcad | and even after removing all instances of it, still would only detect/use X11R6 |
| 04:20.27 | brlcad | like maybe some system Find* was getting called first and our list was pointless |
| 04:20.31 | starseeker | that's strange... it almost sounds like it's getting the system FindX11.cmake and not our local copies |
| 04:20.34 | starseeker | er, yeah :-) |
| 04:21.24 | starseeker | iirc, one of the src/other instances (tk, I think) ends up called first, the way our toplevel currently works |
| 04:21.42 | starseeker | (with all bundled libs on - otherwise of course it depends) |
| 04:22.25 | starseeker | I had that problem earlier. But since you changed 'em all and cleared the cache, it can't be that |
| 04:22.46 | brlcad | well, like I said, I thought of that too and diligently overwrote all FindX11.cmake on each edit attempt |
| 04:22.56 | starseeker | knows |
| 04:22.58 | brlcad | as well as FindGL.cmake since it has some X11 tests of it's own |
| 04:23.31 | brlcad | edit made, re-cmaking |
| 04:23.51 | starseeker | only other thing I can think of (what I would be doing) is to put some MESSAGE statements into the FindX11.cmake files to see what is set when. |
| 04:24.43 | brlcad | so that reminds me of another bitching point .. what is up with ccmake not giving the "g"enerate files option most of the time? |
| 04:24.50 | starseeker | something like MESSAGE("X11 include path with FindX11.cmake in ${CMAKE_CURRENT_SOURCE_DIR}: ${X11_X11_INCLUDE_PATH X11}") |
| 04:25.27 | starseeker | uh - if it's acting like the gui, you need to do the configure twice before generate is available... |
| 04:25.45 | starseeker | recalls a complaint about that on the CMake list a while back... |
| 04:26.50 | brlcad | it annoyingly starts up with EMPTY CACHE in an empty/new build dir, I run 'c'onfigure, I wait... get list of options, make my edits, 'c'onfigure *again* .. and sometimes it'll give me the 'g'enerate option, but usually I have to exit and "cmake ." to generate the makefiles for that last config |
| 04:27.11 | starseeker | O.o |
| 04:27.33 | starseeker | as far as I know, it's supposed to give you the generate option once no new variables have been added to the var list |
| 04:27.42 | starseeker | which is typically after the second configure |
| 04:28.04 | brlcad | well I have no list the first time, so presumably they all get added |
| 04:28.08 | starseeker | if your option edits prompt more variables to appear, you'll have to do it again |
| 04:28.13 | starseeker | yes |
| 04:28.31 | starseeker | in the gui, the first configure never allows the geerate button to activate |
| 04:28.40 | brlcad | then the second time, I usually do BUNDLED on the all deps option, turn on debugging, turn on opt, 'c'onfigure |
| 04:28.53 | starseeker | the second does, provided no new variables are added as a result of opition changes between the first and the second |
| 04:29.16 | starseeker | ah - yeah, that'll add new options as it runs the src/other configures it didn't run the first time |
| 04:29.34 | starseeker | a third configure (with no option changes) should get you the generate button |
| 04:29.40 | starseeker | (or 'g' option) |
| 04:31.00 | brlcad | blech |
| 04:31.38 | starseeker | once the configure emulation script is done it should feel like autotools on the command line |
| 04:31.46 | starseeker | then you won't have to mess with the guis |
| 04:32.26 | brlcad | yeah, I'm really not digging ccmake |
| 04:33.07 | starseeker | usually does the command line: cmake -DBRLCAD_BUNDLED_LIBS=Bundled |
| 04:33.52 | brlcad | the options aren't usefully grouped/sorted, can't see the curses cursor without color, no description/help for options (which you'd think would be a prime benefit of having a fancy curses gui) |
| 04:35.18 | starseeker | cmake-gui probably isn't much better then (I prefer it personally, but that's just me...) |
| 04:35.28 | starseeker | drop-down options are kinda cool though |
| 04:37.36 | brlcad | of course, patches welcome ;) |
| 04:37.54 | brlcad | so yeah, no-go on the path change |
| 04:38.16 | starseeker | *bleep* |
| 04:38.33 | brlcad | removed all except /usr/X11/include in all FindX11 and FindGL files, still detecting /usr/include for headers and /usr/X11R6/lib for libs |
| 04:38.36 | starseeker | is this a machine I can remotely access? |
| 04:39.10 | brlcad | i could probably set up access in a couple min |
| 04:39.19 | starseeker | is willing to give it a go... |
| 04:53.00 | CIA-109 | BRL-CAD: 03brlcad * r47371 10/brlcad/tags/rel-7-20-4/: retagging release 7.20.4 now that most of the build and distcheck issues have been cleaned up. tested numerous configurations on debian and mac 10.6 |
| 04:55.36 | starseeker | brlcad: take a look at: cmake --help-command find_path |
| 04:56.05 | starseeker | #5 in the search list is a list of pre-defined paths for each Platform |
| 04:56.28 | starseeker | that could be interfering |
| 04:57.18 | brlcad | maybe, or the path being searched for isn't useful |
| 04:57.32 | brlcad | looking for an X11 dir seems a bit of a weak test, for example |
| 04:58.04 | brlcad | you generally look for X11/Xlib.h or some other primary header |
| 05:00.50 | CIA-109 | BRL-CAD: 03brlcad * r47372 10/brlcad/trunk/src/librt/CMakeLists.txt: shouldn't be any reason to disable strict mode on librt. change the code, not the messenger. |
| 05:02.34 | CIA-109 | BRL-CAD: 03brlcad * r47373 10/brlcad/trunk/CMakeLists.txt: match the original autotools logic, detect all the way back to 8-bit architectures so we might have a prayer's chance of working out of the box on an embedded platform. |
| 05:26.50 | CIA-109 | BRL-CAD: 03starseeker * r47374 10/brlcad/trunk/ (6 files in 6 dirs): Tweak FindX11.cmake for Mac OSX 10.6 |
| 05:26.58 | starseeker | brlcad: give that a go |
| 05:34.52 | brlcad | hey, I believe you -- if you say it works :) |
| 05:35.08 | starseeker | is finishing the compile now - at 89% |
| 05:35.09 | brlcad | is there an option that says "try these first, THEN try system"? |
| 05:35.21 | brlcad | oh, it wouldn't have gotten that far |
| 05:35.27 | brlcad | failed in tk early |
| 05:35.47 | starseeker | not to my knowledge - I could achieve that behavior, but only by doing so "manually" |
| 05:36.08 | brlcad | so if the list is now being walked in order, /usr/include should probably come last |
| 05:37.18 | brlcad | and any system dirs being searched by default should probably get added |
| 05:37.57 | starseeker | bets that's where the X11R6 stuff was coming from though - the Developer SDKs have multiple copies of usr/X11R6 dirs |
| 05:37.59 | brlcad | rather, dirs that WERE being searched by that default logic |
| 05:38.04 | brlcad | nods |
| 05:38.16 | brlcad | makes sense, fits the symptoms |
| 05:39.00 | starseeker | nods - we could play with it some - if you want to do that, we'd have to investigate where the platform specific dirs are listed and append those variables |
| 05:39.18 | brlcad | I suspected as much very early into the testing, but didn't know an fix and it took a while to isolate the problem |
| 05:39.59 | starseeker | nods - I experimented with something like this once before, but didn't (quite) need to go all the way to the no cmake system path option |
| 05:40.09 | starseeker | this time it's legit - we need it |
| 05:40.27 | brlcad | given how critical proper detection of X11 is to our ability to even compile in a useful manner on most platforms, it warrants making it as robust as possible |
| 05:40.46 | starseeker | nods - probably will have to add FindGL to this mix, too |
| 05:41.15 | starseeker | that is isn't technically as necessary as X11 at the moment, but I don't expect that to last much longer |
| 05:41.24 | brlcad | even better would probably be to find what the autotools logic is, and *also* use that since it's more likely to be more exhaustive |
| 05:41.54 | brlcad | yeah, we're to the point of needing GL for anything serious .. we need to fix our gl problems |
| 05:42.13 | brlcad | if we can't even detect gl cleanly, we certainly can't dev reliably with it |
| 05:42.30 | starseeker | *ding* *ding* *ding* - build complete on your mac. logging off now |
| 05:42.36 | brlcad | awesome, thanks |
| 05:43.11 | starseeker | np - thank you! that would have been a toughie without the system itself to test on |
| 05:43.40 | brlcad | if you want to sync that to stable and branch, and regenerate the tarballs, go for it ;) |
| 05:44.06 | brlcad | otherwise, I'll go with the ones already tagged since they're also tested on linux and don't want to do that whole round of retesting again |
| 05:44.39 | starseeker | votes for leaving it - autotools will work for this round |
| 06:43.41 | brlcad | source tarballs uploading now, release notes hopefully sometime tomorrow |
| 07:38.02 | jordisayol | brlcad: congratulations for the new release! |
| 07:39.15 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) |
| 07:39.34 | jordisayol | brlcad: I see that the package size is bigger than the previous ones. What's the cause of this size difference? |
| 07:50.02 | CIA-109 | BRL-CAD: 03d_rossberg * r47375 10/rt^3/tags/rel-7-20-4/: tag the C++ core interface with the corresponding BRL-CAD version (i.e. 7.20.4) |
| 12:44.16 | CIA-109 | BRL-CAD: 03indianlarry * r47376 10/brlcad/trunk/src/conv/iges/treecheck.c: Change Treecheck() return from void to int |
| 13:42.29 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) |
| 14:05.46 | *** join/#brlcad abhi2011 (~chatzilla@117.200.81.53) |
| 14:38.52 | starseeker | jordisayol: which packages are you building? RPM? |
| 14:39.52 | jordisayol | yes, RPM for Fedora/Centos, RPM for OpenSUSE and DEB for Debian/Ubuntu/LinuxMint/... |
| 14:41.02 | starseeker | jordisayol: we have more docbook stuff (more advanced html and pdf is being generated thanks to Tom Browder) |
| 14:41.10 | starseeker | awesome |
| 14:41.49 | starseeker | tries to remember if this last release is the one that will have the upgraded Boost - that might have upped the size too |
| 14:43.26 | jordisayol | aha, but what is needed to compile brlcad with docbook? |
| 14:44.13 | jordisayol | ...in linux (ubuntu) |
| 14:51.06 | jordisayol | I got this: |
| 14:51.06 | jordisayol | Generate extra docs ...................: ON (man/html |
| 14:51.38 | jordisayol | with "fop" installed |
| 14:52.20 | jordisayol | Generate extra docs ...................: ON (man/html only) |
| 14:54.41 | CIA-109 | BRL-CAD: 03erikgreenwald * r47377 10/brlcad/trunk/src/libgcv/bottess.c: change double ptrs to explicit point_t ptrs. |
| 16:23.30 | jordisayol | starseeker: so, do you think that pdf files must be included in linux packages? |
| 16:39.22 | jordisayol | starseeker: deb package w/o pdf (until now), 50 Mb. with pdf 80 Mb. |
| 16:40.17 | jordisayol | starseeker: please tell me what do you think |
| 16:41.10 | jordisayol | you too brlcad |
| 16:41.29 | jordisayol | i've to go |
| 16:41.52 | jordisayol | please leave your opinion here |
| 16:41.54 | jordisayol | bye |
| 16:55.15 | *** join/#brlcad abhi2011 (~chatzilla@117.200.85.105) |
| 17:28.59 | starseeker | jordisayol: no, pdf's shouldn't be included (IMO) |
| 17:29.37 | starseeker | you have to explicitly turn on PDF building - it's another option |
| 17:29.58 | starseeker | (that option won't even appear unless fop is around) |
| 17:30.44 | starseeker | pdf building is expensive and (unlike the html output) isn't directly used by any of the editing environments |
| 17:37.15 | brlcad | jordisayol: since the pdf files are not yet in the final desired form (layout, images, structure), it's not necessary that they be included in binary distributions but not a problem if they're included either |
| 17:37.45 | brlcad | requiring fop to build brl-cad is a huge requirement, so I wouldn't make it a .deb build dependency (pulls in all of fop+java) |
| 17:38.51 | brlcad | jordisayol: as for the size of the download, the size tends to increase with every release because the size of the code tends to increase every release (ohloh has graphs) |
| 17:41.23 | jordisayol | ok, many thanks starseeker and brlcad. i'l keep as they are |
| 17:41.26 | brlcad | most cad distros are 10x our binary size due to docs and metadata, so I won't really be concerned until we cross the max CD-size barrier (about 860MB) |
| 17:42.17 | brlcad | even then, that'll just to a good audit point to make sure we're not being too wasteful and inefficient with 3rd party deps and data, real practical limit is dvd capacity |
| 17:47.08 | jordisayol | another question. can i switch archer as default graphic app, or is i still in pre-alfa state? |
| 17:47.15 | abhi2011 | I am trying to do a windows build and I read README.windows |
| 17:47.35 | abhi2011 | but there is no brlcad.sln file in brlcad\misc\win32-msvc |
| 17:48.09 | abhi2011 | is the cmake approachm the only approach at the moment ? |
| 17:51.23 | brlcad | jordisayol: it's still pre-alpha, I'm hoping we push out an alpha before the new year |
| 17:51.55 | brlcad | abhi2011: the readme is out of date, cmake is THE approach at the moment, install it on windows and the build should go pretty smoothly |
| 17:52.06 | jordisayol | brlcad: ok, mani thanks. i'll keep everything as is |
| 17:52.07 | abhi2011 | ok |
| 18:01.20 | abhi2011 | so I have visual studio 2008 express edition installed but i get errors with cmake |
| 18:01.30 | abhi2011 | I guess the best option then is to go with mingw |
| 18:01.43 | brlcad | what errors? |
| 18:02.54 | abhi2011 | http://bin.cakephp.org/view/611912235 |
| 18:04.05 | abhi2011 | support for platforms, hmm |
| 18:07.22 | abhi2011 | seems like a bug : http://social.msdn.microsoft.com/Forums/en-US/vssmartdevicesnative/thread/88685f18-11a0-469f-902d-08a00aa01554/ |
| 18:07.34 | abhi2011 | maybe i ll get vc express 2010 and try |
| 18:10.38 | abhi2011 | hmm ok, I had chosen the win64 compiler |
| 18:10.48 | abhi2011 | choosing the normal 32 bit build , works |
| 18:14.28 | abhi2011 | though there are a large number of libs that were not found : http://bin.cakephp.org/view/1966265968 |
| 18:15.46 | abhi2011 | its probably looking for the DLLs in Windows/SysWOW64 and not finding them, maybe I should install them |
| 18:17.00 | abhi2011 | oh wait , its going to compile them, so its probably ok |
| 18:18.20 | abhi2011 | ok got the sln file |
| 18:25.52 | brlcad | abhi2011: yeah, no worries |
| 18:26.04 | abhi2011 | :) |
| 18:26.08 | brlcad | the lib detection is just to decide whether or not we need to use our bundled versions |
| 18:26.33 | brlcad | on windows, where pretty much nothing exists already, it's to be expected that most of the tests will result in using the bundled lib |
| 18:28.14 | brlcad | you might still run into a compilation failure, windows doesn't get tested very often |
| 18:31.04 | brlcad | if you do, though, post it so someone can fix it .. or fix it yourself ;) |
| 18:35.04 | abhi2011 | yes sure |
| 18:35.30 | abhi2011 | i cant find the my simulate project under libged though :P |
| 18:35.40 | abhi2011 | *simulate folder |
| 18:36.32 | abhi2011 | probably removed from the files in the solution, due to bullet not being detected, by cmake |
| 18:37.49 | abhi2011 | yeah , hav to move to windows for a few days, as I am unable to access the svn from linux suddenly, probably some isp issue |
| 18:43.47 | starseeker | is sorry, but will be a Good Thing if you can get things working on Windows as well |
| 18:44.22 | starseeker | yeah, if it can't find bullet it won't try building things needing it |
| 18:46.11 | abhi2011 | starseeker: hehe , np, yeah will compile bullet dynamic libs now :) |
| 18:49.39 | starseeker | makes a note to try out tileQt and check its license... |
| 18:52.44 | abhi2011 | ok, the build completed smoothly, now its saying to run 'make install', I think that would need make to be installed, which is only in linux |
| 18:53.32 | abhi2011 | hmm maybe i ll just run the INSTALL target |
| 18:53.59 | abhi2011 | right that did it |
| 19:09.49 | starseeker | grins - tileQt already has a CMake build :-) |
| 19:09.51 | starseeker | awesome |
| 19:30.04 | abhi2011 | strange, I have just pointed the system environment variables BULLET_DYNAMICS_LIBRARY BULLET_COLLISION_LIBRARY BULLET_MATH_LIBRARY BULLET_SOFTBODY_LIBRARY BULLET_INCLUDE_DIR |
| 19:30.22 | abhi2011 | and set them to the proper paths where bullet .libs are installed |
| 19:30.31 | abhi2011 | still I get the Bullet missing error |
| 19:30.54 | abhi2011 | arent the variables supposed to be system variables ? |
| 19:31.32 | starseeker | abhi2011: try setting them in CMake |
| 19:31.39 | abhi2011 | ah ok |
| 19:33.47 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) |
| 19:43.44 | *** join/#brlcad abhi2011 (~chatzilla@117.200.80.3) |
| 19:52.14 | abhi2011 | starseeker: that does not seem to work either |
| 19:52.32 | starseeker | what's the error? |
| 19:52.54 | abhi2011 | i defined all 5 variables in cmake, but it says : Could NOT find Bullet (missing: BULLET_DYNAMICS_LIBRARY BULLET_COLLISION_LIBRARY BULLET_MATH_LIBRARY BULLET_SOFTBODY_LIBRARY BULLET_INCLUDE_DIR) |
| 19:53.05 | abhi2011 | then it removes them after configuring |
| 19:53.18 | starseeker | hmm. Where did you define them? |
| 19:53.49 | abhi2011 | by adding an entry with the add entry button in the cmake-gui |
| 19:55.22 | starseeker | OK. you might try editing the CMakeCache.txt file... |
| 19:55.33 | abhi2011 | ok |
| 19:58.26 | abhi2011 | i guess the path should only mention the folder name, and not include the filename, as in : F:\Code\libraries\bullet-build\lib\Debug |
| 20:00.52 | starseeker | right |
| 20:01.05 | starseeker | for the includes anyway |
| 20:01.14 | starseeker | the libs will want the full name |
| 20:02.23 | starseeker | so the 5 variables you listed include 4 libs - those are full path with filename |
| 20:02.37 | abhi2011 | ok |
| 20:02.57 | starseeker | BULLET_INCLUDE_DIR should be just the directory with the .h files, or possibly a parent directory depending on the includes |
| 20:32.20 | abhi2011 | ok, now it found it |
| 20:32.44 | abhi2011 | I think setting them as enviromment vars should now also work as long as the full files names are given where needed |
| 21:06.05 | abhi2011 | Bullet running fine in windows now, linked against the static libs |
| 21:06.25 | abhi2011 | starseeker: thanks! |
| 21:09.37 | starseeker | hah - awesome! |
| 21:10.48 | starseeker | abhi2011: I know you've posted links before, but I don't recall - where are you stashing the various videos of your progress? |
| 21:15.10 | abhi2011 | starseeker: they are here : http://brlcad.org/wiki/User:Abhijit#Log |
| 21:15.18 | abhi2011 | there is just 1 video currently |
| 21:15.41 | abhi2011 | another requires the server as its a large scene with glass affects, so its not been done yet |
| 21:16.06 | abhi2011 | *glass shaders |
| 21:19.36 | abhi2011 | has anyone noticed that ws-indent and other scripts which format the code, format it for the older editors like emacs, the code appears misaligned in eclipse and visual studio |
| 21:20.11 | abhi2011 | code aligned in eclipse and vs appears misaligned in emacs :P |