Dne 11. 11. 20 v 3:19 Pavel Valena napsal(a):
----- Original Message -----
> From: "Vít Ondruch" <vondruch(a)redhat.com>
> To: ruby-sig(a)lists.fedoraproject.org
> Sent: Tuesday, November 10, 2020 7:19:38 PM
> Subject: Re: Two stage Ruby compilation / Bootstrapping
>
> Wow, it has been year since I started this thread. Time flies.
>
> But since I was fighting again with one revert, which was not possible
> to do without boostrapping, I went ahead and now I have this PR:
>
>
https://src.fedoraproject.org/rpms/ruby/pull-request/72
Looks Great!
Although I don't see any comment on
0001-Revert-Add-GC.auto_compact-true-false-and-GC.auto_co.patch
- The patch doesn't seem maintainable. (Am I wrong?)
- What it's exactly needed for? (Trim miniruby dependencies?)
This is just "random" patch which can't be applied without having some
Ruby in place. If you apply it, the build immediately fails:
~~~
+ /usr/bin/make -O -j8 V=1 VERBOSE=1 'COPY=cp -p' Q=
BASERUBY = echo executable host ruby is required. use
--with-baseruby option.; false
CC = gcc
LD = ld
LDSHARED = gcc -shared
CFLAGS = -O2 -fexceptions -g -grecord-gcc-switches -pipe -Wall
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
-mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
-fcf-protection -fPIC -m64
XCFLAGS = -D_FORTIFY_SOURCE=2 -fstack-protector-strong
-fno-strict-overflow -DRUBY_DEVEL=1 -fvisibility=hidden
-fexcess-precision=standard -DRUBY_EXPORT -DCANONICALIZATION_FOR_MATHN
-I. -I.ext/include/x86_64-linux -I./include -I. -I./enc/unicode/12.1.0
CPPFLAGS =
DLDFLAGS = -Wl,-z,relro -Wl,--as-needed -Wl,-z,now
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld -Wl,-soname,libruby.so.3.0
-fstack-protector-strong -m64
SOLIBS = -lpthread -lrt -lrt -lgmp -ldl -lcrypt -lm
LANG = C
LC_ALL =
LC_CTYPE =
MFLAGS = -j8 -Otarget --jobserver-auth=4,5
gcc (GCC) 10.2.1 20201016 (Red Hat 10.2.1-6)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
echo executable host ruby is required. use --with-baseruby option.;
false ./tool/generic_erb.rb -I. -o miniprelude.c \
./template/prelude.c.tmpl ./ast.rb ./dir.rb ./gc.rb ./integer.rb
./io.rb ./pack.rb ./trace_point.rb ./warning.rb ./array.rb ./kernel.rb
./ractor.rb ./prelude.rb ./gem_prelude.rb
executable host ruby is required. use --with-baseruby option.
make: *** [uncommon.mk:1113: miniprelude.c] Error 1
make: *** Waiting for unfinished jobs....
~~~
But if you really want to know what is the patch about, the please look
here:
https://bugs.ruby-lang.org/issues/17306
> This is the case (1) I have mentioned bellow. As you can see from the
> patch, it turns out it is not that easy as I was expecting.
>
> * Building `miniruby` target is not enough.
>
> * Loading of dynamic libraries is not enabled by default in miniruby.
>
> * There are required several extensions (ripper and stringio atm).
>
> * There is required some script which acts as "ruby" to glue all this
> together.
>
>
> So based on the experience, I have several discussion topics:
>
> * Is it worth of building miniruby with all this hassle? It could be
> better to build "bootstrap-ruby" instead, which could be possible better
> interchangeable with system ruby. IOW that would bring this closer to
> the variant (2).
`ruby` project does not use any bootstrap, right? What specifically do you mean by
bootstrap-ruby? Is it RPM ~bootstrap?
Incidentally, ruby has `bootstraptest` folder with tests... I don't think it's
used for any regular build, but maybe we could use it for such bootstrapping?
If you checkout Ruby repository, you won't be able to build it without
Ruby available. You should understand that the tarball we are using to
build Ruby is already processed, therefore it does not need Ruby, but
that could be perceived to be against guidelines to "build everything
from source".
But my question was if building just miniruby for boostrap is not too
much hastle, maybe it would be easier to build full featured ruby.
> * Not sure if the miniruby configure options changes a lot. I have the
> feeling that the build system tries to pull in even the parts which
> should be unused :/
>
> * Would it be worth of cleaning up the "miniruby" directory, to have
> more control about what could be used/included. I have diff of the stuff
> which is in tarball and what is the minimal set of files required to
> build miniruby at my hand, if anybody is interested.
Is upstream interested in such trimming? Seems like a worth-while thing to have. Or is it
not upstreamable?
I don't think upstream is really interested. At several occasions I was
told that Ruby build depends on Ruby and upstream is fine with it.
Recent steps such as [1] are using Ruby even more then previously.
Anyway, thinking about this boostrap project over night and thinking
about this question, I think that my next step should be trying to use
the miniruby after `make clean`, which should bring the tarball content
closer to upstream repository. I'll see what more is needed to build
Ruby and I might consider reporting my findings upstream. But I am
afraid this will require more time then I can spend on this.
>
> So what did I miss? Of course I am interested in any feedback and
> especially in suggestions for improvement.
Is there a build? simple-koji-ci does not seem to run, same for tmt CI.
Is there any testing we can do to help?
Yes, forget about simple-koji-ci and get hands dirty with building and
experimenting with .spec file yourself. This is not much about if the
produced build of Ruby is right, but how to produce it.
Vít
[1]
https://bugs.ruby-lang.org/issues/15306