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

IRC Nick Time (GMT-7) Message
jtojanen 04:12 What was the solution to depency on boost date_time ?
I mean because we use boost::recursive_mutex, and it has dependency on Boost DateTime library..
taxilian 07:12 If jtojanen doesn't read the logs and doesn't stick around till I get up I don't know how he expects an answer on IRC
FB_GitHubBot 08:12 FireBreath: firebreath-1.4 Richard Bateman * 3e1f4f2 (1 files in 1 dirs): Added date_time dependency for WITH_SYSTEM_BOOST ... - http://bit.ly/fONQcJ
jtojanen 11:12 Taxilian, are you there?
Yesterday I was troubleshooting build problem with Boost
I see that you have a solution that works
Why do you need add_boost_library() ?
I replaced "find_package(Threads REQUIRED)" with "find_package(Boost COMPONENTS date_time thread REQUIRED)"
And removed add_boost_library() calls
If you have "find_package()" and "add_boost_library()", libraries are added twice; look at linker command line
taxilian 12:12 jtojanen: I will be at a computer in abt 30 min
jtojanen 12:12 okey
jtojanen 12:12 I will take dogs out before the "war" begins here in Finland as clock is almost midnight
taxilian 13:12 lol
jtojanen: I'm back when you are
taxilian 13:12 jtojanen: To answer your question, though, we have add_boost_library() for those (the vast majority) who don't use system boost. We don't generally worry about those who do, since system boost usually (I thought always, but I guess not) does autolinking, which prevents the problem you had
and we don't normally require date_time because in the included boost (whether because it's 1.44 or because of something else I don't know) doesn't actually have a dependency on date_time
taxilian 13:12 so any comments or reactions to the JSAPI refactor? Everyone gone?
jtojanen 14:12 Well, boost auto-linking won't work as libraries are defined using "target_link_libraries", not as "link_libraries"
taxilian 14:12 boost auto-linking has nothing to do with cmake
jtojanen 14:12 I know
taxilian 14:12 Then I'm not sure what you're referring to
jtojanen 14:12 but target_link_libraries define exact path to one library, but link_libraries define path to libraries
where all the libraries are located
and so auto-linking would work
taxilian 14:12 I have absolutely no idea what you're talking about… those sound like cmake commands, except that link_libraries in cmake is deprecated
jtojanen 14:12 In Visual Studio "link_libraries" match with "Addiotional Library Directories".
taxilian 14:12 really? that's strange… it shouldn't
jtojanen 14:12 I have tested
taxilian 14:12 huh
good to know
jtojanen 14:12 Take a look at your linker command line
taxilian 14:12 oh, I know where it goes if that's what it does
I just don't use that command because it's deprecated
when I've needed to do something similar in the past I've just passed extra LINK_FLAGS
jtojanen 14:12 And auto-linking is not supported by all platforms
taxilian 14:12 good to know
anyway, did my explanation of why we're using add_boost_library make sense?
and do you have a better suggestion?
jtojanen 14:12 So we should always use target_link_libraries
taxilian 14:12 yes
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:link_libraries
link_libraries: Deprecated. Use the target_link_libraries() command instead.
the weird thing is that according to those docs, it should add specific libraries, not directories
very strange
jtojanen 14:12 Try out "find_package(Boost COMPONENTS date_time thread REQUIRED)"
taxilian 14:12 that's why I was so confused
well, we could do that
but if we do that then I'm not sure if other libraries will work
and there are times when we need other libraries as well
jtojanen 14:12 They will
taxilian 14:12 let me look at it and get on the same page
btw, happy new year =]
jtojanen 14:12 In that case you have to define "find_package(Boost COMPONENTS library_needed)
You too
taxilian 14:12 so you're in Finland?
jtojanen 14:12 Southern Finland, Vantaa
taxilian 14:12 cool. the only place in Finland I've ever been was Helsinki
for about 6 hours :-P
jtojanen 14:12 Clock is now 23.08
taxilian 14:12 jtojanen: are you suggesting that we replace add_boost_library with the find_package line you suggested?
jtojanen 14:12 Regarding "find_package" it adds Boost include
yes
taxilian 14:12 right
have you looked at the definition of add_boost_library?
jtojanen 14:12 and boost libraries
yes i have
taxilian 14:12 it's on line 84 of cmake/common.cmake
… and all it calls is find_package
am I missing something?
jtojanen 14:12 one second
In projects you use "target_link_libraries(${PROJNAME} ${Boost_LIBRARIES} ..."
taxilian 14:12 right.. does it add those automatically when you use find_package somehow?
jtojanen 14:12 find_package adds necessary libraries to Boost_LIBRARIES
variable
taxilian 14:12 right...
I'm still not understanding where the problem is; I apologize, I must be slow today =]
jtojanen 14:12 So the one liner is all that is needed "find_package(Boost COMPONENTS date_time thread REQUIRED)"
Try it
taxilian 14:12 in place of what?
jtojanen 14:12 root CMakeLists.txt instead of find_package(Threads REQUIRED)
taxilian 14:12 oh, that shouldn't be finding boost threads
… in point of fact, I'm not actually sure what that is there for
I think it just verifies that the platform supports threads, which actually seems a little silly
I didn't put that there, but it doesn't really have anything to do with boost, AFAIK
jtojanen 14:12 But projects depend on Boost Thread
taxilian 14:12 right; that's what add_boost_library(thread) does
find_package(Threads) will look for a package called "Threads"
and I'm really not sure what that is for… let me see if I can figure out where it came from
jtojanen 14:12 Typo
taxilian 14:12 no, that's not supposed to be boost_thread
jtojanen 14:12 It should be thread instead of Threads
taxilian 14:12 and it wouldn't work if it were
kalev: you around?
it was added here: https://github.com/firebreath/FireBreath/commit/5f796d1ad375cf6d56469615d5ace7674997eac7
interesting
"Also link wtih native threading library to avoid issues with missing symbols when linking statically against boost thread library"
so aparently that's why it is there. that's not a boost library, it's actually the native thread library and boost depends on it
jtojanen 14:12 What is this "native threading library"?
taxilian 14:12 presumably pthread
jtojanen 14:12 But boost thread links with pthread
taxilian 14:12 unfortunately, neither kalev nor wargloom are around to ask for more details, probably because they are much closer in the world to you than me
linux C/C++ development isn't my forte, I'm afraid
jtojanen 14:12 Same here
Okey but now I understand
taxilian 14:12 good good. now you see why I was so confused =] I can totally understand your bemusement at those two lines :-P
jtojanen 14:12 I have other question but food is getting cold. right back
taxilian 14:12 no problem. I'll be here for a few hours
jtojanen 15:12 Had to return to the fire from neighbours :)
taxilian 15:12 =]
jtojanen 15:12 In gen_templates\FireBreathWin.rgs ApplicationId is registered to odd place, HKCU\Software\ClassesB ? Surely it is not the first place, should it be Classes (without the B) ?
taxilian 15:12 err, no, that should be Classes without the B
jtojanen 15:12 Problem is that it is marked as NoRemove so it stays after uninstall
taxilian 15:12 *goes to check the source*
wow...
Huh; that's been there a long time
you're the first to notice
I'll fix that real quick
jtojanen 15:12 thanks
taxilian 15:12 are you the guy who knows COM pretty well?
jtojanen 15:12 the same guy
taxilian 15:12 (sorry, I have a hard time keeping track of people who pop in and out =])
jtojanen 15:12 :)
taxilian 15:12 hehe. do you have a sec to ponder a question from me?
jtojanen 15:12 sure
I still have a problem with ActiveX registration..
FB_GitHubBot 15:12 FireBreath: firebreath-1.4 Richard Bateman * 27a825e (1 files in 1 dirs): Removed long-standing typo from FireBreathWin.rgs - http://bit.ly/fULeTQ
taxilian 15:12 go ahead with yours first
mine may be convoluted
jtojanen 15:12 Problem is located at FireBreathWin.cpp
taxilian 15:12 okay
jtojanen 15:12 DllRegisterServer always registers per use
FB_GitHubBot 15:12 FireBreath: master Richard Bateman * 3e1f4f2 (1 files in 1 dirs): Added date_time dependency for WITH_SYSTEM_BOOST ...
FireBreath: master Richard Bateman * 27a825e (1 files in 1 dirs): Removed long-standing typo from FireBreathWin.rgs
FireBreath: master commits 424d15e...27a825e - http://bit.ly/f8YE6L
taxilian 15:12 ahh, yes; that should perhaps be configurable
jtojanen 15:12 mean per use
men per user
taxilian 15:12 I understood you =]
jtojanen 15:12 :)
If one wants to install per machine (all users) it is currently impossible
DllInstall could be modified to this
but it calls DllRegisterServer which always redirects to per user (HKCU)
Line 98
and then line 71
Actually DllInstall tries to implement this behaviour
taxilian 16:12 yeah, I overrode it back a long time ago
gimme a sec
jtojanen 16:12 I am a big fan of Boost so I have to ask, what do you think about Boost Variant?
taxilian 16:12 you're wondering why we don't use it instead of the variant class we have?
jtojanen 16:12 that is the idea
taxilian 16:12 well, the first thing is that when we wrote variant originally I was trying really hard not to add any external dependencies, such as boost
as time went on, it became obvious that wouldn't work
but by then we already had this variant class, which works quite well, and had customized it for our needs
what we use is actually closer to boost::any than boost::variant
and the main thing we needed that those two classes don't really give us is type conversion
jtojanen 16:12 Without helper class
taxilian 16:12 right; we could certainly find a way to add in what we need
but at this point it's a question of taking the time
I already know how to use this one, so why switch to boost::any?
boost::variant doesn't support new arbitrary-ish types like any does, which is nice
though I have (yesterday) changed the default behavior so that FB::variant will no longer take an unknown type without complaint unless you use an alternate constructor
thus giving the ability to pass arbitrary types through the system and write your own conversion functions for them, but not making it implicit
jtojanen 16:12 Which is one step closer to Boost Variant type of behaviour
taxilian 16:12 true
to be honest, I'm not at all opposed to the idea of looking at using a boost class instead of the cdiggins-derived one. I just don't have time
conceptually, it's a better idea to use tested, well designed classes
in practice, this works :-P
jtojanen 16:12 If if works, don't try to fix it
taxilian 16:12 that's my thought exactly =]
I considered looking at it yesterday, since I just spent a full day working on variant
but I was pretty sure I could do what I needed in the time I had on variant, not sure if I had to learn a new class and port all the conversion stuff to the new class
I have a proposed fix for your per-user issue: https://github.com/taxilian/FireBreath/commit/5c6247a319de8ee381feb5f88488f3c984a3dbf7
jtojanen 16:12 let see
taxilian 16:12 do you mind doing a quick code review, possibly testing it? my build environment isn't in a useable state, I'd have to set up a second one
ahh, oops, didn't mean to commit the set in PluginConfig; ahh, well, it's not in the trunk yet, I can still fix it =]
so my issue with ActiveX; I'm trying to seperate everything better into logical projects, preferably that can be mostly built statically. People keep wanting FireBreath to be a library that they can just link to, and I'm at least trying to get closer to that eventual dream. The problem I run into is with COM; I end up having to templatize both my COM classes
I'm just trying to figure out if there is a better way
jtojanen 16:12 I saw that
taxilian 16:12 kinda scary, no? =]
but so far the best solution I've come up with
jtojanen 16:12 I have implemented IDisplayEx myself to be used with JScript
And had that kind problem with it
taxilian 16:12 it would also be good to find a way to be able to provide a class that derives from FBControl so that the plugin dev can override the class like they can with npapi
IDispatchEx, you mean?
jtojanen 16:12 Should go to sleep
01:18am
taxilian 16:12 hehe. what do you think; is the changeset I sent you a valid way of allowing per-machine installs?
if so, I can push it up
jtojanen 16:12 yes it will work
i will have build it; second
taxilian 16:12 cool, thanks
I am adding boost::optional support to FB::variant
jtojanen 16:12 I have this plugin that utilitilies COM Server that provides IDispatch/IDispatchEx objects which provide the interface info using TypeLib
taxilian 16:12 what do you think overall of the way that FireBreath interfaces with IDispatchEx? Is there anything weird or stupid that I'm doing?
jtojanen 16:12 It is kind of ActiveX/NPPlugin to COM :)
There are things to explain to you
taxilian 16:12 well, if you have time sometime I'd appreciate it. believe it or not you're the first person I've talked to who actually understands it all better than I do
which is really really sad, when you think about it =]
I understand your desire to sleep, though =] it can be another time
btw, how is 2011?
jtojanen 16:12 It will benefit both of us :)
Dark and cold winter with a LOT of snow
taxilian 16:12 hehe
yeah, we have a bit of snow, but probably not like there
except here in the mountains — that's probably about the same =]
jtojanen 16:12 Currently 70 cm
2 feet
fatal error C1083: Cannot open include file: 'Win/win_common.h'
taxilian 16:12 change it to just win_common.h
jtojanen 16:12 at plugin dllmain.cpp(12)
taxilian 16:12 (breaking change from the last couple of days, sorry)
you'll also need to change resource.h to global/resource.h
and config.h to global/config.h
jtojanen 16:12 so i can take the line 12 out ?
with win_common.h
taxilian 16:12 not sure I understand. "Win/win_common.h" has been moved, it is now just "win_common.h"
jtojanen 16:12 i will look from the template
taxilian 16:12 yeah, just copy dllmain.cpp and np_winmain.cpp from fbgen/src/Win =]
you don't often change those anyway, so unless you have...
jtojanen 16:12 I didn't have any changes there
taxilian 16:12 makes it easy
jtojanen 16:12 One thing that I was happy about was the change regarding StaticDeinitialize
taxilian 16:12 you know, I've been trying to find a better place to put that for literally years
and it just hit me one day that the browser wouldn't call CanUnloadNow until it was ready
obviously I couldn't put it in DllMain
jtojanen 16:12 I have UAC elevation moniker as global
Yes, and you cannot block inside DllMain
Let say wait worker threads to stop
taxilian 16:12 right; been there tripped over that :-P
so that is a good place to put StaticDeinit, then?
jtojanen 16:12 the right place
taxilian 16:12 I did some tests, and it seemed to work, but I've been still a little nervous =]
good!
jtojanen 16:12 I am using it on another project to clean up "singletons"
Before the change refreshing web page caused the UAC elevation to take place every time
now one per browser life time
i mean once
taxilian 16:12 excelent
I appreciate, btw, that you are willing to pop in and contribute when you find issues; I think I'm doing pretty well so far, but there is definitely a limit to my experience, particularly in the area of COM
many just drop in to complain
jtojanen 16:12 In past I used Google Gears as a base for my projects
kylehuff 16:12 but some, like me, stick around to complain!
=c )
jtojanen 16:12 Have you seen/studied that?
taxilian 16:12 I have read through parts of it
not as much as I probably should
that's true. Kylehuff gets full credit for sticking around while he complains ;-)
jtojanen 16:12 Regsvr32 likes the modification
HKLM registration works
taxilian 16:12 awesome. I'll fix the one little issue and push it to master
are you using git or downloading?
jtojanen 16:12 git and sync with our SVN
taxilian 16:12 ahh. I'll be nice, then, and not rewrite the history =]
jtojanen 16:12 GitHub used to provide svn access but it doesn't work
taxilian 16:12 it doesn't work? it always has for me… 'course, it's been a few weeks since I last tried, but it was working then
jtojanen 16:12 Hasn't work since beginning of December
taxilian 16:12 weird
FB_GitHubBot 16:12 FireBreath: master Richard Bateman * 5c6247a (3 files in 3 dirs): Added support for FB_ATLREG_MACHINEWIDE in PluginConfig.cmake
FireBreath: master Richard Bateman * cb4c560 (2 files in 2 dirs): Added to fbgen template instruct for machine-wide reg
FireBreath: master commits 27a825e...cb4c560 - http://bit.ly/dIfHFt
taxilian 16:12 and there it is
jtojanen 16:12 well git access works
taxilian 16:12 yeah; now that I've really learned how to use git, it drives me crazy to have to use svn
jtojanen 16:12 Now I will have to get some sleep
taxilian 16:12 sleep well, and thanks for the help