Add an (optional) GNU configure option to demand libyaml before continuing, when compiling ruby from source
Hi. When I compile ruby 1.9.3 I get this sometimes:
It seems your ruby installation is missing psych (for YAML output).
To eliminate this warning, please install libyaml and reinstall your ruby.
This is a bit annoying because I need yaml support, so I have to
recompile anyway. So I first compile libyaml, then I recompile ruby.
I had a look at ./configure --help but there was no option provided
to require libyaml before continuing.
My suggestion is to add this to the configure script, so that users
like me can know that the ruby that was compiled 100% has libyaml
support or 100% does not have libyaml support.
Option for configure:
--with-libyaml Require a working libyaml installation before continuing.
If libyaml is not installed at configure-time, the configure script
stops with this message (suggestion):
"We were unable to find a working libyaml installation. As --with-libyaml
was passed, we can not continue before you have installed libyaml. Please
install libyaml, either from source such as from http://pyyaml.org/download/libyaml/
or from your distribution's package manager."
Thanks for reading and considering! I like ruby but the change to
yaml is a bit annoying when compiling ruby, for me it is much easier
if the configure script does not continue, if it has such an option.
#1 [ruby-core:45294] Updated by shyouhei (Shyouhei Urabe) almost 6 years ago
#2 [ruby-core:45339] Updated by mame (Yusuke Endoh) almost 6 years ago
- Status changed from Open to Feedback
I completely agree that the behavior you are proposing is best.
But it would be hard to implement exactly because the library (libyaml) is searched by extconf.rb, which requires ruby executable (miniruby).
So, it is impossible to make configure fail when there is no libyaml.
To be exact, it is possible if not only extconf.rb but also configure checks libyaml.
But it would be also hard to accept this method, in terms of maintenance.
Please let us know if you have any alternative implementation approach.
If there is no proposal, I'm sorry but I'll reject this ticket.
Yusuke Endoh firstname.lastname@example.org