From: eregontp@... Date: 2018-07-07T17:43:24+00:00 Subject: [ruby-core:87854] [Ruby trunk Feature#13620] Simplifying MRI's build system: always make install Issue #13620 has been updated by Eregon (Benoit Daloze). normalperson (Eric Wong) wrote: > Of course, there will be differences not detected before > install, but the goal should be to minimize those differences. There are many differences, and fundamental things like RbConfig.ruby pointing to the current ruby are broken (see the original description). > We should continue doing whatever we can before installing to test. > Probably more than 99% of our test suite can be tested without > installing. But this means keeping to add hacks to support a layout not used by Ruby users :( I'd think many tests could be simplified and made more robust if they did not have to support this weird "build" layout. Or maybe we could make the build layout more similar to the installed layout. As an illustration, it seems MJIT currently requires "make install". I guess it's because it's difficult to support in-source builds and would require more hacks. @k0kubun would know better of course. > 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. All relative paths would be the same. And of course no test should hardcode an absolute path as that cannot work anyway. So it's extremely similar vs "not all all, there is not even a bin/ruby". > 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 :> That seems a very specific concern. But maybe installing to a ramdisk would be good to avoid extra disk writes? Also, most files are not changed when doing an incremental build, so there is probably the opportunity to do very little extra writes, or even use hardlinks. > Examples? I'd guess most simple projects with only a few people working on it. It was a while ago, I don't have a specific example at hand but small C/C++ projects like games, CLI tools, etc. Then they likely don't want to spend so much time on supporting in-build-dir testing. > See above about space and space differences. My Ruby checkout is >500MB, so it doesn't seem much of a concern for disk usage. > 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 That seems very complicated to set up from a brief look at their manual. Actually, having only out-of-source builds, defaulting to, e.g. ruby_repo/build/ + some layout changes would achieve something similar to make-install-by-default, without actually copying files again. It looks like MRuby does something like this: https://github.com/mruby/mruby/blob/master/doc/guides/compile.md#build-process And that layout looks much more similar to an installed layout, even though it has extra *.o around, etc. ---------------------------------------- Feature #13620: Simplifying MRI's build system: always make install https://bugs.ruby-lang.org/issues/13620#change-72872 * 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>