On 11/01/2024 14:45, bart wrote:
> On 11/01/2024 12:24, David Brown wrote:
>> On 10/01/2024 21:20, bart wrote:
>
>>> Before typing 'make', you'd better be sure you're in the right place!
>>>
>>
>> The same is true of getting undressed, and indeed most things in life.
>>
>
>
> You might remember a discussion last autumn about building Lua 5.4.
>

I vaguely remember the discussion, but not the details (sorry).

> There was a lot of confusion since the sources you got from googling
> 'github lua', and also I think from the releases from that github site,
> and sources obtained via 'lua.org', were different.
>
> The latter had an extra directory level compared with github, and two
> makefiles rather than one:
>
>   c:\xxx\lua-5.4.6>dir makefile*/s
>   Directory of c:\xxx\lua-5.4.6
>   02/05/2023  20:06             3,150 Makefile
>
>   Directory of c:\xxx\lua-5.4.6\src
>   03/02/2023  10:43             7,685 Makefile
>
> Github had only the latter level.
>
> Since both have the same name and both can be invoked with:
>
>   make
>
> it meant no error was reported (like: 'no such makefile'), it just went
> wrong.
>
> Here, having to specify the name of a file, /and/ ensuring those two
> input files weren't identically named, could have saved a lot trouble by
> detecting the discrepancy sooner.
>

I don't remember the details, so I am just guessing now - perhaps one
was a developer version and the other a release version. Perhaps there
was just a mistake.

It is /very/ common to have makefiles in subdirectories - different
parts of a project can be built with recursive make. (This can be done
badly, as with many things, and can be the source of confusion,
inefficiencies or problems if different sub-projects depend on each
other.) But you should normally have a "parent" makefile or script in
the outer directory, or at least clear build instructions.

On Wed, 10 Jan 2024 05:28:43 -0000 (UTC), Kaz Kylheku
<433-929-6894@kylheku.com> wrote in <20240109212820.166@kylheku.com>:

> On 2024-01-10, tTh <tth@none.invalid> wrote:
>> On 1/10/24 01:40, Bart wrote:
>>> An easy compiler is one where you just do:
>>>
>>>    gcc prog
>>>
>>> and not, at the very least:
>>>
>>>    gcc prog.c -prog.exe -std=c11 -pedantic-errors
>>>
>>> Meanwhile I routinely test C programs on half a dozen compilers. I
>>> can't be bothered with all this crap.
>>
>> So do as all of us do : put this crap in a Makefile or a shell
>> script, and forget about it.
>
> Please don't get Bart started on makefiles!

Speaking of which...let's not this time. :)

Where would be a good place to discuss Makefiles and the build
systems that use them; and perhaps the build systems that do
the same job as "make"?

comp.lang.misc?

TIA

--
-v

On 11.01.2024 15:58, vallor wrote:
>
> Where would be a good place to discuss Makefiles and the build
> systems that use them; and perhaps the build systems that do
> the same job as "make"?
>
> comp.lang.misc?

I wouldn't consider 'make' a "lang" (even if we could stretch
the interpretation of its syntax as such, but you are aiming
at a different aspect anyway).

Maybe comp.unix.programmer?

Janis

On 2024-01-11, bart <bc@freeuk.com> wrote:
> On 11/01/2024 02:46, Kaz Kylheku wrote:
>> The fixed name of the makefile is a great idea. If I could change
>> anything, I would call it ".makefile".
>
> I think it's a terrible idea. It's like me deciding that when I type:
>
> mcc
>
> by itself, it will automatically compile xyzzy.c, every time. What it
> actually does is a bit saner, it shows some help text:

No, that's like mcc, if not given options, finding a .mccproj
file and building what is described there.

I.e. "build the mcc project that's associated with this directory,
via that directory's .mccproject property".

You need a fixed name to attach a property to the directory.

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

