Although gemspec file (e.g., power_assert and rake) often uses
`git ls-files`, as it does not make sense in other than its own
repository, it has been ignored now. Gather all files expanded
from the bundled gem to install, instead.
* Fix incorrect calls to `Gem.ensure_gem_subdirectories`
This method doesn't take keyword args.
* Remove stuff no longer necessary
Now `Gem.ensure_gem_subdirectories` is doing its job, so some stuff is
no longer needed.
* Use the proper method for default gems
* Respect DESTDIR when creating rubygems folder layout
* Use `Gem.default_specifications_dir`
The local `path` variable does not provide any additional value and was
kept around just for clarity for easier review of the `extrac_files`
method move.
Extract bundled gems under ".bundle/gems" and get rid of
duplication which cause constant redefinition warnings at
`test-all` after `extract-gems` and `test-bundler`.
Compilation of extension libraries written in C++ are reportedly
broken due to https://github.com/ruby/ruby/pull/2404
The root cause of this issue was that the definition of ANYARGS
differ between C and C++, and that of C++ is incompatible with the
updated ones.
We are using the incompatibility against itself. In C++ two distinct
function prototypes can be overloaded. We provide the old, ANYARGSed
prototypes in addition to the current granular ones; and let the
older ones warn about types.
These changes break the behavior of default gems. Bug #13428 says
r58345 is reasonable because gemspec file is installed by `to_ruby_for_cache`
method. But I revert `to_ruby_for_cache` in rbinstall.rb at r58403.
There is no reason that we apply r58345 now.
But I'm not sure about gemspec of default gems affects standalone gems.
I'm going to investigate it on rubygems/rubygems.
[Bug #15500][ruby-core:90867]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66867 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* tool/rbinstall.rb (load_gemspec): do not hide syntax errors in
a gemspec file. check if the result instead.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66460 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
in the MJIT-header-specific path, not default path like vc140.pdb.
mjit_worker.c: specify the MJIT-header-specific pdb path.
tool/rbinstall.rb: install MJIT header pdb as well.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65003 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
to prefix. This is a retry of r64947. So this doesn't still make mswin MJIT
on install directory succeed. One more step required.
tool/rbinstall.rb: This change is needed to install headers correctly since
the extensions are .obj and .pch, not .h
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65000 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
`make install` has loaded forwardable.rb twice, from
forwardable.gemspec and prime.gemspec.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64882 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
[ruby-core:88699][Bug #15035]
This patch was provided by MSP-Greg.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64585 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
This allows user to specify any name in `--with-so-name` that might
cause a name clash with LIBRUBY_ALIASES on the platform.
Without this, for example, configuring with `--with-soname=ruby
--enable-shared` on macOS would end up running `ln -sf libruby.dylib
libruby.dylib` only to fail with the following error in installation:
```
make[2]: stat: libruby.dylib: Too many levels of symbolic links
```
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63544 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* tool/rbinstall.rb ($script_installer.stub): read stub file on
demand. as `$cmdtype` is set to "exe" in parse_args, it is not
set yet when `$script_installer` is defined.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63268 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Nobuyoshi Nakada
Jeremy Evans
David Rodríguez
Vít Ondruch
Hiroshi SHIBATA
卜部昌平
Yusuke Endoh
hsbt
nobu
usa
k0kubun
knu