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