Open GoogleCodeExporter opened 9 years ago
The same error appears on Windows 7 32bit.
Original comment by ge...@bisseling.de
on 4 Oct 2010 at 9:09
Well have you rebooted after the install? "C:\Program Files
(x86)\Lua\5.1\clibs" should be added to your %PATH%. Is it?
P.S. I don't have Windows 7 so this is going to be hard.
Original comment by rpusz...@gmail.com
on 4 Oct 2010 at 12:49
rpusztai: confirmed, it works after you reboot the install. It's in my path now.
Original comment by nitrod...@gmail.com
on 4 Oct 2010 at 2:18
Great. I am closing this issue then. Thanks for your help.
Original comment by rpusz...@gmail.com
on 4 Oct 2010 at 3:16
Isn't there a way to write to the path during the installation instead of
waiting until the next reboot?
Original comment by nitrod...@gmail.com
on 4 Oct 2010 at 3:42
Yup it does write it before, but you probably launched it from the installer.
So... Windows inherits the environment from the spawning app (the installer).
So the environment is old when it starts. I do set the installer so it tells
Windows that I changed the environment. It is a "chicken before the egg"
syndrome.
Original comment by rpusz...@gmail.com
on 4 Oct 2010 at 5:17
Rebooting is a workaround, that means the problem hasn't been solved and the
issue should not be closed.
The installer launched the examples script and the error shows up, made me
think there was something wrong with the install, looked it up on google, found
this page.
Original comment by daniel.v...@gmail.com
on 11 Apr 2011 at 8:01
Most other IDEs request a reboot on install (probably be as easy as setting a
flag in the installer for Lua), this would look and feel far more integrated
than letting people experience an error by default. Needs fixing! Thanks for
overall great packaging btw.
Original comment by janus.ol...@gmail.com
on 19 Dec 2011 at 10:33
I understand your comment, but what about simple updates? Are those suppose to
require a reboot? Should I script more in the installer to first check if LfW
was installed before? This will take more time.
Thoughts?
Original comment by rpusz...@gmail.com
on 19 Dec 2011 at 2:17
Yes, I think you outlined the right and proper solution - do a flag check in
the installer. Are you using NSIS? If so then I've used
http://nsis.sourceforge.net/Check_for_a_Registry_Key in the past and it worked
quite straight-forward (although I agree about time spend: NSIS scripting is a
freaking nightmare, I've seriously considered coding the installer myself a few
times and to date I'm not certain I've actually saved time using NSIS)
Original comment by janus.ol...@gmail.com
on 19 Dec 2011 at 8:13
I use INNO Setup. I just prefer it, but have used NSIS in the past. It is still
the same kind of issues no matter which installer it is though.
I think I will implement this at some point because I think it is generally a
good idea, but the priority will be low.
Original comment by rpusz...@gmail.com
on 19 Dec 2011 at 10:03
Godamn u ppl, just put another info in the example, "if you launched it from
installation this example will not work because the environment variable wasnt
set", or something like that
Original comment by yksnimus
on 4 Oct 2012 at 4:08
Original issue reported on code.google.com by
nitrod...@gmail.com
on 17 Aug 2010 at 3:26Attachments: