On 2024-01-13, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> On 12.01.2024 19:53, bart wrote:
>> On 12/01/2024 18:10, Janis Papanagnou wrote:
>>> On 12.01.2024 18:59, bart wrote:
>>>> On 12/01/2024 16:50, Scott Lurndal wrote:
>>>>>
>>>>> $ cat file.c | cpp | c0 | c1 | c2 | as > file.o
>>>>
>>>> Using ">" on binary content?
>>>
>>> Of course.
>>>
>>>> That seems off.
>>>
>>> Why?
>>
>> Because when you see ">" on a command line, it means redirecting output
>> that would normally be shown as text on a console or terminal.
>
> I propose that you try to give up what you think is "normally" and
> base your knowledge and opinions on facts. Honestly, it will make
> communication generally easier and not make you look like a moron.

He has a point. If a program produces binary data on standard output,
then it will pretty much always have to be redirected.

Usually for programs that produce binary deliverables, you want an
option for standard output. Or perhaps the POSIX - convention: if the
file name given is - (ASCII hyphen), use standard output rather
than opening a file.

In C, standard output (stdio) isn't even a binary stream. It is a text
stream. On Unix that doesn't matter; there is no actual separate text
mode; the "b" modifier of fopen is ignored.

I don't think there is any way to write an ISO C strictly conforming
program which switches stdio to binary mode so that it can reliably
output binary data on standard output on any system. (I'm sure I looked
into this in the past, so if there is a way, I forgot about it.)

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 2024-01-12, bart <bc@freeuk.com> wrote:
> I see. So forget just having intuitive behaviour. Or even behaviour that
> is compatible with related tools, so that:
>
> gcc -c file1.c produces file1.o
> gcc -c file1.c file2.c produces file1.o file2.o
>
> but:
>
> as file1.s produces a.out
> as file1.s file2.s produces a.out

Few people invoke "as" directly. It is not intended for human use,
regardless of how it is invoked.

You can invoke gcc on .s files:
gcc -c file1.s # file1.o pops out

gcc is a compiler driver, not a compiler; it reacts to suffixes.

If you change the suffix to .S, then gcc will run the C preprocessor on
the file. This can be very useful.

Besides being able to use include files, macros and conditionals,
one obvious benefit of that is that you get standard comment syntax.

Different targets of GNU as have different commenting conventions!!!
And this is for compatibility reasons with other assemblers for those
platforms.

Using C preprocessing, it's possible to make one source file work with
different implementations of as that use different assembly language
syntax: like if it happens that there is a proprietary as that has
different syntax from GNU as.

> You guys all deserve medals for being so tolerant.

By now you've almost wasted more keystrokes complaining about how some
command lines require several more tokens than they should, than you
will ever save in your entire lifetime by actually using your preferred
shorter command lines.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 1/12/2024 8:46 PM, Kaz Kylheku wrote:
> On 2024-01-12, bart <bc@freeuk.com> wrote:
>> I see. So forget just having intuitive behaviour. Or even behaviour that
>> is compatible with related tools, so that:
>>
>> gcc -c file1.c produces file1.o
>> gcc -c file1.c file2.c produces file1.o file2.o
>>
>> but:
>>
>> as file1.s produces a.out
>> as file1.s file2.s produces a.out
>
> Few people invoke "as" directly. It is not intended for human use,
> regardless of how it is invoked.

Fwiw, I had to use GAS to assemble my sync code. MASM over on in the
windows world. Then C++11 came out. Ahhhh!

[...]

On 1/12/2024 8:52 PM, Chris M. Thomasson wrote:
> On 1/12/2024 8:46 PM, Kaz Kylheku wrote:
>> On 2024-01-12, bart <bc@freeuk.com> wrote:
>>> I see. So forget just having intuitive behaviour. Or even behaviour that
>>> is compatible with related tools, so that:
>>>
>>>      gcc -c file1.c           produces file1.o
>>>      gcc -c file1.c file2.c   produces file1.o file2.o
>>>
>>> but:
>>>
>>>      as     file1.s           produces a.out
>>>      as     file1.s file2.s   produces a.out
>>
>> Few people invoke "as" directly. It is not intended for human use,
>> regardless of how it is invoked.
>
> Fwiw, I had to use GAS to assemble my sync code. MASM over on in the
> windows world. Then C++11 came out. Ahhhh!
>
> [...]

AT&T syntax vs Intel:

https://youtu.be/A3Qc-2j-6Gc

lol...

On 1/12/2024 8:52 PM, Chris M. Thomasson wrote:
> On 1/12/2024 8:46 PM, Kaz Kylheku wrote:
>> On 2024-01-12, bart <bc@freeuk.com> wrote:
>>> I see. So forget just having intuitive behaviour. Or even behaviour that
>>> is compatible with related tools, so that:
>>>
>>>      gcc -c file1.c           produces file1.o
>>>      gcc -c file1.c file2.c   produces file1.o file2.o
>>>
>>> but:
>>>
>>>      as     file1.s           produces a.out
>>>      as     file1.s file2.s   produces a.out
>>
>> Few people invoke "as" directly. It is not intended for human use,
>> regardless of how it is invoked.
>
> Fwiw, I had to use GAS to assemble my sync code. MASM over on in the
> windows world. Then C++11 came out. Ahhhh!
>
> [...]

