bart <bc@freeuk.com> writes:
>On 12/01/2024 13:40, David Brown wrote:
>> On 12/01/2024 00:20, bart wrote:
>
>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?

It does that so you can pipe the assembler source code in to the
assembler.

$ cat file.s | as

$ cat file.c | cpp | c0 | c1 | c2 | as > file.o

or, if you want, you can type in the assembler source directly.

Or you can save it in a file and supply the file argument to the command.

None of which your stuff supports, which makes it useless to me.

On 12/01/2024 16:34, David Brown wrote:
> On 12/01/2024 17:12, bart wrote:

> I don't really understand what you are trying to say here.  Are you
> suggesting that your 40 year old DOS IDE is equivalent to modern IDE's ?

No. Only that the way I normally work hasn't changed a great deal.

> Are you trying to say you can use your own tools for your own
> language, and rely on a simple script for C compilation, and can't
> handle anything else in a build process?

I'm separating the fundamental build-process for a program from what is
needed for interactive development and testing.

Makefiles you see supplied with open source projects don't generally
make that distinction.

But I can see you're struggling with the concept of simplicity.

>>> download to a
>>> target board via a debugger,

(Hey, I used to do that! Not a makefile in sight either; how is that
possible?

I used to do that with no special tools, no external software and no
external languages. I had to write assemblers for any new devices I has
to use.)

>>> and all sorts of other bits and pieces
>>> according to the needs of the project.  One makefile beats a dozen
>>> scripts.
>>
>> It looks like 'make' is competing with 'bash' then!
>>
>
> I have no idea why you think that - except perhaps because you still
> have no concept of what "make" is and what it does, and think it is just
> a script with a complicated syntax.

So, what the hell is it then? What makes it so special compared with any
other scripting language?

All I can see is that it can create dependency graphs between files -
which have to be determined from info that you provide in the file, it's
not that clever - and can use that to avoid recompilation etc of a file
unless its dependencies have changed.

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

For production builds, it doesn't matter if everything is compiled.

For end-user builds who just want a working binary, they have to build
everything from source anyway.

>> If you're curious about what 'as' expects and speculatively try 'as
>> --help', it displays 167 dense lines.
>>
>
> Are you trying to convince people that your assembler is better than gas
> because yours has fewer features?  Bizarre.

It's simpler and gives a simple summary of how it works.

Clearly your idea of 'better' is to be vastly more complicated.

I guess an assembler which will only work for the processor you happen
to be working with is no good at all. It has to also support dozens that
are not relevant to the task in hand.

BTW my assembler can directly produce EXE and DLL files; in that regard
it IS better than 'as' and probably most others which like to off-load
that critical bit.

bart <bc@freeuk.com> writes:
>On 12/01/2024 16:01, Scott Lurndal wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 12/01/2024 00:20, bart wrote:
>>
>>>> That's exactly how I view gcc's UI. Most Linux-derived utilities are as
>>>> bad: you invoke them, and they just apparently hang. Then you realise
>>>> they're waiting for input. Would it kill somebody to get them to display
>>>> a prompt?
>>>
>>> Are you sure you are not exaggerating just a /tiny/ bit?
>>
>> Clearly, Bart is trolling.
>>
>> And clearly, he doesn't understand the basic unix philosophy
>> of combining commands in pipeline, where "displaying a prompt"
>> would be silly.
>
>Yeah. Because it would be impossible too have two versions of a program
>(say 'as' that I used in my recent post), one for piping, one for
>interactive.

Not impossible. Just unnecessary.

David Brown <david.brown@hesbynett.no> writes:
>On 12/01/2024 17:12, bart wrote:
>> On 12/01/2024 13:40, David Brown wrote:
>>> On 12/01/2024 00:20, bart wrote:

>> It looks like 'make' is competing with 'bash' then!
>>
>
>I have no idea why you think that - except perhaps because you still
>have no concept of what "make" is and what it does, and think it is just
>a script with a complicated syntax.

I can't tell if he's just trolling, or if he really believes what
he writes.

There's no way in bash to generate a dependency graph, which
is the primary function of the make utility.

scott@slp53.sl.home (Scott Lurndal) writes:
>bart <bc@freeuk.com> writes:
>>On 12/01/2024 13:40, David Brown wrote:
>>> On 12/01/2024 00:20, bart wrote:
>>
>>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?
>
>It does that so you can pipe the assembler source code in to the
>assembler.
>
>$ cat file.s | as
>
>$ cat file.c | cpp | c0 | c1 | c2 | as > file.o
>
>or, if you want, you can type in the assembler source directly.
>
>Or you can save it in a file and supply the file argument to the command.
>
>None of which your stuff supports, which makes it useless to me.

But, in any case, why wonder when you can just RTFM?

$ man as
....
You give as a command line that has zero or more input file names. The
input files are read (from left file name to right). A command line
argument (in any position) that has no special meaning is taken to be
an input file name.

If you give as no file names it attempts to read one input file from
the as standard input, which is normally your terminal. You may have
to type the EOF character (default control-D) to tell as there is
no more program to assemble.

Use -- if you need to explicitly name the standard input file in your
command line.

On 12/01/2024 16:50, Scott Lurndal wrote:
> bart <bc@freeuk.com> writes:
>> On 12/01/2024 13:40, David Brown wrote:
>>> On 12/01/2024 00:20, bart wrote:
>>
>> 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?
>
> It does that so you can pipe the assembler source code in to the
> assembler.
>
> $ cat file.s | as
>
> $ cat file.c | cpp | c0 | c1 | c2 | as > file.o

Using ">" on binary content? That seems off.

But I've been playing with 'as', and it has issues. I'm not surprised
you have to use it via pipes, because used conventionally, it stinks.

If you do this:

as hello.s

What might someone expect the output to be? Probably not 'a.out', more
likely hello.o. Why /isn't/ it just hello.o?

Here a.out will be an object file; on Linux, it will sometimes it will
be an executable. No possibility of confusion at all.

What do you expect it to do here:

as one.s two.s

I expected two object files; I got one composite one. (Just as well if
they would both be called a.out!)

> or, if you want, you can type in the assembler source directly.
>
> Or you can save it in a file and supply the file argument to the command.
>
> None of which your stuff supports, which makes it useless to me.

I understand. Because writing:

$ command inputfile

is too complicated. Certainly it is if you have to do:

$ command inputfile -o outputfile

where outputfile is just putfile with the extension changed.

I been running assemblers since the late 70s; I have never seen one
behave as weirdly as 'as'.

I thought /my/ 'aa' product was unconventional (in normally turning ASM
sources directly to executables), but 'as' has it beat.

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.

>>
>> I have no idea why you think that - except perhaps because you still
>> have no concept of what "make" is and what it does, and think it is
>> just a script with a complicated syntax.
>
> So, what the hell is it then? What makes it so special compared with any
> other scripting language?

Meanwhile you seem to have read a bit about it, as you show below.

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 it
does the specific task very well, and it is not bound to a specific
language, or to languages generally, but also to any generation
processes.

>
> All I can see is that it can create dependency graphs between files -
> which have to be determined from info that you provide in the file, it's
> not that clever - and can use that to avoid recompilation etc of a file
> unless its dependencies have changed.

Or rather, unless the entities (that are dependent on) have changed.

And this is a crucial feature; for professional non-trivial 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.

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

>
> For production builds, it doesn't matter if everything is compiled.

For a production build we extract a committed release into an own
file system branch and build all, first for the tests, then to pack
the source (optionally), and then the complete runtime environment.

But we're doing professional software products. And the production
build comes _at the end_.

Before that we need efficient mechanisms to create consistent systems
and configurations, and to avoid unnecessary compiles. And the 'make'
process does exactly that.

> [...]
>
> Clearly your idea of 'better' is to be vastly more complicated.

The Makefile mechanism is extremely important and yet very simple.

Clearly your imputations are based on ignorance.

Janis

> [...]

On 12.01.2024 18:40, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 12/01/2024 17:12, bart wrote:
>>> On 12/01/2024 13:40, David Brown wrote:
>>>> On 12/01/2024 00:20, bart wrote:
>
>>> It looks like 'make' is competing with 'bash' then!
>>
>> I have no idea why you think that - except perhaps because you still
>> have no concept of what "make" is and what it does, and think it is just
>> a script with a complicated syntax.
>
> I can't tell if he's just trolling, or if he really believes what
> he writes.

My suspicion had been that he's maybe no person but an AI bot.
It's just too pathological what he writes and how he behaves to be
sure that he's a human poster. - On the other hand, this is Usenet,
and everything is possible.

Janis

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?

Janis

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.

But you rarely see pure binary being displayed like that on a text display.

Also, in the absence of ">", 'as' wouldn't write its output to the
screen (only to some badly named file), so it is off from that
perspective too.

However I'm obviously just a bot, so what do I know.

bart <bc@freeuk.com> writes:
>On 12/01/2024 16:50, Scott Lurndal wrote:
>> bart <bc@freeuk.com> writes:
>>> On 12/01/2024 13:40, David Brown wrote:
>>>> On 12/01/2024 00:20, bart wrote:
>>>
>>> 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?
>>
>> It does that so you can pipe the assembler source code in to the
>> assembler.
>>
>> $ cat file.s | as
>>
>> $ cat file.c | cpp | c0 | c1 | c2 | as > file.o
>
>Using ">" on binary content? That seems off.

Unix files are untyped sequences of bytes.

(e.g. the 'b' flag to the fopen stdio library routine is ignored on unix).

That windows fucks around with line endings and uses CRLF instead of the
more efficient LF is screwed up.

>

>If you do this:
>
> as hello.s
>
>What might someone expect the output to be?

What the FM documents. RTFM.

bart <bc@freeuk.com> writes:
>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.

No, it doesn't mean that at all. It never has meant that.

'> name' tells the shell to open 'name' on stdout before executing 'as'.

the 'as' command takes text as input and produces binary output (ELF or *Cough*COFF).

bart <bc@freeuk.com> writes:
> On 12/01/2024 16:50, Scott Lurndal wrote:
>> bart <bc@freeuk.com> writes:
>>> On 12/01/2024 13:40, David Brown wrote:
>>>> On 12/01/2024 00:20, bart wrote:
>>>
>>> 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?
>> It does that so you can pipe the assembler source code in to the
>> assembler.
>> $ cat file.s | as
>> $ cat file.c | cpp | c0 | c1 | c2 | as > file.o
>
> Using ">" on binary content? That seems off.

There's no fundamental reason you can't send binary data through a pipe
or write it to stdout and redirect it to a file. It could cause
problems if you accidentally write binary data to a terminal (it might
put your terminal into an odd state).

As it happens, GNU "as" doesn't and can't write its object file output
to a pipe or terminal, so Scott's hypothetical pipeline wouldn't
actually work. The as command doesn't write its output sequentially.
If you force it to write to stdout, it fails with an "Illegal seek"
error.

The "as" command writes its object file output to "a.out" (assembler
output) by default, or to whatever file you specify with "-o filename".
That's about the simplest interface you could have.

> But I've been playing with 'as', and it has issues. I'm not surprised
> you have to use it via pipes, because used conventionally, it stinks.
>
> If you do this:
>
> as hello.s
>
> What might someone expect the output to be? Probably not 'a.out', more
> likely hello.o. Why /isn't/ it just hello.o?

Partly historical inertia, and partly because "as" can't always know
what the output file should be, for example if its input isn't a file.

Yes, it *could* have been designed so it writes its output to foo.o if
it knows it's reading from foo.s, or to a.out (or to stdout?) otherwise.
That might have been a bit more convenient in some cases. But the
existing interface supports all reasonable uses if you know how to use
it.

I rarely invoke "as" directly myself, so 99% of the time I don't *care*
how it works. I didn't know it reads from stdin by default until you
complained about it.

[...]

--
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 12/01/2024 19:15, Scott Lurndal wrote:
> bart <bc@freeuk.com> writes:
>> On 12/01/2024 16:50, Scott Lurndal wrote:
>>> bart <bc@freeuk.com> writes:
>>>> On 12/01/2024 13:40, David Brown wrote:
>>>>> On 12/01/2024 00:20, bart wrote:
>>>>
>>>> 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?
>>>
>>> It does that so you can pipe the assembler source code in to the
>>> assembler.
>>>
>>> $ cat file.s | as
>>>
>>> $ cat file.c | cpp | c0 | c1 | c2 | as > file.o
>>
>> Using ">" on binary content? That seems off.
>
> Unix files are untyped sequences of bytes.
>
> (e.g. the 'b' flag to the fopen stdio library routine is ignored on unix).
>
> That windows fucks around with line endings and uses CRLF instead of the
> more efficient LF is screwed up.
>
>>
>
>> If you do this:
>>
>> as hello.s
>>
>> What might someone expect the output to be?
>
> What the FM documents. RTFM.

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

Oh, I see the problem: I haven't read the fucking manual. Except that if
I do read it, the behaviour will still be around the bend.

You guys all deserve medals for being so tolerant.

On 12/01/2024 19:18, Scott Lurndal wrote:
> bart <bc@freeuk.com> writes:
>> 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.
>
> No, it doesn't mean that at all. It never has meant that.
>
> '> name' tells the shell to open 'name' on stdout before executing 'as'.

And without '> name', where does stuff sent to stdout end up?

On 2024-01-12, Scott Lurndal <scott@slp53.sl.home> wrote:
> David Brown <david.brown@hesbynett.no> writes:
>>On 12/01/2024 00:20, bart wrote:
>
>>> That's exactly how I view gcc's UI. Most Linux-derived utilities are as
>>> bad: you invoke them, and they just apparently hang. Then you realise
>>> they're waiting for input. Would it kill somebody to get them to display
>>> a prompt?
>>
>>Are you sure you are not exaggerating just a /tiny/ bit?
>
> Clearly, Bart is trolling.
>
> And clearly, he doesn't understand the basic unix philosophy
> of combining commands in pipeline, where "displaying a prompt"
> would be silly.

C:\Users\kazk>findstr d
.... "hangs" ...

Even Microsoft somehow got the memo that at least text filters
shouldn't spew chatter.

I can't think of any Unix programs other than "ed" that take commands on
standard input, but don't print a prompt by default.

--
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:12 AM, bart wrote:
> On 12/01/2024 13:40, David Brown wrote:
>> On 12/01/2024 00:20, bart wrote:
>
>>> Why, what hairy stuff are you doing that requires a language as
>>> complex as 'make' and a shell environment as capable as 'bash'? It
>>> sounds more like, you just use the capability because it's there. And
>>> then complain when Windows doesn't have that.
>>>
>>
>> People use good tools when good tools are available - they don't go
>> out of their way to use something inferior.  Why is that a surprise?
>> If you want to cut an orange, do you go out to the garage and find a
>> rusty old knife that is nonetheless useable for cutting a bit of fruit
>> - or do you use the shiny new titanium kitchen knife that is right in
>> front of you?
>>
>> I used "make" on DOS and Windows for about 15 years before I started
>> using Linux as a development system (rather than just for servers and
>> for fun).  Every Windows system I have ever owned personally or used
>> at work has had "make" - because "make" has been the standard for
>> quality development tools since early DOS days.  The version I used
>> first on Windows came with Turbo Pascal - Microsoft's tools came with
>> their own slight variation of make called "nmake".
>>
>> If your build uses only a couple of commands, make doesn't add much
>> compared to a script - but it doesn't cost much either.  And you have
>> the convenience that a lot of editors have shortcut keys for doing a
>> "build", so something like ctrl-B will run "make" in the current
>> directory without needing to set up any specific tool shortcuts.
>> That's convenient.
>>
>> And unlike a language/compiler specific build system like you have
>> within your "mm" or "mcc" tools (if I am not mistaken), "make" will
>> work for anything you can run by commands.  My makefiles might not
>> just build executables from C files,
>
> If you isolate that part of it, then it's what I either build-in to the
> language + compiler (for M), or list in a simple text file (for C).
>
> In either case I will have a project file using a similar list for my
> basic IDE that I use for everyday development. But this part is not
> needed when somebody else needs to build my project.
>
> For a C project consisting of three files (one of Chris's), my IDE looks
> like this:
>
>   https://github.com/sal55/langs/blob/master/ff.png
>
> It probably looked about the same in 1984. The project file for that is
> this:
>
>   run cipher c.c output -e
>
>   module cipher.c
>   module sha2.c
>   module hmac.c
>   file sha2.h
>   file hmac.h
>
> The 'run' lines show what happens when I type 'R' in the IDE.
>
> This project is small enough that it can be built by a third party with
> a one-line instruction. Otherwise it would need an @ file of a few lines
> listing the .c files.
>
> Because this project is tidily structured with paired .c/.h files, my
> older BCC compiler could figure out how to build it from just the lead
> module:
>
>   c:\c>bcc -auto cipher
>      1 Compiling cipher.c     to cipher.asm       (Pass 1)
>   *  2 Compiling hmac.c       to hmac.asm         (Pass 2)
>   *  3 Compiling sha2.c       to sha2.asm         (Pass 2)
>   Assembling to cipher.exe
[...]

Fwiw, for some context here is the original thread where Bart helped me
out wrt getting it to compile on many C compilers:

https://groups.google.com/g/comp.lang.c/c/a53VxN8cwkY/m/XKl1-0a8DAAJ

Thanks again Bart. :^)

scott@slp53.sl.home (Scott Lurndal) writes:
> bart <bc@freeuk.com> writes:
[...]
>>Because when you see ">" on a command line, it means redirecting output
>>that would normally be shown as text on a console or terminal.
>
> No, it doesn't mean that at all. It never has meant that.

Well, maybe. If you drop the "as text", it's fairly accurate, for
certain values of "normally".

If you run "command" at a shell prompt, its stdout goes to the terminal
in which the shell is running. Normally that output should be text. If
it's binary, it's likely to mess up your terminal settings as it
contains byte sequences that look like terminal commands. (If "command"
deliberately outputs terminal commands, that could be useful.)

If you run "command > filename", its stdout goes to the named file.

> '> name' tells the shell to open 'name' on stdout before executing 'as'.
>
> the 'as' command takes text as input and produces binary output (ELF or *Cough*COFF).

And as I mentioned elsethread, at least GNU "as" can only write its
binary output to a seekable file. Apparently it doesn't write it
sequentially.

--
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 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?

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

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

>>
>> 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.

What is wrong with one-man projects?

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

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?

Is lua.exe a toy application? (Since it only has 33 modules and is a
300KB program.)

> 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. 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.

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.

Actually I don't care what the hell you do. I care when it impacts me
when I sometimes have to build something, WHICH IS RARELY MORE THAN
DOZENS OF MODULES OR 100/200K LINES OF CODE, so obviousy trivial
compared with your stuff, and yet I have to go through some torturous
process to get it done.

Let me tell about my own tools:

* My main compiler (not for C), is a whole-program compiler (so
interdepency graphs are pointless).

* It can whizz through sourcecode at 500,000 lines per second at least

* It can generate executable code at 5MB per second at least

This means that for a project that is about 0.5Mloc, or produces a 5MB
executable, recompiling everything might take ONE SECOND.

(And that is with the cheapest PC in the shop and with a non-optimised
compiler.)

Presumably YOUR apps are massively bigger and more complex than that.
But most stuff /I/ want write, or build of other people's, will be much
smaller.

This is why I consider make and friends pointless at this end of the scale.

>>
>> For production builds, it doesn't matter if everything is compiled.
>
> For a production build we extract a committed release into an own
> file system branch and build all, first for the tests, then to pack
> the source (optionally), and then the complete runtime environment.

> But we're doing professional software products. And the production
> build comes _at the end_.

> Before that we need efficient mechanisms to create consistent systems
> and configurations, and to avoid unnecessary compiles. And the 'make'
> process does exactly that.

Well, /I/ don't need that. I used to write commercial software in the
90s. I really never had some problems.

Half the line count (then about 150Kloc in all) was in scripting code.
That could be modified and tested /in the middle of a running application/.

