[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cleaning up bash releases at first directory level

From: Greg Wooledge
Subject: Re: Cleaning up bash releases at first directory level
Date: Tue, 21 Mar 2023 07:55:51 -0400

On Tue, Mar 21, 2023 at 12:18:30PM +0900, Koichi Murase wrote:
> Putting every source file in the src subdirectory is not that extreme,
> but it's still a matter of degree. I guess putting them inside src
> might help people who read the entire file list of the directory from
> top to bottom one by one, but I'm not sure if we should care about
> that level of users. The repository is primarily for the developers
> and secondarily for the users who want to compile Bash from the source
> and who are familiar with the files README, INSTALL, ./configure, etc

The idea of a "src" directory inside your source directory is a fairly
new one, I think.  With projects as old as bash, the idea was that the
top-level directory of the source tree is also the primary level of
functionality (where you would find the file containing "main()" for
instance).  Any subdirectories beneath that are for isolated sections
of the code base.

Documentation files like README and INSTALL are also included in the
top-level directory, and they are given names beginning with capital
letters, so that they appear first in the directory listing.  (This
was a convention adopted back in the days when directory listings were
always sorted by ASCII, so capital letters would come before lowercase
letters.  Sadly, recent versions of Linux have started sorting directory
listings in a case-insensitive manner, in most locales, which breaks
this long-standing convention.)

The OP's suggestion that we uproot the entire historic code base and
replant it according to recent preferences is a huge, sweeping change.
The question is whether the benefits outweigh the negative consequences.
I don't believe that they do.  In fact, it's hard for me to name even
one benefit of doing this, apart from "it would make the OP happy".

The only people who should care about where the source files reside are
those who work with the source files -- people who are maintaining
bash (Chet), or applying patches and installing bash locally (system
administrators, Linux distribution packagers, etc.), or submitting
patches for new features.

For someone who's still learning how to compile bash *at all*, why
should the locations of the files make any difference?  The build
steps are extremely well documented, in multiple places.  Even if
you don't manage to read the documentation, they're the same steps
that you follow for hundreds of other projects -- ./configure, make.
You could blindly try that, knowing nothing about the bash source
tree, and it would just work.

I don't see any reason to change anything.

> I don't think the original poster has shown any sufficient
> reason to make changes compromising that point.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]