| 00:47.13 | starseeker | yep, looks like that did the trick... at least, alot more stuff is ending up in lib... |
| 02:20.53 | *** join/#brlcad IriX64 (~kvirc@64.229.211.15) |
| 02:21.08 | IriX64 | http://pastebin.ca/2106675 |
| 02:21.22 | IriX64 | checked out 30 minutes ago, hope this helps, |
| 02:21.25 | IriX64 | ciao |
| 02:41.54 | brlcad | starseeker: awesome, I'll stub in something for the bs lib |
| 02:57.37 | starseeker | brlcad: maybe just stick the file in misc? seems kinda silly to have a src dir for four lines... |
| 03:02.16 | brlcad | starseeker: that should do it |
| 03:02.20 | CIA-48 | BRL-CAD: 03brlcad * r49121 10/brlcad/trunk/misc/win32-msvc/ (CMakeLists.txt bootstrap.cpp): |
| 03:02.20 | CIA-48 | BRL-CAD: stub in an initial bootstrap 'library' so that all of our application binaries |
| 03:02.20 | CIA-48 | BRL-CAD: on Windows can call SetDllDirectory(). this is avoid having to require users to |
| 03:02.20 | CIA-48 | BRL-CAD: set a PATH yet still keeping libraries in lib and applications in bin like we do |
| 03:02.20 | CIA-48 | BRL-CAD: on all other platforms. |
| 03:02.52 | brlcad | exactly what I was thinking too ;) |
| 03:03.13 | brlcad | plus that way there's no need for preprocessor protections, not built for all platforms |
| 03:05.37 | brlcad | there's still a chance that it won't be sufficient if windows tries to bind libraries prior to static initialization, but we'll see |
| 03:05.45 | starseeker | BRLCAD_ROOT... do I need to substitute that with CMake/ |
| 03:05.46 | starseeker | ? |
| 03:06.03 | brlcad | oh right, hold on |
| 03:10.10 | starseeker | maybe I'd better do a template |
| 03:10.36 | CIA-48 | BRL-CAD: 03brlcad * r49122 10/brlcad/trunk/misc/win32-msvc/bootstrap.cpp: begs explanation, so detail what's going on here. also need common.h for BRLCAD_ROOT. |
| 03:10.39 | brlcad | just needed a header |
| 03:11.07 | brlcad | I think LPCTSTR are just char*, so that might just compile cleanly straight up |
| 03:18.42 | starseeker | brlcad: give me a few minutes - I'm testing something quick on Linux and then I'll need to reboot to the dark side and update... |
| 03:20.31 | starseeker | not sure what IriX64 was seeing - just did a build here and the install worked... |
| 03:30.23 | starseeker | gah - oh right, the copyright update |
| 03:30.34 | starseeker | gets comfortable... |
| 03:43.12 | starseeker | groan |
| 03:44.34 | starseeker | ah hah - let the configure begin... |
| 03:53.57 | starseeker | brlcad: I link this thing in to just executables? |
| 03:54.26 | brlcad | yeah, but maybe just start with one application to test it |
| 04:18.04 | *** join/#brlcad louipc (~louipc@archlinux/fellow/louipc) |
| 04:30.19 | starseeker | brlcad: it wants bs to produce a .lib file, and it looks like right now it won't do that - don't we need to export something? |
| 04:40.37 | brlcad | actually, even better if you just link to that lib file everywhere |
| 04:42.00 | brlcad | starseeker: it doesn't need to export anything because there are no public functions being called by anything else |
| 04:42.21 | brlcad | when the library is loaded (whether embedded in a binary or in its own dll), it'll run that function |
| 04:42.28 | starseeker | that's the problem - it's NOT generating a lib file |
| 04:42.51 | brlcad | what is "it" that wants a lib? |
| 04:42.58 | starseeker | the linking logic |
| 04:43.17 | starseeker | if I try to link bs to an executable, it's looking for a bs.lib file to link |
| 04:43.34 | brlcad | what normally creates one of those? |
| 04:44.27 | brlcad | another perhaps simpler approach is to attach that bootstap.cpp to every application source list |
| 04:44.33 | starseeker | they don't appear without the import/export logic |
| 04:44.53 | starseeker | oh, you mean build it in with the executables? |
| 04:45.03 | brlcad | sure, same idea |
| 04:45.14 | brlcad | maybe simpler than making it spit out a proper lib/dll |
| 04:45.39 | starseeker | that's a thought |
| 04:45.42 | starseeker | one sec... |
| 04:45.43 | brlcad | i'm sure we can make the dll/lib work even if we have to export a useless symbol, but it shouldn't be needed |
| 04:59.06 | brlcad | fyi, we may need to use the /DELAYLOAD linker flag if it tries to load all dll's before static initialization, we'll see |
| 05:03.29 | CIA-48 | BRL-CAD: 03brlcad * r49123 10/brlcad/trunk/misc/win32-msvc/bootstrap.cpp: double-whammy, give the dll an apientry so there's at least one symbol to call |
| 05:03.51 | starseeker | brlcad: hang on, I'm still setting up to test just including the cpp in the src lists |
| 05:06.54 | starseeker | hmm... problem, we can only have one BRLCAD_ROOT defined at a time |
| 05:07.03 | starseeker | shouldn't we have a bu_brlcad_root call in there? |
| 05:07.48 | starseeker | the definition *does* change depending on whether we're in build dir or installed... |
| 05:08.16 | starseeker | but that's a problem, because it means *every* binary will need to link libbu |
| 05:10.03 | brlcad | it can't call bu_brlcad_root() .. that's a libbu function .. which would require libbu be loaded .. which would require knowledge about where libbu is ... |
| 05:10.17 | starseeker | right - so this won't work |
| 05:10.41 | brlcad | it can be some other string, I was just stubbing in the compile time one to see if the idea itself works |
| 05:11.07 | starseeker | shakes his head - doesn't matter what string it is - the problem is it needs to be static |
| 05:12.20 | brlcad | the idea we were talking about earlier is that it'd stub in one thing for build dir and another for install |
| 05:12.52 | starseeker | that only works if it builds two dlls - on to output in the build bin dir, and one to install |
| 05:13.20 | starseeker | and we're back to needing the .lib file, with the import/export fun |
| 05:14.15 | brlcad | that wasn't a show stopper in the least |
| 05:14.19 | starseeker | plus (even better) I don't know what would happen with the linking - which .lib file shouldI specify? |
| 05:14.27 | brlcad | just figured building it in is easier (to at least test) |
| 05:15.24 | starseeker | for that part - but if we can't figure out how to get it working on the build side it's moot |
| 05:15.52 | brlcad | if it doesn't even work, it's moot |
| 05:16.07 | brlcad | I was trying to make sure it works before wasting time on perfecting the build system |
| 05:17.47 | brlcad | if you want to sort out the build system part first, .. that's a bit cart before horse, but okay :) |
| 05:18.04 | starseeker | one sec - I'm adding the cpp file to one of the libbu tests directly |
| 05:18.08 | starseeker | we'll see what happens |
| 05:18.41 | brlcad | btw, 49123 i *think* will give it a symbol to export for dll/lib loading |
| 05:18.58 | brlcad | if not, can add something more explicit if we try the lib route |
| 05:19.26 | brlcad | if it works for the binary, it should be a done deal either built-in or as a dll |
| 05:19.32 | starseeker | k - if it does work, we're gonna have to figure out how to get one result in the build dir and another in the install dir |
| 05:19.39 | brlcad | if it doesn't work, then we can try lib next |
| 05:20.53 | starseeker | why does it even need the lib file if it's supposed to just use the dll? |
| 05:21.21 | brlcad | the lib file is basically a manifest for what's in the dll |
| 05:21.28 | brlcad | it needs that manifest to link, but only the dll at runtime |
| 05:21.38 | brlcad | (because it compiles the manifest into the binary) |
| 05:23.11 | starseeker | crap - wait a minute, why is the libbu.dll file here?? |
| 05:27.29 | starseeker | something's messed up here |
| 05:27.46 | starseeker | <censored> |
| 05:29.46 | starseeker | brlcad: should that "\lib" be "\\lib" ? |
| 05:33.59 | brlcad | ah, yeah |
| 05:34.46 | CIA-48 | BRL-CAD: 03brlcad * r49124 10/brlcad/trunk/misc/win32-msvc/bootstrap.cpp: not the ib directory |
| 05:35.22 | brlcad | remember to try adding /DELAYLOAD too if it doesn't work |
| 05:35.28 | brlcad | linker flag |
| 05:36.12 | starseeker | nods - I'm backwards a step right now - the setting of RUNTIME_OUTPUT_DIRECTORY for add_library isn't working |
| 05:36.19 | starseeker | dlls are still in with the .exe files |
| 05:47.39 | starseeker | crap |
| 05:47.44 | starseeker | I can't override it |
| 05:47.52 | starseeker | it's putting the dll in bin regardless |
| 05:48.14 | starseeker | I may have to email the list |
| 05:48.28 | starseeker | or this could be some VS Express vs. Pro issue |
| 05:48.46 | starseeker | is rapidly losing the will to muck with this... |
| 12:20.55 | *** join/#brlcad Stattrav (~Stattrav@61.12.114.82) |
| 12:20.55 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 14:12.06 | *** join/#brlcad pawleeq (~pawleeq@core1.humlnet.cz) |
| 14:43.51 | CIA-48 | BRL-CAD: 03erikgreenwald * r49125 10/brlcad/trunk/src/libgcv/test_bottess.c: start filling in the "all deleted" compose condition |
| 15:16.08 | ``Erik | heh http://open.salon.com/blog/jlsathre/2012/01/11/25_things_i_learned_from_opening_a_bookstore |
| 15:44.06 | starseeker | hehe |
| 15:44.35 | starseeker | sounds like a fun store |
| 15:50.57 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) |
| 15:58.13 | CIA-48 | BRL-CAD: 03erikgreenwald * r49126 10/brlcad/trunk/src/libgcv/test_bottess.c: makr foo. test nfaces. init bn_tol. |
| 16:01.41 | starseeker | rebuilds the will to much with Windows... |
| 16:15.48 | CIA-48 | BRL-CAD: 03erikgreenwald * r49127 10/brlcad/trunk/src/libgcv/bottess.c: fix off by one error in bulk face removal |
| 16:27.19 | CIA-48 | BRL-CAD: 03erikgreenwald * r49128 10/brlcad/trunk/src/libgcv/bottess.c: fix bug, wrong faces being removed and kept. |
| 16:28.06 | CIA-48 | BRL-CAD: 03erikgreenwald * r49129 10/brlcad/trunk/src/libgcv/test_bottess.c: add more compose tests |
| 16:35.33 | ``Erik | y'know, if that was it, I'm not sure if I'm gonna be happy or pissed O.o *starts rebuilding test geometry) |
| 16:47.59 | *** join/#brlcad merzo (~merzo@109-192-133-95.pool.ukrtel.net) |
| 16:48.17 | starseeker | votes both |
| 18:09.04 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) |
| 18:19.26 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) |
| 18:28.18 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) |
| 18:28.42 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) |
| 18:53.36 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) |
| 19:19.44 | CIA-48 | BRL-CAD: 03n_reed * r49130 10/brlcad/trunk/src/libbu/test_sscanf.c: add tests for string termation behavior and support of literal ']' and '-' in character classes |
| 19:46.47 | CIA-48 | BRL-CAD: 03n_reed * r49131 10/brlcad/trunk/src/libbu/test_sscanf.c: ensure float constants are printable |
| 20:07.44 | starseeker | growls... RUNTIME_OUTPUT_DIRECTORY IS being set, but it's either not reaching the MSVC project files or its being overridden by something else |
| 20:13.58 | *** join/#brlcad IriX64 (~kvirc@64.229.211.15) |
| 20:15.07 | IriX64 | further to that pastebin last night, both src/other/tk and tcl INSTALL files are empty, and i don't know how to fix it. |
| 20:15.56 | IriX64 | ciao |
| 20:16.02 | *** part/#brlcad IriX64 (~kvirc@64.229.211.15) |
| 20:16.22 | starseeker | confound it - what platform, config options?? |
| 20:22.18 | *** join/#brlcad merzo (~merzo@148-11-132-95.pool.ukrtel.net) |
| 20:39.30 | *** join/#brlcad DarkCalf (DC@173.231.40.98) |
| 20:43.18 | CIA-48 | BRL-CAD: 03starseeker * r49132 10/brlcad/trunk/CMakeLists.txt: Looks like we need to set target properties for multiple configurations, in order to re-direct appropriately. |
| 21:12.00 | starseeker | brlcad: tried building bootstrap.cpp into mged - doesn't seem to work, even when I try adding /DELAYLOAD |
| 21:12.53 | starseeker | if you want to give it a go it should be simple now - the default Windows build will put everything into lib, just add ../../misc/win32-msvc/bootstrap.cpp to the MGED sources list |
| 21:25.39 | starseeker | ``Erik: any luck? |
| 21:27.24 | ``Erik | hrm? |
| 21:28.56 | starseeker | with the bots |
| 21:29.25 | ``Erik | a little, it's uncovering bugs, but at least they're understandable now O.o |
| 21:34.57 | ``Erik | (rather be dorking with lithp, though... *sigh* :) |
| 21:41.44 | starseeker | <snort> could be worse - wanna try to convince Windows to have dlls somewhere other than the executable directory? |
| 21:42.46 | starseeker | realizes he probably shouldn't have expected that bootstrap.cpp test to work, given the definition of BRLCAD_ROOT that was probably used |
| 21:43.11 | starseeker | crud... back to Windows... |
| 21:50.14 | ``Erik | <-- quickly deletes his msvc to stay out of this O.o |
| 21:55.12 | starseeker | crap - nope |
| 21:55.55 | starseeker | sigh... this just isn't how Windows normally works... |
| 21:56.18 | starseeker | brlcad: I guess we'll need to have a go at it next week. |
| 22:14.44 | ``Erik | would be curious to hear bob and keith opine on this, thinks the bootstrap thing has an 'ugly wrong hack' smell, but isn't a windows guy O.o |
| 22:14.58 | ``Erik | (also; "windows normally works"? O.O ) |
| 22:15.22 | starseeker | ``Erik: Sean and I discussed it yesterday - he wants to maintain the build/installation tree layout consistently across platforms |
| 22:15.37 | starseeker | disagrees, but you know how that goes... |
| 22:15.57 | ``Erik | I read as much in the backlog, but our layout is "unix", and windows is not unix |
| 22:18.25 | ``Erik | why not just have a set 'relative lib dir' and make it '...\bin\' for windows? even auto* is set up for user/admin settable lib paths, --libdir= |
| 22:19.00 | starseeker | it's not that we couldn't make the "standard" Windows behavior work - by and large, it already WAS working |
| 22:19.15 | starseeker | the trigger was the BotUtility thing in Archer, but something else is wrong there |
| 22:19.41 | starseeker | (maybe just need to get package require libbu working...) |
| 22:19.57 | ``Erik | the issue was loadlib("%s/lib/mylib.so", basedir()); not working on windows, so bob had to do an "if windows" clause? |
| 22:20.00 | starseeker | anyway, the issue is not functionality related - it's the platform difference |
| 22:20.35 | starseeker | that was one issue - if I understand brlcad correctly, he regards that as a separate issue from the platform-dependent layout |
| 22:21.53 | ``Erik | loadlib("%s/mylib.so", libdir()); seems cleaner than trying to twist windows into a unix to me :) *shrug* I still think it'd be interesting hearing windows peoples thoughts on this |
| 22:22.54 | starseeker | ``Erik: there are probably a couple cleaner ways to do that, but even if we do clean that up the layout issue remains :-/ |
| 22:23.17 | ``Erik | (and common layout be damned, shoving square pegs in round holes will never be 'right') |
| 22:24.18 | ``Erik | next, we'll be forcing all platforms to have Brlcad.app/Contents/Linux-x86_64/mged or something |
| 22:25.22 | starseeker | winces |
| 22:25.56 | ``Erik | reductio ad absurdum :) |
| 22:26.34 | starseeker | hopefully brlcad will be back on later and you can get it straight from him - second-hand is probably a bad way to come at this discussion |
| 22:26.50 | starseeker | doesn't want to mischaracterize what he said due to lack of understanding... |
| 22:30.04 | ``Erik | I probably won't be on, kinda planning on moving my server and it might take a few days before I'm back on irc O.o mebbe the right set of people will end up in a room next week to explore ideas and rationales |
| 22:30.31 | starseeker | fun fun |
| 22:30.41 | ``Erik | (and once it goes into the abyss of meetings and groupthink and committee, it'll die a slow painful death) *cough* O:-) |
| 22:31.36 | ``Erik | lispworks 6.1 came out O.o |
| 22:31.52 | starseeker | would prefer bu_brlcad_libraries (in the same vein as bu_brlcad_root and bu_brlcad_data) as a way to reliably get the libraries directory |
| 22:32.52 | starseeker | or even wrap it all into a bu_brlcad_path(type, rhs) that takes root, data, libs, etc. for type and does the right thing under the hood |
| 22:32.54 | ``Erik | me, too.. package maintainers might do something retarded like /usr/brlcad/lib64 or /usr/lib/brlcad/ |
| 22:34.02 | starseeker | that's again a separate issue from the layout question, I suppose |
| 22:34.39 | starseeker | ponders putting together bu_brlcad_path... might be interesting to test out... |