-
-
Notifications
You must be signed in to change notification settings - Fork 617
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
These are ALL our changes to premake-core to get our build up and running. #6
Conversation
15667d5
to
6b68bc9
Compare
This one can be closed? |
I just kept it around as kind of a lookup for what other changes we still have... some of those are not merged into master at all, since I didn't make pull request for them... but I would still like to receive some sort of review on these changes so that we may be able to submit them as individual pull requests in the future. |
Most notable are:
|
…c solution configurations.
Fine with these except for the Lua upgrade, which I know will break some clients that are integrating with other Lua 5.1 systems (debuggers, etc.). What's the reason for the upgrade? If we are going to switch, would it make more sense to go to 5.3 instead of breaking it again in the future? Not entirely opposed to the upgrade, just want to make sure we're doing it for a reason other than "because it's there". |
Yeah, mostly because it's there, but I also wanted to try out LuaJit to see what the performance benefits would be. For us with the big projects we have, premake takes up to 20 seconds to generate everything, so anything to speed up the process would help. So I did the upgrade to 5.2.3 to assure compatibility with LuaJit... then tried LuaJit... and well, we kinda just stuck with it. As for 5.3, I tried it recently... doesn't work... so we stuck with 5.2.3.. The other commits, I'll try to make pull requests for them, after that I'm sure we can close this one. |
fixed debugdir not being used.
Clang 3.6 is not installed as part of VS2015 but might have been from an older VS2013 install.
Rename buffer_init() to avoid clashing with a function with the same name in luasocket code: under Linux, due to the of "flat" ELF namespaces, when luasocket shared library is loaded into premake process the existing premake function is used instead of the function defined in luasocket code, resulting in luasocket buffer not being properly initialized which, in turn, leads to mysterious crashes as soon as it's used, e.g. dereferencing null timeout field: (gdb) bt #0 0x00007ffff7cce642 in timeout_markstart (tm=0x0) at ../../binmodules/luasocket/src/timeout.c:116 premake#1 0x00007ffff7cc7618 in buffer_meth_receive (L=0x5555557882a8, buf=0x5555559044a0) at ../../binmodules/luasocket/src/buffer.c:113 premake#2 0x00007ffff7ccd545 in meth_receive (L=0x5555557882a8) at ../../binmodules/luasocket/src/tcp.c:135 premake#3 0x000055555558c1cc in luaD_precall (L=0x5555557882a8, func=0x5555558e36b0, nresults=1) at ../../contrib/lua/src/ldo.c:434 premake#4 0x00005555555a971f in luaV_execute (L=0x5555557882a8) at ../../contrib/lua/src/lvm.c:1134 premake#5 0x000055555558c555 in luaD_call (L=0x5555557882a8, func=0x5555558e3640, nResults=0) at ../../contrib/lua/src/ldo.c:499 premake#6 0x000055555558c5b3 in luaD_callnoyield (L=0x5555557882a8, func=0x5555558e3640, nResults=0) at ../../contrib/lua/src/ldo.c:509 premake#7 0x0000555555588af5 in lua_callk (L=0x5555557882a8, nargs=2, nresults=0, ctx=0, k=0x0) at ../../contrib/lua/src/lapi.c:925 premake#8 0x00005555555af4f2 in hookf (L=0x5555557882a8, ar=0x7fffffffd270) at ../../contrib/lua/src/ldblib.c:316 premake#9 0x000055555558bafb in luaD_hook (L=0x5555557882a8, event=2, line=273) at ../../contrib/lua/src/ldo.c:269 premake#10 0x000055555558b284 in luaG_traceexec (L=0x5555557882a8) at ../../contrib/lua/src/ldebug.c:687 premake#11 0x00005555555a6b71 in luaV_execute (L=0x5555557882a8) at ../../contrib/lua/src/lvm.c:801 premake#12 0x000055555558c555 in luaD_call (L=0x5555557882a8, func=0x555555889360, nResults=1) at ../../contrib/lua/src/ldo.c:499 premake#13 0x000055555558c5b3 in luaD_callnoyield (L=0x5555557882a8, func=0x555555889360, nResults=1) at ../../contrib/lua/src/ldo.c:509 premake#14 0x0000555555588b60 in f_call (L=0x5555557882a8, ud=0x7fffffffdbb0) at ../../contrib/lua/src/lapi.c:943 premake#15 0x000055555558b5a5 in luaD_rawrunprotected (L=0x5555557882a8, f=0x555555588b2b <f_call>, ud=0x7fffffffdbb0) at ../../contrib/lua/src/ldo.c:142 premake#16 0x000055555558cd85 in luaD_pcall (L=0x5555557882a8, func=0x555555588b2b <f_call>, u=0x7fffffffdbb0, old_top=64, ef=48) at ../../contrib/lua/src/ldo.c:729 premake#17 0x0000555555588c28 in lua_pcallk (L=0x5555557882a8, nargs=0, nresults=1, errfunc=3, ctx=0, k=0x0) at ../../contrib/lua/src/lapi.c:969 premake#18 0x0000555555584734 in premake_pcall (L=0x5555557882a8, nargs=0, nresults=1) at ../../src/host/premake.c:287 premake#19 0x0000555555584867 in premake_execute (L=0x5555557882a8, argc=5, argv=0x7fffffffdd98, script=0x555555685052 "src/_premake_main.lua") at ../../src/host/premake.c:316 premake#20 0x000055555558535e in main (argc=5, argv=0x7fffffffdd98) at ../../src/host/premake_main.c:19 For consistency, rename all the other buffer_xxx functions too, even though they don't conflict with anything right now.
This Pull request is not intended to be merged, it's just here to create visibility into the changes and fixes we made. I can pull out changes and make individual pull requests for those where needed.
At this time however some of the changes depend on earlier changes, so it be nice if we could at least work somewhat in order...