Kaz Kylheku <433-929-6894@kylheku.com> writes:
>On 2024-01-11, bart <bc@freeuk.com> wrote:
>> On 11/01/2024 02:46, Kaz Kylheku wrote:
>>> The fixed name of the makefile is a great idea. If I could change
>>> anything, I would call it ".makefile".
>>
>> I think it's a terrible idea. It's like me deciding that when I type:
>>
>> mcc
>>
>> by itself, it will automatically compile xyzzy.c, every time. What it
>> actually does is a bit saner, it shows some help text:
>
>No, that's like mcc, if not given options, finding a .mccproj
>file and building what is described there.
>
>I.e. "build the mcc project that's associated with this directory,
>via that directory's .mccproject property".
>
>You need a fixed name to attach a property to the directory.

That's fine, but don't make it a hidden file. A hidden file
can be used to record tool preferences, but the file describing
the project itself shouldn't be hidden.

bart <bc@freeuk.com> writes:
[...]
> OK, so just like:
>
> mcc prog
>
> At least someone recognises the utility of doing that rather than the
> gcc palaver. They don't even need the extension!
>
> Yet when I build that convenience into the compiler, people come down
> on me like a ton of bricks.
>
> Talk about hypocrisy.
[...]

I haven't seen this "ton of bricks".

I don't think anyone has objected to the way your mcc works. If
"mcc prog" does what you want, that's fine. It's different from the way
gcc works, but nobody says that everything has to work the same way gcc
does.

If someone *describes* how gcc and make work, you take it as an
accusation, a condemnation of your own tools for being different.
Nobody is saying that.

I'll mention in passing that there are advantages to having
a compiler command refer to the name of the input (prog.c)
rather than the name of the output (prog or prog.exe), because
it lets the user take advantage of filename completion. "make"
is an exception to this, because there are good reasons for it to
refer to the output. Again, I'm not criticizing you for not doing
it that way, just letting you know about a possible rationale for
gcc's existing behavior.

--
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 11/01/2024 01:14, bart wrote:
> On 10/01/2024 23:30, tTh wrote:
>> On 1/10/24 19:57, bart wrote:
>>
>>> The above tries to compile hello.c with gcc. The first attempt
>>> doesn't work. The second does, as no error is displayed. But what
>>> exactly has it compiled it to? As there is no file called 'hello.exe.
>>
>>    o     ____    _____   _____   __  __
>>    o    |  _ \  |_   _| |  ___| |  \/  |
>>    o    | |_) |   | |   | |_    | |\/| |
>>    o    |  _ <    | |   |  _|   | |  | |
>>    o    |_| \_\   |_|   |_|     |_|  |_|
>>    o
>>
>
> I see. It doesn't matter how complex, unfriendly, inconvenient or
> error-prone using a piece of software is, it's all fine so long as you
> tell the user:
>
>   R T F M?
>
> That makes up for designing it properly?
>
> Instead of getting rid of unnecessary hoops you have to jump through,
> you'd just write a thicker instruction manual and sell more training
> courses. (And force people to use 'make' - another dozen hoops.)
>
> Plus of course you can command more pay for mastering that contrived
> complexity.
>
> What /I/ do is strive to get rid of those hoops.

Here's some hoops, for you ...

$ ls
hello.c

No Makefile, you'll notice.

$ make hello
cc hello.c -o hello

$ ./hello
Hello World!

On 11/01/2024 17:56, Richard Harnden wrote:
> On 11/01/2024 01:14, bart wrote:
>> On 10/01/2024 23:30, tTh wrote:
>>> On 1/10/24 19:57, bart wrote:
>>>
>>>> The above tries to compile hello.c with gcc. The first attempt
>>>> doesn't work. The second does, as no error is displayed. But what
>>>> exactly has it compiled it to? As there is no file called 'hello.exe.
>>>
>>>    o     ____    _____   _____   __  __
>>>    o    |  _ \  |_   _| |  ___| |  \/  |
>>>    o    | |_) |   | |   | |_    | |\/| |
>>>    o    |  _ <    | |   |  _|   | |  | |
>>>    o    |_| \_\   |_|   |_|     |_|  |_|
>>>    o
>>>
>>
>> I see. It doesn't matter how complex, unfriendly, inconvenient or
>> error-prone using a piece of software is, it's all fine so long as you
>> tell the user:
>>
>>    R T F M?
>>
>> That makes up for designing it properly?
>>
>> Instead of getting rid of unnecessary hoops you have to jump through,
>> you'd just write a thicker instruction manual and sell more training
>> courses. (And force people to use 'make' - another dozen hoops.)
>>
>> Plus of course you can command more pay for mastering that contrived
>> complexity.
>>
>> What /I/ do is strive to get rid of those hoops.
>
> Here's some hoops, for you ...
>
> $ ls
> hello.c
>
> No Makefile, you'll notice.
>
> $ make hello
> cc     hello.c   -o hello
>
> $ ./hello
> Hello World!

