On 23/08/2023 18:33, David Brown wrote:
> On 23/08/2023 18:54, Anton Shepelev wrote:
>> Bart quoth:
>>
>>> Build systems will get more complex and impenetrable, not
>>> simpler and more transparent.
>>
>> Bart's law.
>>
>> Borland and Free Pascal compilers do not require a separate
>> build system (nor a project file, or solution) to build a
>> large modular program. The modern reliance on super
>> compicated tools for simple tasks is horrifying. It makes
>> the programmer feel as a servant rathern than a demiurge.
>>
>
> The version of "make" that I used with DOS and Windows for about a
> decade came with Borland Pascal.  (It might even have been Turbo Pascal,
> before the renaming.)
>
> Mostly I used the IDE for building Pascal projects, rather than a
> makefile.  I used "make" primarily for assembly code in those days.

The first language product I ever timed was an assembler running on an
8-bit Z80 with a 2.5Mhz clock. Its throughput was nearly 2K lines per
second (memory-to-memory).

That's interesting because the largest program you could write was 64KB,
but in practice half that to allow space for the OS, data, video memory etc.

That means it couldn't take more than 16 seconds (or 10 seconds on 4Mhz
device) to assemble all the code of the program.

So, I wonder what benefit a 'make' program would provide. Given that, on
a floppy system, you would need to load make, load the makefile, access
the directory info for each ASM file to check compilation times, which
all cuts into any potential savings of avoiding loading some ASM files.

In any case, projects were simple enough that you were well aware of any
dependencies yourself.

