IRC Log Viewer » #firebreath » 2012-04-12

IRC Nick Time (GMT-7) Message
eek 00:04 Hello. I am trying to compile firebreath 1.6 on VS2008 windows 7 linker gives me error: fatal error C1047: The object or library file '.\isigner.dir\MinSizeRel\converts.obj' was created with an older compiler than other objects; rebuild old objects and libraries
I am tried 2-3 rebuilds same error.
I have tried 2-3 rebuilds, but same error.
Nidhi 00:04 is Firebreadth supported on non-windows platforms?
FireBreathBot 06:04 JIRA issue http://jira.firebreath.org/browse/FIREBREATH-172 issue created by v.karatay
ssdc 10:04 @taxillian - is this a good time? I'm back (from yesterday) regarding the install issues ...
taxilian 10:04 probably as good as any. let me dig for aminute
ssdc 10:04 sure, sure ... in the meantime, I've been investigating a little on my end as well.
after setting FB_ATLREG_MACHINEWIDE - I'm seeing most things updating accordingly to what I expect
there's FBControl.rgs - which seems to lay out the registry settings once installed
in regards to the machine-wide install - it's setting the paths to HKLM, which is what I'd expect
once running the install though - everything gets stored in the HKCU
but the install does put the files in c:/program files/ etc
digging deeper - looking at the wxs file(s)
they're the ones that SEEM to me to be still referencing HKCU and not updating to HKLM
for example the *_auto.wxs - stores the plugin path in the registry in Software\MozillaPlugins\[name]\Path
but the registry root references HKCU
so ... the WiX stuff seems to me to be the issue - and how they end up being generated and setting up the registry, etc
BUT - I could be wrong :)
taxilian 10:04 that is more or less correct, yes
https://gist.github.com/2369011
so what I have is I have two different .wxs templates
one for all users, one for current user
ssdc 10:04 ok - but that seems to be the wxs template for the uninstall keys right? that doesn't help with the browser's ability to detect a plugin is installed, which seems to be getting set in the *_auto.wxs
taxilian 10:04 this covers all of that
that is automatically generated
there is no template
make sure you're on the latest 1.6
ssdc 10:04 let me check
taxilian 10:04 set(WIX_FORCE_PER "user") makes that one write to user; set(WIX_FORCE_PER "machine") makes it go to HKLM
ssdc 10:04 alright ... I might have an older version of firebreath - let me pull down the latest and try it out
unless 1.6 was released earlier than this past fall (which is when I pulled fb down originally)
taxilian 10:04 I really need to release 1.6.2
that might be recent enough, might not
pull the latest from the 1.6 branch
ssdc 11:04 not from master?
taxilian 11:04 you could do that too
that's what I'm using
technically that's now 1.7
ssdc 11:04 ah - ok, I'll stick with the latest and greatest :)
taxilian 11:04 it's not technically considered "stable", but it actually is just as stable as anything else, AFAIK
and I am using it with my production stuff
ssdc 11:04 ** pulled latest and now building after setting WIX_FORCE_PER to "machine" **
going to take a little while now ...
while I'm waiting for this beast to build ... semi-off topic question for you ... how does a browser choose precedence for where to pick up a plugin?
for example - we want to install initially in the local machine space
but when there are updates, perhaps install in the user space
will that conflict?
taxilian 11:04 well, what is *supposed* to happen is HKCU will override HKLM
and that usually seems to work
I wouldn't really recommend doing that, though
I'd stick with always doing it the same way; if you install per-machine, update per-machine
but theoretically it should work
ssdc 11:04 any reason not to go that way (other than it being somewhat messy)?
taxilian 11:04 just an increased possibility of ambiguity resulting in people getting confused and/or software not operating as expected
ssdc 11:04 sure ... we have a somewhat unique user though ... and trying to thread that needle
most of our users are in hospital settings, etc
and they're mostly non-admin
but in certain scenarios, an admin needs to setup a computer
and rather than just installing for each user, install it once
but updates on the current user space when available
that was our train of thought anyway
taxilian 11:04 do a lot of testing; it may happen that when you try to install the per-user it tries to uninstall the old per-machine, thus requiring admin rights
ssdc 11:04 we'll make sure to test it out :)
hrm ... didn't seem to solve the issue - still installing in the user space
I have set (FB_ATLREG_MACHINEWIDE 1) set (WIX_FORCE_PER "machine")
do I have to modify those wxs files at all?
taxilian 11:04 make sure the .wxs file you're using has InstallScope set to perMachine
ssdc 11:04 ok ... trying that real quick
taxilian 11:04 anyway, it should be easy enough to remove the nsis stuff from that example
and that's the only thing in there that you probably aren't using
ssdc 11:04 yeah - I haven't QUITE gotten to looking over that example yet ...
taxilian 11:04 lol
well, go look at that example, please. it does all that you want
ssdc 11:04 AH! changing the installscope worked ... i swear to got I tried that yesterday, but I only found out about the WIX_FORCE_PER today, so that part was new
taxilian 11:04 yeah, you need both
ssdc 11:04 sweet!
thank you! I'll check out the example to build both types of installers