| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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!!!
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This allows me to run a task which generates java source files, prior to having rake-compiler compile them.
|
| |
|
|
|
|
| |
Example usage:
rake compile -- --with-libyaml-dir=C:/devlibs/libyaml
|
| |
|
|
|
|
|
|
|
| |
Rake::GemPackageTask is deprecated and will be removed.
Gem::PackageTask has been present since RubyGems 1.3.2 and should be
used instead.
rake-compiler already depends on rubygems >= 1.3.5 so no damage done here.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
* Pass explicit list of .class files, not wildcard.
* Because jar output directory is same as directory containing .class files, it
appeared that the jar command line tool was trying to recursively jar itself.
* Handle case where $ in .class file names (seen with use of inner classes, etc.)
was being expanded out on *NIX systems.
* Change feature to test for the above.
* Thanks to Luis for helping work through this and ensuring compatibility with
both *NIX and Windows systems.
Signed-off-by: Alex Coles <alex@alexcolesportfolio.com>
|
| |
|
|
|
| |
Reduce to only one the display of warnings about usage
of ExtensionTask or JavaExtensionTask in mixed environments.
|
| |
|
|
|
| |
File.expand_path is not recommended on 1.9, stick to plain require
should work.
|
|
|
JRuby support created by Alex Coles.
Merge done manually to avoid excesive cherry-picking
|
