Project

General

Profile

Actions

Misc #16747

open

Repository reorganization request

Added by shyouhei (Shyouhei Urabe) over 4 years ago. Updated over 4 years ago.

Status:
Assigned
[ruby-core:97655]

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 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)
Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0