eregontp / gmail.com wrote:
> https://bugs.ruby-lang.org/issues/13620

> Hello all,
> 
> I've been bitten recently when modifying ruby/spec or in #13570 by the sheer number of different configurations to build and test in MRI.
> Currently, I know 4 of them, and I can tell you it is a big headache to make it work on all of them:
> * in-source-dir build, running tool/runruby.rb
> * in-source-dir build, running the installed ruby
> * out-of-source build, running tool/runruby.rb
> * out-of-source build, running the installed ruby
> 
> I just compiled latest MRI this morning, and here are the times:
> * time make -j 8:
> make -j 8  373.22s user 30.88s system 404% cpu 1:39.99 total
> * time make -j 8 install-nodoc
> make -j 8 install-nodoc  3.29s user 0.55s system 259% cpu 1.477 total
> 
> So I am wondering, should we just test with the installed ruby since installing it takes only marginally more time than building?

NAK.

Honestly, this proposal seems so wrong and outlandish that I
wonder if I am misreading or misunderstanding you.  If I am,
then my apologies, you can ignore the rest.

This breaks things for packagers and users of installers (ports,
rvm, etc...) systems who are (as they should be) testing before
installing/distributing any binaries; especially for production
systems.

Honestly, it would be a big shame if we go this route.  There is
no precedence for doing this in any halfway serious project
which Ruby depends on (or is roughly in the same space as,
such as Perl5).

There is no project I can think of which requires installing
to test.  Not even glibc, not Perl5, not git, not jemalloc, ...

> The current complexity of runruby.rb, the generated
> ./rbconfig.rb, etc, all to support testing from the built ruby
> seems not worth it.  It also means all the tests need to
> accommodate this different layout and are essentially testing
> a ruby layout that nobody uses in production.  On the other
> hand, testing the installed ruby would test something which is
> much closer to what is released and used in production, and
> massively simplify the setup to test by making installed
> layout assumptions hold (e.g.: RbConfig.ruby points to the
> current ruby and ruby needs no flags to execute correctly).
> 
> Did I miss something?

Perhaps we can simplify all this without dropping features;
and we can consolidate similar things.

Automake might be nice to simplify our build+test system,
but I guess there were portability concerns last year:

	https://bugs.ruby-lang.org/issues/12124

> I also wish we could choose one of in-source/out-of-source and
> not having to support both, but let's talk about make/make
> install first.

Likewise, dropping either in-source/out-of-source would be
a major loss to either general users who are used to
"./configure && make && make exam && make install"
or developers who want to test several build configs
from the same tree.

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>