c:\xxx>dir/b
hello.c

c:\xxx>mcc hello
Compiling hello.c to hello.exe

c:\xxx>hello
Hello, World! 11-Jan-2024 18:21:56

See? It's built in to my compiler. No separate 'make' is needed. It
doesn't have the restrictions I touched on in my earlier post on the
subject. I can choose add the extension:

c:\xxx>mcc hello.c
Compiling hello.c to hello.exe

It still works. It naturally extends to multiple source files. I don't
need to understand make files.

So my comments still stand. This 'make' example is just a misleading trick.

On 11/01/2024 16:13, Kaz Kylheku wrote:
> On 2024-01-11, bart <bc@freeuk.com> wrote:
>> On 11/01/2024 02:46, Kaz Kylheku wrote:
>>> The fixed name of the makefile is a great idea. If I could change
>>> anything, I would call it ".makefile".
>>
>> I think it's a terrible idea. It's like me deciding that when I type:
>>
>> mcc
>>
>> by itself, it will automatically compile xyzzy.c, every time. What it
>> actually does is a bit saner, it shows some help text:
>
> No, that's like mcc, if not given options, finding a .mccproj
> file and building what is described there.
>
> I.e. "build the mcc project that's associated with this directory,
> via that directory's .mccproject property".
>
> You need a fixed name to attach a property to the directory.

That would be more like a configuration file. It can control the
behaviour of an interactive op, or run some sort of prelude script, or
load some data, prior to starting a normal session.

It wouldn't see such a file, act on it, then (perhaps silently) stop.

If I wanted that behaviour, I would script it, using the same commands
that I've been familiar with for decades from my OS's command prompt.

The name of the script would usually be specific to the project, for
example, 'makeccia' will run 'makeccia.bat'. The '-a' suffix refers to
the floppy A: drive, so it is a very old example.

The only time I reuse generic script names for a project are names like
'backup' and 'store'.

I can see where you're coming from with 'make': if I load my IDE (which
picks up a config file from this directory which describes the current
local project), I can type standard commands like 'C' to compile, and
'R' to run

Within this app, you can be informal since it has an active environment
which is clearly displayed and the files involved are shown. Well, IT IS
AN APP and runs within an obvious context.

'make' looks like it wants to be similarly informal, but there there is
no strong environment, only the name of the current directory, which
might contain /anything/. There is no real context.

bart <bc@freeuk.com> writes:
[...]
> 'make' looks like it wants to be similarly informal, but there there
> is no strong environment, only the name of the current directory,
> which might contain /anything/. There is no real context.

No real context??

The context is typically the current directory, all its direct and
indirect subdirectories, and their contents -- in other words, the
entire project. Or the context can be whatever you want it to be.
"make" is a very general tool (with some defaults for more specific
uses). You can write a Makefile to do just about anything that
can be done on a computer; building a project from source is just
the most common use case.

There are plenty of less generic build tools that work by generating
and invoking a Makefile -- which is a perfectly sensible thing to do,
since "make" already exists. And of course there are other tools
that do similar things without using "make" -- also a perfectly
sensible thing to do.

--
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 1/11/2024 4:24 AM, David Brown wrote:
> On 10/01/2024 21:20, bart wrote:
>> On 10/01/2024 19:24, bart wrote:
>>> On 10/01/2024 18:39, Keith Thompson wrote:
>>>> bart <bc@freeuk.com> writes:
>>>>> On 10/01/2024 14:49, Scott Lurndal wrote:
>>>> [...]
>>>>>> Yet, the entire application can be built with
>>>>>> $ make
>>>>>
>>>>> I bet you can't. There's something missing. Unless the implicit file
>>>>> that make uses happens to be in that '$' directory. Usually you have
>>>>> to navigate to the project first.
>>>>
>>>> That '$' is a shell prompt, not a directory.
>>>>
>>>> Yes, you have to "cd" (like "chdir" on Windows) to the project
>>>> directory
>>>> before typing "make".  You also have to make sure the computer is
>>>> powered on, login, launch a shell, and maybe one or two other things
>>>> before you get to that point.
>>>
>>> You're missing the point. SL is making a big deal about the fact that
>>> you can type 'make' without providing any apparent input. But that
>>> input is provided when you use 'cd' to get the relevant folder.
>>>
>>> Or do you think that the 'make' command provided will build that
>>> specific project irrespective of the CWD?
>>
>> Let me put it another way; how does:
>>
>>    $ make
>>
>> know it is to build that project, and not any other? The default input
>> is presumably "./makefile", with the key bit being that ".".
>
> Yes, that's the usual way for non-trivial uses.  (For simple cases, the
> build-it rules are good enough, given a target.)  You can give make an
> explicit makefile ("make -f proj.make") or it will try to find the
> default one in the current directory.  For gnu make (there are /many/
> other "make" implementations), it will try "GNUmakefile", "makefile",
> then "Makefile".
>
>>
>> So, when claiming that you only need to type one thing to start the
>> process, it is disingenuous to leave out that part out.
>
> No.  Your makefile (or cmake files, or bake files, or whatever build
> system you use) are part of your project - they are part of the source.
>
>>
>> After all, if you wanted to build project A, and, separately, project
>> B, you can't do both of them like this:
>>
>>     $ make
>>     $ make
>
> I think most people here assume the reader is familiar with the very
> basics of working a computer.  But if you want it spelt out, you would
> generally do :
>
>     $ cd ~/projects/project_a
>     $ make
>     $ cd ~/projects/project_b
>     $ make
>
> Does that answer your question?

Humm. I detect a little bit of OCD on Bart's side? Am I wrong?

>
> If the two projects are closely connected, you might have them organised
> as sub-directories of "project".  Then at the top-level, you could have
> a makefile with:
>
>
> all : project_a project_b
> .PHONY : project_a project_b
>
> project_a :
>     $(MAKE) -C project_a
>
> project_b :
>     $(MAKE) -C project_b
>
>
> Then you can build project_a by going to the project_a directory and
> typing "make", or going to the top-level project directory and typing
> "make project_a", or going to the top-level project directory and typing
> "make" to build project_a and project_b, together.  (This is often
> particularly nice when using parallel make to make use of all the cores
> in your expensive computer.)
>
>>
>> We've covered this before. While I quite like sensible defaults, where
>> C compilers tend to be sticklers for dotting all the Is, 'make' goes a
>> little too far the other way.
>>
>> Before typing 'make', you'd better be sure you're in the right place!
>>
>
> The same is true of getting undressed, and indeed most things in life.
>

On 2024-01-11, Scott Lurndal <scott@slp53.sl.home> wrote:
> That's fine, but don't make it a hidden file. A hidden file
> can be used to record tool preferences, but the file describing
> the project itself shouldn't be hidden.

That ship mostly sailed with names like .svn/ and .git/.

