-
Notifications
You must be signed in to change notification settings - Fork 814
Compile mruby compiler as mrbgem. #2760
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
Conversation
This pull-request does too many things at once. Please separate issues. |
I think extract to gem can be one patch, and the other fixes can be separate tickets. |
By the way, why do you want to separate mrbc as a gem, where even the simplest test requires it? |
/* evaluate the test */ | ||
mrb_load_string(mrb, prog); | ||
mrb_funcall(mrb, mrb_top_self(mrb), "report", 0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this even related to mrbc gem?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
MRuby compiler codes(codegen.c and parse.y) is moved to mruby-bin-mrbc so mrb_load_string
won't be defined by default.
@matz Though this PR is mostly from interest so if you think this isn't required I'll close this. |
I think it's essential for embedded environments that you can compile mruby without the parser in the run time. On such small platforms precompiled byte code should be used to reduce the space needed to run an mruby program. So something like this pull request is a good idea. |
@matz is there any chance that a pull-request like this (removing the parser from the core) might be accepted if it is separated? |
@bovi Yes, but separating it might be harder than it seems. Not only tests, even building full libmruby.a requires mrbc to compile .rb files. |
@take-cheeze will you try to separate the code? otherwise I would like to give it a try maybe over the weekend. |
CC @matz, @take-cheeze Just to throw around a thought to split this change into small little pieces.. What about we take all *.rb files from the core and put them into a GEM? Then we would have a pure C core and everything what is Ruby related would be added via GEMs. In this way we could split this change into smaller steps:
In this way we would not only shrink the core (for several projects I actually deleted the *.rb files in the core to port mruby to MCUs), but we would also gain flexibility in what kind of functions the mruby-core really has. I'm not going so far to propose here a separation of the mruby-core-lib into GEMs like "mruby-array-core", "mruby-numeric-core", etc. but it would be an option for the future and I personally would like to see it, specially due to the reason that we have now a robust enough dependency system in mrbgeqms to describe the relations between all GEMs. |
@bovi the process looks reasonable. |
@bovi Separating this PR isn't much hard.
Though the rest would be a big change anyway. |
@take-cheeze yes I know about the libmruby_core and libmruby difference. I just called the proposed GEM "core" to differentiate it from the "-ext" GEMs. I think it is quite hard to find a proper name for the individual libraries. "core" is as you say not correct as "core" actually only contains C based implementation code. But "stdlib" for example would also not be correct as there is more to the stdlib of Ruby then the Ruby files under mrblib. Maybe another suggestion is to just merge the mrblib code with the -ext GEMs? My biggest problem with only moving mrbc to a GEM is, that after such a change we would have a GEM dependency to every built of mruby. As long as we can't deactivate the usage of the code under mrblib, the built system will always require to built the mrbc GEM. That pushes the GEM system to not being an extension system anymore but a hard dependency to the mruby core. Nevertheless the proposed steps were only a suggestion, it is of course also possible to use the existing pull request for now. Having mrbc as a GEM is in either way a good step forward and if you plan to do the change I'm looking forward. PS: Concerning the Ruby API dependencies of the tests I don't see a big issue, as we can move the test code for the Ruby based libraries into the GEM too. Or did I misunderstand your point? |
@bovi Non-"host" build target uses "host" build target There's not much clear definition for what should be mrbgem. My concern is that splitting API makes dependencies complex. |
03112b6
to
2d9c84a
Compare
@matz Recommitted files with few improvements.
Though it seems like there's few fixes to compiler code from @cremno so I'll rebase it if needed. |
Compiler codes is moved to "mruby-compiler". Executable `mrbc` is moved to "mruby-bin-mrbc".
2d9c84a
to
971908b
Compare
@matz Rebased for recent changes. Ready to merge now. |
Merged. Somehow github didn't noticed the merge. closed. |
This is great news. Thanks @take-cheeze for the work!
|
This pull request separates mruby compiler
mrbc
to mrbgem "mruby-bin-mrbc".Remarkable changes:
mrbc
is only built in"host"
build target by default.MRuby::Build#build_mrbc_exec
to buildmrbc
for build target and use it in buildsince
mrbc
won't be built by "mruby-bin-mrbc" by default.(
MRuby::Build#mrbcfile
would be the build target'smrbc
ifMRuby::Build#bins
contains'mrbc'
)report
method is called withmrb_funcall
instead ofmrb_load_string
.mrb_codedump_all
and related functions are moved to "src/codedump.c" since it's used inmrb_load_irep_file_cxt
.