| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
Many C extensions depend on pkgconfig during their configure phase and
this is easy to miss in the ebuild. Handle this in the eclass instead
even though the dependency will not be needed for all extensions.
Closes: https://bugs.gentoo.org/845393
Signed-off-by: Hans de Graaff <graaff@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
|
|
|
|
|
|
|
| |
The phases in ruby-ng.eclass already use ebegin/eend to wrap each phase,
so use einfo here to avoid nested calls.
Signed-off-by: Hans de Graaff <graaff@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If two ruby targets are specified, the scripts get `/usr/bin/env ruby`
shebangs. "env ruby" is then replaced in the ebuilds to be
"ruby${ver}" (ruby27 or ruby30). They needs to be prefixified.
Contrastingly, when there is one ruby target, the shebang is the
correct EPREFIX/usr/bin/ruby${ver}. No prefixify should be applied.
To unify the two cases, the shebangs for the two-ruby-target case are
changed to be `EPREFIX/usr/bin/env ruby`.
Reference: https://github.com/gentoo/gentoo/pull/21046
Package-Manager: Portage-3.0.28, Repoman-3.0.3
Signed-off-by: Benda Xu <heroxbd@gentoo.org>
Signed-off-by: Hans de Graaff <graaff@gentoo.org>
|
|
|
|
|
| |
Bug: https://bugs.gentoo.org/835396
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
|
|
|
|
|
| |
Signed-off-by: Anna Vyalkova <cyber+gentoo@sysrq.in>
Signed-off-by: Joonas Niilola <juippis@gentoo.org>
|
|
|
|
|
|
|
| |
This old version of dev-ruby/psych should be long gone now, and
dev-ruby/psych needs to be added again to support ruby 3.1.
Signed-off-by: Hans de Graaff <graaff@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
|
|
|
|
|
|
|
|
|
|
| |
rubygems
Closes: https://bugs.gentoo.org/423589
Closes: https://bugs.gentoo.org/832268
Signed-off-by: Andrew Aladjev <aladjev.andrew@gmail.com>
Signed-off-by: Hans de Graaff <graaff@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
| |
Add a public method ruby_fakegem_extensions_installed to add the
marker that rubygems uses to determine if extensions have been
installed. We were already adding this as part of the extensions code,
but rubygems also expects this to be present for extensions that we
either ignore or handle differently. Without this marker rubygems
3.2.22 and newer will ignore this gem.
Signed-off-by: Hans de Graaff <graaff@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Set the CFLAGS and LDFLAGS for extensions using the mkmf options
during configuration. This ensures that the flags are correctly set in
the Makefile and we don't need to second-guess any further actions of
extensions themselves, leading to breakage that is hard to work
around.
Closes: https://bugs.gentoo.org/823730
Signed-off-by: Hans de Graaff <graaff@gentoo.org>
|
|
|
|
|
|
|
| |
Introduce RUBY_FAKEGEM_EXTENSION_OPTIONS to allow setting options for
extensions.
Signed-off-by: Hans de Graaff <graaff@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Explicitly pass CC, CFLAGS and LDFLAGS when compiling ruby
extensions. By default ruby re-uses the stored flags used when
compiling ruby itself. This is intended to create a better chance of
compatibility between extensions and ruby itself, and extensions do
not need to bother with this themselves, but it does not match the
expectations of a Gentoo system where each compile action should use
the currently defined flags.
We also cannot guarantee this compatibility in any case since
toolchain packages may have been updated in the meantime.
This change uses the current CC, CFLAGS and LDFLAGS, and adds -fPIC
which ruby extensions need and which would otherwise be added by
ruby. This combination is already used in some ebuilds without any
reported issues.
Signed-off-by: Hans de Graaff <graaff@gentoo.org>
|
|
|
|
|
|
|
|
|
| |
Normally extensions don't install in sitelibdir since they only deal
with compiled code, but there are edge cases. Set sitelibdir correctly
to the install destination so that we can keep using the "install"
target in the Makefile.
Signed-off-by: Hans de Graaff <graaff@gentoo.org>
|
|
|
|
|
|
| |
Some extensions, e.g. dev-ruby/hiredis, require this to be present.
Signed-off-by: Hans de Graaff <graaff@gentoo.org>
|
|
|
|
| |
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
|
|
|
| |
Signed-off-by: Hans de Graaff <graaff@gentoo.org>
|
|
|
|
| |
Signed-off-by: Hans de Graaff <graaff@gentoo.org>
|
|
|
|
| |
Signed-off-by: Hans de Graaff <graaff@gentoo.org>
|
|
|
|
|
|
| |
Closes: https://bugs.gentoo.org/788124
Signed-off-by: Hans de Graaff <graaff@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The default gem did_you_mean was unbundled in
2e225cca1aa95b8a5e54cbd855f17dbaf88940d9 to fix bug
758464. Unfortunately ruby 2.7 fails when did_you_mean is not present
at all, making it impossible to install this ruby version. 2.6 and 3.0
are not affected by this.
With this change we explicitly disable the did_you_mean gem when
invoking ruby in the eclasses.
Thanks to naota for diagnosing the issue and coming up with a
solution.
Closes: https://bugs.gentoo.org/705346
Signed-off-by: Hans de Graaff <graaff@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
|
|
|
| |
_extensionsdir is based on ruby_fakegem_gemsdir, which strips $EPREFIX
for use with helpers
Signed-off-by: Fabian Groffen <grobian@gentoo.org>
|
|
|
|
| |
Signed-off-by: Hans de Graaff <graaff@gentoo.org>
|
|
|
|
|
|
|
| |
Create the directory if needed and take into account that
RUBY_FAKEGEM_EXTENSION_LIBDIR may or may not have an ending /.
Signed-off-by: Hans de Graaff <graaff@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Up to now handling of extensions was done in each ebuild that
contained them. This means that handling is often
inconsistent (e.g. not taking multilib's get_modname into account) and
there is a lot of duplicated code in ebuilds.
Furthermore, this also does not install extensions into the special
extensions directory. rubygems itself has been doing this for some
time, and now bundler 2.2.x has started to explicitly check for the
extensions in this directory, making it incompatibly with our previous
way of installing gems.
The new RUBY_FAKEGEM_EXTENSIONS array and
RUBY_FAKEGEM_EXTENSION_LIBDIR options provide support for installing
extensions automatically based on these settings, taking into account
that the extensions also must be part of testing and that it must be
installed properly.
Signed-off-by: Hans de Graaff <graaff@gentoo.org>
|
|
|
|
|
|
|
|
|
|
| |
dev-ruby/psych has been removed from the tree for some time but may
still be installed, in which case it will cause errors when trying to
read gemspec YAML metadata because it is no longer compatible with
modern ruby versions. Block on it to ensure that dev-ruby/psych is
actually uninstalled.
Signed-off-by: Hans de Graaff <graaff@gentoo.org>
|
|
|
|
| |
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
|
|
|
| |
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ben Kohler <bkohler@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
The fallback gemspec does not contain dependencies so it will only
work for packages without any runtime gem dependencies. It is easy to
use it by mistake when switching from a gem to a source-based archive,
because the source-based archive does not contain the generated
metadata, but RUBY_FAKEGEM_GEMSPEC has not been set yet. This warning
alerts developers to this situation and encourages them to set
RUBY_FAKEGEM_GEMSPEC instead.
Signed-off-by: Hans de Graaff <graaff@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
| |
The previous default was "rake" but this turned out to be a poor
choice because many packages do not implement "rake doc" and even if
they do there are usually many local development environment
assumption attached to that task. Using a consistent "rdoc" call that
is handled by the eclass gets more consistent results at the code of
missing out on specific rdoc options set by packages.
Signed-off-by: Hans de Graaff <graaff@gentoo.org>
|
|
|
|
| |
Signed-off-by: Hans de Graaff <graaff@gentoo.org>
|
|
|
|
|
|
| |
Drop support for EAPI 0, 1, 2, 3.
Signed-off-by: Hans de Graaff <graaff@gentoo.org>
|
|
|
|
| |
Signed-off-by: Hans de Graaff <graaff@gentoo.org>
|
|
|
|
| |
Signed-off-by: Hans de Graaff <graaff@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
| |
Remove automatically generated compressed versions of the javascript
code to avoid warnings about colliding files by ecompress.
We can only do this for the "rdoc" recipe because that is the only
predictable generation method. The other recipes will need to handle
this in the ebuilds.
Signed-off-by: Hans de Graaff <graaff@gentoo.org>
|
| |
|
|
|
|
|
| |
This will allow us to introduce new defaults for some of the
ruby-fakegem settings when switching to EAPI=7.
|
|
|
|
| |
Remove wrong default value and fix documentation accordingly.
|
|
|
|
|
|
|
| |
Move eclass variable definitions to the right place just behind their
documentation or declare them as default unset.
Closes: https://bugs.gentoo.org/637866
|
|
|
|
|
|
|
| |
dohtml is deprecated in EAPI 6, but more importantly it does not
actually do what we want, which is to install all the documentation
files, including fonts, javascript, and css to make the documentation
pages look as intended.
|
| |
|
|
|
|
| |
Signed-off-by: Justin Lecher <jlec@gentoo.org>
|
|
|
|
|
|
| |
Filename expansion is performed when the variable is referenced unquoted
already. There is really no need to call 'ls' on top of that, and even
less reason to wrap it all in 'eval'.
|
|
|
|
| |
Acked by graaff.
|
|
|
|
| |
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
By default gems can provide binaries to be bin-wrapped in /usr/bin in a
directory called "bin" in the gem. This is only a default, and it is
possible for the gem to indicate that another directory contains the
binaries to be bin-wrapped using the gemspec bindir option.
dev-ruby/rspec-core and dev-ruby/bundler are gems where the
binaries are placed in an "exe" directory.
This change introduces RUBY_FAKEGEM_BINDIR, defaulting to "bin" for
backward compatibility, allowing this directory to be specified.
|
|
|
|
| |
Reviewed-By: Hans de Graaff <graaff@gentoo.org>
|