--
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-11, bart <bc@freeuk.com> wrote:
> On 11/01/2024 16:13, Kaz Kylheku wrote:
>> On 2024-01-11, bart <bc@freeuk.com> wrote:
>>> On 11/01/2024 02:46, Kaz Kylheku wrote:
>>>> The fixed name of the makefile is a great idea. If I could change
>>>> anything, I would call it ".makefile".
>>>
>>> I think it's a terrible idea. It's like me deciding that when I type:
>>>
>>> mcc
>>>
>>> by itself, it will automatically compile xyzzy.c, every time. What it
>>> actually does is a bit saner, it shows some help text:
>>
>> No, that's like mcc, if not given options, finding a .mccproj
>> file and building what is described there.
>>
>> I.e. "build the mcc project that's associated with this directory,
>> via that directory's .mccproject property".
>>
>> You need a fixed name to attach a property to the directory.
>
>
> That would be more like a configuration file. It can control the
> behaviour of an interactive op, or run some sort of prelude script, or
> load some data, prior to starting a normal session.
>
> It wouldn't see such a file, act on it, then (perhaps silently) stop.
>
> If I wanted that behaviour, I would script it, using the same commands
> that I've been familiar with for decades from my OS's command prompt.

When I do something in a Makefile, I'm also using the same commands
I've been familiar with for decades.

> The name of the script would usually be specific to the project, for
> example, 'makeccia' will run 'makeccia.bat'. The '-a' suffix refers to
> the floppy A: drive, so it is a very old example.

Anyone still working with .BAT files and railing against Unix
is like a WWII soldier still in the trenches in 1975, refusing
to surrender.

I worked with .BAT files in the MS-DOS era. I left that stuff behind
just as the DOS era was coming to an end, and I went off to university.
Over the years, I had only rare, minor interactions with batch files on
Windows.

it's a very poor scripting language, that Microsoft replaced with the
PowerShell. Each time I had to interact with it over the past 30
years, I was reminded of how bad it is. It's like a freshman student's
weekend project.

The main weakness is that DOS and Windows programs receive the
entire command line as a single string, which they must delimit
themselves into arguments.

No two programs agree on how that should be done, beyond the
the trivial case when the command line has nothing but clumps of
alphanumeric characters separated by spaces.

By the way that @ thing you see in Batch files ("@echo off") is
obviously cribbed from Makefiles! Make prints the commands that it
executes, except ones that have a @ as the first character.

Everything in DOS was cribbed from Unix, badly: piping | operator
that doesn't actually run processes concurrently, < > redirection
oeprators, device names mapped into the filesystem (but in the most
stupid way imaginable, not like /dev). The parent directory being ..,
but not actually due to there being a parent link, only faked out ...
They couldn't make up their minds between / and \ so they stupidly
supported *both* as separators, and put in a flag into the command
interpreter to choose which one it would print.

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

Kaz Kylheku <433-929-6894@kylheku.com> writes:
>On 2024-01-11, Scott Lurndal <scott@slp53.sl.home> wrote:
>> That's fine, but don't make it a hidden file. A hidden file
>> can be used to record tool preferences, but the file describing
>> the project itself shouldn't be hidden.
>
>That ship mostly sailed with names like .svn/ and .git/.

That's metadata that will never be edited directly, but rather
is managed by the appropriate tool. The input
to Make will be edited by the end user unless a command line tool
such as git or svn manage the contents completely from the command
line.

Even if it has a gui UI, there should be mechanisms to build and update a
project without the gui.

On 11/01/2024 22:02, Kaz Kylheku wrote:
> On 2024-01-11, bart <bc@freeuk.com> wrote:

> I worked with .BAT files in the MS-DOS era. I left that stuff behind
> just as the DOS era was coming to an end, and I went off to university.
> Over the years, I had only rare, minor interactions with batch files on
> Windows.
>
> it's a very poor scripting language,

I used the word 'script' loosely.

I make a distinction between command-languages, which generally have
only a linear sequence of commands, no looping or conditional code; and
proper scripting languages which are full languages.

BAT files I consider command languages where you just write commands A,
B, C ... one after the other.

For building programs, I've never needed anything more sophisticated.
This is the batch file for building my C compiler from source and
replacing the current production compiler:

mm -opt cc.m
copy cc.exe \m\mcc.exe
copy headers\windows.h \m

This involves working with 62 source and support files. The assembler
that mcc depends on is managed separately. The BAT file to update that
is this, which involves 15 modules:

mm -opt aa.m
copy aa.exe \m\aa.exe

You can see that there are very, very few demands in these 'scripts'. If
I need real scripting, I have a perfectly good one of my own.

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.

> that Microsoft replaced with the
> PowerShell. Each time I had to interact with it over the past 30
> years, I was reminded of how bad it is. It's like a freshman student's
> weekend project

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?

> The main weakness is that DOS and Windows programs receive the
> entire command line as a single string, which they must delimit
> themselves into arguments.

Really? There's a function called __getmainargs() (you'll find it inside
msvcrt.dll), that produces a list of separated parameters as would be
supplied to a C program that uses 'main(n, args)'.

Otherwise, calling GetCommandLine() and parsing a string is no big deal.
That's exactly how languages like Python and even C (using 'fgets',
forget 'scanf') process user input after the command line is out out of
the way.

> No two programs agree on how that should be done, beyond the
> the trivial case when the command line has nothing but clumps of
> alphanumeric characters separated by spaces.

So how does it work with, as I touched on, the 1000s of lines that might
come after the command line, and or the millions of lines that might be
read from a text file?

> Everything in DOS was cribbed from Unix, badly: piping | operator
> that doesn't actually run processes concurrently, < > redirection
> oeprators, device names mapped into the filesystem (but in the most
> stupid way imaginable, not like /dev). The parent directory being ..,
> but not actually due to there being a parent link, only faked out ...
> They couldn't make up their minds between / and \ so they stupidly
> supported *both* as separators, and put in a flag into the command
> interpreter to choose which one it would print.

OK. I can't say I'm that interested in OSes or shell languages. The
latter are just a way to copy files or launch programs. The former
merely supplied a file system for the first decade or two I was coding.

Of the first three OSes I was exposed to, two were from DEC, one from
ICL. Then there was a period when I was working with bare boards, and
then on small machines which ran a CP/M clone that my company wrote.

MSDOS followed later; I didn't remember doing anything much with that
either.

The \ / think I agree is messy, using only / is simpler, and easier to
locate if using lots of different keyboards. And using LF line
delimiters rather than CRLF, made more sense as soon as people moved to
VDUs. However, I support either.

(Here, gcc gets badly confused between \ and /, but listing the things
gcc gets wrong in its CLI would be a long article by itself.)

Apart from that there's nothing I desperately need from Linux shell
programs; even BAT is overkill most of the time.

I'm be interested in what you think 'make' would do for me given that my
needs are utterly simple. Partly that is because of my 'mm' compiler,
but it would be little different if all my stuff was written in C.

I just make the effort to keep things simple.

Here's another little demo, which is getting my C compiler to work on
Linux (although as a cross-compiler). I was going to write a script but
the first part is only one line, which is to convert from my language to C:

c:\cx>mc -c -linux cc
M6 Compiling cc.m---------- to cc.c

The next part has to be done under WSL:

root@XXX:/mnt/c/cx# gcc cc.c -omcc -lm -ldl -fno-builtin

I've got my compiler binary 'mcc', now I might as well try it on itself,
but I can only produce an ASM file here:

root@XXX:/mnt/c/cx# ./mcc -s cc # -s == -S
Compiling cc.c to cc.asm

To process further, I need to get back to Windows:

c:\cx>aa cc
Assembling cc.asm to cc.exe
Error: Can't find external function: tcgetattr cc.asm

There's a small problem since I used the cc.c produced for Linux
(-linux), which has some OS-specific routines.

But it doesn't matter (it still translated 30K lines of C to 100K lines
of assembly for Win64 ABI, under Linux).

The point of interest is, how would the famous 'make' have helped me
here? I switched from Windows to Linux and back to Windows, and in each
case there was only 1 or 2 lines to type.

On 2024-01-11, Scott Lurndal <scott@slp53.sl.home> wrote:
> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>>On 2024-01-11, Scott Lurndal <scott@slp53.sl.home> wrote:
>>> That's fine, but don't make it a hidden file. A hidden file
>>> can be used to record tool preferences, but the file describing
>>> the project itself shouldn't be hidden.
>>
>>That ship mostly sailed with names like .svn/ and .git/.
>
> That's metadata that will never be edited directly, but rather
> is managed by the appropriate tool.

