Misc #16747
openRepository reorganization request
Description
Back in 0.49, there were only 60 files and 3 directories at the root of this project. This was already at some level, but OK-ish. Now, as we are reaching 3.0, we currently have 167 files and 26 directories. The project has grown up. I believe we need some housekeeping.
I would like to introduce directories and move things around, like what they do for jemalloc.
- Create directory named
src
and move sources there.
There is no need to cargo-cult them so suggestions are welcome.
Updated by hsbt (Hiroshi SHIBATA) over 4 years ago
I strongly agreed on this. In GitHub, README.md
was located with the long scroll action.
I remember @nobu (Nobuyoshi Nakada) has the working branch about this.
Updated by hsbt (Hiroshi SHIBATA) over 4 years ago
With https://bugs.ruby-lang.org/issues/16254, We should re-organize the top-directory before increasing the files like kernel.c and kernel.rb.
Updated by vo.x (Vit Ondruch) over 4 years ago
It should include also better place for default gems:
https://bugs.ruby-lang.org/issues/16778
And also it would be nice if all vendored/bundled code is in dedicated directory if possible, e.g. libraries taken from ccan, onigmo, rubygems, etc.
Updated by nobu (Nobuyoshi Nakada) over 4 years ago
https://github.com/nobu/ruby/tree/feature/src-dir is the status quo.
Updated by shyouhei (Shyouhei Urabe) over 4 years ago
Great work, thank you.
Questions/discussions related to header files:
- For instance ccan is a header-only library. Should it be placed under include?
- What about for instance vm_core.h etc?
- Should files under include be installed? This question leads to #16803.
Questions about files not moved:
- Why is win32/win32.c out of main_src?
Updated by Eregon (Benoit Daloze) over 4 years ago
IMHO it's best if include/
in the repository corresponds closely to what ends up in the install dir.
So I prefer ccan in src/
.
make test*
uses the repository dir, so adding anything else under include/
would expose it to those tests which is not good (they're internal).
Updated by vo.x (Vit Ondruch) over 4 years ago
shyouhei (Shyouhei Urabe) wrote in #note-5:
- For instance ccan is a header-only library. Should it be placed under include?
It is not just header only library, but vendored code. It would be nice if this kind of code lives outside of other Ruby sources. It might be easier to sync such libraries, but mainly, it makes the license audit easier.
Also, not sure what is the rationale for mainsrc, but at the first look, I couldn't find the sources, because it is somehow unexpected name (at least to me).
Updated by greggzst (Grzegorz Jakubiak) over 4 years ago
vo.x (Vit Ondruch) wrote in #note-7:
Also, not sure what is the rationale for mainsrc, but at the first look, I couldn't find the sources, because it is somehow unexpected name (at least to me).
src
is what people are used to, so it should be renamed.
Updated by Eregon (Benoit Daloze) over 4 years ago
vo.x (Vit Ondruch) wrote in #note-7:
Also, not sure what is the rationale for mainsrc, but at the first look, I couldn't find the sources, because it is somehow unexpected name (at least to me).
Indeed, I missed that, why mainsrc
and not just src
?
I think src
would be more intuitive, more commonly used, shorter, etc.
Updated by hsbt (Hiroshi SHIBATA) over 4 years ago
- Status changed from Open to Assigned
mainsrc
is WIP name for migrating this issue. nobu said we can rename src
from mainsrc
after that.
Updated by hsbt (Hiroshi SHIBATA) over 4 years ago
- Assignee set to nobu (Nobuyoshi Nakada)