Bug #10554: preview2 fails to generate prelude.c

• Status: Rejected
• Assignee: nobu (Nobuyoshi Nakada)
• Target version: -
• ruby -v: ruby-2.2.0-preview2
• Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN

[vo.x (Vit Ondruch)]

generating prelude.c
echo executable host ruby is required.  use --with-baseruby option.; false ./tool/generic_erb.rb -I. -c -o prelude.c \
	./template/prelude.c.tmpl ./prelude.rb ./enc/prelude.rb ./gem_prelude.rb ./abrt_prelude.rb
executable host ruby is required. use --with-baseruby option.
uncommon.mk:780: recipe for target 'prelude.c' failed

I have no Ruby installed on my build machine. Last time I checked r48476, which was working just fine.

[usa (Usaku NAKAMURA)]

Hmm, the tarball contains prelude.c, so normally it is not necessary to generate it.
There was no problem my environment.
Sorry, it might be rude, isn't the clock of your machine off?

[vo.x (Vit Ondruch)]

Thanks for feedback. Let me check it once more. May be the patch from #8566 which I am applying might be troublesome.

[vo.x (Vit Ondruch)]

Ok, this seems to be due to r48607 and associated commits. Looking at builds of Ruby 2.1, prelude.c was always generated, while now it is shipped as part of the tarball. And unfortunately, I consider this move in wrong direction, since inclusion of pregenerated prelude.c is more or less against Fedora's policy [2]. Yes, this paragraph is about pre-built binaries and libraries, but I believe that pre-generated code is the same in the same spirit.

Is there any technical reason, why the prelude.c should be pre-generated and shipped in the source tarball? Would you mind to remove it and let it be generated, as it always was? Thanks.

[1] https://kojipkgs.fedoraproject.org//packages/ruby/2.1.5/25.fc21/data/logs/x86_64/build.log
[2] https://fedoraproject.org/wiki/Packaging:Guidelines#No_inclusion_of_pre-built_binaries_or_libraries

[jeremyevans0 (Jeremy Evans)]

Vit Ondruch wrote:

Ok, this seems to be due to r48607 and associated commits. Looking at builds of Ruby 2.1, prelude.c was always generated, while now it is shipped as part of the tarball. And unfortunately, I consider this move in wrong direction, since inclusion of pregenerated prelude.c is more or less against Fedora's policy [2]. Yes, this paragraph is about pre-built binaries and libraries, but I believe that pre-generated code is the same in the same spirit.

Is there any technical reason, why the prelude.c should be pre-generated and shipped in the source tarball? Would you mind to remove it and let it be generated, as it always was? Thanks.

By this argument, the source tarball shouldn't contain parse.c, only parse.y, making bison a requirement for building. And it shouldn't contain configure/Makefile, only configure.in/Makefile.in, making autoconf/automake a requirement for building. Is it Fedora's policy to delete files generated by bison/autoconf/automake and regenerate them before compiling the software? If not, why would prelude.c be any different?

[nobu (Nobuyoshi Nakada)]

Jeremy Evans wrote:

By this argument, the source tarball shouldn't contain parse.c, only parse.y, making bison a requirement for building. And it shouldn't contain configure/Makefile, only configure.in/Makefile.in, making autoconf/automake a requirement for building. Is it Fedora's policy to delete files generated by bison/autoconf/automake and regenerate them before compiling the software? If not, why would prelude.c be any different?

And newline.c, enc/.c, enc/trans/.c, ...

[vo.x (Vit Ondruch)]

Jeremy Evans wrote:

Vit Ondruch wrote:

Ok, this seems to be due to r48607 and associated commits. Looking at builds of Ruby 2.1, prelude.c was always generated, while now it is shipped as part of the tarball. And unfortunately, I consider this move in wrong direction, since inclusion of pregenerated prelude.c is more or less against Fedora's policy [2]. Yes, this paragraph is about pre-built binaries and libraries, but I believe that pre-generated code is the same in the same spirit.

Is there any technical reason, why the prelude.c should be pre-generated and shipped in the source tarball? Would you mind to remove it and let it be generated, as it always was? Thanks.

By this argument, the source tarball shouldn't contain parse.c, only parse.y, making bison a requirement for building. And it shouldn't contain configure/Makefile, only configure.in/Makefile.in, making autoconf/automake a requirement for building. Is it Fedora's policy to delete files generated by bison/autoconf/automake and regenerate them before compiling the software? If not, why would prelude.c be any different?

I knew that somebody will ask this and I'll bite, why Ruby should be shipped in source form at all? Since everything Ruby user needs is binary.

So while some pre-generated code in source tarball allows to remove the BASERUBY need, which is appreciable, prelude.c is not (so far) the case. I'd be very happy if the amount of pre-generated code could be kept as low as possible.

[Eregon (Benoit Daloze)]

Vit Ondruch wrote:

So while some pre-generated code in source tarball allows to remove the BASERUBY need, which is appreciable, prelude.c is not (so far) the case. I'd be very happy if the amount of pre-generated code could be kept as low as possible.

Then you run the risk of not being able to regenerate these files in another context as there might be a need for specific tools, specific versions or some external ressources, etc.

A released tarball should be as easy to build as possible for a user and more importantly provide a stable build.

[vo.x (Vit Ondruch)]

• File 0001-Generate-preludes-using-miniruby.patch 0001-Generate-preludes-using-miniruby.patch added

Benoit Daloze wrote:

A released tarball should be as easy to build as possible for a user and more importantly provide a stable build.

Of course I agree on this point, while there is no proof that preludes.c would be causing issues to anybody.

BTW here is the patch making the prelude.c generated by miniruby again.

[hsbt (Hiroshi SHIBATA)]

• Status changed from Open to Rejected
• Assignee set to nobu (Nobuyoshi Nakada)

Ruby 2.2.0 is already released. If you still have an issue, Can you submit another issue?

Thanks,