Damn C11 has atomics but no threads over on Windows wrt current MSVC.
They have a nice support for C++11, but they left C11 in the dark.
Actually, I only know of one compiler that has atomics, membars and
threads, and that is:

http://www.smorgasbordet.com/pellesc

Know of any others with 100% full support for C11?

When C++11 came out, it was an interesting time for me because I got to
port some of my asm sync code over to standard C++. It was a good time:

https://youtu.be/OlbE0urutpM

;^)

On 12.01.2024 22:01, bart wrote:
> On 12/01/2024 18:02, Janis Papanagnou wrote:
>> On 12.01.2024 18:09, bart wrote:
>>> On 12/01/2024 16:34, David Brown wrote:
>>>>>
>>>>> It looks like 'make' is competing with 'bash' then!
>>
>> Why don't you just read about those two tools and learn, instead
>> of repeatedly spouting such stupid statements of ignorance.
>
> Because I've repeatedly said I don't need them. Why can't you accept that?

Oh, I accept that. - But then I also expect that you don't spread
uninformed nonsense.

>
> How about YOU learn how to build software without those tools?

You're continuing to make silly and stupid statements. - I thought
(given you know DEC and CP/M) you are not a child any more, yet
behave so.

What makes you think that I wouldn't be able to do trivialities?

>
>> It's a _simple_ tool - not complex, as you've previously posted -
>> where you can define dependencies of entities, and define commands
>> that create the targets if entities that are required by the target
>> had changed. Its basic syntax and also its logic is simple,
>
>
>> And this is a crucial feature; for professional non-trivial projects.
>
> Come on then, tell me how big your projects are. Are they bigger than
> Scott Lurndal's 10Mloc example? (Which seems to be mostly Python source
> code.)

Again playing childish? ("Mine is bigger that yours", sort of?)

If you're interested what I actually do and have done, I can tell
you. (Not that it would address or solve any inherent issue *you*
obviously have.)

The past decade (or so) "my" personal projects were only private
hobbies, i.e. small toy-projects from a couple lines to a couple
thousand lines. But I when I speak about "professional software
engineering" I am rather speaking about the professional projects.

Some outline; I was engaged in projects of various sizes. I don't
recall the (not very significant) LOC numbers; these were anyway
only in one case relevant, in a refactoring project of a large
software component (used by at that time 1000+ software companies
for their products, and at that time by nearly 20 million people
in our country). The projects that I led myself or was member of
ranged from a handful on-site persons to many hundreds persons
spread across several sites and even different companies. And
the development durations from very short ranges up to years. The
areas for which the various software projects was developed were;
for the big telecommunication companies (e.g. BT, Dt. Telekom),
for the financial sector, for the state government). We used local
tools for our site(s), and also collaborative tools. The source
code or libraries were partly imported by collaborating companies,
locally they were spread across various project component file
systems. It had been tens thousands of files (I don't recall the
exact number) and millions of lines of code (dito.). Everyone in
the project was able to work on any of the sub-projects or parts,
no specific knowledge (say, about compiler or library versions)
was necessary by the individual member. Make was a standard tool
almost everywhere. Other tools as well; configuration management,
version control, test environments, project management tools, etc.

These were all professional software projects, as opposed to my
(or your) toy projects.

>
>>>
>>> That is something I've never needed done automatically in my own work (I
>>> do it manually as I will know my projects intimately when I'm working
>>> with them).
>>
>> Yes, we know. You've repeatedly shown that you are actually doing
>> small one-man-shows in projects that I can only call toy-projects.
>
> This is incredibly patronising.

I was merely pointing out that you explained yourself (a couple
of times) what sort of projects you are working on; I just named
them toy-projects to make apparent to you where we need a more
professional approach, and that you only address with your view
your personal small isolated programming bubble. It's still quoted
above with context, here again (for example):
"I will know my projects intimately when I'm working with them"
and you also mentioned I think more than once that you work alone.
You might admit that this sort of manageable programming is very
different from professional projects (as I depicted some above).

>
> What is wrong with one-man projects?

There's nothing wrong with them. (I said above that privately I
also do such "projects".) At some point of project complexity you
are advised to handle it more professionally, though. And that is
usually supported by sophisticated project tools and environments.

>
> What is wrong with writing non-professional software? Is that the same
> as non-commercial?

(The question is IMO quite irrelevant, not worth discussing.)

>
> Where is the line between a toy project and a non-toy project? Is it
> related to how lines or how many modules an application might have, or
> the size of the final binaries?
>
> Is it to do with the number of end-users?

There are a couple factors that you may also derive from above.
(Beyond that it's not worth discussing where one ends or the other
begins.)

