extconf.rb: Send RbConfig preferences to #make via env vars
#2705
Conversation
| # Runs `make` in the root directory of the project. Note that this is the | ||
| # `Makefile` for the overall project, not the `Makefile` that is being generated | ||
| # by this script.` | ||
| def make(target) | ||
| Dir.chdir(File.expand_path("../..", __dir__)) do | ||
| system(RUBY_PLATFORM.include?("openbsd") ? "gmake" : "make", target, exception: true) | ||
| system( | ||
| RbConfig::CONFIG.slice(*%w[SOEXT CPPFLAGS CFLAGS CC AR ARFLAGS MAKEDIRS RMALL]), # env |
There was a problem hiding this comment.
Should we extract this operation out so it’s not re-#sliced on every call?
There was a problem hiding this comment.
That's okay, it's not a big deal
There was a problem hiding this comment.
Actually, on hindsight, should we send RbConfig::MAKEFILE_CONFIG (unexpanded Makefile includes) over rather than RbConfig::CONFIG (expanded Makefile values)?
There was a problem hiding this comment.
I assume it wouldn't make a difference right?
There was a problem hiding this comment.
The difference would be if the RbConfig::MAKEFILE_CONFIG values were expanded from variables that
- our hand-written
Makefiledoes not cover / cover differently, or - interpret users’ env vars on a finer level
|
{
"LIBEXT"=>"a",
"LDSHARED"=>"gcc -shared",
"DLDSHARED"=>"gcc -shared",
"OUTFLAG"=>"-o ",
"COUTFLAG"=>"-o "
}but I’m uncertain how to integrate them. |
I suppose they arose because the Ruby |
| # Runs `make` in the root directory of the project. Note that this is the | ||
| # `Makefile` for the overall project, not the `Makefile` that is being generated | ||
| # by this script.` | ||
| def make(target) | ||
| Dir.chdir(File.expand_path("../..", __dir__)) do | ||
| system(RUBY_PLATFORM.include?("openbsd") ? "gmake" : "make", target, exception: true) | ||
| system( | ||
| RbConfig::CONFIG.slice(*%w[SOEXT CPPFLAGS CFLAGS CC AR ARFLAGS MAKEDIRS RMALL]), # env |
There was a problem hiding this comment.
That's okay, it's not a big deal
ParadoxV5
force-pushed
the
rbconfig-make
branch
from
df5a134
to
b954145
Compare
|
Sorry, if you don't mind rebasing one more time, looks like I had a different version of clang analyzer running locally. |
These record the preferences Ruby was built with. As a library that aims to be canonical, Prism should therefore match those, especially as a part of a C extension gem.
ParadoxV5
force-pushed
the
rbconfig-make
branch
from
b954145
to
f3702a3
Compare
These record the preferences Ruby was built with.
As a library that aims to be canonical, Prism should therefore match those, especially as a part of a C extension gem.
Using
RbConfigalso enables cross-compiling using https://bugs.ruby-lang.org/issues/20345 or the mentionedrake-compiler.[P.S.] Do we need tests for these, and if yes, how?