Skip to content
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.

Sign up for GitHub

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

Jump to bottom

deprecate ReleaseRuntime flag, use 'runtime "Release"' instead.: #10

Merged
merged 1 commit into from
Apr 4, 2015
Merged

deprecate ReleaseRuntime flag, use 'runtime "Release"' instead.: #10

merged 1 commit into from
Apr 4, 2015

Conversation

tvandijck
Copy link
Contributor

No description provided.

@TurkeyMan
Copy link
Contributor

I want this fix. It's actually plaguing me right now... but I'm not sure if this is quite the right approach.
Trouble is, that config.isDebugBuild() business has always irk-ed me. It's making a lot of assumptions, and in my experience, they're not reliable.
I tend to think config.isDebugBuild() should be removed, runtime should be used exclusively, and sensible defaults (that match isDebugBuild?) should be applied...?

@tvandijck
Copy link
Contributor Author

Yeah, we went for most backward compatibility... so when runtime is set, it'll be used, if not then it uses the 'old' system... I'm all with you though, but it would require that we set runtime to some sort of default.

@TurkeyMan
Copy link
Contributor

Well, it's true that the default needs to be semi-intelligent... but I don't think the current logic is quite correct. I've fallen for edge cases on numerous occasions.

@starkos
Copy link
Member

starkos commented Apr 4, 2015

I'm going to merge this one as I think it is a good starting point. I'm happy to continuing iterating on it before the full release though.

@starkos starkos merged commit 3eb49ba into premake:master Apr 4, 2015
@tvandijck tvandijck deleted the pr4 branch April 6, 2015 23:41
tvandijck pushed a commit to Blizzard/premake-core that referenced this pull request Jul 31, 2015
Merge pull request premake#10 from jtouton/xcode
6e4183f
martin-traverse pushed a commit to martin-traverse/premake-core that referenced this pull request Apr 19, 2016
@starkos
Merge pull request premake#10 from starkos/load-test-func
1f2b999 
Switch to new test function approach for dynamic loading
tvandijck pushed a commit to tvandijck/premake-core that referenced this pull request May 11, 2016
@starkos
Merge pull request premake#10 from starkos/load-test-func
b6888b5 
Switch to new test function approach for dynamic loading
tvandijck pushed a commit to tvandijck/premake-core that referenced this pull request May 11, 2016
@TurkeyMan
Merge pull request premake#10 from LORgames/ssurtees/translateFix
8e651a1 
Updated tests to reflect path.translate changes in core.
tvandijck pushed a commit to tvandijck/premake-core that referenced this pull request May 11, 2016
@TurkeyMan
Merge pull request premake#10 from starkos/fix-workingdir-test
71c4852 
Fix unit test to match current behavior
samsinsane pushed a commit to LORgames/premake-core that referenced this pull request Apr 5, 2018
Merge pull request premake#10 from premake/cppdialect
71c64b2 
Add cppdialect support
starkos added a commit to starkos/premake-core that referenced this pull request Nov 19, 2021
@starkos
Add Community Update premake#10
4d8560f
starkos added a commit that referenced this pull request Nov 19, 2021
@starkos
Merge pull request #1760 from starkos/website/update-10
ea8a29a 
Add Community Update #10
noresources pushed a commit to depinxi/premake-core that referenced this pull request Mar 23, 2022
@starkos
Add Community Update premake#10
5a086e3
vadz added a commit to vadz/premake-core that referenced this pull request Aug 27, 2023
@vadz
Fix crash when enabling debugger under Linux
e739d88 
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@tvandijck @TurkeyMan @starkos