It's worth to understand, though, that 'make' is not a complex or
unnecessary tool. If you understand its (simple) concept you can
(but don't need to) also use it for your small projects. You only
gain something, not lose anything; once you've overcome the barrier
of acceptance for a probably unknown or unfamiliar tool it's really
nice. (For example I maintain a dvds.csv file and generate a HTML
page for it that I then upload; why not put the generation process
commands and the simple dependencies in a Makefile and just call
'make' and/or 'make install'? - I have tons of little toy-projects
and instead of having everything in mind I have it either in a
Makefile or in a small shell script that occasionally gets into a
Makefile, so that I only need to do a 'make' in whatever context
I actually am.)

It should have meanwhile become obvious that no one forces you to
use Makefiles. And that there's also nothing to say again one's
toy-projects. - Only you cannot derive from such primitive cases
about the sensibility of useful (and even necessary) tools and be
constantly whining and complaining about them only because you
don't see the gain you have with the tools. And that you don't
know them and badmouth them doesn't make it easier to discuss;
you should at least inform yourself if you feel the need to piss
on well established tools.

>
> [...]
>
>
>> Professional projects have a different situation in many respects.
>> (I don't go into detail here, since you're anyway only interested
>> in your local comfort zone.)
>
> No, don't. I assume you've got some hugely complicated app with a
> million moving parts.

You again expose your habit to wrongly "assume" (= to make up)
things just because you don't understand the topic lack the
experience and avoid the facts.

> It's so big that nobody knows what's what. Your
> compilers are so slow that you HAVE to use dependencies to avoid
> spending 90% of the day twiddling your thumbs.

Clueless as you are you are not in the position to be cynical.

In the industry where I've done my professional projects we had
no slow computers. But we had also no toy-projects. Yes, some of
the (full!) compile runs lasted many hours; companies just cannot
afford that waste of time if you compile everything only because
you have no professional computer scientists that know how things
have to be done more sophisticated to reduce time. If you manage
the dependencies you can reduce the effort to compile a software
system to minutes if not seconds. - Ignoring this simple fact is
not only unprofessional, it's plain stupid.

>
> That's a million miles from the stuff I do, yet you still insist /I/
> should be using all the same complicated tools you do.

Despite you have repeatedly been told by many posters you still
repeat that nonsense. - No one said you should be using it. Are
you so pathological that you don't get it?

> [...]
>
> Let me tell about my own tools:

(You constantly do and no one cares.)

> [...]
>
> So, now tell me where the hell 'makefiles' would fit into that scenario.

It's answered above by me as an experience report and suggestion
to consider. It's (only) up to you to take action or ignore it.

>
> Just accept that some of this stuff is out of /your/ comfort zone.

You actually know nothing about my "comfort zone"; as opposed to
you I wasn't repeatedly complaining about this or that.

On 13.01.2024 05:31, Kaz Kylheku wrote:
>
> [...] If a program produces binary data on standard output,
> then it will pretty much always have to be redirected. [...]

The problem with that view is; what is a binary?

I have a *.c source code that contains literal UTF-8 characters.
If I 'cat' that file to the terminal I either see these UTF-8
characters or gibberish, depending on how I set up the terminal.

Unix is (almost) transparent WRT "binary" representations.

Similar with the file system. Are file names in other encodings
than ASCII (or any of the 8-bit extensions) binary? (It only
handles '\0' and '/' differently but the rest transparent.)

Janis

On 13/01/2024 04:17, Kaz Kylheku wrote:
> On 2024-01-13, bart <bc@freeuk.com> wrote:
>> On 13/01/2024 00:47, Keith Thompson wrote:
>>> bart <bc@freeuk.com> writes:
>>
>>> It happens that once you have a working Makefile, it works equally
>>> well either to rebuild a project after a single change, or to build
>>> an entire project from scratch. Someone could probably create
>>> a simpler version of "make" that doesn't look at dependencies,
>>> and that always rebuilds everything. Such a tool would be worse
>>> than "make" for building projects during development, and not
>>> significantly better than "make" for building projects from scratch.
>>>
>>> And that's ignoring the "-j" option, which allows "make" to execute
>>> multiple steps in parallel. That works only because "make" knows
>>> about dependencies, and it can result in a full build from scratch
>>> finishing much more quickly. A simple script that just compiles
>>> each file isn't likely to do that. You can typically specify a
>>> maximum number of parallel jobs equal to the number of CPUs on your
>>> build system, e.g., `make -j $(nproc)`.
>>
>> That's a reasonable thing to do. But how does make do it? Can't a
>> compiler apply the same approach if N files have been submitted?
>
> Yes. And in fact, languages with good module support like Modula-2
> don't need external make utilities.

Finally somebody admitting that some languages may not need make as much.

My language from 25 years ago didn't have compiler-supported modules but
projects were structured in a certain way: all modules shared the same
project-wide header file (which could group other headers).

So a change in one module required compiling only that module. A change
in a header usually required all modules to be recompiled. (Including
the headers: in this scheme, they could contain their own code and
functions which existed in an separate, outer scope.)

If I'd used 'make', the dependency graph would only have told me what I
already knew.

My current language has language- and compiler-supported modules, but is
designed for whole-program compilation and is very fast as previously
stated.

Modules can be grouped into sub-programs, and very large programs could
turn those into dynamic libraries that are compiled separately, but I'm
a long way from needing to do that.

>>
>> After all C allows independent compilation of modules. (Something my
>> language doesn't have; there the granularity is an EXE file, not a module.)
>
> C has no specific syntax for expressing modules. It has translation
> units, with preprocessor header files used for interfacing.

OK, independent compilation of translation units. It has header/include
files which can recursively include other headers, and that can be
shared in an ad hoc manner across multiple translation units.

A large program needs selective and parallel compilation more,
especially as people prefer slow compilers for C.

Since if you have 50 modules (translation units) and each uses the same
giant header files (GTK, windows etc), those headers will normally be
processed 50 times.

In my current language that would only be done once (and using a
condensed form of those APIs which is a fraction the size of the C headers).

> A C compiler could, instead of emitting makefile fragments, keep
> the dependency information in some repository which it itself
> understands, in order to recompile what is necessary.
>
> Only problem is that that compiler would be reimplementing most of make,
> probably badly, and every other similar compiler would have to do the
> same in order to have the same benefit.

We're now talking about the part of make which is about building what I
call a 'program unit': a single EXE or DLL file in Windows terms. (In my
stuff, that can include a single OBJ representing multiple modules.)

I feel this stuff is ideally done in the compiler. But the nature of C
makes that awkward to do. How does gcc, say, have any idea of the extent
of a program? It might not use a shared header to link a distant module
to the rest. And if you do:

gcc hello.c hello.c

it only has an indication that something is wrong when it tries to link
and there are two 'main' functions being exported.

This can be tackled by organising projects according to guidelines, but
it is still largely C from 1972.

On 13/01/2024 05:54, Janis Papanagnou wrote:
> On 12.01.2024 22:01, bart wrote:

>> Come on then, tell me how big your projects are. Are they bigger than
>> Scott Lurndal's 10Mloc example? (Which seems to be mostly Python source
>> code.)
>
> Again playing childish? ("Mine is bigger that yours", sort of?)

No. I know that my projects are very small compared to some in the
industry. The sizes of OSes and all sorts of apps tell me that.

I was interested in where you draw the line.

(This is the same with every kind of product. Some companies produce a
787 airliner with 5 million components, others make a plastic comb with
just one.)

Some 90% of the binaries in my Windows 11 OS are under 1MB. Each of
those forms a 'program unit' which is what my comments about 'building'
are about: how to compile the multiple source files into one binary.

Beyond that you get the problems of creating large 'systems' which is
what you seem to be into.

For the first, I don't rate the use of 'make', not with the designs I've
made in languages and compilers.

For the other, the use of make seems archaic.

> If you're interested what I actually do and have done, I can tell
> you. (Not that it would address or solve any inherent issue *you*
> obviously have.)
>
> The past decade (or so) "my" personal projects were only private
> hobbies, i.e. small toy-projects from a couple lines to a couple
> thousand lines. But I when I speak about "professional software
> engineering" I am rather speaking about the professional projects.
>
> Some outline; I was engaged in projects of various sizes. I don't
> recall the (not very significant) LOC numbers; these were anyway
> only in one case relevant, in a refactoring project of a large
> software component (used by at that time 1000+ software companies
> for their products, and at that time by nearly 20 million people
> in our country). The projects that I led myself or was member of
> ranged from a handful on-site persons to many hundreds persons
> spread across several sites and even different companies. And
> the development durations from very short ranges up to years. The
> areas for which the various software projects was developed were;
> for the big telecommunication companies (e.g. BT, Dt. Telekom),
> for the financial sector, for the state government). We used local
> tools for our site(s), and also collaborative tools. The source
> code or libraries were partly imported by collaborating companies,
> locally they were spread across various project component file
> systems. It had been tens thousands of files (I don't recall the
> exact number) and millions of lines of code (dito.). Everyone in
> the project was able to work on any of the sub-projects or parts,
> no specific knowledge (say, about compiler or library versions)
> was necessary by the individual member. Make was a standard tool
> almost everywhere. Other tools as well; configuration management,
> version control, test environments, project management tools, etc.
>
> These were all professional software projects, as opposed to my
> (or your) toy projects.

