IRC Log Viewer » #firebreath » 2013-07-29

IRC Nick Time (GMT-7) Message
wavey 03:07 hello
Wavey 03:07 Did any of you ever tried to run a firebreath plugin built on windows 7 (platform toolset v100) on windows 8?
taxilian 09:07 good morning all. I'm back in the office
michaelfig 10:07 Hi, I'm trying to implement a plugin with three different JS objects. At first, I had them registered in one plugin with different mimetypes, but that made IE get quite crashy when they were all used on the same page in different OBJECT tags. My new solution is to define a new JS root object, which registers the other three objects as properties. Is this supported, and has anybody else done it? I'm seeing "Error: Error cal
@taxilian: Good morning. Sorry for calling you "Robert" instead of "Richard" in my github pull request. :/ I'd be interested to know if you could use any of my changes. :)
taxilian 10:07 lol. no worries. hang on, let me look at it again
michaelfig you can definitely expose multiple JSAPI objects from a single plugin instance
but I don't know of any reason that using multiple mimetypes should make it "crashy"
michaelfig 10:07 It worked like a charm under other browsers, but my IE7 machine just didn't behave well... it apparently didn't do much checking to see that it didn't need to reinstall the plugin three times whenever it changed, and other stuff like that.
taxilian 10:07 okay; looking at these changes, the main reason I'm not going to accept this one is that there is far too much inside a single pull request; I need pull requests to be a single feature or fix (or a small group of completely related ones).
can you explain what you mean by ?
michaelfig 10:07 I like the design of a root object with three properties much better.
taxilian 10:07 it's cleaner, if you're just doing js tie-ins
michaelfig 10:07 The commit is because in log4cplus, it fails to compile unless you define _WIN32_WINNT. I think it's good practice in general to define this macro up front for all win32 projects, but if you leave it undefined, I think it should still compile.
What do you mean by js tie-ins?
taxilian 10:07 the general policy is to modify external libraries as little as possible, so that updating them will be easier
I mean if your plugin is only interacting iwth javascript and not drawing
michaelfig 10:07 I have the convenient situation of one of the three doing drawing, and the other two just as "tie-ins".
taxilian 10:07 then yeah, I'd just use a single object tag
so how does threads.cxx normally work in other projects w/out that defined, then?
michaelfig 10:07 Beats me. I'm using vc 2005, if that makes a difference.
taxilian 10:07 is LOG4CPLUS_USE_WIN32_THREADS normally defined?
michaelfig 10:07 Apparently so.
taxilian 10:07 hmm. I guess it's possible that it doesn't compile by default in 2005
I would probably prefer you used cmake to add a define globally rather than modify the log4cplus files directly, though
michaelfig 10:07 I agree, now understanding your 3rdparty library policies.
taxilian 10:07 I'm happy to accept, but would definitely prefer to have in its own pull request; I know it's a tad bit more of a pain, but if you just create a new branch (off of firebreath's master) and then cherry-pick it in it shouldn't take too long I need more information about what you're trying to solve
in particular, setting the extension on mac to .dylib is incorrect
michaelfig 10:07 Hrmm.
taxilian 10:07 I'm not sure where SUFFIX is used, though
michaelfig 10:07 In naming the file that's used in the call to chrome.cmake and xpi related stuff.
taxilian 10:07 I see. yeah, mac plugins are not dylibs
so the purpose of the commit is to make the XPI generation work better?
michaelfig 10:07 Yup.
taxilian 10:07 rather, to make it work on non-windows platforms
makes sense
michaelfig 10:07 Yes, exactly.
taxilian 10:07 I can only surmise, then, that you haven't tested it on mac =]
michaelfig 10:07 Yes, that's my third platform: first X11, then Win, then (with almost no experience) Mac.
Still trying to make the beast compile under Mac.
tonikitoo 14:07 $ FireBreath/ . build-release -D CMAKE_BUILD_TYPE=Release
is that the proper way to pass "release" to the prep build
taxilian, ^
I get something like this in console:
CMake Warning:
Manually-specified variables were not used by the project:
taxilian 15:07 tonikitoo you don't need to pass cmake_build_type except on linux
just set xcode to release mode