https://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112017-06-01T10:02:10ZRuby Issue Tracking SystemRuby master - Feature #13620: Simplifying MRI's build system: always make installhttps://bugs.ruby-lang.org/issues/13620?journal_id=652102017-06-01T10:02:10Zshyouhei (Shyouhei Urabe)shyouhei@ruby-lang.org
<ul></ul><p>I think runruby is needed for cross compilations.</p>
<p>By theory you can't test a cross-compiled ruby binary so I guess it might make sense to install before test. But I'm quite skeptical about the possibility of deleting runruby.</p> Ruby master - Feature #13620: Simplifying MRI's build system: always make installhttps://bugs.ruby-lang.org/issues/13620?journal_id=652112017-06-01T11:54:38Znaruse (Yui NARUSE)naruse@airemix.jp
<ul></ul><p>I object this.</p>
<p>You are counting only full build.<br>
But on developing, you need to compare with null build.</p>
<pre><code>% time make -j8 main
CC = clang
LD = ld
LDSHARED = clang -dynamiclib
CFLAGS = -O3 -march=native -gdwarf -fno-fast-math -ggdb3 -Wall -Wextra -Wno-unused-parameter -Wno-parentheses -Wno-long-long -Wno-missing-field-initializers -Wno-tautological-compare -Wno-parentheses-equality -Wno-constant-logical-operand -Wno-self-assign -Wunused-variable -Werror=implicit-int -Werror=pointer-arith -Werror=write-strings -Werror=declaration-after-statement -Werror=shorten-64-to-32 -Werror=implicit-function-declaration -Werror=division-by-zero -Werror=deprecated-declarations -Werror=extra-tokens -fno-common -pipe
XCFLAGS = -D_FORTIFY_SOURCE=2 -fstack-protector -fno-strict-overflow -fvisibility=hidden -DRUBY_EXPORT
CPPFLAGS = -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -D_DARWIN_UNLIMITED_SELECT -D_REENTRANT -I. -I.ext/include/x86_64-darwin16 -I./include -I. -I./enc/unicode/9.0.0
DLDFLAGS = -Wl,-undefined,dynamic_lookup -Wl,-multiply_defined,suppress -install_name /Users/naruse/local/ruby/lib/libruby.2.5.0.dylib -compatibility_version 2.5 -current_version 2.5.0 -fstack-protector -Wl,-u,_objc_msgSend -framework CoreFoundation -fstack-protector -Wl,-u,_objc_msgSend -framework CoreFoundation
SOLIBS = -lpthread -ldl -lobjc
Apple LLVM version 8.1.0 (clang-802.0.42)
Target: x86_64-apple-darwin16.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
generating encdb.h
generating enc.mk
encdb.h unchanged
making srcs under enc
making enc
make[1]: Nothing to be done for `enc'.
make[1]: Nothing to be done for `srcs'.
generating transdb.h
transdb.h unchanged
generating makefiles ext/configure-ext.mk
making trans
make[1]: Nothing to be done for `./enc/trans'.
making encs
ext/configure-ext.mk unchanged
make[1]: Nothing to be done for `encs'.
generating makefile exts.mk
exts.mk unchanged
make[2]: `ruby' is up to date.
make[1]: Nothing to be done for `note'.
make -j8 main 2.97s user 0.62s system 108% cpu 3.305 total
</code></pre>
<p>On such case almost all libraries are already build and the build time is much shorter.</p>
<p>Therefore when I am developing ext/ libraries, adding install-nodoc doubles the build-install time.</p> Ruby master - Feature #13620: Simplifying MRI's build system: always make installhttps://bugs.ruby-lang.org/issues/13620?journal_id=652122017-06-01T12:34:20Znobu (Nobuyoshi Nakada)nobu@ruby-lang.org
<ul></ul><p>Let's zap in-source-dir builds first.</p> Ruby master - Feature #13620: Simplifying MRI's build system: always make installhttps://bugs.ruby-lang.org/issues/13620?journal_id=652132017-06-01T13:23:33Zusa (Usaku NAKAMURA)usa@garbagecollect.jp
<ul></ul><p>nobu (Nobuyoshi Nakada) wrote:</p>
<blockquote>
<p>Let's zap in-source-dir builds first.</p>
</blockquote>
<p>I want to agree with you, but every users of tarball packages run <code>configure</code> in the directory where it exists.</p> Ruby master - Feature #13620: Simplifying MRI's build system: always make installhttps://bugs.ruby-lang.org/issues/13620?journal_id=652162017-06-01T15:26:44ZEregon (Benoit Daloze)
<ul></ul><p>naruse (Yui NARUSE) wrote:</p>
<blockquote>
<p>I object this.</p>
<p>You are counting only full build.</p>
</blockquote>
<p>Actually the numbers above are for building just after a pull.<br>
And if any file is touched, it takes longer than install-nodoc.</p>
<blockquote>
<p>But on developing, you need to compare with null build.</p>
<p>On such case almost all libraries are already build and the build time is much shorter.</p>
<p>Therefore when I am developing ext/ libraries, adding install-nodoc doubles the build-install time.</p>
</blockquote>
<p>How much is it? 6s instead of 3s?<br>
Probably this depends a fair amount on disk speed.<br>
I have a small bcache SSD. Times are better on a true SSD.<br>
Maybe we should install to /tmp :D</p>
<p>Here are my numbers for a null build:</p>
<p>$ time make -j 8 all<br>
make -j 8 all 3.24s user 0.53s system 364% cpu 1.034 total<br>
$ time make -j 8 all install-nodoc<br>
make -j 8 all install-nodoc 3.56s user 0.58s system 262% cpu 1.580 total</p>
<p>While it is more, I cannot really feel the difference.<br>
Changing anything in my editor takes much longer than that.<br>
Running the tests for the relevant extension also takes a while.</p> Ruby master - Feature #13620: Simplifying MRI's build system: always make installhttps://bugs.ruby-lang.org/issues/13620?journal_id=652192017-06-01T17:17:30Znaruse (Yui NARUSE)naruse@airemix.jp
<ul></ul><p>nobu (Nobuyoshi Nakada) wrote:</p>
<blockquote>
<p>Let's zap in-source-dir builds first.</p>
</blockquote>
<p>I don't agree.<br>
I hadn't see a software which denies in-source-dir builds.</p>
<blockquote>
<p>While it is more, I cannot really feel the difference.<br>
Changing anything in my editor takes much longer than that.</p>
</blockquote>
<p>Before changing something in editor, I must wait running current code.<br>
I don't want 6 sec to be just pointed that the test code has typo.<br>
(additional to say I don't want wait 3 sec I sometimes wish it become less than 1 sec)</p> Ruby master - Feature #13620: Simplifying MRI's build system: always make installhttps://bugs.ruby-lang.org/issues/13620?journal_id=652222017-06-01T22:51:10Znormalperson (Eric Wong)normalperson@yhbt.net
<ul></ul><p><a href="mailto:eregontp@gmail.com" class="email">eregontp@gmail.com</a> wrote:</p>
<blockquote>
<p><a href="https://bugs.ruby-lang.org/issues/13620" class="external">https://bugs.ruby-lang.org/issues/13620</a></p>
</blockquote>
<blockquote>
<p>Hello all,</p>
<p>I've been bitten recently when modifying ruby/spec or in <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: Using mkmf for ruby/spec C API specs (Closed)" href="https://bugs.ruby-lang.org/issues/13570">#13570</a> by the sheer number of different configurations to build and test in MRI.<br>
Currently, I know 4 of them, and I can tell you it is a big headache to make it work on all of them:</p>
<ul>
<li>in-source-dir build, running tool/runruby.rb</li>
<li>in-source-dir build, running the installed ruby</li>
<li>out-of-source build, running tool/runruby.rb</li>
<li>out-of-source build, running the installed ruby</li>
</ul>
<p>I just compiled latest MRI this morning, and here are the times:</p>
<ul>
<li>time make -j 8:<br>
make -j 8 373.22s user 30.88s system 404% cpu 1:39.99 total</li>
<li>time make -j 8 install-nodoc<br>
make -j 8 install-nodoc 3.29s user 0.55s system 259% cpu 1.477 total</li>
</ul>
<p>So I am wondering, should we just test with the installed ruby since installing it takes only marginally more time than building?</p>
</blockquote>
<p>NAK.</p>
<p>Honestly, this proposal seems so wrong and outlandish that I<br>
wonder if I am misreading or misunderstanding you. If I am,<br>
then my apologies, you can ignore the rest.</p>
<p>This breaks things for packagers and users of installers (ports,<br>
rvm, etc...) systems who are (as they should be) testing before<br>
installing/distributing any binaries; especially for production<br>
systems.</p>
<p>Honestly, it would be a big shame if we go this route. There is<br>
no precedence for doing this in any halfway serious project<br>
which Ruby depends on (or is roughly in the same space as,<br>
such as Perl5).</p>
<p>There is no project I can think of which requires installing<br>
to test. Not even glibc, not Perl5, not git, not jemalloc, ...</p>
<blockquote>
<p>The current complexity of runruby.rb, the generated<br>
./rbconfig.rb, etc, all to support testing from the built ruby<br>
seems not worth it. It also means all the tests need to<br>
accommodate this different layout and are essentially testing<br>
a ruby layout that nobody uses in production. On the other<br>
hand, testing the installed ruby would test something which is<br>
much closer to what is released and used in production, and<br>
massively simplify the setup to test by making installed<br>
layout assumptions hold (e.g.: RbConfig.ruby points to the<br>
current ruby and ruby needs no flags to execute correctly).</p>
<p>Did I miss something?</p>
</blockquote>
<p>Perhaps we can simplify all this without dropping features;<br>
and we can consolidate similar things.</p>
<p>Automake might be nice to simplify our build+test system,<br>
but I guess there were portability concerns last year:</p>
<pre><code>https://bugs.ruby-lang.org/issues/12124
</code></pre>
<blockquote>
<p>I also wish we could choose one of in-source/out-of-source and<br>
not having to support both, but let's talk about make/make<br>
install first.</p>
</blockquote>
<p>Likewise, dropping either in-source/out-of-source would be<br>
a major loss to either general users who are used to<br>
"./configure && make && make exam && make install"<br>
or developers who want to test several build configs<br>
from the same tree.</p> Ruby master - Feature #13620: Simplifying MRI's build system: always make installhttps://bugs.ruby-lang.org/issues/13620?journal_id=652302017-06-02T12:02:12ZEregon (Benoit Daloze)
<ul></ul><p>normalperson (Eric Wong) wrote:</p>
<blockquote>
<p>Honestly, this proposal seems so wrong and outlandish that I<br>
wonder if I am misreading or misunderstanding you. If I am,<br>
then my apologies, you can ignore the rest.</p>
<p>This breaks things for packagers and users of installers (ports,<br>
rvm, etc...) systems who are (as they should be) testing before<br>
installing/distributing any binaries; especially for production<br>
systems.</p>
</blockquote>
<p>I see your point, but I think we have a rather different view on this question.<br>
Let me show you my opinion to understand better.</p>
<p>Do you realize that testing in this situation is actually testing an artifact that nobody uses in production?<br>
e.g. if make install is broken, these tests won't notice,<br>
and the installed ruby might be broken, without any notice.</p>
<p>I don't really see your point about testing before install.<br>
One could install to a test prefix before installing for the whole system.<br>
It could even default to say a ruby/build sub-directory or so<br>
and then the difference with in-source build is really small.</p>
<blockquote>
<p>Honestly, it would be a big shame if we go this route. There is<br>
no precedence for doing this in any halfway serious project<br>
which Ruby depends on (or is roughly in the same space as,<br>
such as Perl5).</p>
</blockquote>
<p>I met quite a few C/C++ projects which require install to run.<br>
Indeed, it's not convenient, but if "make" meant "make install to ./build"<br>
how would you know the difference?</p>
<blockquote>
<p>Perhaps we can simplify all this without dropping features;<br>
and we can consolidate similar things.</p>
</blockquote>
<p>It might be possible.<br>
One way to simplify would be to make the built ./ruby runnable without<br>
anything extra (no need for runruby.rb anymore).<br>
This seems to revolve around linking to the proper libruby.so in case of a shared build.<br>
We could simply re-build the small ruby binary when "make install"<br>
and use an absolute path to libruby.so for both so they resolve to the right one.</p>
<p>There are many more complexities than that in the build system,<br>
but it would be a good start.</p>
<p>There are currently too many configurations, and therefore I believe they are not all tested:<br>
in/out-of-source * shared/non-shared * built/installed * platforms</p>
<p>It also seems to me that we test the configurations that a real user is the least likely to use.</p>
<blockquote>
<p>Likewise, dropping either in-source/out-of-source would be<br>
a major loss to either general users who are used to<br>
"./configure && make && make exam && make install"<br>
or developers who want to test several build configs<br>
from the same tree.</p>
</blockquote>
<p>Does the latter work? I tried using the same source repo<br>
for both in-source and out-of-source build and it did not work.</p> Ruby master - Feature #13620: Simplifying MRI's build system: always make installhttps://bugs.ruby-lang.org/issues/13620?journal_id=652322017-06-02T13:31:28Zmagaudet (Matthew Gaudet)
<ul></ul><p>Just a word of encouragement here.</p>
<p>The ways in which ruby seems to differ between installed and in-tree testing has bitten me doing Ruby+OMR work a number of times, and I'd love to see some simplification. (In particular, I load Ruby+OMR as a shared library, but Ruby by default only searches the install path, which is why the Ruby+OMR instructions show <code>LD_LIBRARY_PATH=$PWD OMR_JIT_OPTIONS=... make test</code> to test without installing.</p>
<p>I quite like Benoit's suggestion that <code>make</code> => <code>make install PREFIX=./build</code></p> Ruby master - Feature #13620: Simplifying MRI's build system: always make installhttps://bugs.ruby-lang.org/issues/13620?journal_id=652482017-06-02T22:41:29Znormalperson (Eric Wong)normalperson@yhbt.net
<ul></ul><p><a href="mailto:eregontp@gmail.com" class="email">eregontp@gmail.com</a> wrote:</p>
<blockquote>
<p>Issue <a class="issue tracker-2 status-1 priority-4 priority-default" title="Feature: Simplifying MRI's build system: always make install (Open)" href="https://bugs.ruby-lang.org/issues/13620">#13620</a> has been updated by Eregon (Benoit Daloze).</p>
<p>normalperson (Eric Wong) wrote:</p>
<blockquote>
<p>Honestly, this proposal seems so wrong and outlandish that I<br>
wonder if I am misreading or misunderstanding you. If I am,<br>
then my apologies, you can ignore the rest.</p>
<p>This breaks things for packagers and users of installers (ports,<br>
rvm, etc...) systems who are (as they should be) testing before<br>
installing/distributing any binaries; especially for production<br>
systems.</p>
</blockquote>
<p>I see your point, but I think we have a rather different view on this question.<br>
Let me show you my opinion to understand better.</p>
<p>Do you realize that testing in this situation is actually testing an artifact that nobody uses in production?<br>
e.g. if make install is broken, these tests won't notice,<br>
and the installed ruby might be broken, without any notice.</p>
</blockquote>
<p>Of course, there will be differences not detected before<br>
install, but the goal should be to minimize those differences.</p>
<p>We should continue doing whatever we can before installing to test.<br>
Probably more than 99% of our test suite can be tested without<br>
installing.</p>
<blockquote>
<p>I don't really see your point about testing before install.<br>
One could install to a test prefix before installing for the whole system.<br>
It could even default to say a ruby/build sub-directory or so<br>
and then the difference with in-source build is really small.</p>
</blockquote>
<p>Installing to a test prefix would be little difference than<br>
testing with the working tree: there can still be path<br>
differences compared to what will be the final paths.</p>
<p>It would also waste over 100MB space and increase disk/SSD wear.<br>
This may not matter to most developers; but I prefer we support<br>
the cheapskate, anti-consumerist ones :></p>
<blockquote>
<blockquote>
<p>Honestly, it would be a big shame if we go this route. There is<br>
no precedence for doing this in any halfway serious project<br>
which Ruby depends on (or is roughly in the same space as,<br>
such as Perl5).</p>
</blockquote>
<p>I met quite a few C/C++ projects which require install to run.</p>
</blockquote>
<p>Examples?</p>
<blockquote>
<p>Indeed, it's not convenient, but if "make" meant "make install to ./build"<br>
how would you know the difference?</p>
</blockquote>
<p>See above about space and space differences.</p>
<blockquote>
<blockquote>
<p>Perhaps we can simplify all this without dropping features;<br>
and we can consolidate similar things.</p>
</blockquote>
<p>It might be possible.<br>
One way to simplify would be to make the built ./ruby runnable without<br>
anything extra (no need for runruby.rb anymore).<br>
This seems to revolve around linking to the proper libruby.so in case of a shared build.<br>
We could simply re-build the small ruby binary when "make install"<br>
and use an absolute path to libruby.so for both so they resolve to the right one.</p>
</blockquote>
<p>Actually, libtool has support to auto-generated wrapper scripts<br>
which can take care of .so paths, and RUBYLIB can probably be<br>
added, too.</p>
<p>I'm not remotely an expert on libtool, though; but I've<br>
encountered it on some projects (sox(*)), which made running<br>
from the source tree much easier.</p>
<p>(*) git clone git://git.code.sf.net/p/sox/code sox</p>
<blockquote>
<p>There are many more complexities than that in the build system,<br>
but it would be a good start.</p>
<p>There are currently too many configurations, and therefore I believe they are not tested:<br>
in/out-of-source * shared/non-shared * built/installed * platforms</p>
<p>It also seems to me that we test the configurations that a real user is the least likely to use.</p>
<blockquote>
<p>Likewise, dropping either in-source/out-of-source would be<br>
a major loss to either general users who are used to<br>
"./configure && make && make exam && make install"<br>
or developers who want to test several build configs<br>
from the same tree.</p>
</blockquote>
<p>Does the latter work? I tried using the same source repo<br>
for both in-source and out-of-source build and it did not work.</p>
</blockquote>
<p>The latter works; but using the <em>same</em> working tree for both<br>
in-source and out-of-source builds does not.</p>
<p>There can definitely be unlimited out-of-source build trees from<br>
the same working source tree. I did this for working on<br>
auto-fiber testing on [Feature <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid (Closed)" href="https://bugs.ruby-lang.org/issues/13618">#13618</a>]:</p>
<p>mkdir e && (cd e && /path/to/ruby/configure --with-iom=epoll ...)<br>
mkdir s && (cd s && /path/to/ruby/configure --with-iom=select ...)<br>
mkdir k && (cd k && /path/to/ruby/configure --with-iom=kqueue ...)</p>
<p>I still use in-source builds in some cases for convenience,<br>
however. I tend to use in-source builds for projects where<br>
I am not a regular contributor.</p> Ruby master - Feature #13620: Simplifying MRI's build system: always make installhttps://bugs.ruby-lang.org/issues/13620?journal_id=728702018-07-07T17:06:59ZEregon (Benoit Daloze)
<ul><li><strong>Subject</strong> changed from <i>Simplifying MRI's build system: always install</i> to <i>Simplifying MRI's build system: always make install</i></li></ul> Ruby master - Feature #13620: Simplifying MRI's build system: always make installhttps://bugs.ruby-lang.org/issues/13620?journal_id=728722018-07-07T17:43:23ZEregon (Benoit Daloze)
<ul></ul><p>normalperson (Eric Wong) wrote:</p>
<blockquote>
<p>Of course, there will be differences not detected before<br>
install, but the goal should be to minimize those differences.</p>
</blockquote>
<p>There are many differences, and fundamental things like RbConfig.ruby pointing to the current ruby are broken (see the original description).</p>
<blockquote>
<p>We should continue doing whatever we can before installing to test.<br>
Probably more than 99% of our test suite can be tested without<br>
installing.</p>
</blockquote>
<p>But this means keeping to add hacks to support a layout not used by Ruby users :(<br>
I'd think many tests could be simplified and made more robust if they did not have to support this weird "build" layout.<br>
Or maybe we could make the build layout more similar to the installed layout.</p>
<p>As an illustration, it seems MJIT currently requires "make install".<br>
I guess it's because it's difficult to support the build layout and would require more hacks.<br>
<a class="user active user-mention" href="https://bugs.ruby-lang.org/users/10073">@k0kubun (Takashi Kokubun)</a> would know better of course.</p>
<blockquote>
<p>Installing to a test prefix would be little difference than<br>
testing with the working tree: there can still be path<br>
differences compared to what will be the final paths.</p>
</blockquote>
<p>All relative paths would be the same.<br>
And of course no test should hardcode an absolute path as that cannot work anyway.<br>
So it's extremely similar vs "not all all, there is not even a bin/ruby".</p>
<blockquote>
<p>It would also waste over 100MB space and increase disk/SSD wear.<br>
This may not matter to most developers; but I prefer we support<br>
the cheapskate, anti-consumerist ones :></p>
</blockquote>
<p>That seems a very specific concern.<br>
But maybe installing to a ramdisk would be good to avoid extra disk writes?<br>
Also, most files are not changed when doing an incremental build,<br>
so there is probably the opportunity to do very little extra writes, or even use hardlinks.</p>
<blockquote>
<p>Examples?</p>
</blockquote>
<p>I'd guess most simple projects with only a few people working on it.<br>
It was a while ago, I don't have a specific example at hand but small C/C++ projects like games, CLI tools, etc.<br>
Then they likely don't want to spend so much time on supporting in-build-dir testing.</p>
<blockquote>
<p>See above about space and space differences.</p>
</blockquote>
<p>My Ruby checkout is >500MB, so it doesn't seem much of a concern for disk usage.</p>
<blockquote>
<p>Actually, libtool has support to auto-generated wrapper scripts<br>
which can take care of .so paths, and RUBYLIB can probably be<br>
added, too.</p>
<p>I'm not remotely an expert on libtool, though; but I've<br>
encountered it on some projects (sox(*)), which made running<br>
from the source tree much easier.</p>
<p>(*) git clone git://git.code.sf.net/p/sox/code sox</p>
</blockquote>
<p>That seems very complicated to set up from a brief look at their manual.</p>
<p>Actually, having only out-of-source builds, defaulting to, e.g. ruby_repo/build/ + some layout changes<br>
would achieve something similar to make-install-by-default, without actually copying files again.<br>
It looks like MRuby does something like this:<br>
<a href="https://github.com/mruby/mruby/blob/master/doc/guides/compile.md#build-process" class="external">https://github.com/mruby/mruby/blob/master/doc/guides/compile.md#build-process</a><br>
And that layout looks much more similar to an installed layout, even though it has extra *.o around, etc.</p> Ruby master - Feature #13620: Simplifying MRI's build system: always make installhttps://bugs.ruby-lang.org/issues/13620?journal_id=728892018-07-08T09:41:46ZEregon (Benoit Daloze)
<ul></ul><p><a class="user active user-mention" href="https://bugs.ruby-lang.org/users/724">@normalperson (Eric Wong)</a> wrote in ruby-core:87864:</p>
<blockquote>
<p>mkmf works fine with everything in ext/ without install, so I<br>
expect mjit to work, too. I will let Nobu figure it out.</p>
</blockquote>
<p>FWIW, mkmf.rb is a famous example for terrible hacks to accommodate the build layout :p<br>
There is this $extmk global variable and ~20 conditions based on it in lib/mkmf.rb which makes the code unreadable and fragile.<br>
Due to that, running mkmf.rb needs more hacks for testing in tree (and shows confusing behavior without it):<br>
<a href="https://github.com/ruby/ruby/blob/d41baaee9f4cb725f82d74fc4978d923e6e63cbf/spec/ruby/optional/capi/spec_helper.rb#L3-L4" class="external">https://github.com/ruby/ruby/blob/d41baaee9f4cb725f82d74fc4978d923e6e63cbf/spec/ruby/optional/capi/spec_helper.rb#L3-L4</a><br>
There is even a hook on the global variable, which executes all sort of things on the first assignment, regardless of the value set:<br>
<a href="https://github.com/ruby/ruby/blob/d41baaee9f4cb725f82d74fc4978d923e6e63cbf/tool/fake.rb#L37-L70" class="external">https://github.com/ruby/ruby/blob/d41baaee9f4cb725f82d74fc4978d923e6e63cbf/tool/fake.rb#L37-L70</a></p>
<p>I think one solution here is to make building in-tree C extensions more similar to external C-extensions.<br>
It's basically what TruffleRuby does, for openssl/zlib/syslog/psych and $extmk is just always <code>false</code>.</p> Ruby master - Feature #13620: Simplifying MRI's build system: always make installhttps://bugs.ruby-lang.org/issues/13620?journal_id=778482019-04-30T12:45:34ZEregon (Benoit Daloze)
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-5 priority-4 priority-default closed" href="/issues/15812">Bug #15812</a>: Run specs from install folder?</i> added</li></ul> Ruby master - Feature #13620: Simplifying MRI's build system: always make installhttps://bugs.ruby-lang.org/issues/13620?journal_id=1018852023-02-15T19:55:21ZEregon (Benoit Daloze)
<ul></ul><p>FWIW, here is another terrible hack due to trying to run before files have a proper Ruby home structure:<br>
<a href="https://github.com/ruby/ruby/commit/a2c66f52f402cb58372e271226f3341065561e53" class="external">https://github.com/ruby/ruby/commit/a2c66f52f402cb58372e271226f3341065561e53</a> and reported as <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Ruby 3.1.3 installs wrong gemspec for debug gem (Closed)" href="https://bugs.ruby-lang.org/issues/19158">#19158</a>.</p> Ruby master - Feature #13620: Simplifying MRI's build system: always make installhttps://bugs.ruby-lang.org/issues/13620?journal_id=1018862023-02-15T19:55:30ZEregon (Benoit Daloze)
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-5 priority-4 priority-default closed" href="/issues/19158">Bug #19158</a>: Ruby 3.1.3 installs wrong gemspec for debug gem</i> added</li></ul>