Issue #13620 has been updated by Eregon (Benoit Daloze).


normalperson (Eric Wong) wrote:
>  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.

I see your point, but I think we have a rather different view on this question.
Let me show you my opinion to understand better.

Do you realize that testing in this situation is actually testing an artifact that nobody uses in production?
e.g. if make install is broken, these tests won't notice,
and the installed ruby might be broken, without any notice.

I don't really see your point about testing before install.
One could install to a test prefix before installing for the whole system.
It could even default to say a ruby/build sub-directory or so
and then the difference with in-source build is really small.

>  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).

I met quite a few C/C++ projects which require install to run.
Indeed, it's not convenient, but if "make" meant "make install to ./build"
how would you know the difference?

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

It might be possible.
One way to simplify would be to make the built ./ruby runnable without
anything extra (no need for runruby.rb anymore).
This seems to revolve around linking to the proper libruby.so in case of a shared build.
We could simply re-build the small ruby binary when "make install"
and use an absolute path to libruby.so for both so they resolve to the right one.

There are many more complexities than that in the build system,
but it would be a good start.

There are currently too many configurations, and therefore I believe they are not tested:
in/out-of-source * shared/non-shared * built/installed * platforms

It also seems to me that we test the configurations that a real user is the least likely to use.

>  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.

Does the latter work? I tried using the same source repo
for both in-source and out-of-source build and it did not work.

----------------------------------------
Feature #13620: Simplifying MRI's build system: always install
https://bugs.ruby-lang.org/issues/13620#change-65230

* Author: Eregon (Benoit Daloze)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
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?

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?

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.



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

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