| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
this allows using
```
Rake::JavaExtensionTask.new("name", gemspec) do |ext|
ext.release = '8'
end
```
on Java 8 (for building the gem), because the flag is available since
Java 9, see
https://maven.apache.org/plugins/maven-compiler-plugin/examples/set-compiler-source-and-target.html
this flag is for backward compatibility, so it's safe to just skip it if
we can't use it.
relates to https://github.com/puma/puma/pull/3109
https://github.com/socketry/nio4r/pull/292
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a build wishes to generate some of the extension source files then
the pattern input is insufficient. Provide a place to stash an
additional FileList that will then become a dependency of the compile
tasks.
Example:
```ruby
file 'ext/libfoo/generated.c' do |t|
open(t.name, 'w+) { |f| f << '#include <foo.h>' }
end
Rake::ExtensionTask.new('foo') do |ext|
ext.extra_sources << 'generated.c'
end
```
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since Rubygems 3.3.21, the Gem::Platform name always contains the
library version for gnu platforms. So where the rake-compiler config
entries previously were:
```yaml
---
rbconfig-x86_64-linux-gnu-2.7.0: "/usr/local/rake-compiler/ruby/x86_64-redhat-linux/ruby-2.7.0/lib/ruby/2.7.0/x86_64-linux-gnu/rbconfig.rb"
rbconfig-x86_64-linux-2.7.0: "/usr/local/rake-compiler/ruby/x86_64-redhat-linux/ruby-2.7.0/lib/ruby/2.7.0/x86_64-linux-gnu/rbconfig.rb"
```
with later versions of rubygems, it is only
```yaml
---
rbconfig-x86_64-linux-gnu-2.7.0: "/usr/local/rake-compiler/ruby/x86_64-redhat-linux/ruby-2.7.0/lib/ruby/2.7.0/x86_64-linux-gnu/rbconfig.rb"
```
This means that the current way of finding a matching runtime, by doing
a string comparison on the config keys, is no longer appropriate. This
is causing failing builds downstream in `rake-compiler-dock`.
This PR:
- extracts a new CompilerConfig class to encapsulate the logic
- uses `Gem::Platform#=~` to tell if the gem platform matches the
runtime platform
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Because yaml requires stringio implicitly. If stringio is required, we
can't use rake-compiler for stringio.
See also: https://github.com/ruby/stringio/pull/21#issuecomment-1082632676
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
(#199)
The required_ruby_version was set twice, although one in define_native_tasks is enough.
Fixes #198
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
GitHub: fix GH-196
It's caused when name that includes "/" is specified to
Rake::ExtensionTask.new and the default lib_dir is used such as
https://github.com/konsolebox/digest-xxhash-ruby . In the case, built
binaries are copied to lib/ not lib/XXX/.
Reported by konsolebox. Thanks!!!
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
GitHub: fix GH-195
It's caused when base Ruby and cross Ruby use different
RbConfig::CONFIG["ENABLE_SHARED"]. Gem's extension directory is depend
on it. So we should use the same RbConfig::CONFIG["ENABLE_SHARED"] for
both base Ruby and cross Ruby.
Reported by Mike Dalessio. Thanks!!!
|
| | |
|
| | |
|
| |
|
|
|
|
| |
GitHub: fix GH-194
Reported by Andrew Kane. Thanks!!!
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"rake native gem" without "cross" didn't set the ruby version constraint.
Instead it failed with NoMethodError like so:
/ffi $ rake native gem
no configuration section for specified version of Ruby (rbconfig-i386-mingw32-2.6.3)
no configuration section for specified version of Ruby (rbconfig-x64-mingw32-2.6.3)
install -c build/x86_64-linux/ffi_c/2.6.3/ffi_c.so lib/ffi_c.so
cp build/x86_64-linux/ffi_c/2.6.3/ffi_c.so build/x86_64-linux/stage/lib/ffi_c.so
rake aborted!
NoMethodError: undefined method `split' for nil:NilClass
/home/lars/.rvm/gems/ruby-2.6.3/gems/rake-compiler-1.0.9/lib/rake/extensiontask.rb:515:in `ruby_api_version'
/home/lars/.rvm/gems/ruby-2.6.3/gems/rake-compiler-1.0.9/lib/rake/extensiontask.rb:262:in `block in define_native_tasks'
/home/lars/.rvm/gems/ruby-2.6.3/gems/rake-12.3.3/exe/rake:27:in `<top (required)>'
/home/lars/.rvm/gems/ruby-2.6.3/bin/ruby_executable_hooks:24:in `eval'
/home/lars/.rvm/gems/ruby-2.6.3/bin/ruby_executable_hooks:24:in `<main>'
Tasks: TOP => native => native:x86_64-linux => native:ffi:x86_64-linux
(See full trace by running task with --trace)
|
| |
|
|
|
|
| |
Until now rake-compiler uses "make" to build the extension binary, but doesn't use "make install" to copy it into the lib directory.
This has the downside, that only the extension binary is copied, but no additional files.
In particular files registered per mkmf's $INSTALLFILES mechanism are not respected.
Using "make install" fixes this.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This was introduced in commit a7c113e580c1565000166f9967da82ff2ecdaeaa to avoid interference with host build.
However it prohibits setting important flags for cross-build.
Also don't force 'LDFLAGS=-pipe -s' in configure, which doesn't work with clang targeting MacOS.
It can now be set externally.
|
