IRC Log Viewer » #firebreath » 2010-12-08

IRC Nick Time (GMT-7) Message
meegee 02:12 hi
is anyone around?
jshanab_wcw 05:12 morning
jshanab_wcw 07:12 I am getting a "unresolved external symbol _initializeWinsockIfNecessary" error and I cannot figure out what to put in the projectDef.cmake
neilg_ 07:12 jshanab_wcw: What library is that symbol in?
jshanab_wcw 07:12 libwinsock2 i believe. i have tried winsock,winsock.lib, libwinsock... oh, got am idea
neilg_ 07:12 libwinsock? Are you using cygwin or something?
I'm not familiar with that library
I'm wondering if you mean ws2_32.lib?
jshanab_wcw 08:12 I do not know. code has include "winsock.h" it is what I remember using years ago. I will try ws2_32.lib in the projectDef.cmake
neilg_ 08:12 Yep, that should work. You'll need to add it as a library dependency if you're using winsock
http://www.firebreath.org/display/documentation/Using+Libraries
jshanab_wcw 08:12 i guess ws2 stands for winsock2 :-) . But it looks like this points to another problem, I have windows specific code in my common directory. Files from the live 555 streamer code i assumed was platform agnostic
jshanab_wcw 09:12 Does anyone know how to add WS2_32.lib at the CMakeList.txt level? I nned to put it in an if(WIN32) in one.
neilg_ 09:12 Yes, follow the link I gave
That describes how to do it at the CMakeList.txt level
taxilian 09:12 jshanab_wcw: why do you want to do it in CMakeLists.txt instead of projectDef.cmake?
neilg_ 09:12 CMakeLists.txt I meant
jshanab_wcw 09:12 Because it is a file in the live555 streamer that already checks for win32 and includes or not. I don't have a WIN directory for it
taxilian 09:12 so? it's still going to always be there on windows, right?
jshanab_wcw 09:12 neilg, I dod that but it errors out on the NOTFOUND. I don't know how to create a valid search i guess
taxilian. I dunno, should I create a WIN subfolder? will it automatically be picked up? or do I just put a projectDef.cmake in that folder?
taxilian 09:12 oh, wait.. this is another project
got it
all you need to do is put if (WIN32) …. endif() around the target_link_libraries
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:target_link_libraries
jshanab_wcw 09:12 ok, but how do I specify the location? (Which may change from windows 7 to XP 32 and 64 bit)
taxilian 09:12 which library?
jshanab_wcw 09:12 WS2_32.lib
taxilian 09:12 you shoudln't need to
just put WS2_32.lib
jshanab_wcw 09:12 I'll try it again, maybe it is case sensitive
taxilian 09:12 not on windows it won't be
check the project settings, as usual
what function is it that you are using that needs this?
jshanab_wcw 09:12 It is used by the BasicUsage Environment in the live555 streamer code
taxilian 09:12 what functions do you get link errors on if it isn't there?
jshanab_wcw 09:12 unresolved external symbol _initializeWinsockIfNecessary
When I try to check the properties, the linker section is replaced with a librarian section, I cannot see a ref to libs my lib includes. (but i can check with nm)
neilg_ 09:12 Right, because you're creating a DLL and not a library
(as in why you see the librarian section)
jshanab_wcw 09:12 Is the target_link_libraries additive? can I have more than one and can it be after the add_library statement? Sorry for all this Cmake Questions
neilg_ 09:12 Yes, it's accumulative
Also, you may well have to delete your build directory and regenerate it using CMake (or the prep script) because I've found CMake just not working properly when I add things like include paths or libraries
jshanab_wcw 09:12 ok, but it is statlic not a dll i thought
taxilian 09:12 did you do add_library(STATIC ?
jshanab_wcw 09:12 yes, for most of them, only the top level is a dll (I don't really want multiple levels of dll at the moment
taxilian 09:12 good plan
jshanab_wcw 09:12 I am surprized how long it takes to build when i delete the build directory. I have a decent machine with plenty of ram, I guess I am used to my house where 4 machines jump in on the build.
No difference, it still gets the same unresolved "unresolved external symbol _initializeWinsockIfNecessary"
neilg_ 10:12 You need to link against live555
That symbol comes from live555 and isn't in winsock (which is why I was confused earlier)
I had to google for it to find out where that symbol comes from and found http://comments.gmane.org/gmane.comp.multimedia.live555.devel/4791
taxilian 10:12 yeah; I was trying to figure that out, because initializeWinsockIfNecessary is not a winsock function
jshanab_wcw 10:12 oh!, my bad. Thanks
neilg_ 10:12 Right, that's why I was confused too. But hopefully that gives you enough to go on!
taxilian 10:12 so what does everyone think of the new logo?
jshanab_wcw 10:12 I am wondering if I am putting things in the correct place. I see my CPlayer.obj trying to link in BasicUsageEnvironment and it in turn tries to link in GroupSock.lib. The first linker error is in BasicUsageEnvironment, but it is unclear to me wher to link in cause the same error is also in the groupsock ref. Visual studio error meesages a so clear
taxilian 10:12 =] can't help you there… I'd have to see the whole project
I've decided that git pull —rebase is my best friend
amackera 10:12 taxilian: Ooo I like the new logo!
taxilian 10:12 good timing saying that, since kylehuff made it =]
neilg_ 10:12 I like it too, it's nice
FB_GitHubBot 10:12 FireBreath: master Richard Bateman * d3c46ab (2 files in 2 dirs): Fixed lingering issues with using vs express - http://bit.ly/ewgipI
amackera 10:12 it's much less trademark-infringe
infringing* :P
taxilian 10:12 yeah, definitely =]
amackera 10:12 kylehuff: nice work on the logo!
kylehuff 10:12 thanks amackera - but I was just the API to photoshop; taxilian, netjunki and jshanab_wcw were driving
taxilian 10:12 LOL
amackera 10:12 haha
FB_GitHubBot 10:12 FireBreath: firebreath-1.3 Richard Bateman * b61ef00 (2 files in 2 dirs): Fixed lingering issues with using vs express - http://bit.ly/iadyJB
jshanab_wcw 10:12 LOL http://www.firebreath.com/
taxilian 10:12 yeah
I tried to snag that one
but they renewed it on time :-(
it was 2 weeks from expiring =]
jshanab_wcw 10:12 The google hosting link first found in google is down
taxilian 10:12 yeah
google code is currently down
they made it read-only for maintenance this morning
I think someone broke something =]
jshanab_wcw 10:12 I wantd to see the newest logo
taxilian 10:12 it's on firebreah.org as well
in fact, it's pretty much everywhere we have a logo now =]
jshanab_wcw 10:12 OK, cool. hey the font looks like a "brand" hehe
taxilian 10:12 lol
jshanab_wcw 10:12 I have 4 directories at the same level and 3 of them and one above depend on it. Haveing an add_library in each and trying to get the dependencies correct is getting me. What is the best way to set up this build. Can I eliminate all the add_libraries except the top level and somehow get all these picies at once into it
taxilian 10:12 if they are all static libraries, you shouldn't have to link them all together, you should only need to have all of the dependencies set at the base level
I think
in the DLL itself
you could possibly put all of them into the same static lib, yes
jshanab_wcw 10:12 Is there a good example of that?
taxilian 10:12 you can include files from a different subfolder, that's not a problem
jshanab_wcw 10:12 I would still have a CMakeList.txt file in each directory or no?
taxilian 10:12 file(GLOB dir_files RELATiVE ${CMAKE_CURRENT_SOURCE_DIR} dir/*.cpp dir/*.h dir/*.whateverelse)
and magically ${dir_files} contains all of the matched files
examples of that all over the place
there isn't anything weird about it
jshanab_wcw 10:12 ah.
taxilian 10:12 just add the files to ${SOURCES} (or whatever variable you use when you add_library)
you're making this cmake stuff far more complicated than it is, my friend =]
jshanab_wcw 10:12 So it seems. :-)
I didn't start that way but when things didn't work I complicated tham as I learned. All part of the process :-)
taxilian 10:12 hehe
I really, *really* wish there was an ebook version of Mastering CMake around
I also wish they'd sell it for a slightly more reasonable price… I mean, seriously. $55? that's a lot for a book this size on one topic
I really really want to build a book scanner; then I could digitize my books and carry all of them on my iPad (instead of just many of them)
jshanab_wcw 10:12 I tried the GLOB_RECURSIVE at one point
http://www-flc.desy.de/ldcoptimization/documents/talks/CMake_Tutorial.pdf
taxilian 10:12 huh. never used that one
there isn't one, actually… but there is a GLOB_RECURSE
jshanab_wcw 10:12 sorry... GLOB_RECURSE I'll let you know how it turns out ;-/
taxilian 10:12 =]
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:file
once you get the hand of 'em, the cmake docs are usable
I won't say good, but useable
jshanab_wcw 11:12 ok the GLOB_RECURSE works very well. it built and linked, now the moment(s) of truth
Gotta do the WiX
jshanab_wcw 11:12 taxilian. I am following the blog entries you made a while back, but I do not see a Wix or install project added to my solution. I have removed the build directory and reran prep and am rebuilding now.
taxilian 11:12 did you install WiX?
jshanab_wcw 11:12 Yup
taxilian 11:12 what version?
jshanab_wcw 11:12 3.5
taxilian 11:12 hmm. what version of FireBreath are you using? there was an issue with 3.5 that was recently fixed
jshanab_wcw 11:12 I don't remember, how do I check, there are no versions in the path names ??
taxilian 11:12 yeah, unfortunately there is no indication until 1.4, which is not yet out
jshanab_wcw 11:12 let me check my download log, it was last sat
taxilian 11:12 well, maybe a better way would be to just get the latest from github
either 1.3 or 1.4, your choice
jshanab_wcw 11:12 Actually I did git it. git can tell me right?
taxilian 11:12 then just git pull
jshanab_wcw 11:12 pretty recent? 3 files changed CMakeLists.txt,axutil.h and variiant.h
Should it create a top level project in VS2010?
taxilian 11:12 yeah; it should be called something like <plugin name>_WixInstaller
jshanab_wcw 11:12 It doesn't. Are there any steps I need to take beyond running prep
taxilian 11:12 shouldn't be
jshanab_wcw 11:12 release vs debug ?
taxilian 11:12 you could add some debug messages to cmake/WiX.cmake and see if it is finding it
shouldn't matter
where is WiX installer?
installed?
jshanab_wcw 11:12 I just used there installer, lemme look
c:/program files(x86)/Windows installer XML v3.5
taxilian 11:12 hmm. hsould find it with the changes I made
I don't know
jshanab_wcw 11:12 ok, I'll hit it after lunch
neilg_ 11:12 Did you restart your cmd window since installing WiX?
taxilian 11:12 shouldn't matter; WiX.cmake searches for the exe file, doesn't use the path
neilg_ 11:12 The WiX sets up environment variables that will only get picked up by new shell instances
WiX.cmake uses the environment variable
taxilian 11:12 not only
it uses several things
one of them is the path that he uses
I don't have wix in my path and it works fine
neilg_ 11:12 Because you have it in "Program Files" and not "Program Files (x86)"
What's in the cmake isn't enough
taxilian 11:12 actaully, no
I run windows 7 64 bit
it uses hte PROGRAM_FILES env var (or whatever), so it doesn't matter
neilg_ 11:12 The Cmake has "$ENV{ProgramFiles}/Windows Installer XML"
taxilian 11:12 right
neilg_ 11:12 ProgramFiles=C:\Program Files
taxilian 11:12 and if you look on a windows7 box, $ENV{ProgramFiles} == "C:\Program Files (x86)"
at least on all three of mine
neilg_ 11:12 ProgramFiles(x86)=C:\Program Files (x86)
I have a Windows 7 box right in front of me right now
There are two environment variables (the ones I listed above) that point to the two different locations
Depending on whether a 32-bit or 64-bit installer is used
taxilian 11:12 interesting; I wonder what hte differece is, then. because on my windows 7 box (in front of me), it's C:\Program Files (x86)
neilg_ 11:12 There's been at least one person (but maybe more?) who had problems getting it to work after installing WiX until they started a new shell so I looked through and saw that as being the likely problem
taxilian 11:12 good to know, though; that means that we need to update the search paths
neilg_ 11:12 I meant to mention it and then quite uselessly forgot. lol
taxilian 11:12 so we're both right, sometimes
I hate that. why can't windows be consistent?
neilg_ 11:12 I also have multiple Windows 7 64-bit machines, they're all set up the same way (with the two environment variables). I'm not sure why it's different for you - but the fact that it can be is troubling!
taxilian 11:12 there are two environment variables
but they are both the same
neilg_ 11:12 They're all Windows 7 Ultimate - but if that makes a difference then WTF... lol
taxilian 11:12 when I type "set" in the command prompt
mine are as well
welcome
neilg_ 11:12 I never knew until now that they could even be changed so... wow. That's quite sucky that they can't be relied upon!
taxilian 11:12 oh, I haven't changed them
I ahven't touched any of that
neilg_ 12:12 I believe you - I haven't changed mine either. Like I say, I wasn't even aware that they would be different
*across machines
taxilian 12:12 right. we'll want to update the WiX script to expect that...
neilg_ 12:12 And yet it definitely sounds like it's wrong on your machine because you have the two environment variables and one is pointing at the wrong Program Files path
I say wrong, I mean wrong from my understanding of how it should work. lol
In any case, it's a simple change to the wix.cmake script!
kalev_ 12:12 I just checked and these two variables are both the same for me too
PROGRAMFILES='C:\Program Files (x86)'
PROGRAMFILES(X86)='C:\Program Files (x86)'
PROGRAMW6432='C:\Program Files'
oh, interesting. In cmd.exe they are different but in bash.exe the variables match.
taxilian 12:12 my guess is that in 32 bit applications (even a 32 bit version of cmd) they match
which would indicate that cmake would most likely have them match as well....
neilg_ 12:12 Just another Windows oddity to deal with!
kalev_ 12:12 yep, makes sense
jshanab_wcw 12:12 both the same on 32bit, different on win 7 64 :-(
don't we have 2 arguments to the prep scripts in windows?
ok, found the "Other" wiki page
always right after I ask. pffft
neilg_ 12:12 :)
jshanab_wcw 12:12 Well, The env in wix.cmake has the env{wix} and tat alone will be correct. I have removed and rebuilt but i can't seem to get it to create the installer project
taxilian 12:12 be back in a bit
amackera 12:12 Strange... You can't overload a function that overloads an operator...?
Ah nevermind, default arguments in the first function caused ambiguity
jshanab_wcw 13:12 The dbg_msg in the wix.cmake. Where do those mesasages go?
Dumb Question. Is the wxs file in need of manual update or are those variables in there taken care of during project build
taxilian 13:12 those are taken care of during project build
jshanab_wcw 13:12 So i just need to get the darn project to show up, grrrr
taxilian 13:12 jshanab_wcw: the dbg_msg is a function in that file
jshanab_wcw 13:12 so there is a VERBOSE variable. How does that get set? add to the prpe command line
taxilian 13:12 right
jshanab_wcw 13:12 Could I coax you into an example
taxilian 13:12 prep2010.cmd projects build "-D VERBOSE=1"
jshanab_wcw 13:12 ah a -D
It does not seem to run that script, That is if I should see stuff echoed on the cmd window
taxilian 13:12 have you removed the WiX stuff from your projectDef.cmake?
jshanab_wcw 13:12 no, but i did add stuff above it, hummm
taxilian 13:12 wouldn't expect that to matter
jshanab_wcw 13:12 When i try to register my dll with regsvr32, it fails, I am thinking that is becasue it needs a bunch more dlls avcodec etc
taxilian 13:12 hmm. it could be several things, but that could definitely do it
jshanab_wcw 13:12 Can I instrument the cmake somehow to determine where it is missing the call that creates the installer project?
taxilian 13:12 hang on a sec, let me look at it
(sorry, I ahve a presentation in a few minutes, so I've been making sure I was ready)
jshanab_wcw 13:12 Another dumb Q. If the box is 64bit is WIN32 still true
taxilian 13:12 yes
you can add MESSAGE("fdafdsafdsa") whever you want it to print a message
when you set verbose=1 did it change the output?
jshanab_wcw 13:12 ok, will do
taxilian 13:12 note that many of the DBG_MSG lines are commented out
so that even verbose output isn't *too* bad :-P
jshanab_wcw 13:12 well the messages I added are showing so I will narrow things down. It calls that about 27 times, once per project :-)
taxilian 13:12 yep =]
awesome, huh?
hint: look at the first one, that's probably where the problem will show up
jshanab_wcw 13:12 weird i don't get the debug messages though
taxilian 13:12 when you add message(...)?
jshanab_wcw 13:12 I get the ones I add but not the built in ones, so something must be false.
neilg_ 13:12 jshanab_wcw: I recommend that you get a copy of Dependency Walker. It's a very useful tool that shows you all your dependencies. If you use it to open your plugin DLL then it will show you any DLLs you need to have in order to register it
jshanab_wcw 13:12 Thanks, been looking for a ldd/strace like tool
taxilian 13:12 ahh, yes. I misunderstood your question
dependency walker is your firend
friend, even
jshanab_wcw 14:12 Fire just rolls off your finger tips
jshanab_wcw 14:12 Found a weird one. the ${WIX_ROOT_DIR} is set but set to nothing, so it never searches ...
taxilian 14:12 that should only happen after the first time wix.cmake is included and doesn't find it
jshanab_wcw 14:12 But even subsequent calls to prep fail!
It gets stuck
It calls for every project, but only one project is the plugin and has a win directory
taxilian 14:12 right
because that include detects if WiX is installed
so the first time that it is included it looks for the WIX_ROOT_DIR
after that, WIX_ROOT_DIR will be empty if it didn't detect anything
jshanab_wcw 14:12 I put a SET(WIX_ROOT_DIR) before the if and it still doesn't call into the search, I need to read up on CMAke still
taxilian 14:12 so to really see what is happening, you need to look at the first time it is included
well, I have to write 2 2 page papers, so I'm going to disappear for a bit
jshanab_wcw 14:12 I think I am! the first one fails. And witht he SET() it should ALWAYS now enter the if and print the message inside
OK, thanks and "have fun"
taxilian 14:12 if you all could try to help all the people who need help, I'd appreciate it; I have to duck out :-(
good luck
if you don't figure it out before Friday I can probably help more then
maybe tomorrow
see ya
jshanab_wcw 14:12 FYI I could not get it to take the if in wix.cmake. When I comment it out, I get the installer project.
neilg_ 15:12 Strange. But you have something that works now?
jshanab_wcw 15:12 Well. I get this error when i try to build : Component cmpFB6001DE053FC67151C6334F843E3280 installs to user profile. It must use a registry key under HKCU as its KeyPath, not a file.
amackera 15:12 hmm.. what's the component's keypath set to?
jshanab_wcw 15:12 I have no idea where I would set that
amackera 15:12 Should be in your projects/<project>/Win/WiX/<project>Installer.wix file
jshanab_wcw 15:12 I thought that is a template and when I asked, nothing has to change in it
amackera 15:12 Yeah it's autogenerated for you, but you can see what the keypath is in there
It might help us debug?
jshanab_wcw 15:12 it says, LOL, keypath="yes"
amackera 15:12 haha... hmmm...
Actually wait.. is this file autogen'd?
I think that file is safe to modify, it's autogen'd from fbgen
(which is only run once, at plugin creation time)
jshanab_wcw 15:12 So is it possible that since i installed WiX after I did the FBGen that this file is not correct? that is why it still has "${PLUGIN_NAME}" in it?
amackera 15:12 I think this file gets run though cmake to fill in those variable
variables*
Hmm...
jshanab_wcw 15:12 When I run Cmake, it doesnt change.
amackera 15:12 That's right, the file in your projects directory won't change
The file in the build directory will be filled out with the proper values, I think
neilg_ 15:12 And even then... Maybe. I think it works most of the time but I've definitely found changes that CMake didn't bring across into the build directory. Which is why I often delete it and regenerate it!
jshanab_wcw 16:12 changed template from AppDirectory to CommonAppDirectory
taxilian 16:12 jshanab_wcw: did you get it working?
jshanab_wcw 16:12 I am about to double click on the msi
taxilian 16:12 oh, hey, did you try removing your build dir?
'cause it's possible that it cached the WIX_ROOT_DIR
jshanab_wcw 16:12 numerous times. I had to finally just comment out the if statement and then change the template to say CommonAppDataFolder
taxilian 16:12 hmm
jshanab_wcw 16:12 Maybe cause I installed WiX way after I ran fbgen ?
Where are the test pages you drug to the browser in your demo?
taxilian 16:12 no
fbgen has nothing to do with wix
it's in build/projects/<plugin>/gen/
jshanab_wcw 16:12 ah, gen. thanks
taxilian 16:12 I keep meaning to add something to put that in a more intelligent place
but haven't taken the time yet
jshanab_wcw 16:12 Sooo. the plugin shows up in about:plugins but no plugin loaded alert and plugin().setEvent() does nothing. i am wondering if because it takes a long list of parameters if it failed silently
taxilian 16:12 no
didn't you say that regsvr32 still fails?
until that is fixed, the plugin won't work
because most likely whatever causes that (unless you've been playing with parts of FireBreath that you haven't told me) is preventing the DLL from being loaded
jshanab_wcw 16:12 oh, well I thought that was because i was trying on one small piece. The other libraries are needed. but that is a good point, i probably need to add all the additional into the .wsx template. I thought (hoped) itwould take care of all the dependencies
taxilian 16:12 doesn't matter where it is installed; if it can't find the other DLLs, then the library won't load
this is why I try to avoid ever using other DLLs from a plugin; it complicates things
jshanab_wcw 16:12 yeah, but avcodec and all thothers are kinda needed, including Visual studion redistributable :-(
taxilian 16:12 can't help you there =]
just be aware that it's likely to be a pain
jshanab_wcw 16:12 the FBControl.htm was created at fbgen tiem and changes in VS will be kept thru prep ?
taxilian 16:12 anything (and everything) in the build dir is created by cmake
and will change without notice
at any time, unless you cut corners (which will cause you rpoblems later) you should be able to delete the build dir and recreate it by running the prep script
the only thing that fbgen creates is your plugin dir
and you can find the original files in fbgen/src/
however, if you want you can customize your FBControl.htm by copying it from gen_templates/ in the root into your plugin dir
and it will use the template in your plugin dir instead
jshanab_wcw 16:12 Thanks, I knew I saw you do that in a tutorial :-)
taxilian 16:12 do which?
jshanab_wcw 16:12 changing the htm test page
taxilian 16:12 ahh. I guess maybe I did
now that I think of it, I must have in order to do the param tag example
forgot that
jshanab_wcw 16:12 Right, And I have the PARAM from hell 17 name=value's in one string
taxilian 16:12 lol
actually, that's not a bad way to do it
the reason why is that the plugin has to know the name of each param
so it's often easier to just parse a string than to keep adding new param tags to support
jshanab_wcw 16:12 Yeah it works out well, there is a utility class that when consturcted witht he string provides a map
taxilian 16:12 be back in a bit
taxilian 19:12 back
taxilian 20:12 scJohn: any luck with vs express?
taxilian 20:12 welcome
quite around here in the evenings =]
Austin 20:12 Hello taxilian, first time here and thank you for great work so far on this project. I'm mostly a passive follower at this point.
taxilian 20:12 you working on any plugins? just playing?
Austin 20:12 Just playing at this point, was planning on doing some usb/serial port access through plugin but nothing serious yet.
taxilian 20:12 cool
let us know if you run into any problems =]
Austin 20:12 I logged issue 115 last night, someone had problems compiling on Ubuntu.
Did you get the gist of the bug?
taxilian 20:12 yeah; I did, but I can't reproduce it
I thought I fixed it with the first patch you supplied
haven't had time to look at the second
this morning I tried but google code was down
Austin 20:12 There's a dependency problem which the second patch may fix.
taxilian 20:12 I don't have a full linux dev box at the moment
Austin 20:12 Basically, if you run prepmake.sh twice, the cmake output is different the second time.
taxilian 20:12 interesting
ahh, I see
Austin 20:12 It's due to cmake caching variables.
taxilian 20:12 yeah, that makes sense
Austin 20:12 The gtk stuff isn't the only place this happens, but I haven't had time to look at the others.
taxilian 20:12 I should have seen that; I moved it into the macro to try to fix something, but then still had to manually clear the variables
should have moved it back out
hmm. I'm really not happy with the way that GTK stuff works :-/ not sure how to improve it, though
the other one that I've seen is the issue with using log4cplus
but that only happens if you have two plugins and only one uses logging
Austin 20:12 Ok. I haven't looked at this in depth, but maintaining the correct dependencies in an easy way is sometime problematic. I haven't used cmake before
taxilian 20:12 hmm. I'll have to pull those patches in, but I won't have time to play with it until next week, I suspect
cmake is usually pretty good, but you do have to still be careful, like anything
Austin 20:12 That's fine, I only looked at this to try to help out someone on the list.
taxilian 20:12 I appreciate that
it takes a lot off my shoulders when others step forward to help
and right now I'm carrying a lot =]
Austin 20:12 Yes, I see all those emails on the list and don't know how you get time.
Unfortunately I don't get much time to look at this but I'll probably still follow along.
taxilian 20:12 well, glad to have you around anyway =]