Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Janis Papanagnou <janis_papanagnou+ng@hotmail.com>
Newsgroups: comp.lang.c
Subject: Re: question about linker
Date: Mon, 9 Dec 2024 18:35:57 +0100
Organization: A noiseless patient Spider
Lines: 110
Message-ID: <vj79pv$gjhr$1@dont-email.me>
References: <vi54e9$3ie0o$1@dont-email.me> <vil0qc$3fqqa$3@dont-email.me>
 <vil82t$3ie9o$2@dont-email.me> <vila9j$3j4dg$1@dont-email.me>
 <vin4su$49a6$1@dont-email.me> <vin95m$5da6$1@dont-email.me>
 <vinh3h$7ppb$1@dont-email.me> <vinjf8$8jur$1@dont-email.me>
 <vip5rf$p44n$1@dont-email.me> <viprao$umjj$1@dont-email.me>
 <viqfk9$13esp$1@dont-email.me> <viqhmn$131h8$3@dont-email.me>
 <visbmp$1ks59$1@dont-email.me> <visgs7$1mgdb$1@dont-email.me>
 <viv5ve$2dqir$1@dont-email.me> <vivggi$2gkth$1@dont-email.me>
 <vj5807$gift$1@paganini.bofh.team>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 09 Dec 2024 18:35:59 +0100 (CET)
Injection-Info: dont-email.me; posting-host="1831f7430e8998035619d33d7ee64315";
	logging-data="544315"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+cv/64WWk/x5JCCJMesyW5"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
Cancel-Lock: sha1:SftkK5yQ01icGrBTnRNb3RrF6PU=
X-Enigmail-Draft-Status: N1110
In-Reply-To: <vj5807$gift$1@paganini.bofh.team>
Bytes: 7173

On 08.12.2024 23:52, Waldek Hebisch wrote:
> Bart <bc@freeuk.com> wrote:
>> It is suitable for a vast number of programs. I'm sure it could be used 
>> for multi-developer projects too. After all, don't your projects also 
>> place all project-structure info into /one/ makefile? Which developer 
>> has editing rights on that file?
> 
> There are _many_ possible organizations.  Rather typical is one
> Makefile _per directory_.  Most 'make'-s seem to be able to do
> file inclusion, so you may have a single main Makefile that
> includes whatever pieces are necessary.  For example, if somebody
> wanted to add support for your language to gcc, that would need
> creating a subdirectory and putting file called 'Make-lang.in'
> inside.  Make-lang.in is essentially Makefile for your language,
> but it is processed to substitute crucial variable and included
> as part of gcc Makefile.  Of course, you will need more, but
> this covers Makefile part.
> 
>> Who decides what the modules are going to be? If one developer decided 
>> they need a new module, what is the procedure to get that added to the 
>> makefile?
> 
> In open source project normal thing is a patch or a Git pull
> request.  This specifies _all_ needed changes, including Makefile-s
> if there is a need for new module it gets added where needed.
> I one "my" project there can be multiple module in a file, so
> a new module may go to existing file (if it is closely related
> to other module in the file) or to a separate file.  I also needs
> changes to Makefile.
> 
> The above is technical part.  Other is governace of a project.
> If there are multiple developers, then there may be some form
> of review.  Or a developer may be declared to be maintainer of
> given part and allowed changes without review.  'gcc' has several
> "global maintainers", they can change each part and approve
> all changes.  There are maintainers for specific parts, they
> can modify parts they are resposnible for and approve changes
> there, for other parts they need approval.  There are "write
> after approval" people who propose changes but are allowed to
> merge them only after approval from folks in the first two
> groups.  There is also a steering body which votes and
> make decision after.  Some project use some forms of democracy.
> For example, all developers may be considerd equal, but
> any change need aproval from another developer.  In case of
> objections there is a vote.  Some projects have a "dictator"
> of "lead developer" who has final say on anything project-related.
> 
> I have no experience in commercial setups, but IIUC normally
> firms have rules and responsible persons.  Person responible
> for a project divides work and possibly delegates responsibility.
> Firm or project rules may require review, so that other developer
> looks at changes.  There could be design meeting before
> coding.

For "commercial setups" it's as you wrote above: "There are _many_
possible organizations.", so there's no single way to organize
things. One thing that is common (as far as my [naturally limited]
observations go) is that they also use tools that support defining
processes that reflect project structure, responsibilities, and
software and system design, and its organization. For example we
had tools that described and managed the software creation process;
defining a component, defining a [new] release, associating bug
reports and feature requests to releases, open tracks to implement
things (bug-fixes/features), fix-records to track the changes, etc.
and all controlled by a process-framework with dedicated people
responsible or able to do certain tasks. People could check-in
source code, documentation, tests. Actions and state transitions
were bound to access rights (depending on various factors). New
states were notified to responsible people in the process-chain
to enable them to do their work based on new project results,
say to do reviews, or tests, or build a release if preconditions
are all fulfilled.

And there's of course also "supplementary tools"; [hierarchical]
'make' systems for the dependency/creation tasks (libs, docs,
tests, exes), project management and planning systems for the
respective tasks. - I'm sure not all of this will be found in
every commercial project - and, to be honest, I've heard stories
that I wouldn't think be possible in a professional context! -
but typically a huge part of what I described was quite standard
in the commercial contexts I worked in; differences where mainly
only by the chosen tools, and omissions of some details in the
process and grade of automation that were considered unnecessary
in a given context.

So far just off the top of my head; I'm sure I forgot to mention
one or the other (maybe even important) element.

>> [...]
>>
>> However a language at the level of C still appears to be extremely 
>> popular. I guess people like something that is not so intimidating and 
>> that they can feel in command of.
> 
> Hmm, the only language at C level that I know and is popular
> is C.  Ada, COBOL, Fortran, Modula 2, Pascal, PL/I are languages
> that I consider to be at level similar to C.  But AFAIK no of them
> is really popular and in modern time they aim to be higher-level
> than C.  Forth is at lower level and really not that popular.

It seems that Ada and Fortran are still in significant areas in use,
aren't they?

(I wouldn't call that "popular", though, because that word has quite
some [arguable] connotations.)

> [snip rest]

Janis