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
Makefile: restrict macOS LuaJIT flags to v2.0 only #33
base: master
Are you sure you want to change the base?
Conversation
Howdy! Thanks for this! I am in the middle of adding some useful new stuff along with a few changes to put out a big new version in the next few weeks (will likely even call it v3.0), had taken a bit of a break from Nift but am keen to get the project up and running again and make it even better than it already is (have lots of ideas there), so there's a few minor changes coming but big improvements too (including switching to JSON for all config/info/etc files in a project .nsm directory, which will likely become .nift though Nift will upgrade all this for older projects automatically, will also do up a bunch of intro guides and boilerplate repos for how to use various tools/frameworks etc. in a Nift project for those who aren't keen to dive head first into docs). I'll merge this in some time in the next few weeks so that you're listed as a contributor. I am tempted to change it so Nift can optionally be compiled without Lua embedded entirely because it's also possible to embed Python and/or Ruby as well unbundled. It'd be way too big to have either of Python or Ruby bundled and people then require the development version(s) of Python/Ruby installed, plus I'm unsure if you can have different instances of Python/Ruby running concurrently for multi-threaded builds (though can handle the mutex size of things for people there 'under the hood' so to speak so that people aren't stuck restricting all of their builds to a single thread (configurable in each project config file). Consequently I'm still considering offering the options with allowing Python and/or Ruby to be embedded unbundled, ideally I'd love to offer these options through the releases on things like brew, snap, flathub/pak, chocolatey etc. but I'm not sure I can really offer people the options there and it may put too many people off needing the development versions of Python and/or Ruby installed just for the default versions of Nift they can get through package/app managers etc.. But I also think people could find it quite useful being able to use Python and/or Ruby during the build stage of their websites and be able to easily share data between Nift's template language/build process and Python/Ruby.. Curious to know what other people's thoughts are there.. |
Another issue with unbundled, including for example making unbundled the default for Lua(JIT) is I'm not 100% sure on how easily one can compile for release platforms like Brew etc. which would work for any version installed unbundled on a user's machine. I will have to look into that further for both Lua(JIT) and if I do add in ways to compile and/or release Nift with Python and/or Ruby embedded unbundled. |
Removing |
I missed what Michael wrote, I'll look into what both of you have said when
I get a chance..
…On Friday, September 15, 2023, Krovma ***@***.***> wrote:
Removing -pagezero_size and -image_base works for Arm64(M1) with source
built lua 5.4
—
Reply to this email directly, view it on GitHub
<#33 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABTXLM3N252FWYDCAVGIP3X2MZXNANCNFSM6AAAAAAQTWZMKY>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
@n-ham any luck? Thanks! |
I think the
-pagezero_size
and-image_base
were added due to a bug in LuaJIT 2.0 on macOS. This was fixed in LuaJIT 2.1 as seen on an old copy of website (recent copies only recommend LuaJIT 2.1 on macOS) https://web.archive.org/web/20220407012421/http://luajit.org/install.html#embedSince bundled LuaJIT is 2.1, I think the flags only need to be set if system copy is LuaJIT 2.0.
As note, the
-pagezero_size
/image_base
values are incompatible with ARM (M1) and will result in binaries that always segmentation fault.I wasn't sure about
-Qunused-arguments
so just left that. Also, the-image_base
number seems to be missing a zero, but I didn't modify it since I don't know if that was intentional.I created separate
ifeq
rather thanelse ifeq
since other flags should be same, but can change if preferred.