On 02/02/2024 18:36, Keith Thompson wrote:
> bart <bc@freeuk.com> writes:
> [...]
>> The way 'as' works IS rubbish. It is fascinating how you keep trying
>> to turn it round and make it about me. There can't possibly be
>> anything wrong with it, whoever says so must be deluded!
>
> "as" works. It's not perfect, but it's good enough. Its job is to
> translate assembly code to object code. It does that. There's is
> nothing you could do with your preferred user interface (whatever that
> might be) that can't be done with the existing one. "as" is rarely
> invoked directly, so any slight clumsiness in its well defined user
> interface hardly matters. Any changes to its interface could break
> existing scripts.

That always seems to be the excuse. Some half-finished test version is
produced, with no proper file interface, and an output that temporarily
gets sent to a.out until it can be sorted out properly.

But it never is finished, and the same raw half-finished product works
the same way decades later, surprising every new generation who have to
relearn its quirks.

I saw an example today in tutorial:

as -o filename.o filename.as

having to type the name twice again.

> Nobody is claiming that "there can't possibly be anything wrong with
> it". You made that up.
>
> Why does the way "as" works offend you?

It just does. I've used a few assemblers, this one is downright weird:

* The output is odd: it ALWAYS goes to a.out. Hmm, that's the executable
file produced by gcc, so is it performing linking? No, this a.out
is an object file; gcc's a.out is an executable! (And if you and link
a.out with gcc, it will go wrong unless you use -o)

* You have to specify the output file name and extension, so writing
the input file twice

* If you start it with no params, instead of a usage message, it sits
silently waiting for you to type assembly code live at the terminal

* It accepts multiple input files. OK, presumably it will write each to
a corresponding .o file? No it writes all the code to one output.

* So, it is combining multiple, distinct assembler files to one single
object? That's actually quite neat. Except no, the input files are
effectively just concatenated into one big ASM file. Any symbol L3
in one, will clash with an L3 in another.

* All these behaviours are quite different to that of gcc. Pass
a.s, a.s, a.s to gcc, and will produce a.o, b.o, c.o. 'as' will
concatenate and produce one object file called a.out.

This is apparently the flagship assembler provided with Unix systems.

On 02/02/2024 19:43, tTh wrote:
> On 2/2/24 16:18, bart wrote:
>>
>> My definition is where you build one program (eg. one EXE or DLL file
>> on Windows) with ONE invocaton of the compiler, which processes ALL
>> source and support files from scratch.
>>
>    And can you disclose the magic trick who let your magic
>    compiler know exactly the list of "ALL source and support
>    files" needed for a scratchy build ?

If talking about the language used by my whole-program compiler, the
info comes from the module scheme. And /that/ involves simply listing
the modules the project comprises, in one place.

Other languages with module schemes tend to have ragged collections of
'import' statements at the top of every module.

Below is the lead module of my C compiler (cc.m) which is not C code,
but in my language. This module only contains project info. This allows
a choice of module for different configurations, but I sometimes just
comment lines in and out.

No other project info, import statements etc appear anywhere else.

5 modules are not shown in that list, which belong to the language's
standard library. Those are included automatically.

-------------------------------
cc.m
-------------------------------

!CLI
module cc_cli

!Global Data and Tables

module cc_decls
module cc_tables

!Lexing and Parsing
module cc_lex
module cc_parse

!General

module cc_lib
module cc_support

!PCL handling
module cc_blockPCL
module cc_genPCL
module cc_libPCL
module cc_pcl

!MCL handling

module cc_mcldecls
module cc_genmcl
module cc_libmcl
module cc_optim
module cc_stackmcl

!Bundled headers

module cc_headers
! module cc_headersx

module cc_export

!Diagnostics
module cc_show
! module cc_showdummy

!x64 and exe backend

! module mc_genss
! module mc_objdecls
! module mc_writeexe
! module mc_writess
! module mc_disasm

-------------------------------