I could send (by email) a script module to a customer and they could run
that without restarting their session.

Others could use my scripting language to create their own OEM add-on
products, without needing to rebuild the main application.

Yes, there was an install and configuration process, done via a GUI.

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

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

I write all my own tools, including a private C compiler. (I use it to
help with translating bindings from C headers, or to build DLLs of
libraries that exist as C source code, when the build info doesn't make
it in impossible.)

If I needed a tool like 'make', I would have created one.

Instead I developed fast, whole-program compilers and scripting languages.

> Clearly your imputations are based on ignorance.

Yeah. I could say the same thing. But usually I try and stay polite and
argue only against ideas and not people.

Have a good day.

bart <bc@freeuk.com> writes:
> 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?

There are many tools I don't need. I don't spend my days complaining
that they don't work the way I think they should.

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

Why?

Or, more to the point: No.

--
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 2024-01-12, bart <bc@freeuk.com> wrote:
>> but also build documentation (doxygen, LaTeX,
>> pandoc, graphviz, etc.), run tests, run "clean", build release zip
>> files, download to a target board via a debugger, and all sorts of other
>> bits and pieces according to the needs of the project.  One makefile
>> beats a dozen scripts.
>
> It looks like 'make' is competing with 'bash' then!

Make recipes are actually lines of shell code executed by the shell;
make does not reimplement a redundant command interpretation.(*)

You can use the SHELL variable to specify an alternative interpreter
for the make recipe lines.

---

* GNU Make contains logic for recognizing recipe lines that are
trivial commands, and eliding the use of the shell for those. So that is
to say that some simple command like "cc this.c -o this.o -c" is handled
via fork and exec directly. It must be the case that if SHELL is used
to specify an alternative interpreter, that logic is suppressed.

>>> That's exactly how I view gcc's UI. Most Linux-derived utilities are
>>> as bad: you invoke them, and they just apparently hang. Then you
>>> realise they're waiting for input. Would it kill somebody to get them
>>> to display a prompt?
>>
>> Are you sure you are not exaggerating just a /tiny/ bit?
>
> 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.

> 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.

--
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:
> 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?

You do need make, if you're on a Unix-like system and you want to make
"hello" out of "hello.c" with a command that consists of only two words.

This requirement was articulated by you.

--
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.

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>bart <bc@freeuk.com> writes:
>> On 12/01/2024 16:50, Scott Lurndal wrote:
>>> bart <bc@freeuk.com> writes:
>>>> On 12/01/2024 13:40, David Brown wrote:
>>>>> On 12/01/2024 00:20, bart wrote:
>>>>
>>>> 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?
>>> It does that so you can pipe the assembler source code in to the
>>> assembler.
>>> $ cat file.s | as
>>> $ cat file.c | cpp | c0 | c1 | c2 | as > file.o

Yes, I used this as an example pipeline. I don't recall
if the original as(1) wrote to stdout or always just to
a.out.

>> What might someone expect the output to be? Probably not 'a.out', more
>> likely hello.o. Why /isn't/ it just hello.o?
>
>Partly historical inertia, and partly because "as" can't always know
>what the output file should be, for example if its input isn't a file.

Yup. a.out is the historical inertia.

bart <bc@freeuk.com> writes:
>On 12/01/2024 19:18, Scott Lurndal wrote:
>> bart <bc@freeuk.com> writes:
>>> 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.
>>
>> No, it doesn't mean that at all. It never has meant that.
>>
>> '> name' tells the shell to open 'name' on stdout before executing 'as'.
>
>And without '> name', where does stuff sent to stdout end up?
>

Wherever the shell points stdout to before executing the program.
Might be a terminal, might be a pipe, might be a fifo, might
be a file, might be a network stream (via netcat or via shell
support for TCP connections), might be a printer.

bart <bc@freeuk.com> writes:
>On 12/01/2024 18:02, Janis Papanagnou wrote:

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

The example shown had 8 million lines of C and C++ code. Less
than 10% was python.

Granted, a significant fraction of that is generated from yaml descriptions
of memory mapped registers, yet it is still compiled by the C and C++ compilers.