eregontp / gmail.com wrote:
> 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.

Of course, there will be differences not detected before
install, but the goal should be to minimize those differences.

We should continue doing whatever we can before installing to test.
Probably more than 99% of our test suite can be tested without
installing.

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

Installing to a test prefix would be little difference than
testing with the working tree: there can still be path
differences compared to what will be the final paths.

It would also waste over 100MB space and increase disk/SSD wear.
This may not matter to most developers; but I prefer we support
the cheapskate, anti-consumerist ones :>

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

Examples?

> Indeed, it's not convenient, but if "make" meant "make install to ./build"
> how would you know the difference?

See above about space and space differences.

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

Actually, libtool has support to auto-generated wrapper scripts
which can take care of .so paths, and RUBYLIB can probably be
added, too.

I'm not remotely an expert on libtool, though; but I've
encountered it on some projects (sox(*)), which made running
from the source tree much easier.

(*) git clone git://git.code.sf.net/p/sox/code sox

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

The latter works; but using the _same_ working tree for both
in-source and out-of-source builds does not.

There can definitely be unlimited out-of-source build trees from
the same working source tree.  I did this for working on
auto-fiber testing on [Feature #13618]:

mkdir e && (cd e && /path/to/ruby/configure --with-iom=epoll ...)
mkdir s && (cd s && /path/to/ruby/configure --with-iom=select ...)
mkdir k && (cd k && /path/to/ruby/configure --with-iom=kqueue ...)

I still use in-source builds in some cases for convenience,
however.  I tend to use in-source builds for projects where
I am not a regular contributor.

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