Re: question about linker

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