Oh, it's touched all the time.

$ vi .git/config

Messing with hooks in .git/hooks.

Commit message edited in .git/COMMIT_EDITMSG.

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

> Why, what hairy stuff are you doing that requires a language as complex
> as 'make' and a shell environment as capable as 'bash'?

Not OP, so please forgive me for jumping in, but I've found over the
years that source distributions-- especially multi-platform source
distributions --often require quite a bit more attention on the build side.

Supporting a non-trivial program on e.g. three different CPU
architectures with just as many (or more!) compilers across many
different versions of several operating systems can quickly become
impossible with one dedicated script per variation.

Binary distributions are a different story, of course.

bart <bc@freeuk.com> writes:
> On 11/01/2024 22:02, Kaz Kylheku wrote:
>> On 2024-01-11, bart <bc@freeuk.com> wrote:
>> I worked with .BAT files in the MS-DOS era. I left that stuff behind
>> just as the DOS era was coming to an end, and I went off to university.
>> Over the years, I had only rare, minor interactions with batch files on
>> Windows.
>> it's a very poor scripting language,
>
> I used the word 'script' loosely.
>
> I make a distinction between command-languages, which generally have
> only a linear sequence of commands, no looping or conditional code;
> and proper scripting languages which are full languages.
>
> BAT files I consider command languages where you just write commands
> A, B, C ... one after the other.

BAT files can also have IF and FOR statements. The program that
processes them, cmd.exe, is similar in many ways to a Unix shell, but
with substantially different syntax. Both are also used to type
commands interactively.

Of course you can write BAT files with no control flow. You can do the
same thing with Unix shell scripts.

I presume the distinction you're making is useful for you, but it's not
inherent in the tools.

[...]

--
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 11/01/2024 22:18, Kaz Kylheku wrote:
> On 2024-01-11, Scott Lurndal <scott@slp53.sl.home> wrote:
>> That's fine, but don't make it a hidden file. A hidden file
>> can be used to record tool preferences, but the file describing
>> the project itself shouldn't be hidden.
>
> That ship mostly sailed with names like .svn/ and .git/.
>

These are not part of the project - they are metadata for coordinating
how the project is stored and how changes are tracked. I can take a
project from a subversion and transfer it to a git server or zip it up
and post it - the makefile (or other build system files and scripts)
must be part of that, while .svn and .git directories most certainly are
not part of that.

You could argue that .gitignore is a useful file to track, and I would
not mind if subversion had a similar file (or, ideally, also read and
used .gitignore files). And it would arguably have been better if this
file had been called "git.ignore" instead.

But files that control actions and need to be tracked should not be
hidden files. Hidden files are for user preferences, or local temporary
files.

On 11/01/2024 19:49, bart wrote:
>
> The name of the script would usually be specific to the project, for
> example, 'makeccia' will run 'makeccia.bat'. The '-a' suffix refers to
> the floppy A: drive, so it is a very old example.
>
To be clear here - I don't think anyone would greatly object if "make"
required an explicit makefile name, rather than using a default
filename. It is more convenient to type "make" than "make -f
project.mak", but some people prefer to do exactly that, rather than
using a default makefile. It is particularly convenient if you have
several small projects in the same directory, and don't want to combine
a single makefile.

And of course if "make" had originally required an explicit filename,
there are plenty of *nix idioms and tricks to simplify things - adding a
shebang to a makefile to make it executable, shell aliases, bash
scripts, etc. People always manage to make things work in a way that is
convenient for them.

But since "make" uses "makefile" by default, that's what most people use.