! lines are comments. PCL is the IL. MCL is native code. The mc_ files
provide direct EXE generation, rather than ASM (as normally built it
invokes my external assembly 'as'. I'm joking, it is called 'aa'.). But
I haven't bothered with that backend.

This is in in action:

c:\cx>mm cc Build the above app
Compiling cc.m---------- to cc.exe

c:\cx>cc sql Test cc on sql.c
Compiling sql.c to sql.exe

c:\cx>sql See if it works
SQLite version 3.25.3 2018-11-05 20:37:38
...

Building the compiler with 'mm cc' takes 80ms; that's why I have no need
of dependency graphs or incremental compilation.

bart <bc@freeuk.com> writes:
>On 02/02/2024 18:36, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:

>I saw an example today in tutorial:
>
> as -o filename.o filename.as
>
>having to type the name twice again.

As has been pointed out numerous times, you don't need to
type both names twice.

All I have to type to build my entire project is 'mr'.

I very seldom every need to use 'cc' or 'as' directly except
for one-off examples to post here.

On 2024-02-02, bart <bc@freeuk.com> wrote:
> That always seems to be the excuse. Some half-finished test version is
> produced, with no proper file interface, and an output that temporarily
> gets sent to a.out until it can be sorted out properly.

Historically, GCC had to work with proprietary "as" programs; it
couldn't redefine the API.

> But it never is finished, and the same raw half-finished product works
> the same way decades later, surprising every new generation who have to
> relearn its quirks.

Most people using GCC do not learn anything about as.

Even those programming in assembler, because the gcc driver
recognizes .s and .S suffixes.

But we've been through this?

> I saw an example today in tutorial:
>
> as -o filename.o filename.as
>
> having to type the name twice again.

You want:

gcc -c filename.S

The .S file is preprocessed for you so you can use #define macros and
#include, and handed off to an assembler, somehow resulting in
filename.o.

There are lots of tutorials out there written by people who are
"writing to learn".

> It just does. I've used a few assemblers, this one is downright weird:

I've used lots of electric stove elements and room heaters! But this
ceramic resistor is weird. It has no on/off switch or temperature
control, and just bare wires?! No plug. Sure, if I pass current through
it, it warms up, so I guess what these electrical engineers call "working"
in their little world.

"as" is not an application designed for programming; it's an internal
toolchain component. Why can't you understand that?

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

bart <bc@freeuk.com> writes:
> On 02/02/2024 18:36, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
[...]
> That always seems to be the excuse. Some half-finished test version is
> produced, with no proper file interface, and an output that
> temporarily gets sent to a.out until it can be sorted out properly.

It's not an "excuse", it's an explanation.

But OK, let me drop everything and fix it for you. I can submit a patch
for "as" so it behaves the way you want. I'll also submit patches for
gcc so it invokes "as" with the new interface. It will still have to
handle the old interface at least temporarily, so there will have to be
a way to ask "as" which interface it uses. Nothing will ever generate a
file named "a.out" unless it's explicitly told to do so. I'll also send
the word out so everyone knows not to rely on the name "a.out" anymore.
And I'll convince everyone that they've been doing it wrong for the last
several decades.

I'll let you know when that's done. Because nothing short of that would
satisfy you.

[...]

--
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 Thu, 01 Feb 2024 19:03:38 -0800, Keith Thompson wrote:

> A #include directive with <> searches for a "header", which is not
> stated to be a file. A #include directive with "" searches for a file
> in an implementation-defined manner; if that search fails, it tries
> again as if <> had been used.

The trouble with that interpretation is, it would seem to rule out the use
of things like include libraries for user headers. Do you really think
that was the intention?

On Fri, 2 Feb 2024 11:05:22 +0100, David Brown wrote:

> On 02/02/2024 00:30, Lawrence D'Oliveiro wrote:
>
>> Ninja was created as an alternative to Make.
>
> It is an alternative to some uses of make - but by no means all uses.

It gets rid of the overlap when you have a meta-build system generating
the lowest-level build control files (Makefiles).

On Fri, 2 Feb 2024 19:52:45 +0000, bart wrote:

> as -o filename.o filename.as

On *nix systems, we can use “cc” as kind of a “universal” compile command,
not just for C code but for assembler as well, e.g.

cc -c filename.o filename.s

(without preprocessor)

cc -c filename.o filename.S

(with preprocessor)

cc -o filename filename.S

(with preprocessor and linking stages as well).

Can your system offer these options?

On Fri, 2 Feb 2024 13:47:25 +0000, bart wrote:

> That's true: only 47 years in computing, and 42 years of evolving,
> implementing and running my systems language.

On how many different platforms?

Seems like your primary experience has been with beating your head against
Microsoft Windows. That’s got to have health implications.

On 02/02/2024 21:23, Lawrence D'Oliveiro wrote:
> On Fri, 2 Feb 2024 19:52:45 +0000, bart wrote:
>
>> as -o filename.o filename.as
>
> On *nix systems, we can use “cc” as kind of a “universal” compile command,
> not just for C code but for assembler as well, e.g.
>
> cc -c filename.o filename.s
>
> (without preprocessor)
>
> cc -c filename.o filename.S
>
> (with preprocessor)
>
> cc -o filename filename.S
>
> (with preprocessor and linking stages as well).
>
> Can your system offer these options?

What option is that, to have one command 'cc' that can deal with N
different languages?

No. But I can offer a system where you have a choice of N different
compilers or assemblers for the same language:

lc64 filename.c
tcc filename.c
gcc filename.c -ofilename.exe
mcc filename

nasm -fwin64 filename.asm
yasm -fwin64 filename.asm
aa filename -obj
as filename.s -ofilename.o

How do you choose different compilers or assemblers with 'cc'?

I also offer a scheme with my tools where the tool magically knows what
language it is dealing with:

mm filename (filename.m => filename.exe)
mcc filename (filename.c => filename.exe)
aa filename (filename.asm => filename.exe)
qq filename (run filename.q)
pci filename (run filename.pcl)
ms filename (run filename.m)

..m and .q files are lead modules of an application.
..c files are standalone modules

One .asm file normally represents a whole program unless generated from mcc

On 02/02/2024 21:42, Lawrence D'Oliveiro wrote:
> On Fri, 2 Feb 2024 13:47:25 +0000, bart wrote:
>
>> That's true: only 47 years in computing, and 42 years of evolving,
>> implementing and running my systems language.
>
> On how many different platforms?

I started in 1976. I started using Windows for my products in 1995
because all my potential customers could buy an off-the-shelf Windows
PC. Linux was nowhere. Unix was only in academia, I think; nowhere
relevant to me anyway.

My first compiler (not for my language) targetted PDP10. Subsequent ones
generated code for Z80 plus 3 generations of x86.

I started using the C library in 1995 too (via my FFI), as it was
simpler than WinAPI for file-handling.

> Seems like your primary experience has been with beating your head against
> Microsoft Windows. That’s got to have health implications.

That wasn't a serious question was it; you just wanted to have a go at
Windows.

Why do you consider that fair game, but people hate if when anyone
criticises Unix?

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Thu, 01 Feb 2024 19:03:38 -0800, Keith Thompson wrote:
>> A #include directive with <> searches for a "header", which is not
>> stated to be a file. A #include directive with "" searches for a file
>> in an implementation-defined manner; if that search fails, it tries
>> again as if <> had been used.
>
> The trouble with that interpretation is, it would seem to rule out the use
> of things like include libraries for user headers. Do you really think
> that was the intention?

I don't know. I imagine an implementation could interpret the word
"file" to include information extracted from libraries. Note that it
doesn't have to correspond to the concept of a "file" used in <stdio.h>;
that refers to files in the execution environment, not the compilation
environment.

--
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 Fri, 2 Feb 2024 22:12:04 +0000, bart wrote:

> On 02/02/2024 21:42, Lawrence D'Oliveiro wrote:
>
>> Seems like your primary experience has been with beating your head
>> against Microsoft Windows. That’s got to have health implications.
>
> That wasn't a serious question was it; you just wanted to have a go at
> Windows.

You yourself have complained endlessly about build setups that work fine
on *nix systems, but that give you trouble on Windows. It’s like you don’t
see the source of your difficulties right in front of your eyes.

> Why do you consider that fair game, but people hate if when anyone
> criticises Unix?

I don’t care about “Unix” any more, and I doubt many other people do. All
the systems legally entitled to call themselves ”Unix” are dying if not
already dead.

On Fri, 2 Feb 2024 21:51:43 +0000, bart wrote:

> What option is that, to have one command 'cc' that can deal with N
> different languages?

Hint: it uses the filename extension to determine which language, and
which flavour of the language even, it is dealing with.

> No. But I can offer a system where you have a choice of N different
> compilers or assemblers for the same language:

Are their ABIs compatible?

On Fri, 02 Feb 2024 16:09:09 -0800, Keith Thompson wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> On Thu, 01 Feb 2024 19:03:38 -0800, Keith Thompson wrote:
>>
>>> A #include directive with <> searches for a "header", which is not
>>> stated to be a file. A #include directive with "" searches for a file
>>> in an implementation-defined manner; if that search fails, it tries
>>> again as if <> had been used.
>>
>> The trouble with that interpretation is, it would seem to rule out the
>> use of things like include libraries for user headers. Do you really
>> think that was the intention?
>
> I don't know. I imagine an implementation could interpret the word
> "file" to include information extracted from libraries.

Then the distinction between “headers” that are “files”, versus those that
are not, as so carefully worded in the standard (as you pointed out),
becomes meaningless.

On 2024-02-03, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Fri, 02 Feb 2024 16:09:09 -0800, Keith Thompson wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>>> On Thu, 01 Feb 2024 19:03:38 -0800, Keith Thompson wrote:
>>>
>>>> A #include directive with <> searches for a "header", which is not
>>>> stated to be a file. A #include directive with "" searches for a file
>>>> in an implementation-defined manner; if that search fails, it tries
>>>> again as if <> had been used.
>>>
>>> The trouble with that interpretation is, it would seem to rule out the
>>> use of things like include libraries for user headers. Do you really
>>> think that was the intention?
>>
>> I don't know. I imagine an implementation could interpret the word
>> "file" to include information extracted from libraries.
>
> Then the distinction between “headers” that are “files”, versus those that
> are not, as so carefully worded in the standard (as you pointed out),
> becomes meaningless.

Not any more than the distinction between shell functions, built-in
commands and external commands.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 02/02/2024 18:26, Scott Lurndal wrote:
> bart <bc@freeuk.com> writes:
>> On 02/02/2024 15:18, Scott Lurndal wrote:
>
>>
>> You're saying that anyone not using Unix, not building 10Mloc projects,
>> and not a fan of make, should FOAD?
>
> No. I'm saying that your dislike of make is personal. If you
> don't like it, don't use it. Make your own, nobody is stopping
> you. Just don't brag about how "small", "easy" or "nice" it is
> until it can handle the same job as make.
>

Well no. These are impossible design specifications. Obviously we would
like something which is smaller than make, easier to use, generally
nice, and also supports every single job that "make" supports. But the
only way you can achieve that is to keep the program essentially the
same and fiddle about a bit with the syntax. And at best, that will
achieve a few marginal improvements.

To build a "smaller, easier, nicer" make, if that is the goal (and it's
a very legitimate one), you're going to have to ask what does make do?
What functionality does it have that is rarely used, or which could be
achieved on other ways, or which users can be persuaded isn't really
necessary?" For example make keeps a list of dependencies. But my by no
means untypical machine has six 3.7 Ghz cores. If those dependencies are
going to be hand-written C source files, there's no longer any point in
keeing track of changed dependent files. Back in the day, when make was
written there was. But now, surely we can just submit the whole lot to
the compiler, and maybe we lose a second. And by stripping the
dependencies out of make, we can write a program which is a whole lot
easier to use.

(Unfortunately if you write C++ rather than C, even a 3.7 GHz machine
isn't going to be fast enough. But maybe your users don't use C++).

But that's the way to do it.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 02/02/2024 22:12, bart wrote:
>
> Why do you consider that fair game, but people hate if when anyone
> criticises Unix?
>
Because UNIX systems used to typically cost tens of thousands of
dollars, whilst a PC could be had for under a thousand dollars. So
everyone could have a PC, but if you were given a UNIX system you were a
bit special. And that gave UNIX programmers a sense of superiority.

It's a very silly attitude of course.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 02/02/2024 18:54, Kaz Kylheku wrote:
> On 2024-02-02, bart <bc@freeuk.com> wrote:
>> The way 'as' works IS rubbish.
>
> Pretend a developer of "as" (say, the GNU one) is reading this thread.
>
> What is it that is broken?
>
> Do you have a minimal repro test case of your issue?
>
> What is the proposed fix?
>
>> turn it round and make it about me. There can't possibly be anything
>> wrong with it, whoever says so must be deluded!
>
> A vast amount of code is being compiled daily, passing through as,
> without anyone noticing.
>
It's a constant problem.

It's usually easy enough to knock up a piece of code to do something.
The problem is deploying it. Now of course some code is successfully
deployed, and you can point to that. But if that wasn't the case then
the industry would not exist at all, and, by pointing that out, you are
not really doing anything much to address the problem, which is that
deployment is where our costs are incurred, where the barriers to entry
are, and why a lot of projects fail.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On 02/02/2024 18:54, Kaz Kylheku wrote:
>> On 2024-02-02, bart <bc@freeuk.com> wrote:
>>> The way 'as' works IS rubbish.
>> Pretend a developer of "as" (say, the GNU one) is reading this
>> thread.
>> What is it that is broken?
>> Do you have a minimal repro test case of your issue?
>> What is the proposed fix?
>>
>>> turn it round and make it about me. There can't possibly be anything
>>> wrong with it, whoever says so must be deluded!
>> A vast amount of code is being compiled daily, passing through as,
>> without anyone noticing.
>>
> It's a constant problem.

OK, maybe *you* can explain why it's a problem.

[...]

--
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-02-03, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> On 02/02/2024 18:54, Kaz Kylheku wrote:
>> On 2024-02-02, bart <bc@freeuk.com> wrote:
>>> The way 'as' works IS rubbish.
>>
>> Pretend a developer of "as" (say, the GNU one) is reading this thread.
>>
>> What is it that is broken?
>>
>> Do you have a minimal repro test case of your issue?
>>
>> What is the proposed fix?
>>
>>> turn it round and make it about me. There can't possibly be anything
>>> wrong with it, whoever says so must be deluded!
>>
>> A vast amount of code is being compiled daily, passing through as,
>> without anyone noticing.
>>
> It's a constant problem.
>
> It's usually easy enough to knock up a piece of code to do something.
> The problem is deploying it.

I am not sure what you're referring to. The "as" program is successfully
deployed. It meets its requirements and does its job behind the scenes,
without attracting attention.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 03/02/2024 06:13, Keith Thompson wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> On 02/02/2024 18:54, Kaz Kylheku wrote:
>>> On 2024-02-02, bart <bc@freeuk.com> wrote:
>>>> The way 'as' works IS rubbish.
>>> Pretend a developer of "as" (say, the GNU one) is reading this
>>> thread.
>>> What is it that is broken?
>>> Do you have a minimal repro test case of your issue?
>>> What is the proposed fix?
>>>
>>>> turn it round and make it about me. There can't possibly be anything
>>>> wrong with it, whoever says so must be deluded!
>>> A vast amount of code is being compiled daily, passing through as,
>>> without anyone noticing.
>>>
>> It's a constant problem.
>
> OK, maybe *you* can explain why it's a problem.
>

You snip the explantion than demand another explantion.

I'm sitting at a computer with a C compiler installed. Currently there's
a discussion about make and Bart's ideas for a better make. So I could
look at what Bart is saying and try to write a better make. And likely
it would take a few days and not be too difficult.

But I can't easily deploy that code. I can't communicate with people who
might be interested, get it on their machines, get them to try it out. I
can do it a bit of course. I can put the source on github and I'll get
some downloads. But you'll find that on many systems it won't build, it
won't install, it won't have the correct runtime environment, it's
impossible to distribute binary executables, it needs unaceptable
fiddling with global paths to make it run effectively, if the user
doesn't own the computer the person who does own the computer won't
allow him to run the software. Etc etc. That's where the challenges are.
Far more than actually writing the program.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On 03/02/2024 06:13, Keith Thompson wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>> On 02/02/2024 18:54, Kaz Kylheku wrote:
>>>> On 2024-02-02, bart <bc@freeuk.com> wrote:
>>>>> The way 'as' works IS rubbish.
>>>> Pretend a developer of "as" (say, the GNU one) is reading this
>>>> thread.
>>>> What is it that is broken?
>>>> Do you have a minimal repro test case of your issue?
>>>> What is the proposed fix?
>>>>
>>>>> turn it round and make it about me. There can't possibly be anything
>>>>> wrong with it, whoever says so must be deluded!
>>>> A vast amount of code is being compiled daily, passing through as,
>>>> without anyone noticing.
>>>>
>>> It's a constant problem.
>> OK, maybe *you* can explain why it's a problem.
>
> You snip the explantion than demand another explantion.

The context was bart's statement that "The way 'as' works IS rubbish".
You seemed to be agreeing that that's "a constant problem".
If you meant something else, never mind.

[snip]

--
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 03/02/2024 08:02, Keith Thompson wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> On 03/02/2024 06:13, Keith Thompson wrote:
>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>> On 02/02/2024 18:54, Kaz Kylheku wrote:
>>>>> On 2024-02-02, bart <bc@freeuk.com> wrote:
>>>>>> The way 'as' works IS rubbish.
>>>>> Pretend a developer of "as" (say, the GNU one) is reading this
>>>>> thread.
>>>>> What is it that is broken?
>>>>> Do you have a minimal repro test case of your issue?
>>>>> What is the proposed fix?
>>>>>
>>>>>> turn it round and make it about me. There can't possibly be anything
>>>>>> wrong with it, whoever says so must be deluded!
>>>>> A vast amount of code is being compiled daily, passing through as,
>>>>> without anyone noticing.
>>>>>
>>>> It's a constant problem.
>>> OK, maybe *you* can explain why it's a problem.
>>
>> You snip the explantion than demand another explantion.
>
> The context was bart's statement that "The way 'as' works IS rubbish".
> You seemed to be agreeing that that's "a constant problem".
> If you meant something else, never mind.
>
> [snip]
>
I was making the same point that Bart is making, but in a more general
way. I don't use as and I don't know anything about it specifically. But
the pattern with tools like that is that whilst they usually assemble
scripts correctly, they don't make them easy to deploy. That's Bart's
exerience, and it is my experience.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 03/02/2024 06:30, Kaz Kylheku wrote:
> On 2024-02-03, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>> On 02/02/2024 18:54, Kaz Kylheku wrote:
>>> On 2024-02-02, bart <bc@freeuk.com> wrote:
>>>> The way 'as' works IS rubbish.
>>>
>>> Pretend a developer of "as" (say, the GNU one) is reading this thread.
>>>
>>> What is it that is broken?
>>>
>>> Do you have a minimal repro test case of your issue?
>>>
>>> What is the proposed fix?
>>>
>>>> turn it round and make it about me. There can't possibly be anything
>>>> wrong with it, whoever says so must be deluded!
>>>
>>> A vast amount of code is being compiled daily, passing through as,
>>> without anyone noticing.
>>>
>> It's a constant problem.
>>
>> It's usually easy enough to knock up a piece of code to do something.
>> The problem is deploying it.
>
> I am not sure what you're referring to. The "as" program is successfully
> deployed. It meets its requirements and does its job behind the scenes,
> without attracting attention.
>
>

as is a development tool. So there are two aspects to it. The first is
deploying as itself. It must be available and capable of being invoked
on all machines where it needs to be available. It mustn't refuse to run
correctly because some path somewhere is not set up or it doesn't have
write permission to output an executable, and so on. That may well have
been achieved. Typing "as" into the shell on the computer I'm typing
this on does indeed invoke the program.

But the other side to it that as must make it easy to deploy the actual
useful end user programs that it is used to develop. So if we write an
as script, it must be easy to make that script part of an executable,
place it on the user's machine, and set it up so that the user can
easily run it and play space invaders or achieve whatever else he
ultimately wishes to achieve. And what Bart is saying is that that is
where as is falling down.

I don't use as myself, so it's hard to commment on the specifics. But
from experience with similar systems, this will be where the problems
lie. The complaint sems to be that because of the quirky way in which it
matches up scripts to output executables, it's too hard to package the
scripts so that they are assembled correctly. Since as I say I don't use
as I can't comment on that directly, but I can well believe it.

Of course some software is assembled with as and deployed successfully.
The program wouldn't exist if that wasn't the case.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm