| 00:00.02 | starseeker | gah |
| 00:00.03 | ``Erik | wait, no |
| 00:00.05 | ``Erik | it's not |
| 00:00.08 | ``Erik | posix.1 |
| 00:00.10 | starseeker | phwd |
| 00:00.49 | ``Erik | all the windows ones look very windows, very not unix |
| 00:00.57 | ``Erik | so you may need an #ifdef __WIN32__ or something |
| 00:01.09 | starseeker | if we have to |
| 00:01.32 | starseeker | all the *.c.in files will be modified however they have to be to work everywhere, up to and including ifdefs |
| 00:02.24 | ``Erik | http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/430449b3-f6dd-4e18-84de-eebd26a8d668 |
| 01:13.35 | CIA-42 | BRL-CAD: 03starseeker * r40172 10/brlcad/branches/cmake/ (3 files in 2 dirs): Set up basic functionality for doing a time delta of the configure process with CMake. |
| 01:18.49 | CIA-42 | BRL-CAD: 03starseeker * r40173 10/brlcad/branches/cmake/CMakeLists.txt: |
| 01:18.49 | CIA-42 | BRL-CAD: Don't try to hide failure of the C code based approach to time determination |
| 01:18.49 | CIA-42 | BRL-CAD: with script based approaches - failures on Windows will produce incorrect data |
| 01:18.49 | CIA-42 | BRL-CAD: without warning in some cases, so the C based approach has to work. |
| 01:48.49 | starseeker | winces - I guess I haven't been setting this up right after all for install |
| 02:01.35 | *** join/#brlcad _yukonbob (~svs@S010600235a187d92.ok.shawcable.net) |
| 02:14.02 | *** join/#brlcad IriX64 (~IriX64@bas2-sudbury98-1096601208.dsl.bell.ca) |
| 02:48.31 | starseeker | yeah, that's the joker - as I'm set up right now, I can't set up a working make install |
| 03:42.17 | CIA-42 | BRL-CAD: 03starseeker * r40174 10/brlcad/branches/cmake/ (CMakeLists.txt src/libbu/CMakeLists.txt): |
| 03:42.17 | CIA-42 | BRL-CAD: Start trying to figure out how to get make install working. Apparently 'here |
| 03:42.17 | CIA-42 | BRL-CAD: there be dragons' - Darwin doesn't use RPATH, so either need INSTALL_NAME_DIR or |
| 03:42.17 | CIA-42 | BRL-CAD: some sort of @executable_path thing... start reading |
| 03:42.17 | CIA-42 | BRL-CAD: http://www.cmake.org/pipermail/cmake/2007-October/017180.html for some |
| 03:42.17 | CIA-42 | BRL-CAD: background. |
| 03:58.31 | CIA-42 | BRL-CAD: 03starseeker * r40175 10/brlcad/branches/cmake/src/ (15 files in 15 dirs): OK, slightly better - rtexample now at least prints its usage message both in the build tree and in the install bin dir. |
| 03:59.48 | starseeker | heads home |
| 04:26.46 | brlcad | rxrxsdrx |
| 04:27.05 | brlcad | whee |
| 04:29.45 | brlcad | kanzure: missed earlier, but try to catch you again later (g'night!) |
| 05:02.46 | kanzure | good night. |
| 06:25.02 | *** join/#brlcad Stattrav (~Stattrav@27.57.134.217) |
| 06:31.46 | *** join/#brlcad merzo (~merzo@smartbussiness.mobicom.net.ua) |
| 10:02.09 | *** join/#brlcad mafm (~mafm@83.37.7.245) |
| 12:05.42 | *** join/#brlcad Zaebos (~irc@pd95b7f5e.dip0.t-ipconnect.de) |
| 13:14.22 | d-lo | Mernin all! |
| 13:24.55 | CIA-42 | BRL-CAD: 03davidloman * r40176 10/rt^3/trunk/CMakeLists.txt: Some how the RT3_BUILD_TESTS variable declaration got removed. Restore it. |
| 13:27.53 | CIA-42 | BRL-CAD: 03davidloman * r40177 10/rt^3/trunk/tests/ (4 files in 2 dirs): Stub in test cxx file for libpkgcpp. Modify svn:ignore for config/build by-products. |
| 13:28.41 | CIA-42 | BRL-CAD: 03davidloman * r40178 10/rt^3/trunk/src/libPkgCpp/PkgServer.h: Forgot to add #include statements. Also, convert quint32->int in order to keep QT out of this lib. |
| 13:32.41 | CIA-42 | BRL-CAD: 03davidloman * r40179 10/rt^3/trunk/ (5 files in 2 dirs): Make libpkgcpp headers public ones in order to use them :) |
| 13:47.03 | CIA-42 | BRL-CAD: 03davidloman * r40180 10/rt^3/trunk/tests/libpkgcpp/ (CMakeLists.txt pkgcppTest.cxx): Clean up some Include issues to make the tests compile correctly. |
| 14:20.03 | CIA-42 | BRL-CAD: 03davidloman * r40181 10/rt^3/trunk/tests/libpkgcpp/pkgcppTest.cxx: Una mas #include fix. |
| 14:43.18 | d-lo | ah.... c-ryptonyte! Help a newbie guys: |
| 14:43.24 | d-lo | bu_exit(int status, const char *fmt, ...) |
| 14:43.36 | d-lo | wth are the ... there for? |
| 14:45.15 | starseeker | d-lo: there may be other arguments to bu_exit? |
| 14:45.53 | d-lo | is that a question or an answer? :) |
| 14:46.06 | starseeker | both |
| 14:46.15 | starseeker | you checked bu.h? |
| 14:46.26 | d-lo | that's where I got that little gem :P |
| 14:46.39 | d-lo | or are you referring to the macros? |
| 14:46.43 | starseeker | ooo, I see it now |
| 14:46.44 | starseeker | odd |
| 14:47.05 | d-lo | i just don't know what it means. |
| 14:47.17 | d-lo | "Variable number of arguments" ? |
| 14:47.17 | starseeker | yeah, that's a new one for me too |
| 14:47.33 | starseeker | probably very cool if I knew what it was though! |
| 14:47.58 | d-lo | *waits till ``Erik or brlcad chimes in* |
| 14:48.03 | d-lo | =D |
| 14:48.04 | starseeker | hunts up a use of bu_exit |
| 14:49.23 | starseeker | empherical evidence suggests variable argument counts... |
| 14:49.26 | starseeker | conv/nmg/g-nmg.c: bu_exit(1, "Cannot open %s\n", argv[bu_optind]); |
| 14:49.26 | starseeker | conv/nmg/g-nmg.c: bu_exit(1, "db_dirbuild failed\n"); |
| 15:32.58 | brlcad | d-lo: that's how you implement a printf-style function where the number of arguments to the function can change |
| 15:34.39 | brlcad | 1 arg: printf("hello world\n"); 2 args: printf("hello %s\n", "world"); 3 args: printf("hello %s #%d\n", "world", 1); the format is printf(const char *fmt, ...); |
| 15:34.52 | brlcad | now replace printf with bu_log and you have the same thing |
| 15:35.21 | brlcad | there are lots of different ways to abuse variable arugments too, but that's one of the more common ways |
| 15:35.31 | brlcad | should be used sparingly |
| 15:41.09 | starseeker | brlcad: I'm a bit confused by the rules that update include/conf/COUNT - it doesn't seem to be every time make is run, but I've seen it in an incremented state - what is intended to trigger a COUNT increment? |
| 15:42.27 | starseeker | ok, this is a good error message :-) : bu_exit(EXIT_FAILURE, "Ack! %d\nflaming death\n", ferror(fd_in)); |
| 15:42.37 | d-lo | tee hee :) |
| 15:52.27 | starseeker | turns mildly red as he sees d_rossberg already has some CMake logic in include/conf |
| 15:52.50 | d-lo | Embarrassed or Hulk Angry?! :) |
| 15:53.29 | starseeker | embarrassed |
| 15:53.43 | starseeker | although I still don't know what COUNT is actually for |
| 15:54.35 | starseeker | he has in-CMake logic to increment it, which will increment everytime CMake is run but not every time make is run |
| 15:57.02 | brlcad | the basic intent is capture how many times a particular build has been performed so you can tell whether a given binary install was cleanly compiled |
| 15:57.51 | brlcad | the trick, however, is that you don't want every single pass of make to be counted, nor do you want the updating of the include/conf files to cause a complete recompile of anything that uses them |
| 15:58.20 | brlcad | care was taken to make sure that doesn't happen now |
| 15:58.40 | brlcad | basically, COUNT is updated for every configure+make pass through the build |
| 15:58.50 | starseeker | OK |
| 15:58.50 | CIA-42 | BRL-CAD: 03starseeker * r40182 10/brlcad/branches/cmake/CMakeLists.txt: Got this logic backwards - do RPATH if not on Mac. |
| 15:58.51 | brlcad | so if you re-configure after make, it'll be 2 |
| 16:00.45 | starseeker | OK - I think I can come up with a way to do something like that |
| 16:03.44 | brlcad | corrollary would be to increment it every time you run cmake, but not make |
| 16:04.14 | starseeker | alrightie - that's actually a good deal simpler |
| 16:04.49 | starseeker | except if I run cmake twice without a make inbetween, it shouldn't increment right? |
| 16:05.13 | brlcad | *shrug* |
| 16:05.25 | brlcad | don't see harm in incrementing it |
| 16:05.39 | brlcad | the main benefit is whether you see a 0 or a non-0 count |
| 16:06.50 | brlcad | if I see zero install, I know that (SHOULD) means that someone did a checkout, compile, and install .. without dorking around with config options, patching files, installing external deps, rebuilding, etc |
| 16:06.59 | starseeker | ok - just wanted to be sure I preserved the "desired" behavior - right now I've got it incrementing every time make is run, which is annoying |
| 16:07.05 | brlcad | there really wouldn't be any harm in updating every time make is run either |
| 16:07.30 | brlcad | it's just hard to get the dependency checking correct so that it doesn't recompile things every other pass by make |
| 16:07.47 | starseeker | well, libbu and friends rebuild the parts of themselves that see the COUNT include |
| 16:08.01 | starseeker | right |
| 16:08.45 | starseeker | opts for "every time cmake is run" - much simpler and more portable |
| 16:08.50 | starseeker | can use d_rossberg's logic |
| 16:09.42 | starseeker | what about include/conf/DATE? |
| 16:11.57 | brlcad | look at include/conf/Makefile.am |
| 16:12.05 | brlcad | it has the rebuild rules in there -- they're pretty simple |
| 16:12.45 | brlcad | COUNT updates whenever DATE HOST PATH or USER changes |
| 16:13.15 | brlcad | DATE updates whenever HOST PATH USER or configure is run |
| 16:13.16 | starseeker | oh, I see - forgot those were update-on-change and not just build-after-this-one |
| 16:13.23 | brlcad | HOST PATH and USER update whenever configure is run |
| 16:14.11 | brlcad | <PROTECTED> |
| 16:15.12 | brlcad | fwiw, the TS entry is only there so that there is guaranteed to be a date stamp in the output build log |
| 16:15.55 | brlcad | nothing uses it or relies on it, just prints the date to the log so when someone sends it in, we can tell when they actually ran the build |
| 16:16.07 | starseeker | nods |
| 16:16.09 | brlcad | been useful on several occasions |
| 16:16.52 | brlcad | most of the project systems date-stamp their build logs by default, but 'make' doesn't |
| 16:20.42 | CIA-42 | BRL-CAD: 03davidloman * r40183 10/rt^3/trunk/tests/libpkgcpp/CMakeLists.txt: Add libbu linkage to cmake for bu_log, bu_bomb, and bu_exit |
| 16:36.27 | CIA-42 | BRL-CAD: 03starseeker * r40184 10/brlcad/branches/cmake/CMakeLists.txt: |
| 16:36.28 | CIA-42 | BRL-CAD: Thanks to Sean for clarifying the purpose of the include/conf variables - it |
| 16:36.28 | CIA-42 | BRL-CAD: looks like these can be populated entirely using CMake logic or previously |
| 16:36.28 | CIA-42 | BRL-CAD: generated time files, which means these are now (in principle) fully portable as |
| 16:36.28 | CIA-42 | BRL-CAD: far as generation is concerned. |
| 16:42.20 | starseeker | need to cook up a way to print out the TS cross platform, but other than that looking good now - probably some formatting tweaks left |
| 16:42.33 | starseeker | (so far as include/conf is concerned anyway :-P) |
| 16:49.09 | brlcad | starseeker: note that it doesn't need to be a standard format or anything, it's for a human to read |
| 16:49.15 | brlcad | so it can just call "date" |
| 16:49.32 | starseeker | 'cept Windows doesn't really have a suitable date command |
| 16:49.58 | starseeker | I think that part is under control - I've got a little C TRY_RUN thing going that seems to be OK |
| 16:50.40 | starseeker | a variation of that built and run as a target in the beginning is probably the portable way |
| 16:51.38 | starseeker | the Windows date thing might work well enough for a timestamp, but if I can deal with all platforms at once using a C approach... |
| 16:53.48 | brlcad | wouldn't worry about it too much for windows |
| 16:53.55 | brlcad | msvc build log has a stamp iirc |
| 16:54.01 | starseeker | ah |
| 16:54.34 | brlcad | otherwise, unix date is like date /t and time /t on windows .. fugly but there in a simplistic way |
| 16:58.18 | brlcad | holy crappoli .. starseeker did you see how big those 7.16.10 linux binaries were? |
| 16:59.45 | kanzure | :) |
| 16:59.56 | starseeker | brlcad: yes |
| 16:59.57 | brlcad | checking here, but that's almost unbelievable that the tgz is 400MB without it expanding all of the symbolic links |
| 16:59.58 | kanzure | brlcad: hello |
| 17:00.21 | brlcad | also surprising that the bz2 is almost half the size |
| 17:00.31 | starseeker | brlcad: I suppose I messed up somehow :-( |
| 17:00.57 | brlcad | starseeker: does linux tar dereference symbolic links by default? |
| 17:01.11 | starseeker | good question |
| 17:01.40 | brlcad | hard to imagine that we've quadrupled since 7.12 :) |
| 17:01.50 | brlcad | unless you built static :) |
| 17:01.55 | brlcad | hello kanzure |
| 17:02.17 | starseeker | I thought I used the standard build routines |
| 17:02.28 | kanzure | quadrupling isn't a standard build routine :) |
| 17:02.34 | starseeker | winces |
| 17:02.58 | kanzure | hehe |
| 17:05.52 | brlcad | starseeker: there's also a report from ubuntu users that it's giving a libtermio error, but the version isn't confirmed |
| 17:07.03 | CIA-42 | BRL-CAD: 03starseeker * r40185 10/brlcad/branches/cmake/ (CMakeLists.txt misc/CMake/test_srcs/print_timestamp.c): Add a C based target for printing a timestamp during the Make process. |
| 17:07.09 | starseeker | had misgivings about doing the binary build for release - he's not got experience doing so... |
| 17:07.10 | brlcad | hope you did the release flags (--enable-all --enable-optimized) |
| 17:07.38 | brlcad | :) |
| 17:08.23 | kanzure | brlcad: so, i want to go after a DARPA proposal/grant/thing (i don't know what to call it) |
| 17:08.28 | kanzure | a funding opportunity |
| 17:08.29 | starseeker | thought so but can't recall - maybe that's what I did wrong |
| 17:08.43 | kanzure | basically they want sourceforge for hardware.. thingiverse-except-for-real, github+CAD+ICAD, etc. etc. |
| 17:08.47 | starseeker | brlcad: want me to yank 'em until we get it right? |
| 17:09.01 | kanzure | i've been working on this sort of thing for a year or more now, and it's really cool to see this opportunity |
| 17:09.14 | kanzure | i was wondering if you have any insight into this process. i know you work at ARL, which is definitely not DARPA.. but uh |
| 17:09.24 | brlcad | ah, I lied .. msvc doesn't build stamp -- at least not the brief output |
| 17:09.32 | brlcad | so having it output would still be useful there |
| 17:09.53 | brlcad | kanzure: who is they? |
| 17:10.13 | kanzure | DARPA. whoever wrote the document describing the funding opportunity. |
| 17:10.34 | brlcad | ah, darpa has an rfp out for this sort of project specifically? |
| 17:10.49 | brlcad | not just their general research area rfp |
| 17:13.15 | kanzure | this is a pre-RFP that specifically says they will not do RFPs O_o |
| 17:13.19 | kanzure | er, i mean.. |
| 17:13.38 | kanzure | this is a BAA document |
| 17:14.17 | kanzure | "nor will a formal Request for Proposal or additional solicitation regarding this announcement be issued. Requests for same will be disregarded." |
| 17:26.16 | starseeker | brlcad: I just tried it again and it came out the same size |
| 17:32.49 | brlcad | wow, step-g is four times the size of mged... :) |
| 17:33.39 | kanzure | yeah, it's pretty big |
| 17:33.52 | kanzure | er i guess you mean the compiled/linked version |
| 17:33.57 | kanzure | it's all the step class library stuff. |
| 17:34.37 | kanzure | in related news.. i've been trying to use swig to write a wrapper for openNURBS into python |
| 17:34.50 | kanzure | but it turns out that ON_GL has to be rewritten or something? oh well |
| 17:34.54 | brlcad | yeah, that's a huge portion of the size increase |
| 17:35.18 | kanzure | really? i was thinking it might be due to bloat with bad flags or something |
| 17:35.43 | brlcad | the only binary that looks suspicious is rttherm |
| 17:36.15 | kanzure | i mentioned a few weeks ago how i was writing a STEP export utility in python (without SCL and completely ignoring the EXPRESS definitions).. so far it's just a fwe thousand lines of code |
| 17:36.31 | kanzure | i was thinking i should use swig to write a wrapper around the step class library, but if it's so ridiculously huge maybe not :) |
| 17:36.58 | brlcad | I think I see where the size increases came from |
| 17:38.47 | brlcad | the step library itself isn't nearly as big as step-g ended up being |
| 17:39.05 | brlcad | I think there's templatized entity expansion going on |
| 17:39.23 | brlcad | libstepcore is 4MB |
| 17:40.20 | brlcad | opennurbs jacked up the sizes a fair bit since the 7.12 release |
| 17:40.54 | brlcad | starseeker: looks like links are in there correctly |
| 17:44.37 | starseeker | cool |
| 17:44.40 | brlcad | so the breakdown I'm seeing is pretty substantially influenced by our jni wrapper and brlcad aggregate library |
| 17:45.08 | starseeker | I think rttherm is built static (recall wondering about that...) |
| 17:46.05 | CIA-42 | BRL-CAD: 03starseeker * r40186 10/brlcad/branches/cmake/CMakeLists.txt: Whoops, read the right file. |
| 17:46.21 | brlcad | yeah, rttherm is big too |
| 17:51.31 | brlcad | total: 1268MB => libbrlcad: 310MB librtserver: 200MB rttherm: 65MB step-g: 64MB libged: 108MB librt: 104MB opennurbs: 72MB new html docs: 28MB |
| 17:52.12 | brlcad | so 40% is two aggregate libs (all the lib sizes are static+dynamic btw) |
| 17:53.57 | brlcad | opennurbs alone is probably the biggest culprit, definitely jacks things up with 6 or 7 static copies getting linked in |
| 17:54.07 | brlcad | wonder if step-g is static.. |
| 17:58.52 | brlcad | starseeker: if you would, run these for me on that linux build: |
| 17:59.01 | brlcad | ldd /usr/brlcad/lib/mged |
| 17:59.10 | brlcad | er, bin |
| 17:59.29 | brlcad | ldd /usr/brlcad/bin/step-g |
| 18:19.28 | kanzure | why is opennurbs statically linked |
| 18:55.49 | brlcad | libbrlcad and librtserver are aggregate libraries, fully resolved |
| 18:56.21 | brlcad | otherwise, it's not that opennurbs is being staticly linked |
| 18:56.37 | brlcad | it's used both static and dynamic in lots of different places |
| 18:56.59 | brlcad | rttherm is the only special case that is linking static |
| 19:18.56 | starseeker | brlcad: you want pastebins of 'em? |
| 19:21.13 | starseeker | http://pastebin.org/568866 |
| 19:23.55 | CIA-42 | BRL-CAD: 03r_weiss * r40187 10/brlcad/trunk/src/librt/primitives/bspline/nurb_norm.c: fixed typo bug in function rt_nurb_s_norm, references u.knots but should reference v.knots |
| 19:32.11 | brlcad | starseeker: perfect, thanks |
| 19:34.05 | brlcad | so that pretty much confirms that the massive size is due to template instantiation |
| 19:34.15 | brlcad | not so much step or opennurbs |
| 19:34.23 | brlcad | but c++ :) |
| 19:34.26 | starseeker | can we do anything about that? |
| 19:34.27 | starseeker | heh |
| 19:34.38 | brlcad | could strip symbols |
| 19:34.56 | brlcad | that's probably about half the 1.3GB |
| 19:35.09 | brlcad | but I'd still rather have debug symbols myself |
| 19:35.20 | starseeker | nods |
| 19:35.47 | brlcad | could break out libbrlcad as a separate product, save 300MB |
| 19:36.11 | starseeker | is that our equalivent of the brlcad.dll ? |
| 19:36.39 | brlcad | yep |
| 19:36.51 | brlcad | though not 1-1 |
| 19:37.01 | brlcad | daniel leaves out a lot of symbols and adds a few new ones in |
| 19:37.14 | brlcad | ideally it should be all the symbols plus his new ones |
| 19:37.42 | brlcad | don't know how many people rely on -lbrlcad |
| 19:38.38 | brlcad | looking through history, he only provides the brlcad.dll for windows so wouldn't be too horrible to put it up there |
| 19:40.54 | CIA-42 | BRL-CAD: 03r_weiss * r40188 10/brlcad/trunk/src/conv/iges/trimsurf.c: since myhit is used as a bu_list it needs to be initialized, prevents possible problem of referencing uninitialized forward pointer in bu_list structure |
| 19:46.24 | CIA-42 | BRL-CAD: 03erikgreenwald * r40189 10/isst/trunk/ (CMakeLists.txt cmake-modules/ cmake-modules/FindBRLCAD.cmake): start cmake-ifying |
| 19:52.37 | CIA-42 | BRL-CAD: 03r_weiss * r40190 10/brlcad/trunk/src/conv/iges/trimsurf.c: added missing fourth parameter |
| 20:05.43 | CIA-42 | BRL-CAD: 03r_weiss * r40191 10/brlcad/trunk/src/conv/iges/revolve.c: fixed bug where structures were referenced after freed |
| 20:28.55 | brlcad | yeah, richard's much more suited to API validation... |
| 20:29.02 | brlcad | those are actually useful |
| 20:31.43 | brlcad | he's going to have the old bsplines working before too long, heh |
| 20:31.50 | starseeker | heh |
| 20:32.01 | brlcad | (someone should get him working more on nmg instead) :) |
| 20:45.59 | CIA-42 | BRL-CAD: 03erikgreenwald * r40192 10/isst/trunk/cmake-modules/FindBRLCAD.cmake: add include/tie |
| 20:46.30 | CIA-42 | BRL-CAD: 03erikgreenwald * r40193 10/isst/trunk/CMakeLists.txt: things and stuff, stuff and things, hack hack hack |
| 20:52.21 | brlcad | starseeker: what was the xterm line you were using for EDITOR? |
| 20:52.41 | brlcad | to get around the ted/red editor invocation bug |
| 20:59.10 | *** part/#brlcad willdye (~willdye@fern.dsndata.com) |
| 21:11.21 | starseeker | it was some variation on xterm -e |
| 21:13.08 | starseeker | #!/bin/sh |
| 21:13.09 | starseeker | xterm -e vim $1 |
| 21:13.19 | starseeker | stuck that in vim.sh |
| 21:13.33 | starseeker | then export EDITOR=/home/user/vim.sh |
| 21:19.09 | brlcad | got it, thanks |
| 21:30.21 | starseeker | poop, cmake bootstrap on solaris isn't working right now |
| 21:36.46 | ``Erik | oh, nice. turning off intellisense in msvc involves removing a .dll |
| 21:39.25 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) |
| 21:52.17 | CIA-42 | BRL-CAD: 03erikgreenwald * r40194 10/brlcad/trunk/misc/win32-msvc8/brlcad/brlcad.sln: add adrt to solution |
| 22:01.10 | CIA-42 | BRL-CAD: 03erikgreenwald * r40195 10/brlcad/trunk/misc/win32-msvc8/libged/libged.vcproj: add bot.c |
| 22:20.21 | brlcad | starseeker: you have Bob's ear handy or he already left? |
| 22:20.29 | starseeker | he left |
| 22:20.32 | brlcad | darn |
| 22:21.33 | brlcad | I'd like to get one of his latest pro/e plugin builds uploaded to .bz |
| 22:21.43 | brlcad | I recall him saying he at least made a 7.16.9 build |
| 22:22.19 | starseeker | he may have, not sure |
| 22:24.19 | ``Erik | aren't there redistribution limitations on the proe dll's required? |
| 22:24.33 | CIA-42 | BRL-CAD: 03starseeker * r40196 10/brlcad/branches/cmake/misc/CMake/FindTCL.cmake: Start the process of doing a robust FindTCL.cmake - long way to go here. |
| 22:26.42 | brlcad | we're not redistributing proe's dlls |
| 22:49.50 | CIA-42 | BRL-CAD: 03starseeker * r40197 10/brlcad/branches/cmake/misc/CMake/FindTCL.cmake: OK, a bit better - don't have cache settings in place when doing the FOREACH loop initially, and make sure the cache value at the end is the first item in the list. |
| 23:30.54 | ``Erik | ah, just to make it easier for those who do happen to have proe |
| 23:35.33 | brlcad | right |
| 23:35.48 | brlcad | also, to compile you have to have the extra pro/toolkit license |
| 23:36.02 | brlcad | you use that to unlock the plugin for distribution (so you can use it in pro/e without protk) |
| 23:36.24 | brlcad | I'm making a new download section for it now |
| 23:36.25 | ``Erik | ah (haven't ever messed with pro/e) |
| 23:36.40 | brlcad | the unigraphics plugin was the same way |
| 23:37.25 | brlcad | cept they made unlocking super-fun .. mandatory 10min timer to unlock your binary |
| 23:38.33 | ``Erik | wow, glad I don't tend to deal with that kinda lameness O.o |
| 23:38.41 | ``Erik | goes back to looking at iphone sdk's *cough* |
| 23:39.52 | ``Erik | (xcode 3.2 requires 10.6, xcode 3.1.4 is the last for 10.5, which supposed ios3.1.3, but I'm having issues getting cocos2d-iphone to compile for it :/ ) |