On 12/01/2024 00:20, bart wrote:
> On 11/01/2024 22:02, Kaz Kylheku wrote:
>> On 2024-01-11, bart <bc@freeuk.com> wrote:
>
>> I worked with .BAT files in the MS-DOS era.  I left that stuff behind
>> just as the DOS era was coming to an end, and I went off to university.
>> Over the years, I had only rare, minor interactions with batch files on
>> Windows.
>>
>> it's a very poor scripting language,
>
> I used the word 'script' loosely.
>
> I make a distinction between command-languages, which generally have
> only a linear sequence of commands, no looping or conditional code; and
> proper scripting languages which are full languages.
>

People can mean different things by "script" and "scripting language",
so it is good that you are making this clear.

> BAT files I consider command languages where you just write commands A,
> B, C ... one after the other.
>
> For building programs, I've never needed anything more sophisticated.
> This is the batch file for building my C compiler from source and
> replacing the current production compiler:
>
>     mm -opt cc.m
>     copy cc.exe \m\mcc.exe
>     copy headers\windows.h \m
>
> This involves working with 62 source and support files. The assembler
> that mcc depends on is managed separately. The BAT file to update that
> is this, which involves 15 modules:
>
>     mm -opt aa.m
>     copy aa.exe \m\aa.exe
>
> You can see that there are very, very few demands in these 'scripts'. If
>  I need real scripting, I have a perfectly good one of my own.
>
> 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, 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.

>
>> that Microsoft replaced with the
>> PowerShell. Each time I had to interact with it over the past 30
>> years, I was reminded of how bad it is. It's like a freshman student's
>> weekend project
>
> 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?

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.

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

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

At least with bash, what you type equates to what you might type
interactively. I doubt there is a an interactive, REPL-style make (or
maybe there is; I wouldn't be suprised).

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

But take the related trio gcc, as and ld.

gcc and ld behave as expected with no input (with gcc it's a 'fatal
error'; with ld it's a more restrained 'no input files').

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

My equivalent says this:

c:\c>aa
AA2.0 Assembler/Linker 10-Jan-2024
Usage:
aa filename[.asm] # Assemble filename.asm to
filename.exe
aa -help # Show other options

If you're curious about what 'as' expects and speculatively try 'as
--help', it displays 167 dense lines.

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.

One could even just be an alias of the other to avoid two copies. The
program could detect what name it was invoked under, and operate in a
different mode or with a different option.

As demonstrated here under Windows: 'mm' is a compiler with an option to
immediately run the program just compiled, without generating an EXE:

c:\mx>mm -run hello
Compiling hello.m to memory
Hello World! 16:20:21

However, if I make a copy called 'ms.exe' (I don't know how to do
aliases on Windows):

c:\mx>copy mm.exe ms.exe
1 file(s) copied.

Then it will automatically invoke that option, and also make it less
verbose to give the illusion it's directly running from source, which it is:

c:\mx>ms hello
Hello World! 16:21:52

Here is a more impressive example:

c:\cx>\mx\ms cc hello
Compiling hello.c to hello.exe

Here, it's first building my C compiler from source, then using that to
compile hello.c. (It adds 0.1 seconds to compile-time; it's still faster
than compiling it with gcc!)

Anyway, 'as' could be a lot better; just saying...

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

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

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

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.

> At least with bash, what you type equates to what you might type
> interactively. I doubt there is a an interactive, REPL-style make (or
> maybe there is; I wouldn't be suprised).
>
>
>>> 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.
>
> But take the related trio gcc, as and ld.
>
> gcc and ld behave as expected with no input (with gcc it's a 'fatal
> error'; with ld it's a more restrained 'no input files').
>
> 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.)

Yes, "as" can work with piped input. Yes, on real OS's this is a common
way to use it. Windows has, surprising no one, only a half-arsed and
inefficient pipe implementation, so it is more common to use temporary
files for this sort of thing. (I am not familiar with TDM's builds and
packaging of gcc and friends, but with mingw-64 builds it is certainly
possible to use pipes. You simply pass the flag "-pipe" to gcc.)

>
> My equivalent says this:
>
>   c:\c>aa
>   AA2.0 Assembler/Linker 10-Jan-2024
>   Usage:
>           aa filename[.asm]           # Assemble filename.asm to
> filename.exe
>           aa -help                    # Show other options
>
> 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.