IRC Log Viewer » #firebreath » 2010-11-02

IRC Nick Time (GMT-7) Message
cygmatic 05:11 hm, i hate it when my mail client pretends a mail wasn't answered... taxilian_away, just hadn't seen yours before i answered
amackera_web 08:11 sweet!
amackera 08:11 lol
taxilian 08:11 cygmatic: that's okay, you gave him more information
taxilian 10:11 hey, luigi
welcome, even
luigi 10:11 hthanks
I' m one of tha lazy.... thanks for the web interface
I ' ve responded to your mail regarding external boost
taxilian 10:11 =]
reading now
hmm. the unable to open file sounds like a visual studio / boost install config problem
luigi 10:11 could be
I used a quite unstandard way of building boost that was based on cmake
taxilian 10:11 I would try to find that file (it'll be in your boost dirs somewhere) and then add that path to your global library path
luigi 10:11 that file is not in the installed lib folder
taxilian 10:11 then you don't have boost installed correctly
unfortunately, I'm no expert on boost
if it were me, I'd just use a cmake project to build your second binary and include it from the CMakeLists.txt of your first one
then you can just use the same stuff that FireBreath does
but that's me
luigi 10:11 I was thinking the same, the problem is I have to insert in the FB project all the stuff needed to build the other one
taxilian 10:11 what kinds of "stuff" are we talking?
it might be easy
luigi 10:11 I need to link to OpenSceneGraph and to my own code
taxilian 10:11 linking to a built library is easy
just add the path to the lib in target_link_libraries
you can even add an external vcproj
cygmatic: you around?
luigi 10:11 It is all built with cmake
taxilian 10:11 luigi: that should be even easier, then; just add the subdirectory with the cmakelists.txt file you need
take a look at the src/libs/ dir in the dev branch for some examples
particularly log4cplus, which has very little added at the bottom and can be built with or without FireBreath
luigi 10:11 where is the dev branch?
taxilian 10:11 linked to from here:
when I say branch I really mean repo, btw
luigi 10:11 found
taxilian 10:11 ultimately I want to have macros for adding firebreath library dirs so that you can add your own local to your plugin
which will hopefully encourage development of libraries that can be easily used with firebreath
luigi 10:11 I see log4cplus has the source inside fb repo
taxilian 10:11 yeah; I had to modify their cmakelists.txt, so I had to pull in the source
it's one of 3 libraries we do that with; the others are boost and unittest++
luigi 10:11 did you made some changes to boost also?
taxilian 10:11 yes
but not to the source files
we disabled the auto-linking stuff
and created cmakelists files for certain modules
also this is a subset of the boost functionality; it doesn't have everything
but has most things
luigi 10:11 aha ... maybe that is the problem that affects me ....
taxilian 10:11 and I'm happy to add things that are commonly used if I have missed something
not unless you're using the bundled boost instead of SYSTEM_BOOST
luigi 10:11 I can try to see if I can use interprocess within fb
probably not many people have used external boost under windows
taxilian 10:11 if not, let me know, and I'll add it
AFAIK, only you and nikita =]
however, I do know enough to know that the error you're getting is due to a configuration problem of your system boost
luigi 10:11 I would just like to get a recipy to build boost (or part of it) with cmake ... I could also use the same boost FB uses,
taxilian 10:11 you can do that with FB's libs if you want
it's pretty easy; just include the libs/<library> dir you need
luigi 10:11 in fb 1.3 boost is under src\3rdParty and has no CMakeLists.txt inside while log4cplus is under src\libs\ and has a CMakeLists.txt
taxilian 10:11 right
we never build all of boost
we build one lib at a time
the CMakeLists.txt is in src/3rdParty/boost/libs/threads, for example
luigi 10:11 I see
taxilian 10:11 the goal is always to build as little as neccesary
luigi 10:11 I see you put include(${CMAKE_DIR}/common.cmake) inside therads and dat-time boost
taxilian 10:11 yes; that's so that I can use the macros. You can surround that with IF( FIREBREATH ) if you need
luigi 10:11 I do not see any macros inside those files
taxilian 10:11 hmm. you're right
I forgot; I do boost libs different from toher libs
you can remove common; I don't think it's used, then
luigi 10:11 So probably I can use the boost lib inside FB in an external project
taxilian 10:11 should be possible
might have to tweak things a bit
if you do, send me a diff and I'll pull it into firebreath core
luigi 10:11 I have also found other small pb in resize event code
How is the best way to work? clone fb on google code?
taxilian 10:11 that's the easiest for us, since it lets us track who submitted the change
hg diff works as well, but it's a bit more trouble
luigi 10:11 Which is the best start point to clone?
some months ago I started a clone but did not had time to work on
And I did not found an hg gui interface
taxilian 11:11 I would do it off of dev, myself, but it depends on what you want to work off of
on windows there is tortoisehg
you can also update your old clone to trunk if you want
just hg pull from either stable or dev
luigi 11:11 is dev stable enough to work on?
taxilian 11:11 I'm working on it
so I think so =]
if you have any problems, I'm usually around to help
really even dev is generally pretty stable, though there are occasionally instances where something breaks. The main thing is that there may be features that haven't been fully tested yet
I think nirvdrum is developing off of it right now, and possible neilg_away as well
luigi 11:11 I' m not much proficient in hg: is easy to applay a mod
to apply a mod of stable to dev or vice-versa?
taxilian 11:11 I'm not sure what you're asking
a mod?
luigi 11:11 a diff, a commit
taxilian 11:11 it's about the same
the boost repo itself is actually seperate, in fact
just make the changes you need and then I'll walk you through creating a diff for me =]
and I'll put it in
neilg_ 11:11 Yup, we're developing with it right now
We just have to solve an issue with IE Protected Mode (nothing FireBreath can help with sadly!)
taxilian 11:11 yeah; if you want to start throwing stuff up on a wiki page for that, I'll try to help update it =] we really need to collect all the info for protected mode in one place
incidently, I'm (finally) adding a way to determine which FireBreath version was used to build a plugin
neilg_ 11:11 I'll definitely build a wiki for that though I think it boils down to launching an elevated process and using IPC to communicate between them :)
taxilian 11:11 yeah, but I think I've explained how to do that at least 20 times
you'd think I would have written it myself by now
is it vain that as I finally use FireBreath to create something real, I find myself more and more impressed with it? =]
I keep needing to do something and then finding "wow, that's even easier than I expected"
and I wrote most of it
be back in a bit
neilg_ 12:11 I've just discovered a flaw with registering a plugin DLL using regsvr32 with a limited user account
It makes sense even though it's frustrating
When you use a different user who has permissions to write to the registry then it installs into the HKCU for THAT user and not the limited user
So does anybody know what entries regsvr32 creates for a plugin? I'm going to have to replicate that for our installer (which, sadly, isn't using WiX)
taxilian 13:11 neilg_: strongly, *strongly strongly strongly* recommend using the WiX installer, even if you embed it in your other one
but if that's not something you're willing to do, the registry entries are most easily obtained using the WiX stuff and then pulling it out of the generated XML
neilg_ 13:11 Yup, I just realised that there were generated WiX scripts which I think have the relevant data that I need
taxilian 13:11 when dealing with plugins the number of things that can go wrong with install and upgrade cuts by at least 50% when you use an MSI
neilg_ 13:11 I'd love to use WiX - I liked NSIS for a while until I hit many of its shortcomings
taxilian 13:11 it isn't a question of WiX vs NSIS
it's a question of MSI vs anything else
neilg_ 13:11 We're using NSIS here but we have to hack around a few things to make it work
Right, I know
taxilian 13:11 yeah, I've used NSIS a lot for plugin installers
some of the worst work experiences of my life came as a direct result
neilg_ 13:11 The only problem we have with WiX is one more dependency on the build servers. I'd love to switch over to WiX after reading about it for the past few months
Used to use InstallShield... *shudder*
taxilian 13:11 (little things like executives of Comcast complaining that my installer didn't work and I was up for 3 days trying to figure out why)
which would you rather have? an additional dependency on the build servers now and a little learning time or a lot of troubleshooting why installs and upgrades aren't working right later?
granted, FireBreath's self-reg system is fairly solid, but there are still things that can go wrong over time
neilg_ 13:11 The only issue I have is that I need things to be per-machine and not just per-user which _hopefully_ is just a case of using HKLM instead of HKCU
taxilian 13:11 that requires admin access
I guess you're doing a game, though, right? so not as big of a deal
neilg_ 13:11 Writing to Program Files requires admin access
taxilian 13:11 you can tweak FireBreath to do HKLM by making a change to FireBreathWin.cpp
I think it's in ActiveXPlugin/
neilg_ 13:11 I assume it's the "FbPerUserRegistration perUser(true);"?
taxilian 13:11 yes
change to false
that should really be configurable
I think that'll be enough to do it, anyway
neilg_ 13:11 Where do you normally install plugins?
taxilian 13:11 experiment a bit
you might have to change the .rgs as well
neilg_ 13:11 Yup, I'm just testing that out now. Wait, .rgs? Not sure what that is
taxilian 13:11 I work with business and useability apps, not games. a large portion of my potential customers do not have admin access
the .rgs files are in gen_templates
but you can copy any of the files in that dir to your plugin dir and it will override it
it probably specifies HKCU, but I don't remember if that is actually honored ever or not
I know at least sometimes it is not
kinda weird
gotta love ATL
neilg_ 13:11 I plead the fifth
taxilian 13:11 oh, come now. everyone loves all Microsoft products. I know because Microsoft told me so
neilg_ 13:11 It's interesting to hear you say that because we're targetting similar segments - except we're also targetting education too. Because of that most people expect things to be pre-installed
I actually like a lot of what Microsoft's done and some of their APIs are really well designed. But other things are... less so
taxilian 13:11 pre-installed can be good, but the problem you run into is on a system like that, if it *isn't* preinstalled and it requires admin rights, the user can't install it
the nice thing about an MSI is that I believe it can be configured to install as admin if you have the ability to, but as user otherwise
you can do that with NSIS as well. if you do, you will probably regret it for the rest of your life
because you have no state when you uninstall or upgrade; if an MSI is installed as admin, it will require admin to uninstall or upgrade
NSIS may just detect that "oh, I'm not admin, so I'll deal with it in HKCU. hmm. not there. okay, put the new one there"
and you can get some really weird issues when things are only partially updated or uninstalled
neilg_ 13:11 I really don't like NSIS anymore. I did initially but just because something's better than InstallShield doesn't make it good!
Being stabbed in the eye repeatedly with a blunt object is better than InstallShield
taxilian 13:11 also, if you are targetting pre-installation scenarios then I would really recommend an MSI because it is generally much easier to mass-deploy an MSI
granted =]
I guess I'm really talking about any EXE installer, not just NSIS
that's just the one you mentioned and the only one I've used
crap, gotta run
remembered something
neilg_ 13:11 Sure, understood! I guess one of our worries is that WiX is still fairly new but it seems to do some really nice things
Okay, have fun!
taxilian 13:11 oh, sorry about that. I'm back =]
had to take care of something
WiX isn't all that new; also, while it was not developed by Microsoft, Microsoft now uses it for most of their installers
it is also the system recommended by Google
neilg_ 13:11 I saw that the Office team uses it. That's one of the reasons I'm pushing for us to use it instead of NSIS which, frankly, has been a rather large waste of my time
It doesn't even support UAC at all except through a third-party plugin - and as far as I'm concerned that's a minimum requirement for a decent installer these days
kalev 13:11 The Visual Studio team uses it also
neilg_ 13:11 I thought they did too but I didn't want to make false claims :)
taxilian 13:11 luigi: look at boost/config/auto_link.hpp
I think you'll find the answer to your question