OK, thanks. So this is more like you working for a large organisation,
having extensive premises, perhaps multiple sites, HR departments,
finance, sales, managers, directors, receptionists ...

While some people like me have worked for a small company of 10 or 20
people. I was also self-employed for a decade. In both cases
professional work was done with real, paying customers, just like a
million such small businesses. We sold products in a half a dozen countries.

You might appreciate then that in a small organisation things might be
done differently, more simply, with fewer overheads and more informally.

This can also mirror what happens with software projects. Most
open-source software I've wanted to build has been on the scale of a
small business or even a one-man operation.

Yet next to their small premises is a giant office-block containing all
the auto-config and makefile stuff that you are obliged to deal with if
you want to use their product.

>> What is wrong with one-man projects?
>
> There's nothing wrong with them. (I said above that privately I
> also do such "projects".) At some point of project complexity you
> are advised to handle it more professionally, though. And that is
> usually supported by sophisticated project tools and environments.

My situation is different: I created my own languages, working tools and
environment. I've always made it a part of development, to ensure a fast
development cycle and to be productive.

Complexity was kept under control. Projects were necessarily small
(because it was just me, but also because of limited machine resources).

> It's worth to understand, though, that 'make' is not a complex or
> unnecessary tool. If you understand its (simple) concept you can
> (but don't need to) also use it for your small projects.

If I was to use 'make', I would have to implement it myself. This I once
started to do, until I started reading the manual, and it went on for
ever. I then disliked it even more.

> You only
> gain something, not lose anything; once you've overcome the barrier
> of acceptance for a probably unknown or unfamiliar tool it's really
> nice. (For example I maintain a dvds.csv file and generate a HTML
> page for it that I then upload; why not put the generation process
> commands and the simple dependencies in a Makefile and just call
> 'make' and/or 'make install'? - I have tons of little toy-projects
> and instead of having everything in mind I have it either in a
> Makefile or in a small shell script that occasionally gets into a
> Makefile, so that I only need to do a 'make' in whatever context
> I actually am.)

It sounds like a classic 'hammer and nail' scenario. (If your only tool
is a hammer, every task looks like a nail.)

> It should have meanwhile become obvious that no one forces you to
> use Makefiles.

That is actually not true. Clearly, I don't use them for my own stuff.

But sometimes I want to build what ought to be a straightforward
program, but the necessary info is hidden inside a makefile.

Or in the case of LIBJPEG, inside 15 makefiles, one for each compiler
(for that famously portable language known as C).

However, one was a generic makefile which I was able to use, in a rare
case of make actual working.

I was then able to capture the commands generated, and so determine what
the relevant files were.

This was somewhat complex as it first produced libraries in the form of
..a files, which were then used with further .c for building multiple EXEs.

All /I/ needed are the list of C files to submit to a compiler for each
program. Here, 'make' was just one huge obstacle. Why don't the docs
just list the relevant files (as well the makefiles)?

> And that there's also nothing to say again one's
> toy-projects.

LIBJPEG is not up there were your huge professional product, but it is
hardly a toy. It could easily have been one of the libraries you used.
(It's just rather over the top for a JPEG encoder/decoder!)

> In the industry where I've done my professional projects we had
> no slow computers. But we had also no toy-projects. Yes, some of
> the (full!) compile runs lasted many hours

So you had slow compilers. Either that or your product was huge.

A fast compiler like tcc can generate 10MB of binaries per second per
core (even on my slow PC).

Running it for one hour would create a 36GB binary.

OK, your compilers will do more analysis and will optimise, but it still
sounds slow. No wonder you have to use make!

I take it there was no one whose job it was to overview the efficiency
of the overall process. But presumably changing languages and tools or
even just overhauling the software to remove cruft was out of the question.

However, unless the end product was one monolithic binary, you'd be able
to parallelise some processes - or was that already done and it still
took hours?

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>bart <bc@freeuk.com> writes:
>> On 13/01/2024 00:47, Keith Thompson wrote:
>>> bart <bc@freeuk.com> writes:
>>
>>> It happens that once you have a working Makefile, it works equally
>>> well either to rebuild a project after a single change, or to build
>>> an entire project from scratch. Someone could probably create
>>> a simpler version of "make" that doesn't look at dependencies,
>>> and that always rebuilds everything. Such a tool would be worse
>>> than "make" for building projects during development, and not
>>> significantly better than "make" for building projects from scratch.
>>> And that's ignoring the "-j" option, which allows "make" to execute
>>> multiple steps in parallel. That works only because "make" knows
>>> about dependencies, and it can result in a full build from scratch
>>> finishing much more quickly. A simple script that just compiles
>>> each file isn't likely to do that. You can typically specify a
>>> maximum number of parallel jobs equal to the number of CPUs on your
>>> build system, e.g., `make -j $(nproc)`.
>>
>> That's a reasonable thing to do. But how does make do it? Can't a
>> compiler apply the same approach if N files have been submitted?
>
>I've never looked into it.
>
>I suppose it could be done, but IMHO compilers are complex enough
>without adding logic to perform parallel compilations, especially since
>"make" already solves that problem.

The most common example of submitting N files for compilation
in a single compile command would be java.

Even then, it wasn't sufficient, so ant was developed.

https://ant.apache.org/

scott@slp53.sl.home (Scott Lurndal) writes:
>Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>bart <bc@freeuk.com> writes:
>>> On 13/01/2024 00:47, Keith Thompson wrote:
>>>> bart <bc@freeuk.com> writes:
>>>
>>>> It happens that once you have a working Makefile, it works equally
>>>> well either to rebuild a project after a single change, or to build
>>>> an entire project from scratch. Someone could probably create
>>>> a simpler version of "make" that doesn't look at dependencies,
>>>> and that always rebuilds everything. Such a tool would be worse
>>>> than "make" for building projects during development, and not
>>>> significantly better than "make" for building projects from scratch.
>>>> And that's ignoring the "-j" option, which allows "make" to execute
>>>> multiple steps in parallel. That works only because "make" knows
>>>> about dependencies, and it can result in a full build from scratch
>>>> finishing much more quickly. A simple script that just compiles
>>>> each file isn't likely to do that. You can typically specify a
>>>> maximum number of parallel jobs equal to the number of CPUs on your
>>>> build system, e.g., `make -j $(nproc)`.
>>>
>>> That's a reasonable thing to do. But how does make do it? Can't a
>>> compiler apply the same approach if N files have been submitted?
>>
>>I've never looked into it.

And it's rather irrelevent, as make handles projects with multiple
languages as well as projects which generate compilable collateral
during the build process.

The project that I posted about earlier has python elements, C
elements, C++ elements and some custom shell scripts to generate
header files used by the C and C++ elements. All of this
is sequenced (dependency graph) by the make utility and to
the extent possible, uses all the hardware resources available
with parallel job submission (subject to dependency constraints).

And the jobs need not be submitted locally, they can be easily
farmed out to hundreds of hosts in a grid environment.

bart <bc@freeuk.com> writes:
> On 13/01/2024 04:17, Kaz Kylheku wrote:
>> On 2024-01-13, bart <bc@freeuk.com> wrote:
[...]
>>> That's a reasonable thing to do. But how does make do it? Can't a
>>> compiler apply the same approach if N files have been submitted?
>> Yes. And in fact, languages with good module support like Modula-2
>> don't need external make utilities.
>
> Finally somebody admitting that some languages may not need make as much.

Bart, seriously, what the hell are you talking about?

It's true that some languages don't need "make" as much as C does.

Nobody here has said otherwise, likely because other languages are
largely off-topic here in comp.lang.c.

By all means, don't use "make". Nobody wants you to use it. Nobody
thinks you need to care how it works.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On 13/01/2024 21:42, Keith Thompson wrote:
> bart <bc@freeuk.com> writes:
>> On 13/01/2024 04:17, Kaz Kylheku wrote:
>>> On 2024-01-13, bart <bc@freeuk.com> wrote:
> [...]
>>>> That's a reasonable thing to do. But how does make do it? Can't a
>>>> compiler apply the same approach if N files have been submitted?
>>> Yes. And in fact, languages with good module support like Modula-2
>>> don't need external make utilities.
>>
>> Finally somebody admitting that some languages may not need make as much.
>
> Bart, seriously, what the hell are you talking about?
>
> It's true that some languages don't need "make" as much as C does.
>
> Nobody here has said otherwise, likely because other languages are
> largely off-topic here in comp.lang.c.

Except 'make'? I get the impression that most programs written in C have
a large component written in 'make' too. A component you can't always
ignore since essential build info is encoded in it.

In the case of the GMP project that came up, a language purportedly
written in C, it seemed to depend on auto-config, make, bash, m4, awk,
gcc-options and god knows what else.

It would be ironic that, if I was to write an application in C, it would
be 100% C with no other language involved. Not even any compiler options
(not with my compiler anyway).

I think I'd be the only one here doing that!

(I wonder: are people here so addicted to 'make' that they don't
actually know how to describe a project without it?)

>
> By all means, don't use "make". Nobody wants you to use it.

Lots of people are saying I'm not being forced to, for example:

JP:
> It should have meanwhile become obvious that no one forces you to
> use Makefiles.

JP:
> - No one said you should be using it.

But who then strongly hint that I should be using it:

JP:
> Why don't you just read about those two tools and learn

JP:
> It's very interesting that despite your very small and restricted
> experience you'd decide to follow the "not invented here" principle
> instead of using long established, refined, and well accepted tools
> that are already available (and even for free), and reliably work.

(Well, I'm not a sheep. And when I started out, I /had/ to invent stuff
because it wasn't otherwise available. Doing so I made a discovery: it
worked great! )

------------------------
Here are some additional comments for everybody (KT can stop reading).

This is my simpified view of software development, split into four broad
activities:

N = 1 | N > 1
-------------------------------
| | |
Developer | (A) | (C) |
| | |
-------------------------------
| | |
Final | (B) | (D) |
| | |
-------------------------------

N
This is the number of program units that are involved. A unit
is a single binary file (eg. EXE or DLL on Windows).

Developer

This is the work done by a developer on a daily basis, eg.
editing, compiling and testing the same project 100 times a day.

Final

This relates to a one-time build of the project, usually of
some working version. It may be done remotely by someone
else, working from source code.

Here is how /I/ usually deal with those different scenarios:

(A) I use two tools: a compiler, and a simple IDE. They both work from
a simple list of source and support files.

(B) This is the same as (A) but stripped down: only a compiler is
used. There may be a minimal, flat, set of files. Multiple source
files are sometimes converted to one monolithic file for less
hassle.

(C) and (D) I'm not going to go into these. The requirements are
going to be too diverse. Anyone who's a programmer will know how to
organise this stuff.

So, as I understand what everybody else as been saying about how they
work, it seems to looks like this:

(A) The primary tool is make.

(B) The primary tool is make.

(C) The primary tool is make.

(D) The primary tool is make.

(Nobody here has mentioned IDEs, but that is a personal choice that
shouldn't be foisted on anyone else. Everyone is big on make though.)

When I want to build someone else's open source project, I would prefer
to get (B) or (D). I nearly always get (A) or (C). And with 'make',
which on Windows, often doesn't work.

So, make is being used not just as a substitute build system when
creating ONE executable file. But it is also used to do everything else.
I see that as a mistake.

On 1/13/24 23:39, bart wrote:

> It would be ironic that, if I was to write an application in C, it would
> be 100% C with no other language involved. Not even any compiler options
> (not with my compiler anyway).

Is your application can be compiled on Linux, OpenBSD, Solaris,
HP-UX, FreeBSD, AIX, MacOSX and a few others commonly used
operating system ?

--
+---------------------------------------------------------------------+
| https://tube.interhacker.space/a/tth/video-channels |
+---------------------------------------------------------------------+

bart <bc@freeuk.com> writes:
> On 13/01/2024 21:42, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
>>> On 13/01/2024 04:17, Kaz Kylheku wrote:
>>>> On 2024-01-13, bart <bc@freeuk.com> wrote:
>> [...]
>>>>> That's a reasonable thing to do. But how does make do it? Can't a
>>>>> compiler apply the same approach if N files have been submitted?
>>>> Yes. And in fact, languages with good module support like Modula-2
>>>> don't need external make utilities.
>>>
>>> Finally somebody admitting that some languages may not need make as much.
>> Bart, seriously, what the hell are you talking about?
>> It's true that some languages don't need "make" as much as C does.
>> Nobody here has said otherwise, likely because other languages are
>> largely off-topic here in comp.lang.c.
>
> Except 'make'? I get the impression that most programs written in C
> have a large component written in 'make' too. A component you can't
> always ignore since essential build info is encoded in it.

Most? I don't know. Many? Sure.

You wrote, "Finally somebody admitting that some languages may not need
make as much.". Has anyone here claimed otherwise? If not, why do you
find Kaz's statement so remarkable?

You repeatedly react strongly to things nobody said. You invent
strawman arguments.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On 13/01/2024 23:26, Keith Thompson wrote:
> bart <bc@freeuk.com> writes:
>> On 13/01/2024 21:42, Keith Thompson wrote:
>>> bart <bc@freeuk.com> writes:
>>>> On 13/01/2024 04:17, Kaz Kylheku wrote:
>>>>> On 2024-01-13, bart <bc@freeuk.com> wrote:
>>> [...]
>>>>>> That's a reasonable thing to do. But how does make do it? Can't a
>>>>>> compiler apply the same approach if N files have been submitted?
>>>>> Yes. And in fact, languages with good module support like Modula-2
>>>>> don't need external make utilities.
>>>>
>>>> Finally somebody admitting that some languages may not need make as much.
>>> Bart, seriously, what the hell are you talking about?
>>> It's true that some languages don't need "make" as much as C does.
>>> Nobody here has said otherwise, likely because other languages are
>>> largely off-topic here in comp.lang.c.
>>
>> Except 'make'? I get the impression that most programs written in C
>> have a large component written in 'make' too. A component you can't
>> always ignore since essential build info is encoded in it.
>
> Most? I don't know. Many? Sure.
>
> You wrote, "Finally somebody admitting that some languages may not need
> make as much.". Has anyone here claimed otherwise? If not, why do you
> find Kaz's statement so remarkable?

People have suggested using make for everything, from hello.c up to JP's
and SL's massive applications.

They have suggested using it for any language and even stuff which is
program code.

I've certainly seen makefiles associated with most open source apps I've
looked up.

So, yes, it was refreshing that someone admitted that a language didn't
need it. (I've tried saying so about mine, but people either don't
believe me, ignore it, or dismiss it.)

On 13/01/2024 05:54, Janis Papanagnou wrote:

> It's very interesting that despite your very small and restricted
> experience

I don't agree. My experience has spanned mainframes, minicomputers and
generations of microprocessors.

I designed and built 8-bit and 16-bit machines and video boards from
components. I've programmed them from nothing, even bootstrapping my
first HLL starting from binary machine code, via hex and assembly
through to a compiler.

Throughout the 80s I wrote endless drivers, graphics libraries, GUI
libs, FP emulation, maths libs, took care of fonts, invented image file
formats, and started writing GUI applications and scripting languages.

Not one line was written in any other language.

I believe it was quite remarkable to make money from commercial projects
using a complete 'full stack' toolset written 100% by me and in 100% my
languages.

> you'd decide to follow the "not invented here" principle
> instead of using long established, refined, and well accepted tools
> that are already available (and even for free), and reliably work.

It wasn't really a choice at first. C compilers for microprocessors c.
1982 were hopelessly slow, and that's if it they could somehow be got
into our machines since every 8-bit computer used a different disk format.

They were also expensive, and I wasn't even a programmer so no one was
going to pay for it.

Besides, I'd looked in The C Programming Language, and thought it was
dreadful. I perservered with my own language which compiled in a second
or two rather than minutes.

I've never looked back.

It's no secret here that I don't like C, but I sometimes need to use
some libraries which come as C source. But for those (the ones where I
can crack the makefile encryption!), I have my private C compiler to
generate binaries. Isn't that something?

Sometimes you need to go against the flow. Some innovative products have
come about from people deciding to do their own thing. Mine however are
personal tools.

I already know you're going to reply to this, if at all, with a big
<SNIP> and a comment 'Nobody Cares'.

Jealous any? I wouldn't swap places with you or your apps that can take
hours to build. IMV somebody is doing something wrong.

(This is my current 2024 set of language tools:

https://github.com/sal55/langs/blob/master/CompilerSuite.md

There is no 'make'. It is utterly pointless here.)

On 12/01/2024 21:31, Kaz Kylheku wrote:
> On 2024-01-12, bart <bc@freeuk.com> wrote:

>> I mainly remember the times when they do hang.
>
> DOS/Windows stuff hangs also:
>
> C:\Users\kazk>findstr foo
> ... "hang" ...
>
> Even Microsoft clued in to the idea that a text filter shouldn't
> spew extraneous diagnostics by default.

If you type 'findstr' with no arguments, it reports an error. Maybe
'sort' was a better example to make your point.

>> But with 'as', it just sits there. I wonder what it's waiting for; for
>> me to type in ASM code live from the terminal? (If 'as' is designed for
>> piped-in input, tdm/gcc doesn't appear to use that feature as I remember
>> it generating discrete, temporary .s files.)
>
> gcc -pipe works in pipe mode.
>
> The "as" command is intended for compiler use; not only is it not
> an interactive assembler, it doesn't even have particularly good
> diagnostics for batch use. You have to know what you're doing.

You're sort of making excuses for it. My 'aa' assembler was also
designed mainly for machine-generated code, so it has very few frills.

The syntax however is decent enough that I can use it for my inline
assembler too.

The way it works is also conventional: it takes .asm files as input and
produces a file as output. It doesn't call every output 'a.out'!

But that CLI is part of the lead module.

By leaving that out, the remaining modules can statically compiled
(embedded) into another application. That can invoke the assembler via
this function:

export func assembler(
ichar outputfile,
ref[]ichar asmfiles, dllfiles,
int nasmfiles, ndllfiles, fobj, fdll, fcaption,
ref[]ichar assemsources = nil,
ichar entrypointname)int =

which takes 10 arguments. I'd sort of wondered how some of that info is
imparted to 'as' when the only input is a single string.

(This manages N asm inputs and L libraries. Sources can come from files,
or from in-memory strings, to avoid having to write out ASM files.
Output will be a single EXE, DLL or OBJ file.)

aa.exe is about 0.1MB; as.exe is 1.5MB.

On 13/01/2024 23:02, tTh wrote:
> On 1/13/24 23:39, bart wrote:
>
>> It would be ironic that, if I was to write an application in C, it
>> would be 100% C with no other language involved. Not even any compiler
>> options (not with my compiler anyway).
>
>    Is your application can be compiled on Linux, OpenBSD, Solaris,
>    HP-UX, FreeBSD, AIX, MacOSX and a few others commonly used
>    operating system ?

I'm not suggesting that it will be 100% portable, just that it will
involve no tools other than a C compiler.

But if it is C code, and is either a pure library, or only does console
or file i/o, then why not?

bart <bc@freeuk.com> writes:
>On 13/01/2024 23:26, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
>>> On 13/01/2024 21:42, Keith Thompson wrote:
>>>> bart <bc@freeuk.com> writes:
>>>>> On 13/01/2024 04:17, Kaz Kylheku wrote:
>>>>>> On 2024-01-13, bart <bc@freeuk.com> wrote:
>>>> [...]
>>>>>>> That's a reasonable thing to do. But how does make do it? Can't a
>>>>>>> compiler apply the same approach if N files have been submitted?
>>>>>> Yes. And in fact, languages with good module support like Modula-2
>>>>>> don't need external make utilities.
>>>>>
>>>>> Finally somebody admitting that some languages may not need make as much.
>>>> Bart, seriously, what the hell are you talking about?
>>>> It's true that some languages don't need "make" as much as C does.
>>>> Nobody here has said otherwise, likely because other languages are
>>>> largely off-topic here in comp.lang.c.
>>>
>>> Except 'make'? I get the impression that most programs written in C
>>> have a large component written in 'make' too. A component you can't
>>> always ignore since essential build info is encoded in it.
>>
>> Most? I don't know. Many? Sure.
>>
>> You wrote, "Finally somebody admitting that some languages may not need
>> make as much.". Has anyone here claimed otherwise? If not, why do you
>> find Kaz's statement so remarkable?
>
>People have suggested using make for everything, from hello.c up to JP's
>and SL's massive applications.

You are again ascribing words to people. People have pointed out
to you that make can be used for a number of purposes.

They've not suggested that you -use- make yourself.

>
>They have suggested using it for any language and even stuff which is
>program code.

No, they've _stated_ that it can be used for any language or stuff
which is _not_ program code. That's just a plain and simple fact.

bart <bc@freeuk.com> writes:

[...]

> While 'make' conflates several kinds of processes: [...]

make doesn't conflate these different applications, any
more than 'cat' "conflates" different kinds of files.
They simply are general tools with a broad range of
applicability. The idea that the applications listed
are in some way inherently different shows only the
limitations of your thinking, not any essential truth
about make.

bart <bc@freeuk.com> writes:

> On 12/01/2024 19:15, Scott Lurndal wrote:
[...]
>> What the FM documents. RTFM.
>
> I see. So forget just having intuitive behaviour. [...]

The problem is not what the behavior is. The problem is
with your intuition about what the behavior should be.

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Bart <bc@freeuk.cm> writes:
[...]

> I've told you (multiple times, for *years*) how to invoke gcc in
> ISO C conforming mode *if that's what you want*.

By my reckoning, for more than five years. Do you think it might
be time to give up on the idea that he will ever hear you?

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> bart <bc@freeuk.com> writes:
[...]

> You repeatedly react strongly to things nobody said. You invent
> strawman arguments.

That's what bart does. He continually misrepresents other
people's statements, to make them look stupid, so he can feel
superior. Only insecure people feel a need to perpetually brag
and to constantly run down everyone else's point of view. Given
that he's been doing this for the better part of a decade it's
unlikely he is going to change any time soon.

On 14/01/2024 17:22, Tim Rentsch wrote:
> bart <bc@freeuk.com> writes:
>
>> On 12/01/2024 19:15, Scott Lurndal wrote:
> [...]
>>> What the FM documents. RTFM.
>>
>> I see. So forget just having intuitive behaviour. [...]
>
> The problem is not what the behavior is. The problem is
> with your intuition about what the behavior should be.

I would love to know what behaviour of an assembler is intuitive to /you/.

Or anybody.

I would be surprised if that involved the brain-dead behaviour of either
naming every output 'a.out', so overwriting the file created 5 seconds
previously, or spewing reams of binary code to a text terminal sensitive
to escape codes.

I don't know how many assemblers you're written; I've done four or five
standalone ones. All took files as input, and wrote correspondingly
named files as output.

(Except my first one, but that machine didn't a file system, so it can
be excused.)

The behaviour of 'as' is quite extraordinary. But it is typical of the
regulars here to gang up on somebody who points out the bleeding
obvious, and pretend that /they/ are mistaken, and that 'as' works
perfectly.

(Maybe you should apply to work for The Post Office and Fujitsu in the UK!)

How about accepting some constructive criticism for a change, and
ADMITTING that the behaviour is rubbish, but it has to be accepted
because the way it works is hard-coded into too many tools to change it.

Having a product called 'as2' is totally out of the question of course!