So 'make' (which I'd never used and perhaps had never heard of), was
useless. Better to direct my efforts at resident assemblers and
compilers to minimise disk activity. (Would 'make' have invoked the
assembler separately for each source needing compiling?)

On Wednesday, 23 August 2023 at 21:13:24 UTC+1, Bart wrote:
> On 23/08/2023 18:33, David Brown wrote:
> > On 23/08/2023 18:54, Anton Shepelev wrote:
> >> Bart quoth:
> >>
> >>> Build systems will get more complex and impenetrable, not
> >>> simpler and more transparent.
> >>
> >> Bart's law.
> >>
> >> Borland and Free Pascal compilers do not require a separate
> >> build system (nor a project file, or solution) to build a
> >> large modular program. The modern reliance on super
> >> compicated tools for simple tasks is horrifying. It makes
> >> the programmer feel as a servant rathern than a demiurge.
> >>
> >
> > The version of "make" that I used with DOS and Windows for about a
> > decade came with Borland Pascal. (It might even have been Turbo Pascal,
> > before the renaming.)
> >
> > Mostly I used the IDE for building Pascal projects, rather than a
> > makefile. I used "make" primarily for assembly code in those days.
> The first language product I ever timed was an assembler running on an
> 8-bit Z80 with a 2.5Mhz clock. Its throughput was nearly 2K lines per
> second (memory-to-memory).
>
> That's interesting because the largest program you could write was 64KB,
> but in practice half that to allow space for the OS, data, video memory etc.
>
> That means it couldn't take more than 16 seconds (or 10 seconds on 4Mhz
> device) to assemble all the code of the program.
>
> So, I wonder what benefit a 'make' program would provide. Given that, on
> a floppy system, you would need to load make, load the makefile, access
> the directory info for each ASM file to check compilation times, which
> all cuts into any potential savings of avoiding loading some ASM files.
>
> In any case, projects were simple enough that you were well aware of any
> dependencies yourself.
>
> So 'make' (which I'd never used and perhaps had never heard of), was
> useless. Better to direct my efforts at resident assemblers and
> compilers to minimise disk activity. (Would 'make' have invoked the
> assembler separately for each source needing compiling?)
>
Back in the day, hobbyists would code games on an assembler running on
the games platform itself. But serious commercial developers had cross
compilers. It was faster, it gave them access to more tools, and you
didn't have the problem that the assembler itself could compete with
the game for resources.
The host platform would still be a small computer by modern standards.
But it would be considerably bigger than the target platform. And it
would have a way of invoking programs relatively efficiently. On the
target platform, it would often take several minutes or so for a program
to load and boot.
So make would be useful. It would give you a list of the source files
in the program and the compiler options used to build them. And it
would manage the dependencies. However the programs were so
small and tended to have such a flat structure that this wasn't a major
advantage over rebuilding everything.
But make isn't too bad in active development. Because when it breaks,
you maintain it, in a way similar to maintaining the actual source.
The problems come when make breaks when moving code to a new
platform, and the person receiving the code is new to the development
of the project. Then it can be very difficult.

David Brown to Anton Shepelev:

> > Borland and Free Pascal compilers do not require a
> > separate build system (nor a project file, or solution)
> > to build a large modular program. The modern reliance on
> > super compicated tools for simple tasks is horrifying.
> > It makes the programmer feel as a servant rathern than a
> > demiurge.
>
> The version of "make" that I used with DOS and Windows for
> about a decade came with Borland Pascal. (It might even
> have been Turbo Pascal, before the renaming.)

Yes, the Borland Pascal distribution on vetusware.com
includes a make utility, but I am not at all certain it is
required to build a modular program. I think the compiler
will figure out the dependency hierarcy between the various
source files itself, reserving `make' for especially complex
cases.

> Mostly I used the IDE for building Pascal projects, rather
> than a makefile.

So did I, but the FreePascal command-line compiler is
perfectly usable without make, because the language supports
real modules and spares the programmer specifying the
dependency hierarchy by hand. Libraries and paths are
specified in configuration file fpc.cfg.

FreePascal's make uses makefiles written in Pascal:

https://wiki.freepascal.org/FPMake

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

On 23/08/2023 22:13, Bart wrote:
> On 23/08/2023 18:33, David Brown wrote:
>> On 23/08/2023 18:54, Anton Shepelev wrote:
>>> Bart quoth:
>>>
>>>> Build systems will get more complex and impenetrable, not
>>>> simpler and more transparent.
>>>
>>> Bart's law.
>>>
>>> Borland and Free Pascal compilers do not require a separate
>>> build system (nor a project file, or solution) to build a
>>> large modular program. The modern reliance on super
>>> compicated tools for simple tasks is horrifying. It makes
>>> the programmer feel as a servant rathern than a demiurge.
>>>
>>
>> The version of "make" that I used with DOS and Windows for about a
>> decade came with Borland Pascal.  (It might even have been Turbo
>> Pascal, before the renaming.)
>>
>> Mostly I used the IDE for building Pascal projects, rather than a
>> makefile.  I used "make" primarily for assembly code in those days.
>
> The first language product I ever timed was an assembler running on an
> 8-bit Z80 with a 2.5Mhz clock. Its throughput was nearly 2K lines per
> second (memory-to-memory).
>
> That's interesting because the largest program you could write was 64KB,
> but in practice half that to allow space for the OS, data, video memory
> etc.
>
> That means it couldn't take more than 16 seconds (or 10 seconds on 4Mhz
> device) to assemble all the code of the program.
>
> So, I wonder what benefit a 'make' program would provide.

I didn't run "make" on a Z80. I ran it on a PC - cross-assembling for
microcontrollers.

"make" let me keep all the information and flags needed for assembling
and linking the program in one neat, convenient file. And because I
focus my programming on writing modular, organised, maintainable code, I
might have 20 or 30 assembly files for a 16 KB program, and at least as
many include files. There would be lots of macros too, avoiding
error-prone manual duplication. On good old DOS + Win3.1 that takes time.

My makefiles also handle things like generating outputs in different
formats (such as for debugging, or burning into EEPROMs, or zip files
for sending to customers), and sometimes also for automating
downloading, running or updating the software on cards.

There are /lots/ of things you can do with makefiles for organising
projects and automating work on them, besides just avoiding unnecessary
compiles or assembly runs.

> Given that, on
> a floppy system, you would need to load make, load the makefile, access
> the directory info for each ASM file to check compilation times, which
> all cuts into any potential savings of avoiding loading some ASM files.
>

Sorry, that makes no sense. If your filesystem is slow (and I was
working with a hard disk system, not a floppy system - but it was still
slow), then reading "make.exe" and "makefile" is a big win if it avoids
reading or writing at least two files, in comparison to always doing a
clean build.

> In any case, projects were simple enough that you were well aware of any
> dependencies yourself.

Usually in those days I wrote the dependency lists manually in the makefile.

>
> So 'make' (which I'd never used and perhaps had never heard of), was
> useless. Better to direct my efforts at resident assemblers and
> compilers to minimise disk activity. (Would 'make' have invoked the
> assembler separately for each source needing compiling?)
>

Your experience is your own. My experience is that "make" is a very
useful too that I have used most work days over the last 30 years. (I
probably also used it a bit at university before that.)

On 2023-08-23, Bart <bc@freeuk.com> wrote:
> On 23/08/2023 18:33, David Brown wrote:
>> On 23/08/2023 18:54, Anton Shepelev wrote:
>>> Bart quoth:
>>>
>>>> Build systems will get more complex and impenetrable, not
>>>> simpler and more transparent.
>>>
>>> Bart's law.
>>>
>>> Borland and Free Pascal compilers do not require a separate
>>> build system (nor a project file, or solution) to build a
>>> large modular program. The modern reliance on super
>>> compicated tools for simple tasks is horrifying. It makes
>>> the programmer feel as a servant rathern than a demiurge.
>>>
>>
>> The version of "make" that I used with DOS and Windows for about a
>> decade came with Borland Pascal.  (It might even have been Turbo Pascal,
>> before the renaming.)
>>
>> Mostly I used the IDE for building Pascal projects, rather than a
>> makefile.  I used "make" primarily for assembly code in those days.
>
> The first language product I ever timed was an assembler running on an
> 8-bit Z80 with a 2.5Mhz clock. Its throughput was nearly 2K lines per
> second (memory-to-memory).
>
> That's interesting because the largest program you could write was 64KB,
> but in practice half that to allow space for the OS, data, video memory etc.
>
> That means it couldn't take more than 16 seconds (or 10 seconds on 4Mhz
> device) to assemble all the code of the program.
>
> So, I wonder what benefit a 'make' program would provide. Given that, on
> a floppy system, you would need to load make, load the makefile, access
> the directory info for each ASM file to check compilation times, which
> all cuts into any potential savings of avoiding loading some ASM files.

Unix already had make as far back as 1979.

Here is the source tree for the utilities:

https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd

There are some single file .c utilities and some subdirectories.

There is a "makeall" shell script which invokes something amusingly
called "cmake" on the top level files, individually.

This cmake is a script in the cmake/ subdirectory. A silly thing it has
a big case statement that switches on the program name and branches to a
customized compile command. Many of them are identical except for names;
it's obviously copy-paste.

Most of the subdirectories have makefiles (lower case "makefile";
they hadn't yet thought of supporting "Makefile" so that it would
appear above lower-cased source file names; modern make still looks
for a "makefile" too).

The makefiles are tidy; they look better than an equivalent script.
By equivalent I mean a script that handles the dependencies for
incremental rebuilds.

Here is adb/makefile from V7 Unix, dated January 11, 1979:

CFLAGS = -i -O

all: adb

cmp: adb
cmp adb /bin/adb
rm adb *.o

cp: adb
cp adb /bin/adb
rm adb *.o

adb: access.o command.o expr.o findfn.o
adb: format.o input.o opset.o main.o
adb: message.o output.o pcs.o print.o
adb: runpcs.o setup.o sym.o
adb:; cc -o adb -i *.o

access.o: defs.h
command.o: defs.h
expr.o: defs.h
findrtn.o: defs.h
format.o: defs.h
input.o: defs.h
main.o: defs.h
message.o: mac.h mode.h
output.o: defs.h
pcs.o: defs.h
print.o: defs.h
runpcs.o: defs.h
setup.o: defs.h
sym.o: defs.h

This is very tidy and more or less how make should be used today.

We can see that in 1979, make already had built-in rules for compiling. We
don't see the compile command anywhere, or how CFLAGS is pulled into the build.

It must have been beneficial to those coders to only have to
recompile output.c to output.o when output.c was touched.

(They did a counterproductive thing with the combined "defs.h" there
though, if they wanted the best possible incremental rebuild
experience.)

Anyway, most of the crap you see around make-based builds is the result
of people not understanding how to use make, and evidence of avoiding
learning it.

When people don't know how to get a desired behavior out of make,
they resort to working around it with code generation, additional
scripts and whatnot.

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

On 24/08/2023 16:51, Kaz Kylheku wrote:
> On 2023-08-23, Bart <bc@freeuk.com> wrote:
>> On 23/08/2023 18:33, David Brown wrote:
>>> On 23/08/2023 18:54, Anton Shepelev wrote:
>>>> Bart quoth:
>>>>
>>>>> Build systems will get more complex and impenetrable, not
>>>>> simpler and more transparent.
>>>>
>>>> Bart's law.
>>>>
>>>> Borland and Free Pascal compilers do not require a separate
>>>> build system (nor a project file, or solution) to build a
>>>> large modular program. The modern reliance on super
>>>> compicated tools for simple tasks is horrifying. It makes
>>>> the programmer feel as a servant rathern than a demiurge.
>>>>
>>>
>>> The version of "make" that I used with DOS and Windows for about a
>>> decade came with Borland Pascal.  (It might even have been Turbo Pascal,
>>> before the renaming.)
>>>
>>> Mostly I used the IDE for building Pascal projects, rather than a
>>> makefile.  I used "make" primarily for assembly code in those days.
>>
>> The first language product I ever timed was an assembler running on an
>> 8-bit Z80 with a 2.5Mhz clock. Its throughput was nearly 2K lines per
>> second (memory-to-memory).
>>
>> That's interesting because the largest program you could write was 64KB,
>> but in practice half that to allow space for the OS, data, video memory etc.
>>
>> That means it couldn't take more than 16 seconds (or 10 seconds on 4Mhz
>> device) to assemble all the code of the program.
>>
>> So, I wonder what benefit a 'make' program would provide. Given that, on
>> a floppy system, you would need to load make, load the makefile, access
>> the directory info for each ASM file to check compilation times, which
>> all cuts into any potential savings of avoiding loading some ASM files.
>
> Unix already had make as far back as 1979.
>
> Here is the source tree for the utilities:
>
> https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd
>
> There are some single file .c utilities and some subdirectories.
>
> There is a "makeall" shell script which invokes something amusingly
> called "cmake" on the top level files, individually.
>
> This cmake is a script in the cmake/ subdirectory. A silly thing it has
> a big case statement that switches on the program name and branches to a
> customized compile command. Many of them are identical except for names;
> it's obviously copy-paste.
>
> Most of the subdirectories have makefiles (lower case "makefile";
> they hadn't yet thought of supporting "Makefile" so that it would
> appear above lower-cased source file names; modern make still looks
> for a "makefile" too).
>
> The makefiles are tidy; they look better than an equivalent script.
> By equivalent I mean a script that handles the dependencies for
> incremental rebuilds.
>
> Here is adb/makefile from V7 Unix, dated January 11, 1979:
>
> CFLAGS = -i -O
>
> all: adb
>
> cmp: adb
> cmp adb /bin/adb
> rm adb *.o
>
> cp: adb
> cp adb /bin/adb
> rm adb *.o
>
> adb: access.o command.o expr.o findfn.o
> adb: format.o input.o opset.o main.o
> adb: message.o output.o pcs.o print.o
> adb: runpcs.o setup.o sym.o
> adb:; cc -o adb -i *.o
>
>
> access.o: defs.h
> command.o: defs.h
> expr.o: defs.h
> findrtn.o: defs.h
> format.o: defs.h
> input.o: defs.h
> main.o: defs.h
> message.o: mac.h mode.h
> output.o: defs.h
> pcs.o: defs.h
> print.o: defs.h
> runpcs.o: defs.h
> setup.o: defs.h
> sym.o: defs.h
>
> This is very tidy and more or less how make should be used today.
>
> We can see that in 1979, make already had built-in rules for compiling. We
> don't see the compile command anywhere, or how CFLAGS is pulled into the build.
>
> It must have been beneficial to those coders to only have to
> recompile output.c to output.o when output.c was touched.

Some observations:

* This is a C project? If so there is a remarkable lack of .c files!

* opset.o has no dependencies?

* There is a lot of repetition of defs.h

* All the modules (except opset.o) are named twice

* How are the dependencies derived? I guess either manually, which
can be error prone, or an extra tool is needed that understands
C code

* The project seems simple enough that you will know:

* No .c file depends on any other. Any edit to a .c
file only requires compiling that one file

* With any changes to defs.h, you might as well compile the lot

* At best, the makefile lists the modules that are submitted to the
linker

In this case, you can easily do without 'make'.

I can't remember how I built my programs in 1979. But three years later
with my own tools, I would use a project file that would look like this
for a C project file, in 2023:

run adb

module access.c
module command.c
module expr.c
module findrtn.c
module format.c
module input.c
module main.c
module message.c
module output.c
module pcs.c
module print.c
module runpcs.c
module setup.c
module sym.c

header defs.h
header mac.h
header mode.h

In 1980s it wouldn't have been much different. It's used by an IDE which:

* Knows which compiler has been configured (using an actual config
file)

* Uses the project name (adb.pro) as the default for the executable

* Knows it compiles only files prefixed by 'module'

Tyical commands are C, CA, L, R to compile, compile-all, link, run.
Other options can be added here.

Early versions of that IDE had a resident compiler and editor. That IDE
in 2023 is a 75KB script.

However my non-C languages why, while they still use a project file,
don't know to be told what the modules. That info (together with any
extras such as DLLs) is at the start of the source code. Then only C is
used, no CA or L commands needed.

(I need to manually sync the files in the project file, with those in
those; that part is not well developed. But the latter tends to have
also sorts of extra junk too, like docs.)

This is not the file used to create distributions of binaries. Nor is
that used by the enduser to install binaries.

Bart <bc@freeuk.com> writes:
>On 24/08/2023 16:51, Kaz Kylheku wrote:
>> On 2023-08-23, Bart <bc@freeuk.com> wrote:
>>> On 23/08/2023 18:33, David Brown wrote:
>>>> On 23/08/2023 18:54, Anton Shepelev wrote:
>>>>> Bart quoth:
>>>>>
>>>>>> Build systems will get more complex and impenetrable, not
>>>>>> simpler and more transparent.
>>>>>
>>>>> Bart's law.
>>>>>
>>>>> Borland and Free Pascal compilers do not require a separate
>>>>> build system (nor a project file, or solution) to build a
>>>>> large modular program. The modern reliance on super
>>>>> compicated tools for simple tasks is horrifying. It makes
>>>>> the programmer feel as a servant rathern than a demiurge.
>>>>>
>>>>
>>>> The version of "make" that I used with DOS and Windows for about a
>>>> decade came with Borland Pascal.  (It might even have been Turbo Pascal,
>>>> before the renaming.)
>>>>
>>>> Mostly I used the IDE for building Pascal projects, rather than a
>>>> makefile.  I used "make" primarily for assembly code in those days.
>>>
>>> The first language product I ever timed was an assembler running on an
>>> 8-bit Z80 with a 2.5Mhz clock. Its throughput was nearly 2K lines per
>>> second (memory-to-memory).
>>>
>>> That's interesting because the largest program you could write was 64KB,
>>> but in practice half that to allow space for the OS, data, video memory etc.
>>>
>>> That means it couldn't take more than 16 seconds (or 10 seconds on 4Mhz
>>> device) to assemble all the code of the program.
>>>
>>> So, I wonder what benefit a 'make' program would provide. Given that, on
>>> a floppy system, you would need to load make, load the makefile, access
>>> the directory info for each ASM file to check compilation times, which
>>> all cuts into any potential savings of avoiding loading some ASM files.
>>
>> Unix already had make as far back as 1979.
>>
>> Here is the source tree for the utilities:
>>
>> https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd
>>
>> There are some single file .c utilities and some subdirectories.
>>
>> There is a "makeall" shell script which invokes something amusingly
>> called "cmake" on the top level files, individually.
>>
>> This cmake is a script in the cmake/ subdirectory. A silly thing it has
>> a big case statement that switches on the program name and branches to a
>> customized compile command. Many of them are identical except for names;
>> it's obviously copy-paste.
>>
>> Most of the subdirectories have makefiles (lower case "makefile";
>> they hadn't yet thought of supporting "Makefile" so that it would
>> appear above lower-cased source file names; modern make still looks
>> for a "makefile" too).
>>
>> The makefiles are tidy; they look better than an equivalent script.
>> By equivalent I mean a script that handles the dependencies for
>> incremental rebuilds.
>>
>> Here is adb/makefile from V7 Unix, dated January 11, 1979:
>>
>> CFLAGS = -i -O
>>
>> all: adb
>>
>> cmp: adb
>> cmp adb /bin/adb
>> rm adb *.o
>>
>> cp: adb
>> cp adb /bin/adb
>> rm adb *.o
>>
>> adb: access.o command.o expr.o findfn.o
>> adb: format.o input.o opset.o main.o
>> adb: message.o output.o pcs.o print.o
>> adb: runpcs.o setup.o sym.o
>> adb:; cc -o adb -i *.o
>>
>>
>> access.o: defs.h
>> command.o: defs.h
>> expr.o: defs.h
>> findrtn.o: defs.h
>> format.o: defs.h
>> input.o: defs.h
>> main.o: defs.h
>> message.o: mac.h mode.h
>> output.o: defs.h
>> pcs.o: defs.h
>> print.o: defs.h
>> runpcs.o: defs.h
>> setup.o: defs.h
>> sym.o: defs.h
>>
>> This is very tidy and more or less how make should be used today.
>>
>> We can see that in 1979, make already had built-in rules for compiling. We
>> don't see the compile command anywhere, or how CFLAGS is pulled into the build.
>>
>> It must have been beneficial to those coders to only have to
>> recompile output.c to output.o when output.c was touched.
>
>Some observations:
>
>* This is a C project? If so there is a remarkable lack of .c files!

The default rules built into make(1) include a rule like

%.o: %.c
$(CC) $(CFLAGS) -o $@ -c $<

adb: access.o ...

Means that the target 'adb' is dependent on access.o (and others elided here for brevity)

So 'all' (the first target in the makefile) is dependent upon 'adb'.
'adb' is dependent upon a bunch of things, in the order presented in
the make file.

To build 'all' requires building 'adb'. building 'adb' requires bulding
all the relevent dependencies.

make will note that there is an 'access.c' with the same name as
'access.o' in the current working directory and will build access.o
using the default %.o: %.c rule.

Once all the dependencies are built, the final adb dependency is on
the command to link all the objects into the final adb executable.

If the cmp target is invoked (e.g. make cmp) explicitly, the
executable will be compared with a version in /bin and the working
directory will be cleaned. Likewise the 'cp' target will install
the excutable in /bin and clean up intermediate files.

>
>* opset.o has no dependencies?

That does appear to be a bug.

$ grep include /work/reference/usl/unix/v7/usr/src/cmd/adb/opset.c
#include "defs.h"

Bart <bc@freeuk.com> writes:
> On 24/08/2023 16:51, Kaz Kylheku wrote:
[...]
>> Unix already had make as far back as 1979.
>> Here is the source tree for the utilities:
>> https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd
[...]
>> There are some single file .c utilities and some subdirectories.
>> There is a "makeall" shell script which invokes something amusingly
>> called "cmake" on the top level files, individually.
>> This cmake is a script in the cmake/ subdirectory. A silly thing it
>> has
>> a big case statement that switches on the program name and branches to a
>> customized compile command. Many of them are identical except for names;
>> it's obviously copy-paste.
>> Most of the subdirectories have makefiles (lower case "makefile";
>> they hadn't yet thought of supporting "Makefile" so that it would
>> appear above lower-cased source file names; modern make still looks
>> for a "makefile" too).
>> The makefiles are tidy; they look better than an equivalent script.
>> By equivalent I mean a script that handles the dependencies for
>> incremental rebuilds.
>> Here is adb/makefile from V7 Unix, dated January 11, 1979:
>> CFLAGS = -i -O
>> all: adb
>> cmp: adb
>> cmp adb /bin/adb
>> rm adb *.o
>> cp: adb
>> cp adb /bin/adb
>> rm adb *.o
>> adb: access.o command.o expr.o findfn.o
>> adb: format.o input.o opset.o main.o
>> adb: message.o output.o pcs.o print.o
>> adb: runpcs.o setup.o sym.o
>> adb:; cc -o adb -i *.o
>>
>> access.o: defs.h
>> command.o: defs.h
>> expr.o: defs.h
>> findrtn.o: defs.h
>> format.o: defs.h
>> input.o: defs.h
>> main.o: defs.h
>> message.o: mac.h mode.h
>> output.o: defs.h
>> pcs.o: defs.h
>> print.o: defs.h
>> runpcs.o: defs.h
>> setup.o: defs.h
>> sym.o: defs.h
>> This is very tidy and more or less how make should be used today.
>> We can see that in 1979, make already had built-in rules for
>> compiling. We
>> don't see the compile command anywhere, or how CFLAGS is pulled into the build.
>> It must have been beneficial to those coders to only have to
>> recompile output.c to output.o when output.c was touched.
>
> Some observations:
>
> * This is a C project? If so there is a remarkable lack of .c files!

Make has a number of implicit rules, one of which is that foo.o depends
on foo.c and is generated by something like "$(CC) $(CFLAGS) -c foo.c".
It wasn't necessary to list the *.c files in the Makefile.

> * opset.o has no dependencies?

It implicitly depends on opset.c. If opset.o doesn't exist when you run
make, it will compile opset.c to generateit.

> * There is a lot of repetition of defs.h
>
> * All the modules (except opset.o) are named twice

Because they all depend on defs.h.

> * How are the dependencies derived? I guess either manually, which
> can be error prone, or an extra tool is needed that understands
> C code

Yes, either manually or with an extra tool.

> * The project seems simple enough that you will know:
>
> * No .c file depends on any other. Any edit to a .c
> file only requires compiling that one file
>
> * With any changes to defs.h, you might as well compile the lot
>
> * At best, the makefile lists the modules that are submitted to the
> linker
>
> In this case, you can easily do without 'make'.

If you're building the whole thing from scratch, probably.

Suppose you're doing development on the project. Since the last time
you built it, you've modified 3 of the 16 *.c files. Maybe you don't
remember which ones. Maybe you used a script to do a global
search-and-replace, so you don't even know which files you changed
unless you look at their timestamps. Without make, you can either
rebuild everything (which on a project of this size on 1979 hardware, or
on a larger project on modern hardware, might be unreasonably slow), or
you can figure out which files you need to recompile. The latter is
error-prone. (I've certainly re-run a program after making a source
file change and forgetting to recompile.)

Or you can type "make" and it will rebuild only what needs to be
rebuilt. Type "make" again, and it does nothing, because there's
nothing to do.

Sure, you could provide a script that just compiles everything
unconditionally. That could be useful for users who want to build the
project from source but don't need to modify anything. (And you could
construct such a script from the output of make.)

But if you can make some reasonable assumptions about the tools your
users will have on their systems, there's no need for such a script.
Anyone who would even consider building Unix V7 adb command from source
in 1979 would have had make already, and the presence of a makefile in
the directory would have been more than enough of a clue that that's how
to build it. (More modern software distributions would likely have a
README and/or INSTALL file, and the makefile would have a "clean"
target.)

For a typical user who wants to do a clean build, running "make" just
works. There's a lot of stuff going on behind the scenes, but the
typical user doesn't need to care about that, as long as the maekefile
is written correctly.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On 2023-08-24, Bart <bc@freeuk.com> wrote:
> On 24/08/2023 16:51, Kaz Kylheku wrote:
>> Here is adb/makefile from V7 Unix, dated January 11, 1979:
>>
>> CFLAGS = -i -O
>>
>> all: adb
>>
>> cmp: adb
>> cmp adb /bin/adb
>> rm adb *.o
>>
>> cp: adb
>> cp adb /bin/adb
>> rm adb *.o
>>
>> adb: access.o command.o expr.o findfn.o
>> adb: format.o input.o opset.o main.o
>> adb: message.o output.o pcs.o print.o
>> adb: runpcs.o setup.o sym.o
>> adb:; cc -o adb -i *.o
>>
>>
>> access.o: defs.h
>> command.o: defs.h
>> expr.o: defs.h
>> findrtn.o: defs.h
>> format.o: defs.h
>> input.o: defs.h
>> main.o: defs.h
>> message.o: mac.h mode.h
>> output.o: defs.h
>> pcs.o: defs.h
>> print.o: defs.h
>> runpcs.o: defs.h
>> setup.o: defs.h
>> sym.o: defs.h
>>
>> This is very tidy and more or less how make should be used today.
>>
>> We can see that in 1979, make already had built-in rules for compiling. We
>> don't see the compile command anywhere, or how CFLAGS is pulled into the build.
>>
>> It must have been beneficial to those coders to only have to
>> recompile output.c to output.o when output.c was touched.
>
> Some observations:
>
> * This is a C project? If so there is a remarkable lack of .c files!

This is how makefiles are still written today.

here is a section from the Makefile of the TXR language I work on

OBJS := txr.o lex.yy.o y.tab.o match.o lib.o regex.o gc.o unwind.o stream.o
OBJS += arith.o hash.o utf8.o filter.o eval.o parser.o rand.o combi.o sysif.o
OBJS += args.o autoload.o cadr.o struct.o itypes.o buf.o jmp.o protsym.o ffi.o
OBJS += strudel.o vm.o tree.o time.o psquare.o
OBJS += chksum.o chksums/sha1.o chksums/sha256.o chksums/crc32.o chksums/md5.o
OBJS += linenoise/linenoise.o
OBJS-$(debug_support) += debug.o
OBJS-$(have_syslog) += syslog.o
OBJS-$(have_glob) += glob.o
OBJS-$(have_ftw) += ftw.o
OBJS-$(have_posix_sigs) += signal.o
OBJS-$(have_sockets) += socket.o
OBJS-$(have_termios) += termios.o
OBJS-$(have_zlib) += gzio.o
EXTRA_OBJS-$(add_win_res) += win/txr.res

You will not find the .c files mentioned.

The program is an executable made by loading and linking .o files.

Given a progran name like "adb", make cannot figure out what .o files
it is made out of, so that has to be spelled out somehow.

Given a .o file like output.o, make *can* implicitly figure out that
there is an output.c, which might be newer.

Looks like that by 1979, they had all this in make already. Built
in rules, and automatic inference of prerequisites based on suffix
rules.

> * opset.o has no dependencies?

Not exactly true; there is an opset.c file, so it has that dependency.

If opset.c includes header files that are not mentioned here, then
that's a bug in the makefile.

(And why we like to obtain dependency makefile fragments from the
compiler.)

> * There is a lot of repetition of defs.h

Perhaps they didn't yet have multiple left-hand-side targets yet?

In modern (or even not-so-modern) make, we woiuld do:

OBJS = access.o command.o expr.o findfn.o \
format.o input.o opset.o main.o \
message.o output.o pcs.o print.o \
runpcs.o setup.o sym.o

adb: $(OBJS)

$(OBJS): defs.h # a few don't include defs.h: no huge deal.

In GNU Make:

OBJS_no_defs = opsyms.o message.o

$(filter-out $(OBJS_no_defs), $(OBJS)): defs.h

> * All the modules (except opset.o) are named twice

In spite of that, the linker line

adb:; cc -o adb -i *.o

neglects to refer to the makefile's list of objects,
reaching for a shell wildcard.

Clearly, this looks like good practices around makefiles had
far from gelled yet.

> * How are the dependencies derived? I guess either manually, which
> can be error prone, or an extra tool is needed that understands
> C code
>
> * The project seems simple enough that you will know:
>
> * No .c file depends on any other. Any edit to a .c
> file only requires compiling that one file

Correct and make has that covered already.

> * With any changes to defs.h, you might as well compile the lot

Exactly: using "make clean" or "rm *.o" and then make.

> In this case, you can easily do without 'make'.

You can, but even automating the recompiling of just the
changed .c file will be a fairly ugly script.

Without dependencies and without the "cp" and "cmp"
targets, the makefile gets short:

CFLAGS = -i -O

OBJS = access.o command.o expr.o findfn.o \
format.o input.o opset.o main.o \
message.o output.o pcs.o print.o \
runpcs.o setup.o sym.o

adb:; cc -o adb -i $(OBJS)

We can drop the "all" target because adb is the first
and only target.

If the files use a comon header, with just one more
line we handle that:

$(OBJS): defs.h

message.o: mac.c mode.h

So it's a no-brainer.

Don't discount make because of bad makefiles, including ones
from the birthplace of make.

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

On 24/08/2023 19:47, Kaz Kylheku wrote:
> On 2023-08-24, Bart <bc@freeuk.com> wrote:

> (And why we like to obtain dependency makefile fragments from the
> compiler.)

That sounds like an incremental process. How does the compiler know
which files to look at? It looks at the makefile. Presumably
dependencies (conditional compilation) have to be turned off to ensure
all files are visited.

> Without dependencies and without the "cp" and "cmp"
> targets, the makefile gets short:
>
> CFLAGS = -i -O
>
> OBJS = access.o command.o expr.o findfn.o \
> format.o input.o opset.o main.o \
> message.o output.o pcs.o print.o \
> runpcs.o setup.o sym.o
>
> adb:; cc -o adb -i $(OBJS)

This reminds me of another point:

* The makefile exposes intermediate .o files

I think this is undesirable. That's an internal compiler detail. Some
compilers may use different extensions. Some may even dispense with
intermediate files (I was thinking of doing that), or don't have a
linking stage.

The same .o file extension may also be used by multiple languages.

Another matter, which applies to your original example, is that adding
or removing modules requires updating multiple sites in the makefile.

> We can drop the "all" target because adb is the first
> and only target.
>
> If the files use a comon header, with just one more
> line we handle that:
>
> $(OBJS): defs.h
>
> message.o: mac.c mode.h
>
> So it's a no-brainer.
>
> Don't discount make because of bad makefiles, including ones
> from the birthplace of make.

I'm discounting it for my own purposes because (1) I have a module
system so half of it is redundant; (2) for C, I only need simple lists
of C files; (3) I use very fast compilers so the other half,
dependencies, is also redundant.

There's not much left!

(I also consider development, remote one-off builds, and app
installation as separate tasks that shouldn't be lumped together)

I wonder if the existence of makefiles stopped C getting modules?
Because it fills part of that role, but is a separate thing outside of
the language.

On Thu, 24 Aug 2023 18:29:02 GMT, scott@slp53.sl.home (Scott Lurndal)
wrote in <OjNFM.897908$GMN3.79590@fx16.iad>:

> The default rules built into make(1) include a rule like
>
> %.o: %.c
> $(CC) $(CFLAGS) -o $@ -c $<

A lot of times, for simple one-off projects, I don't
need a Makefile.

Assuming a valid source file "try.c", I can
type "make try" and get an executable
called "try".

_ _ _ _ _ _ _
$ echo "int main(){ return 0; }" > try.c
$ make try
cc try.c -o try
$ make CFLAGS=-O3 try
make: 'try' is up to date.
$ rm try
$ make CFLAGS=-O3 try
cc -O3 try.c -o try
$ echo 'CFLAGS=-O3' > Makefile
$ rm try
$ make try
cc -O3 try.c -o try
_ _ _ _ _ _ _

I may be mistaken, but I'm pretty sure this works
in any modern POSIX environment.

Folks are calling it "Unix/Linux" software. But a subset of
that is POSIX, and a POSIX environment on Windows should let
you build some of the same software. (I used to use Cygwin
for that, before I jumped ship completely from Windows.)

And I used the package manager to install autoconf,
which gave me the aclocal command.

Bart:

If you're cloning a git repository on an autoconf package,
expect to run ./autogen.sh -- the included "configure" script
probably isn't set up for Windows. (Guessing.)

And for autogen to work, you'll need the autoconf
developer environment. If you're on Windows,
a working autoconf would seem to be important here,
since that gives you the "aclocal" command that is part
of the process -- and which sets up the configure script
for your environment.

(Just be glad you aren't using imake...)

--
-v

On 2023-08-24, Bart <bc@freeuk.com> wrote:
> On 24/08/2023 19:47, Kaz Kylheku wrote:
>> On 2023-08-24, Bart <bc@freeuk.com> wrote:
>
>> (And why we like to obtain dependency makefile fragments from the
>> compiler.)
>
> That sounds like an incremental process. How does the compiler know
> which files to look at? It looks at the makefile. Presumably
> dependencies (conditional compilation) have to be turned off to ensure
> all files are visited.

When nothing is built at all, then the dependencies don't matter. Every
object file must be built. In the course of building it, the
dependencies are visited by the compiler. GCC can dump them in the form
of a makefile fragment. Those fragments can be included into the
Makefile (using -include (dash include) which doesn't fail when the
included file is missing).

>> Without dependencies and without the "cp" and "cmp"
>> targets, the makefile gets short:
>>
>> CFLAGS = -i -O
>>
>> OBJS = access.o command.o expr.o findfn.o \
>> format.o input.o opset.o main.o \
>> message.o output.o pcs.o print.o \
>> runpcs.o setup.o sym.o
>>
>> adb:; cc -o adb -i $(OBJS)
>
> This reminds me of another point:
>
> * The makefile exposes intermediate .o files
>
> I think this is undesirable. That's an internal compiler detail. Some
> compilers may use different extensions. Some may even dispense with
> intermediate files (I was thinking of doing that), or don't have a
> linking stage.

Looks like it has stood the test of time: here we are in 2023, and
still there are .o files made from .c files.

> The same .o file extension may also be used by multiple languages.

That is so, E.g. C++ will use .o, assembly language files will use .o.
The part of the name before the .o has to be different in such
a mixed project. You just don't have have an input.s and input.c
assembling and compiling to input.o, or not in the same directory.

> Another matter, which applies to your original example, is that adding
> or removing modules requires updating multiple sites in the makefile.

j

>
>> We can drop the "all" target because adb is the first
>> and only target.
>>
>> If the files use a comon header, with just one more
>> line we handle that:
>>
>> $(OBJS): defs.h
>>
>> message.o: mac.c mode.h
>>
>> So it's a no-brainer.
>>
>> Don't discount make because of bad makefiles, including ones
>> from the birthplace of make.
>
> I'm discounting it for my own purposes because (1) I have a module
> system so half of it is redundant; (2) for C, I only need simple lists
> of C files; (3) I use very fast compilers so the other half,
> dependencies, is also redundant.
>
> There's not much left!
>
> (I also consider development, remote one-off builds, and app
> installation as separate tasks that shouldn't be lumped together)
>
> I wonder if the existence of makefiles stopped C getting modules?
> Because it fills part of that role, but is a separate thing outside of
> the language.

I'd say it's mostly because modules are academic.

I worked with Modula-2, and Pascal variants with modules, so I
understand what modules do.

They are a kind of toy idea that works fine for certain kinds of
programs.

The "module agnostic" C model proves to be flexible in various
situations like producing firmware image such as bootloaders,
shared libraries, kernel drivers and whatnot.

Module system are opinionated about initialization. They generate the
startup code to initialize modules in the correct order. This can be
inflexible. A firmware build for the bare metal may require custom
linking with flexible use of sections to assign initialization functions
to different initialization phases.

Being "module agnostic" means C is mixed with other languages easily.
If a C object file needs a function to be called to initialize it,
that will be an ordinary, named function.

From what I remember of Modula-2, it doesn't offer any solution for
program shutdown. The top-level initialization blocks in modules were
called in the correct order: used modules initialized before using
modules. But there was nothing for orderly shutdown.

Circular references were a problem. In real-world programs, modules have
circular dependencies: A depends on B, while B also depends on A.

Firstly, you need some way to support that on a syntactic level.
In C we can do it, e.g. using incomplete types. The header
file "B.h" can refer to a "struct A" without having to include "A.h".

Initialization may be broken into multiple stages like b_early_init()
is called before a_early_init(), where b_early_init does those B
initializations that don't depend on anything in A. Then later
b_late_init() is called that performs initializations that now assume
a_early_init() has been.

I think that a module system that doesn't handle flexible multi-phase
initialization, orderly shutdown and circular dependencies, and
relies on "magic" unnamed code being generated by the compiler is
too broken for most real world use. C dodged a bullet by not going for
anything like that.

It's better to leave some problems unsolved than to commit to a bad
solution.

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

On 2023-08-24, vallor <vallor@cultnix.org> wrote:
> If you're cloning a git repository on an autoconf package,
> expect to run ./autogen.sh -- the included "configure" script
> probably isn't set up for Windows. (Guessing.)

An Autoconf ./configure script must work on any platform
to which the program can reasonably be considered to be ported,
plus some on which it has not been tried.

> And for autogen to work, you'll need the autoconf
> developer environment.

That defeats the whole purpose of Autoconf.

Many GNU programs are like this, unfortunately.

When they make a release, they generate the configure script and then
tar everything up. So what they are shipping is not a clean snapshot
from their repository!

Conversely, when you clone their repositories, you are not getting the
same thing as a release tarball.

You're assumed to be a developer who is willing to install the right
version of AutoCrap this and AutoPoop that,and then run "make boostrap"
or whatever.

If you're unfortunate enough to work with AutoTools, then for pete's
sake, generate the configure script, and the Makefile.in and whatnot,
and check them into the repository. Do that every time they change.

Make it so you can cut a release using "git tag" and nothing else.

--
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 23/08/2023 03:18, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 22/08/2023 01:31, Ben Bacarisse wrote:
>>>
>>>>> If there's anything extra, then that can be explained. This can be put into
>>>>> a Readme or Install or Build text file.
>>>> Sounds simple. What does this simple solution look like for a68g? I'll
>>>> send it to the authors if you don't want to do that yourself.
>>>>
>>>
>>> Have a look at the post I made 21-08-23 14:12 BST, and follow-on ones,
>>> where I explore what happens when a build process provides such
>>> information.
>> I'll look if you provide the message ID. That's how Usenet posts are
>> cited.
>>
>>> In that case, 1000s of lines of 'configure' scripts and numerous makefiles
>>> could be reduced to a 6-line build script, even if the lines are somewhat
>>> long.
>>>
>>> That is unusual, but note that this was version 9 of that project; that
>>> info was not present on version 6.
>> That's not an Algol 68G version number. You have switched horses yet
>> again.
>>
>>> (I'm not replying to your other points as you are not receptive to what I
>>> am trying to do. You are just shrugging your shoulders at Windows. So is
>>> nearly everyone. You are part of the problem.
>> What should I do "at Windows". You seem to think I should care about
>> how easily Unix/Linux software builds on it. Why should I?
>
> At least you appear to believe me when I say that makefiles on Windows are
> very often troublesome. Since some here are trying to say that it's purely
> due to my incompetence.

Will you answer any questions?

> But you also say that I should put on my cape and single-handedly fix all
> the myriad projects where it could be handled better.

No I did not say that. In fact I said something very different

> So you acknowledge that some apps build poorly on Windows, but are not
> surprised, and also don't appear to care since you don't use Windows.
>
> Then I'm not quite sure why you're taking part in this thread. It seems to
> be one giant <shrug>.

I participated because you didn't know what make is, how it is used or
the benefits it brings to the people who use it. I hope you are, at
least, a little better informed on these topics.

> It's my turn then not to be surprised that Linux is so highly favoured in
> build systems

Linux is favoured by the build systems because all the examples you
picked were for Linux software. Is there no similar healthy ecosystem
of Windows software? If so, I image very little of it would build on
Linux without some work.

> if your attitude is typical but Windows gets the second or
> third class treatment:

For years, Linux was (so the story went) the poor relation. All the
good end-user software was developed for Windows. Surely that has not
changed to such an extent that the only software you care about is now
Linux-specific.

> ... But you seem to think I should
> personally take charge of every such project on the planet,

Spin! Seriously, every time I ask if you have a background in politics
you duck the question. Do you?

--
Ben.

Richard Harnden <richard.nospam@gmail.com> writes:

> On 23/08/2023 03:18, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 22/08/2023 01:31, Ben Bacarisse wrote:
>>>
>>>>> If there's anything extra, then that can be explained. This can be put into
>>>>> a Readme or Install or Build text file.
>>>> Sounds simple. What does this simple solution look like for a68g? I'll
>>>> send it to the authors if you don't want to do that yourself.
>>>>
>>>
>>> Have a look at the post I made 21-08-23 14:12 BST, and follow-on ones,
>>> where I explore what happens when a build process provides such
>>> information.
>> I'll look if you provide the message ID. That's how Usenet posts are
>> cited.
>
> It was Message-ID: <ubvnsg$1tkml$1@dont-email.me>

Thank you. I'm not sure I have time now. Life has intervened...

--
Ben.

On 24/08/2023 23:59, Kaz Kylheku wrote:
> On 2023-08-24, Bart <bc@freeuk.com> wrote:

>> I think this is undesirable. That's an internal compiler detail. Some
>> compilers may use different extensions. Some may even dispense with
>> intermediate files (I was thinking of doing that), or don't have a
>> linking stage.
>
> Looks like it has stood the test of time: here we are in 2023, and
> still there are .o files made from .c files.
>
>> The same .o file extension may also be used by multiple languages.

For actual object files, I've also used .obj. Or my C compiler used only
..asm, no binary object files (and even .asm was usually internal; no
discrete file).

Elsewhere I don't use intermediate files at all. Or for interpreted
languages I've sometimes use bytecode files, which do not need linking.

It can be quite diverse and that's just for what I do!

>> I wonder if the existence of makefiles stopped C getting modules?
>> Because it fills part of that role, but is a separate thing outside of
>> the language.
>
> I'd say it's mostly because modules are academic.
>
> I worked with Modula-2, and Pascal variants with modules, so I
> understand what modules do.
>
> They are a kind of toy idea that works fine for certain kinds of
> programs.
>
> The "module agnostic" C model proves to be flexible in various
> situations like producing firmware image such as bootloaders,
> shared libraries, kernel drivers and whatnot.
>
> Module system are opinionated about initialization. They generate the
> startup code to initialize modules in the correct order. This can be
> inflexible. A firmware build for the bare metal may require custom
> linking with flexible use of sections to assign initialization functions
> to different initialization phases.
>
> Being "module agnostic" means C is mixed with other languages easily.
> If a C object file needs a function to be called to initialize it,
> that will be an ordinary, named function.
>
> From what I remember of Modula-2, it doesn't offer any solution for
> program shutdown. The top-level initialization blocks in modules were
> called in the correct order: used modules initialized before using
> modules. But there was nothing for orderly shutdown.
>
> Circular references were a problem. In real-world programs, modules have
> circular dependencies: A depends on B, while B also depends on A.

Each language has its own ideas about what modules even mean.

I've tried to keep mine simple and practical. My first attempt had a
hierarchical module structure with no circular imports. It was a
nuisance (but there were underhand methods to get around that).

Then I eventually had circular references (I may have moved to
whole-program compilation at the same time), but there was a problem in
determining load-order:

If A imports B and vice-versa, and they each have an automatically
called init section, which gets loaded first?

My current scheme solves that. And for my stuff, it works extremely well.

Although it also just moves some of the interface problems away from
boundaries between modules, and into the boundaries between programs and
libraries: my program/library structure is still hierarchical.

> Firstly, you need some way to support that on a syntactic level.
> In C we can do it, e.g. using incomplete types. The header
> file "B.h" can refer to a "struct A" without having to include "A.h".

I partly did it by allowing out-of-order definitions for everything. But
that is quite hard to do. My latest project steps back from that.

> Initialization may be broken into multiple stages like b_early_init()
> is called before a_early_init(), where b_early_init does those B
> initializations that don't depend on anything in A. Then later
> b_late_init() is called that performs initializations that now assume
> a_early_init() has been.
>
> I think that a module system that doesn't handle flexible multi-phase
> initialization, orderly shutdown and circular dependencies, and
> relies on "magic" unnamed code being generated by the compiler is
> too broken for most real world use. C dodged a bullet by not going for
> anything like that.

> It's better to leave some problems unsolved than to commit to a bad
> solution.

I've mentioned a simple module scheme that could be used for C, but
requiring compiler support. It requires that all modules use tidy .c/.h
pairs.

Circular references aren't a problem, because in C, modules still use
separate interface (.h) files, and the latter are written manually.

It was automatic interface/export files combined with independent module
compilation that was the obstacle with my early module attempts.

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:

> On 8/22/2023 7:18 PM, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:

>>> (I'm not replying to your other points as you are not receptive to what I
>>> am trying to do. You are just shrugging your shoulders at Windows. So is
>>> nearly everyone. You are part of the problem.
>>
>> What should I do "at Windows". You seem to think I should care about
>> how easily Unix/Linux software builds on it. Why should I?
>
> Install windows, download MSVC; download vcpkg; okay, search vcpkg for
> your

/Buy/ and install windows. I don't think it's now free is it?

> libs, cross your fingers... If they are there, then good! Otherwise, you
> need to manually install them per their installation instructions, manually
> in the sense of not using vcpkg. ;^)

Smiley noted. For a while I thought you were suggesting I really should
do this!

--
Ben.

Bart <bc@freeuk.com> writes:
> On 24/08/2023 23:59, Kaz Kylheku wrote:
>> On 2023-08-24, Bart <bc@freeuk.com> wrote:
>>> I think this is undesirable. That's an internal compiler detail. Some
>>> compilers may use different extensions. Some may even dispense with
>>> intermediate files (I was thinking of doing that), or don't have a
>>> linking stage.
>> Looks like it has stood the test of time: here we are in 2023, and
>> still there are .o files made from .c files.
>>
>>> The same .o file extension may also be used by multiple languages.
>
> For actual object files, I've also used .obj. Or my C compiler used
> only .asm, no binary object files (and even .asm was usually internal;
> no discrete file).

The authors of a makefile written to build the UNIX V7 adb command in
1979 didn't worry about the compiler using a suffix other than ".o", or
about the compiler driver having a name other than "cc". There's no
reason they should have. It probably never occurred to them that it
would be built on a non-UNIX system. Neither MS Windows nor MS-DOS even
existed yet.

And if there had been a possibility of the compiler generating ".obj"
files, the suffix could easily have been parameterized in the makefile.

If you're wondering why the makefile referred to the object files at all
rather than the source files, it's so that the object files could be
kept around and not rebuilt unnecessarily during development.

> Elsewhere I don't use intermediate files at all. Or for interpreted
> languages I've sometimes use bytecode files, which do not need
> linking.

That's nice. Seriously, it is. But we're discussing the makefile for a
UNIX-only tool written in C. Why mention irrelevancies (unless you're
suggesting that adb should have been written in an interpreted language
in 1979)?

> It can be quite diverse and that's just for what I do!

The makefile we're discussing wasn't written for diverse environments.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On 8/24/2023 6:23 PM, Ben Bacarisse wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>
>> On 8/22/2023 7:18 PM, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>
>>>> (I'm not replying to your other points as you are not receptive to what I
>>>> am trying to do. You are just shrugging your shoulders at Windows. So is
>>>> nearly everyone. You are part of the problem.
>>>
>>> What should I do "at Windows". You seem to think I should care about
>>> how easily Unix/Linux software builds on it. Why should I?
>>
>> Install windows, download MSVC; download vcpkg; okay, search vcpkg for
>> your
>
> /Buy/ and install windows. I don't think it's now free is it?

Right, indeed! Fwiw, the free windows comes automatically equipped with
files by the name of:

win42_system32_this_is_not_a_virus_dot_com_no_seriously_this_is_not_bad_at_all.jpg.jpeg.exe

Yikes! Just kidding, but one should buy the damn thing it if they want
to install it. Actually, win11 might be some sort of virus anyway...
Na... I remember way back when windows would install perfectly fine
without a password for the god damn Administrator account! Yikes... ;^o
Ouch...

>> libs, cross your fingers... If they are there, then good! Otherwise, you
>> need to manually install them per their installation instructions, manually
>> in the sense of not using vcpkg. ;^)
>
> Smiley noted. For a while I thought you were suggesting I really should
> do this!
>

Only when you have nothing to do for around a year. Perhaps, ... Na. :^)

I really don't mind using windows. I had a lot of fun when I had to use
Solaris off and on for several years.

On 2023-08-23, Bart <bc@freeuk.com> wrote:
> At least you appear to believe me when I say that makefiles on Windows
> are very often troublesome.

By the same (preprocessor?) token, Visual C or C++ programs
are troublesome on Unix.

Nothing is more siloed than Windows development tools connected
with Microsoft.

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

On Friday, 25 August 2023 at 06:52:04 UTC+1, Kaz Kylheku wrote:
> On 2023-08-23, Bart <b...@freeuk.com> wrote:
> > At least you appear to believe me when I say that makefiles on Windows
> > are very often troublesome.
> By the same (preprocessor?) token, Visual C or C++ programs
> are troublesome on Unix.
>
> Nothing is more siloed than Windows development tools connected
> with Microsoft.
>
Yes. The big companies like Microsoft and Apple don't really like portable
software, because they want programs to run on their system and their
system alone.
But Baby X programs run on both Windows and Linux. The CMake script
works for both, with just a small amount of platform-specific twiddling.

On 25/08/2023 03:23, Ben Bacarisse wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>
>> On 8/22/2023 7:18 PM, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>
>>>> (I'm not replying to your other points as you are not receptive to what I
>>>> am trying to do. You are just shrugging your shoulders at Windows. So is
>>>> nearly everyone. You are part of the problem.
>>>
>>> What should I do "at Windows". You seem to think I should care about
>>> how easily Unix/Linux software builds on it. Why should I?
>>
>> Install windows, download MSVC; download vcpkg; okay, search vcpkg for
>> your
>
> /Buy/ and install windows. I don't think it's now free is it?
>

I believe it can now be downloaded and installed for free (as in "free
beer", certainly not as in "free speech" ! ). There are limitations and
restrictions if you don't register it, and you can't register without
paying for it. I have no idea of the details, however, and whether the
restrictions or requirements would be acceptable to you. (That is, if
you actually /want/ to install Windows.)

On 25/08/2023 02:23, Ben Bacarisse wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>
>> On 8/22/2023 7:18 PM, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>
>>>> (I'm not replying to your other points as you are not receptive to what I
>>>> am trying to do. You are just shrugging your shoulders at Windows. So is
>>>> nearly everyone. You are part of the problem.
>>>
>>> What should I do "at Windows". You seem to think I should care about
>>> how easily Unix/Linux software builds on it. Why should I?
>>
>> Install windows, download MSVC; download vcpkg; okay, search vcpkg for
>> your
>
> /Buy/ and install windows. I don't think it's now free is it?

Ok, you seem to have a problem with paying for certain types of
software, but presumably are OK with paying for hardware.

The cheapest desktop PC I could find in the UK with a minute or two's
search was £250 ($300?). It includes Windows 11.

Or you can try a second-hand PC, from a proper retailer, from £40 (I
don't know how Windows licensing works on those).

My point is that the cost, whatever it is, isn't extortionate. And I
will pay it to ensure something that works out-of-the-box and does not
need installing.

I would pay for Linux too if only I could find a machine that had it!
And I don't mean that weird hybrid called WSL. (I have bought a
second-hand laptop with Linux: I wasn't impressed.)

On 25/08/2023 02:11, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 23/08/2023 03:18, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>>>
>>>> On 22/08/2023 01:31, Ben Bacarisse wrote:
>>>>
>>>>>> If there's anything extra, then that can be explained. This can be put into
>>>>>> a Readme or Install or Build text file.
>>>>> Sounds simple. What does this simple solution look like for a68g? I'll
>>>>> send it to the authors if you don't want to do that yourself.
>>>>>
>>>>
>>>> Have a look at the post I made 21-08-23 14:12 BST, and follow-on ones,
>>>> where I explore what happens when a build process provides such
>>>> information.
>>> I'll look if you provide the message ID. That's how Usenet posts are
>>> cited.
>>>
>>>> In that case, 1000s of lines of 'configure' scripts and numerous makefiles
>>>> could be reduced to a 6-line build script, even if the lines are somewhat
>>>> long.
>>>>
>>>> That is unusual, but note that this was version 9 of that project; that
>>>> info was not present on version 6.
>>> That's not an Algol 68G version number. You have switched horses yet
>>> again.
>>>
>>>> (I'm not replying to your other points as you are not receptive to what I
>>>> am trying to do. You are just shrugging your shoulders at Windows. So is
>>>> nearly everyone. You are part of the problem.
>>> What should I do "at Windows". You seem to think I should care about
>>> how easily Unix/Linux software builds on it. Why should I?
>>
>> At least you appear to believe me when I say that makefiles on Windows are
>> very often troublesome. Since some here are trying to say that it's purely
>> due to my incompetence.
>
> Will you answer any questions?

What sort of answers are you looking for?

>> But you also say that I should put on my cape and single-handedly fix all
>> the myriad projects where it could be handled better.
>
> No I did not say that. In fact I said something very different
>
>> So you acknowledge that some apps build poorly on Windows, but are not
>> surprised, and also don't appear to care since you don't use Windows.
>>
>> Then I'm not quite sure why you're taking part in this thread. It seems to
>> be one giant <shrug>.
>
> I participated because you didn't know what make is, how it is used or
> the benefits it brings to the people who use it. I hope you are, at
> least, a little better informed on these topics

I understand now that people use it to solve certain types of problems
where there are no commonly used alternatives.

I disagree about some of the problems, and have generally used
alternatives. Those alternatives also tend to be simpler and shorter.

I understand that given the choice of one tool, and typical patterns of
use (pack /everything/ into one hard-to-understand file), people will
get into the habit of using it for everything, even when simple
alternatives will work just as well.

There could easily be an option in a makefile (if not, than redirecting
the output will do most of it) where the commands needed to do a clean
build, with certain defaults, can be captured into a shell script.

Then just supply that script with a source bundle (as well as the
makefile). That could be a more foolproof backup.

>> It's my turn then not to be surprised that Linux is so highly favoured in
>> build systems
>
> Linux is favoured by the build systems because all the examples you
> picked were for Linux software. Is there no similar healthy ecosystem
> of Windows software? If so, I image very little of it would build on
> Linux without some work.

I don't actively seek out Windows software. But most attempts to use
libraries seem to end up in some rabbit-hole which always leads back to
Linux.

While open-source projects I might want to build tend to be
Linux-centric, even ones you'd think cannot possible depend on which OS
they run on, since they only read and write files.

Some that are Windows-only tend to use big tools like Visual Studio,
which is not for me either.

Even a library with ready-made binaries, like GTK, has a humungous set
of headers. Even the instructions to install on Windows start off with
advice to MSYS2 which 'provides a UNIX-like environment for Windows'.
Um, it's bunch of headers!

The first GTK example I saw used this command line:

gcc $(pkg-config --cflags gtk4) -o hello-world-gtk hello-world-gtk.c
$(pkg-config --libs gtk4)

Presumably pkg-config is something I have to install, that picks up some
config info that is part of GTK and imparts it to the compiler?

See, another rabbit-hole! I went into GTK in some detail when I tried to
use it from bcc. There, pkg-config is meaningless. (I have my own ideas
on how libraries like this should be presented, but that is another
tangential subject.)

(BTW I was just about able to run a GTK hello-world using bcc, using a
workaround. That workaround was necessary because GTK2 exposed bitfields
within its public interface.

Bitfields are implementation-dependent (?). The issue here was that it
affected the size of an important struct. My bcc doesn't do bitfields,
they are treated as regular ints so struct sizes can be different.)

On 25/08/2023 11:53, Bart wrote:
> On 25/08/2023 02:23, Ben Bacarisse wrote:
>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>
>>> On 8/22/2023 7:18 PM, Ben Bacarisse wrote:
>>>> Bart <bc@freeuk.com> writes:
>>
>>>>> (I'm not replying to your other points as you are not receptive to
>>>>> what I
>>>>> am trying to do. You are just shrugging your shoulders at Windows.
>>>>> So is
>>>>> nearly everyone. You are part of the problem.
>>>>
>>>> What should I do "at Windows".  You seem to think I should care about
>>>> how easily Unix/Linux software builds on it.  Why should I?
>>>
>>> Install windows, download MSVC; download vcpkg; okay, search vcpkg for
>>> your
>>
>> /Buy/ and install windows.  I don't think it's now free is it?
>
>
> Ok, you seem to have a problem with paying for certain types of
> software, but presumably are OK with paying for hardware.

I would certainly have a problem paying for software I don't want, and I
don't believe Ben actually /wants/ to have Windows installed.

It's fair enough IMHO to pay a reasonable amount for software you want
or need - just like paying for anything else.

>
> The cheapest desktop PC I could find in the UK with a minute or two's
> search was £250 ($300?). It includes Windows 11.
>
> Or you can try a second-hand PC, from a proper retailer, from £40 (I
> don't know how Windows licensing works on those).
>
> My point is that the cost, whatever it is, isn't extortionate. And I
> will pay it to ensure something that works out-of-the-box and does not
> need installing.
>
> I would pay for Linux too if only I could find a machine that had it!
> And I don't mean that weird hybrid called WSL. (I have bought a
> second-hand laptop with Linux: I wasn't impressed.)
>

There are plenty of machines available with Linux pre-installed, but
they are rarely found in computer shops (excluding Chromebooks, as the
Linux base is well hidden on most of these). A bit of googling should
turn up results quite quickly.

But usually installing Linux is pretty simple, and there are so many
distros to choose from, so most users install it themselves unless they
are looking for supported Linux servers or workstations (which have a
rather different level of budget).

The way marketing commercial software works, it is actually cheaper for
manufacturers to sell you machines with Windows and a pile of crapware
than to sell you an empty machine or one with free software installed.
Anti-virus companies, MS Office, and others pay the manufacturer to
install time-limited versions of their software with pop-up "reminders"
to con less knowledgeable users into paying subscriptions that they are
told they need.