Bart:
>> Suppose you dispensed with all that dependency stuff; how long would
>> it take to build such a project? Say compared with just compiling one
>> module.
>>

David Brown:

> That particular project takes a minute and a half to compile on my
> laptop (it's faster on my main machine). It's 373 compilations, perhaps
> 40% of it C++. Too long for convenience.

OK. I'm surprised (since you say you work on embedded systems) that
software for those can be so elaborate.

I've worked with some restricted machines, and my program builds, which
were also done ON those machines (no cross-compiler on a bigger
machine!) has never taken anywhere near as long as that.

But I thought, should I give 'make' one more chance? I tried some
smallish projects:

-----------------------------
Pico C interpreter: This has a makefile, but it was for Linux. A Windows
build requires MSVC and VS (or whatever is needed to deal with .sln
files), so no thanks.

Yet, I have built this project in the past without make or VS, once I'd
extracted the necessary info.

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

Lua Interpreter: This had a makefile, but gave errors. A closer look
revealed things like "-DLINUX...". I know this builds on Windows, but
there was no info as to how that I could see.

----------------------
8cc C compiler: Linux only (although this wasn't mentioned; unistd.h in
the sources gave a clue).

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

SubC C Compiler: this uses a makefile file, but also has WINBUILD.BAT
for Windows. I guess make was not quite flexible enough for Windows, or
had too many Linux dependencies.

But WINBUILD didn't quite work. Maybe it was to do with some errors
unpacking 2-3 .tgz/.tar files: 'Cannot create symbolic link: a required
privilege...'.

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

So, maybe 'make' can work under Windows, if only I can find a suitable
project where that actually happens!

What I did find was build systems that are chaotic; the above are
typical unfortunately.

'make' is only part of the problem. Yet these projects are quite
small-scale, with dozens of source files, compared with gcc 13.2 which
had 75,000 source files, and that was described by two people here as
being simple to build.

DB:
> Computers are good at tedious work. They are good at tracking this kind
> of small detail. Why not let the computer do the work here?

Exactly. But I'm not seeing that in these projects. Somebody has to go
to a lot of trouble to create those build scripts, or get additional
sofware's help to create them. Which in the end did not result in my
being able to do an effortless, trouble-free build.

>All it takes is a little googling and a willingness to learn -
makefiles have a somewhat cryptic syntax,

And here you confirm what I said!

>Longer does not mean better. Often it means set in your ways, and
unwilling to look at alternatives.

On the contrary. Alternatives are EXACTLY what I have always worked on,
especially over the last decade.

Maybe it's /you/ who's unwilling to looked at alternatives, but are too
locked in to existing languages, compilers, OSes and support tools. Such
a critical mass has been created that there is no easy way out; just
piling on more stuff, finding creative ways to make things faster.

My C compiler project is roughly on the same scale as the above
examples. Somebody sitting at my desk right now wanting to build my C
compiler would type this from inside the project folder:

C:\cx>mm cc

The project is 71 source and support files, spread this plus two further
nested folders (these contain my compiler's standard headers and
reflects their structure).

The folders contain other stuff not necessary for the build; it doesn't
matter. /Some/ might be junk, a lot is needed for development.

If you wanted to build this product, I could supply a ZIP with a clean
set of files. It would also contain mm.exe, the compiler needed. (Oh
yes, my C compiler is not written in C.)

However, what I would probably do instead is this:

C:\cx>mm -ma cc

This creates an amalgamated file cc.ma. Now I just email you mm.exe and
cc.ma, and you just type:

Anywhere> mm cc.ma # .ma is optional if no clashes

Maybe you'd rather compile C source code instead? OK, I would then do:

C:\cx>mc -c cc # Transpile to single C file

And email you just the cc.c file. You can build it on Windows like this
(add your own options to taste):

Anywhere> gcc cc.c # (tcc needs extra options)

This builds a self-contained C compiler called a.exe. Does it work? I'll
try it:

C:\cx>a cc
Compiling cc.c to cc.exe

But, maybe you want to use Linux? OK, let's see what I can do. I can try
this instead:

C:\cx>mc -c -linux cc m # C file Linux-specific portions

Then, on Linux, you'd need to build it like this demo on WSL:

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

However, there are limitations, since my C compilers target Win64 ABI,
not Linux. You can do this:

root@DESKTOP:/mnt/c/cx# ./bcc -c sql
Compiling sql.c to sql.obj

root@DESKTOP:/mnt/c/cx# ./bcc -S sql
Compiling sql.c to sql.asm

But you can't create sql.exe (that needs to access msvcrt.dll). And even
those .obj/.asm files contain Windows-specific native code.

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

So, what do think of my alternatives? No build system in sight, whether
makefiles, SLN files or batch files.

In each case there was a simple one-line command involving one compiler
and one named source file, even if that line got longer the further we
got from my language, and from Windows.

For an actual multi-file, original C project, I've demonstrated
elsewhere the -auto option of my C compiler. But for use with existing
compilers for other people to use from the command line I would provide
@ or .bat files.

Of course, most of my actual development, not command line work, is from
from my mini-IDE, currently a 75KB program. I can use that for C too but
only bcc is supported.

Bart <bc@freeuk.com> writes:

> But I thought, should I give 'make' one more chance? I tried some smallish
> projects:
>
> -----------------------------
> Pico C interpreter: This has a makefile, but it was for Linux. A Windows
> build requires MSVC and VS (or whatever is needed to deal with .sln files),
> so no thanks.

What has this got to do with make?

> Yet, I have built this project in the past without make or VS, once I'd
> extracted the necessary info.

Did you contribute your method, batch file, makefile or whatever to the
project? If not, why not?

> -------------------------------------------------
>
> Lua Interpreter: This had a makefile, but gave errors.

Linux software, does not compile without effort on Windows. In other
news, bear defecates in the woods.

> A closer look
> revealed things like "-DLINUX...". I know this builds on Windows, but there
> was no info as to how that I could see.

They make it hard. It's hidden on the download page under the heading
"Building" with the confusing link "detailed instructions".

But again, what has this do with make?

> ---------------------- 8cc C compiler: Linux only (although this
> wasn't mentioned; unistd.h in the sources gave a clue).

Again, hidden away in the README file:

"8cc supports x86-64 Linux only. I have no plan to make it
portable..."

Who'd think to look there?

And again, what has this to do with make?

> ------------------------
>
> SubC C Compiler: this uses a makefile file, but also has WINBUILD.BAT for
> Windows. I guess make was not quite flexible enough for Windows, or had too
> many Linux dependencies.

Or maybe the person who wrote the BAT file did not know make? Now if
you had some evidence that a BAT file was needed because make can't do
the job on Windows then you might actually have a comment that relates
to giving make one more try. But you don't.

Your remark about giving make a another try in a post about build
systems suggests you don't know what it's for. It does not magically
allow software to be built on different systems. However, it might
help. While a .BAT file will be of no use on Linux, a well-written
makefile might need only a few tweaks to compile a program with MS VC
and of course it could include a Windows-only target like "prog.exe" so
no that tweaks might be needed.

> --------------
>
> So, maybe 'make' can work under Windows, if only I can find a suitable
> project where that actually happens!

Or you could chip in and help by writing a windows makefile (or adding
suitable rules to a existing makefile) for one of them.

> What I did find was build systems that are chaotic; the above are typical
> unfortunately.

They seem be crying out for someone to write a good Windows makefile
for them. Will that be you?

> 'make' is only part of the problem.

Or make could be a big part of the solution.

--
Ben.

On 13/08/2023 21:45, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
> What has this got to do with make?
> But again, what has this do with make?

> And again, what has this to do with make?

I'm looking for a project to build on Windows using make. I didn't have
much luck; they seem to avoid using it!

>> Lua Interpreter: This had a makefile, but gave errors.
>
> Linux software, does not compile without effort on Windows. In other
> news, bear defecates in the woods.

Rubbish. Lua had been easy to build: just submit the right set of .c
files to the compiler. Except the next version had a slightly different
set of files.

>> A closer look
>> revealed things like "-DLINUX...". I know this builds on Windows,
but there
>> was no info as to how that I could see.
>
> They make it hard. It's hidden on the download page under the heading
> "Building" with the confusing link "detailed instructions".

Not if you approach it via 'github lua'. There is more info if you go to
the proper Lua site, but I still couldn't see what you are supposed to
do to build Lua using 'make', as that was the purpose of the exercise:
to find even ONE project where make actually works on Windows!

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

I'm going to try one more project, which is Tiny C. This is better
documented, and directly within the downloaded files.

The build process for Linux is './configure' (oh-oh) then 'make', but it
says, for Windows read tcc-win32.txt.

There it says: install MSYS and /then/ do './configure' followed by 'make'!

But then it also gives the choice of running a batch file.

So, another project where they give up on 'make' on Windows. And this is
what you guys want me to adopt? These examples aren't very compelling
are they?

Since I'm at this point, I might as well try that batch file. It relies
on gcc. And ... compiler errors amongst loads of warning and notes.

Disappointing. But if it had worked, configure + makefile together were
654 lines, this batch file was 28 lines.

It presumably contains the right instructions to build this app; what's
with the other 626 lines?

>> What I did find was build systems that are chaotic; the above are
typical
>> unfortunately.
>
> They seem be crying out for someone to write a good Windows makefile
> for them. Will that be you?
>
>> 'make' is only part of the problem.
>
> Or make could be a big part of the solution.

My solutions in the snipped portions are:

* Use a language with its own build system and a built-way to create
one-file amalgamations

* For C, find a way to create (sqlite3-like) one-file amalgamations

* Supply build information as an @ list of files or a /simple/ shell
script (or just explain in English how to build)

* For anything more elaborate, use a script but in a language anyone
understands

Remember for someone else to build a working program from source,
dependencies within a make files are irrelevant.

Bart <bc@freeuk.com> writes:

> On 13/08/2023 21:45, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>> What has this got to do with make?
>> But again, what has this do with make?
>
>> And again, what has this to do with make?
>
> I'm looking for a project to build on Windows using make. I didn't have
> much luck; they seem to avoid using it!

You found a Unix utility hardly used on Windows. Film at 11.

> Remember for someone else to build a working program from source,
> dependencies within a make files are irrelevant.

Yes, make is not a configuration and build system. It does not attempt
to solve any of the issues in your posts on the topic.

A lot of the software you looked at is open source (some of it also free
as in freedom) originating on Linux systems. A key consideration for
such software is to encourage development rather than just building.
That's why make is popular and commonly used in the Linux world.

Things may have changed, but when I used to use Windows a lot, software
was rarely distributed as source code and even more rarely in a form
that encouraged tinkering. If there is a way of doing this, that is
widely used in the Windows world, I don't know what it is.

--
Ben.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>Bart <bc@freeuk.com> writes:
>
>> On 13/08/2023 21:45, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>>> What has this got to do with make?
>>> But again, what has this do with make?
>>
>>> And again, what has this to do with make?
>>
>> I'm looking for a project to build on Windows using make. I didn't have
>> much luck; they seem to avoid using it!
>
>You found a Unix utility hardly used on Windows. Film at 11.

As far as I am aware, Windows doesn't have a native make utility in
the first place (nmake is part of the visual studio distribution), so
its likely that Bart's quest to find a package that uses make on
windows will fail.

In article <PPeCM.479849$TCKc.32962@fx13.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
>Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>Bart <bc@freeuk.com> writes:
>>
>>> On 13/08/2023 21:45, Ben Bacarisse wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>> What has this got to do with make?
>>>> But again, what has this do with make?
>>>
>>>> And again, what has this to do with make?
>>>
>>> I'm looking for a project to build on Windows using make. I didn't have
>>> much luck; they seem to avoid using it!
>>
>>You found a Unix utility hardly used on Windows. Film at 11.
>
>As far as I am aware, Windows doesn't have a native make utility in
>the first place (nmake is part of the visual studio distribution), so
>its likely that Bart's quest to find a package that uses make on
>windows will fail.
>

DOS/Windows (and Mac similarly) has *never* shipped with any sort of
development environment, so arguing that it doesn't have "make" is kind of
pointless.

--
https://en.wikipedia.org/wiki/Mansplaining

It describes comp.lang.c to a T!

On Monday, 14 August 2023 at 02:06:04 UTC+1, Kenny McCormack wrote:
> In article <PPeCM.479849$TCKc....@fx13.iad>,
> Scott Lurndal <sl...@pacbell.net> wrote:
> >Ben Bacarisse <ben.u...@bsb.me.uk> writes:
> >>Bart <b...@freeuk.com> writes:
> >>
> >>> On 13/08/2023 21:45, Ben Bacarisse wrote:
> >>>> Bart <b...@freeuk.com> writes:
> >>>> What has this got to do with make?
> >>>> But again, what has this do with make?
> >>>
> >>>> And again, what has this to do with make?
> >>>
> >>> I'm looking for a project to build on Windows using make. I didn't have
> >>> much luck; they seem to avoid using it!
> >>
> >>You found a Unix utility hardly used on Windows. Film at 11.
> >
> >As far as I am aware, Windows doesn't have a native make utility in
> >the first place (nmake is part of the visual studio distribution), so
> >its likely that Bart's quest to find a package that uses make on
> >windows will fail.
> >
> DOS/Windows (and Mac similarly) has *never* shipped with any sort of
> development environment, so arguing that it doesn't have "make" is kind of
> pointless.
>
Yes, when I started as a DOS programmer you had to buy a compiler.
I asked for one as a birthday present from my grandmother, and I remember
trying to explain to her what she had just bought me. Then later on I
moved to Windows and bought Visual Studio. It was a lot of money
for me at the time, and was a "personal" copy. It lacked an optimiser, some
group work facilities (I think) and you weren't allowed to sell software compiled
with it. The full version cost several hundred pounds and was out of reach.
But I loved it because of the integrated help (this was pre good internet).

Then they broke it when Vista came out. I compained, and received
an arrogant and dismissive response. I was absolutely furious. The
personal, affordable compilers were discontinued, and only the enterprise
edition available. Which cost more than the computer. There was a free
Visual Studio available, but you could tell that at the time Microsoft
wasn't happy about releasing free software. It was badly done, and difficult
to use, and didn't support the latest C standards, and didn't have proper API
documentation. And it came with ban on using it to develop software
with what they called a "viral" licence.

Nowadays Visual Studio is free even to commercial users. Stallman has
won. But you have to download it. It doesn't ship as standard.

In article <8fb22829-9b5e-4108-a513-df3b72391405n@googlegroups.com>,
Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
....
>> DOS/Windows (and Mac similarly) has *never* shipped with any sort of
>> development environment, so arguing that it doesn't have "make" is kind of
>> pointless.

I may actually have mis-spoken here. DOS did originally come with GWBASIC,
so you could, at least write and run programs back then.

Whether BASIC (of any stripe) counts as a development environment is, of
course, open to debate...

Does modern Windows come with VB.NET ready-to-go, or do you have to
download it?

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/FreeCollege

On Monday, 14 August 2023 at 03:44:31 UTC+1, Kenny McCormack wrote:
> In article <8fb22829-9b5e-4108...@googlegroups.com>,
> Malcolm McLean <malcolm.ar...@gmail.com> wrote:
> ...
> >> DOS/Windows (and Mac similarly) has *never* shipped with any sort of
> >> development environment, so arguing that it doesn't have "make" is kind of
> >> pointless.
> I may actually have mis-spoken here. DOS did originally come with GWBASIC,
> so you could, at least write and run programs back then.
>
Yes, when microcomputers came out in the 1980s, it was thought that the
average user would also develop his own programs. So when you booted
the computer it put you into the BASIC. Because the machine was so small,
there wasn't a distinction between the editor and the intepreter.
>
> Whether BASIC (of any stripe) counts as a development environment is, of
> course, open to debate...
>
I'm an implementer of BASIC myself so don't diss the language. MIniBasic, which
is my version, is used in embedded systems. Often the embedded processor is
doing something pretty trivial in programming terms (the interest of the project
is in the electronics). It's easier to edit a short MiniBasic script on the machine
than cross-compile and load an executable.
>
> Does modern Windows come with VB.NET ready-to-go, or do you have to
> download it?
>
You have to download it. VB is still used for serious commercial development.
But for programs where the focus is on the GUI and business logic. It's not
used much for the sort of programming that I do.

On 2023-08-14, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <PPeCM.479849$TCKc.32962@fx13.iad>,
> Scott Lurndal <slp53@pacbell.net> wrote:
>>Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>Bart <bc@freeuk.com> writes:
>>>
>>>> On 13/08/2023 21:45, Ben Bacarisse wrote:
>>>>> Bart <bc@freeuk.com> writes:
>>>>> What has this got to do with make?
>>>>> But again, what has this do with make?
>>>>
>>>>> And again, what has this to do with make?
>>>>
>>>> I'm looking for a project to build on Windows using make. I didn't have
>>>> much luck; they seem to avoid using it!
>>>
>>>You found a Unix utility hardly used on Windows. Film at 11.
>>
>>As far as I am aware, Windows doesn't have a native make utility in
>>the first place (nmake is part of the visual studio distribution), so
>>its likely that Bart's quest to find a package that uses make on
>>windows will fail.
>>
>
> DOS/Windows (and Mac similarly) has *never* shipped with any sort of
> development environment, so arguing that it doesn't have "make" is kind of
> pointless.

MS-DOS came with DEBUG.COM: an assembly language development
environment. :)

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

On 14/08/2023 01:46, Scott Lurndal wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 13/08/2023 21:45, Ben Bacarisse wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>> What has this got to do with make?
>>>> But again, what has this do with make?
>>>
>>>> And again, what has this to do with make?
>>>
>>> I'm looking for a project to build on Windows using make. I didn't have
>>> much luck; they seem to avoid using it!
>>
>> You found a Unix utility hardly used on Windows. Film at 11.
>
> As far as I am aware, Windows doesn't have a native make utility in
> the first place (nmake is part of the visual studio distribution), so
> its likely that Bart's quest to find a package that uses make on
> windows will fail.
>

There are projects with makefiles that are meant to work with Windows.
IME they mostly don't work, in that something usually goes wrong. I just
couldn't remember what they were.

I do however remember one that did work: LuaJIT. I downloaded it now,
and there, the main makefile has this comment:

# Suitable for POSIX platforms (Linux, *BSD, OSX etc.).
# Note: src/Makefile has many more configurable options.
# # ##### This Makefile is NOT useful for Windows! #####
# For MSVC, please follow the instructions given in src/msvcbuild.bat.
# For MinGW and Cygwin, cd to src and run make with the Makefile there.

I don't have MSVC (I can rarely get it to work, and it's monstrous).

Mingw I guess means gcc on Windows. When I tried that other makefile, it
worked perfectly. The output messages were also clean and restrained (no
endless crap flying up the screen for an hour, like GMP under MSYS).

But this is rare. My assertion is that they're usually troublesome. I
also don't hold with having to use MSVC when I have a perfectly good
compiler, gcc, even with its foibles.

This project is unusual (or maybe this is common) as it can't really be
built with any compiler. Attempts to use one that's not supported will
display:

lj_def.h:300: error: #error "missing defines for your compiler"

Here it's done properly: helpful messages inside the downloaded files.

In article <20230813210150.757@kylheku.com>,
Kaz Kylheku <864-117-4973@kylheku.com> wrote:
....
>MS-DOS came with DEBUG.COM: an assembly language development
>environment. :)

Indeed. And I used it as such - many times. I also used DEBUG as an editor.

--
12% of Americans think that Joan of Arc was Noah's wife.

On Monday, August 14, 2023 at 6:14:39 AM UTC-4, Kenny McCormack wrote:
> In article <202308132...@kylheku.com>,
> Kaz Kylheku <864-11...@kylheku.com> wrote:
> ...
> >MS-DOS came with DEBUG.COM: an assembly language development
> >environment. :)
> Indeed. And I used it as such - many times. I also used DEBUG as an editor.
>
> --
> 12% of Americans think that Joan of Arc was Noah's wife.
There is a GNU version of Make for Windows. There is also a GNU version of the GCC for Windows that can compile compatible binaries for Window's and x86_x64.

For native Windows apps though, it really doesn't make sense to use it long term, as the MSVC is clearly optimized to leverage the OS and all its features to make programs work efficiently.

Besides the Visual Studio build system that you can configure within the app, if you prefer "lighter" dev environments, its perfectly easy to use VS Code with an off the shelf build system like CMake or PreMake (or even GNU Make) as long as you have a C/C++ compiler already in your System Variables Path (or configured through VS Code's config). What you lose by NOT doing Windows application development inside of Visual Studio is its extremely feature rich Debug suite.

On 13/08/2023 15:53, Bart wrote:
> Bart:
> >> Suppose you dispensed with all that dependency stuff; how long would
> >> it take to build such a project? Say compared with just compiling one
> >> module.
> >>
>
> David Brown:
>
> > That particular project takes a minute and a half to compile on my
> > laptop (it's faster on my main machine).  It's 373 compilations, perhaps
> > 40% of it C++.  Too long for convenience.
>
> OK. I'm surprised (since you say you work on embedded systems) that
> software for those can be so elaborate.
>

I work on embedded systems - mostly microcontroller systems. But why
would that mean few files in a project? Like most programmers, I
organise my source files and split things up in logical sections. So
even the smallest of programs might have 15 or more C files. And this
particular program is not small, and includes things like a network
stack, an RTOS, and a large number of manufacturer-supplied driver files
in the microcontroller's SDK. The final binary is about 200 KB in size.
Oh, and I was counting compilations, not source files - the "make"
here builds two binaries with different options for different variations
of the program. (And the build was on my old laptop - my desktop takes
half the time.)

> But I thought, should I give 'make' one more chance?

No, you did not. You thought "perhaps people really do find make
useful. I'll have to invent some more crap and mistakes to justify
refusing to use this practical tool for 40 years. Maybe if I post
enough nonsense, this time people will believe the problem is with make,
not with me".

>
> So, maybe 'make' can work under Windows,

As I said, I have used "make" with Windows for about three decades. And
I am not alone - lots of other people seem to manage fine.

>
> 'make' is only part of the problem. Yet these projects are quite
> small-scale, with dozens of source files, compared with gcc 13.2 which
> had 75,000 source files, and that was described by two people here as
> being simple to build.

I have built about a dozen gcc cross-compilers on Windows over the
years. Microcontroller manufacturers are far better about providing
"official" and supported gcc toolchain builds now, but there was a time
when you had to do more things by yourself. I've built it more recently
on Linux, because that's my main development platform. Usually you use
scripts or ready-made recipes, since you are looking for libraries,
binutils, and other tools for cross-development as well as the compiler,
but however you do it, most of the work is controlled by a few "make"
invocations.

On 13/08/2023 22:45, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>

>> Lua Interpreter: This had a makefile, but gave errors.
>
> Linux software, does not compile without effort on Windows. In other
> news, bear defecates in the woods.
>
>> A closer look
>> revealed things like "-DLINUX...". I know this builds on Windows, but there
>> was no info as to how that I could see.
>
> They make it hard. It's hidden on the download page under the heading
> "Building" with the confusing link "detailed instructions".
>
> But again, what has this do with make?
>

I opened a command prompt on my Windows PC, downloaded lua source and
built it according to the "detailed instructions". All told, it took
about a minute, including reading the instructions. "make" on Windows
works fine.

On 14/08/2023 13:49, David Brown wrote:
> On 13/08/2023 15:53, Bart wrote:
>> OK. I'm surprised (since you say you work on embedded systems) that
>> software for those can be so elaborate.
>>
>
> I work on embedded systems - mostly microcontroller systems. But why
> would that mean few files in a project? Like most programmers, I
> organise my source files and split things up in logical sections. So
> even the smallest of programs might have 15 or more C files. And this
> particular program is not small, and includes things like a network
> stack, an RTOS, and a large number of manufacturer-supplied driver files
> in the microcontroller's SDK. The final binary is about 200 KB in size.

So several different components. Would you really need to build all the
other components when working on only one of them, if you didn't have a
makefile to tell you where each belonged?

> Oh, and I was counting compilations, not source files - the "make"
> here builds two binaries with different options for different variations
> of the program. (And the build was on my old laptop - my desktop takes
> half the time.)
>
>> But I thought, should I give 'make' one more chance?
>
> No, you did not. You thought "perhaps people really do find make
> useful. I'll have to invent some more crap and mistakes to justify
> refusing to use this practical tool for 40 years. Maybe if I post
> enough nonsense, this time people will believe the problem is with make,
> not with me".

And yet I wasn't able to successfully build a working Windows executable
for 3 out of those 4 programs (including Tcc that I added later, and
excluding the Linux-only program). Whether I was using make or not.

I *was* able to do so for LuaJIT, and using 'make'. So what was the
difference in the latter case; why didn't my 'incompetence' stretch to
that program too?

Is it possible that more care was given to making it foolproof?

Below I show how I build the Pico C project. The recommendation was to
use heavyweight MS tools to build this 0.1MB project, but it is
unnecessary given the right info.

A VS installation can be up to 100,000 times the size of pico.exe.

BTW bcc built it in 1/8th of a second, for a program half the size of
your 200KB project.

> I have built about a dozen gcc cross-compilers on Windows over the
> years. Microcontroller manufacturers are far better about providing
> "official" and supported gcc toolchain builds now, but there was a time
> when you had to do more things by yourself.

Yeah. I used to create my own languages and compilers for microcomputers
(I still do!). Plus writing all my own drivers. That's when I wasn't
also building prototypes of those computers using 120 hand-wired ICs
(that, I don't do anymore).

As for the 120,000 files of gcc 13.2 versus the 70 files of bcc: gcc-O3
runs the Pico program below about twice as fast as bcc.

--------------------
Pico C @file listing the source files needed:

clibrary.c
debug.c
expression.c
heap.c
include.c
lex.c
parse.c
picoc.c
platform.c
table.c
type.c
variable.c
ctype.c
errno.c
math.c
stdbool.c
stdio.c
stdlib.c
string.c
time.c
platform_msvc.c
library_msvc.c

Building Pico C using bcc and that 'pico' @ file:

c:\pico>bcc -old -out:pico @pico
Compiling clibrary.c to clibrary.asm
Compiling debug.c to debug.asm
Compiling expression.c to expression.asm
Compiling heap.c to heap.asm
Compiling include.c to include.asm
Compiling lex.c to lex.asm
Compiling parse.c to parse.asm
Compiling picoc.c to picoc.asm
Compiling platform.c to platform.asm
Compiling table.c to table.asm
Compiling type.c to type.asm
Compiling variable.c to variable.asm
Compiling ctype.c to ctype.asm
Compiling errno.c to errno.asm
Compiling math.c to math.asm
Compiling stdbool.c to stdbool.asm
Compiling stdio.c to stdio.asm
Compiling stdlib.c to stdlib.asm
Compiling string.c to string.asm
Compiling time.c to time.asm
Compiling platform_msvc.c to platform_msvc.asm
Compiling library_msvc.c to library_msvc.asm
Assembling to pico.exe

Building Pico C using gcc and the same file:

c:\pico>gcc -opico.exe @pico

(Some warnings not shown). Tcc failed to compile it. Options are kept
out of the @ file to keep it cross-compiler.

On 14/08/2023 14:06, David Brown wrote:
> On 13/08/2023 22:45, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>
>>> Lua Interpreter: This had a makefile, but gave errors.
>>
>> Linux software, does not compile without effort on Windows. In other
>> news, bear defecates in the woods.
>>
>>> A closer look
>>> revealed things like "-DLINUX...". I know this builds on Windows, but
>>> there
>>> was no info as to how that I could see.
>>
>> They make it hard. It's hidden on the download page under the heading
>> "Building" with the confusing link "detailed instructions".
>>
>> But again, what has this do with make?
>>
>
> I opened a command prompt on my Windows PC, downloaded lua source and
> built it according to the "detailed instructions". All told, it took
> about a minute, including reading the instructions. "make" on Windows
> works fine.

So, how did you do it? I assume this is proper Windows and not WSL.

On the downloaded source bundle from Github, there were no such
instructions.

If I go to the 'detailed instructions', there I managed to derive a list
of .c files, which I put into a text file called 'fred'.

Then I can build Lua using any of:

bcc @fred -old
tcc @fred
gcc @fred -olua -O3

So the build system is - a list of 33 files (which I compiled into one
..exe; Lua prefers to split it into .exe and .dll).

No make file needed in this case at all. The supplied makefile was 25
times bigger than the simple list.

However, the point I already made was that I /wanted/ to 'make' to see
if I could get through it without errors.

David Brown <david.brown@hesbynett.no> writes:
>On 13/08/2023 15:53, Bart wrote:
>> Bart:
>> >> Suppose you dispensed with all that dependency stuff; how long would
>> >> it take to build such a project? Say compared with just compiling one
>> >> module.
>> >>
>>
>> David Brown:
>>
>> > That particular project takes a minute and a half to compile on my
>> > laptop (it's faster on my main machine).  It's 373 compilations, perhaps
>> > 40% of it C++.  Too long for convenience.
>>
>> OK. I'm surprised (since you say you work on embedded systems) that
>> software for those can be so elaborate.
>>
>
>I work on embedded systems - mostly microcontroller systems. But why
>would that mean few files in a project? Like most programmers, I
>organise my source files and split things up in logical sections. So
>even the smallest of programs might have 15 or more C files. And this
>particular program is not small, and includes things like a network
>stack, an RTOS, and a large number of manufacturer-supplied driver files
>in the microcontroller's SDK. The final binary is about 200 KB in size.
> Oh, and I was counting compilations, not source files - the "make"
>here builds two binaries with different options for different variations
>of the program. (And the build was on my old laptop - my desktop takes
>half the time.)

We provide the firmware for our SoCs. That firmware includes
such things as UEFI or Uboot along with all the code to isolate hardware
from the OS (e.g. ACPI and processor-specific interfaces) as well
as code to initialize the hardware and the code for the various
onboard management cores (MIPS/ARM M class). It is a very large source base.

Bart <bc@freeuk.com> writes:
>On 14/08/2023 14:06, David Brown wrote:
> > On 13/08/2023 22:45, Ben Bacarisse wrote:
> >> Bart <bc@freeuk.com> writes:
> >>
> >
> >>> Lua Interpreter: This had a makefile, but gave errors.
> >>
> >> Linux software, does not compile without effort on Windows. In other
> >> news, bear defecates in the woods.
> >>
> >>> A closer look
> >>> revealed things like "-DLINUX...". I know this builds on Windows, but
> >>> there
> >>> was no info as to how that I could see.
> >>
> >> They make it hard. It's hidden on the download page under the heading
> >> "Building" with the confusing link "detailed instructions".
> >>
> >> But again, what has this do with make?
> >>
> >
> > I opened a command prompt on my Windows PC, downloaded lua source and
> > built it according to the "detailed instructions". All told, it took
> > about a minute, including reading the instructions. "make" on Windows
> > works fine.
>
>So, how did you do it? I assume this is proper Windows and not WSL.
>
>On the downloaded source bundle from Github, there were no such
>instructions.

You've been pointed to the instructions more than once in this
thread.

On 14/08/2023 16:49, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:

>> So, how did you do it? I assume this is proper Windows and not WSL.
>>
>> On the downloaded source bundle from Github, there were no such
>> instructions.
>
> You've been pointed to the instructions more than once in this
> thread.

And I've twice said I've found them. I also said how I eventually
managed to build that program (hint: it didn't involve a makefile).

But what those other commentators have not said is how they would build
it or have built it. With a working Windows makefile or not? I still
don't know.

I do know that all 5 projects I mentioned could be trivially built with
the simplest script. Yet all through the other thread everybody was
pushing make and makefiles.

But then you always make these drive-past comments in claiming something
that isn't true, or suggesting I'm lying about something, or saying my
in-house languages were hobby projects, and never back them up or admit
you were wrong.

It seems like a personal campaign against me.

So, in that case: fuck you.

On 14/08/2023 15:58, Bart wrote:
> On 14/08/2023 14:06, David Brown wrote:
> > On 13/08/2023 22:45, Ben Bacarisse wrote:
> >> Bart <bc@freeuk.com> writes:
> >>
> >
> >>> Lua Interpreter: This had a makefile, but gave errors.
> >>
> >> Linux software, does not compile without effort on Windows.  In other
> >> news, bear defecates in the woods.
> >>
> >>> A closer look
> >>> revealed things like "-DLINUX...". I know this builds on Windows, but
> >>> there
> >>> was no info as to how that I could see.
> >>
> >> They make it hard.  It's hidden on the download page under the heading
> >> "Building" with the confusing link "detailed instructions".
> >>
> >> But again, what has this do with make?
> >>
> >
> > I opened a command prompt on my Windows PC, downloaded lua source and
> > built it according to the "detailed instructions".  All told, it took
> > about a minute, including reading the instructions.  "make" on Windows
> > works fine.
>
> So, how did you do it? I assume this is proper Windows and not WSL.
>

Yes, "proper" Windows. I have msys2/mingw64 installed. (I haven't used
it for several years, because I haven't needed it.) I followed the
instructions - "curl" to download the lua tarball, "tar" to extract it,
then "cd" into the directory. As noted on the "detailed instructions",
I tried "make" and found it failed to guess the platform exactly. So I
then - as directed by the instructions - used "make mingw". Then I had
"lua.exe" and "luac.exe" build.

> On the downloaded source bundle from Github, there were no such
> instructions.

The "readme" file says "For complete information about Lua, visit lua.org."

Seriously, how much spoonfeeding do you need? Is it /that/ hard to read
a few lines on a webpage?

On 14/08/2023 19:00, Bart wrote:
> On 14/08/2023 16:49, Scott Lurndal wrote:
>> Bart <bc@freeuk.com> writes:
>
>>> So, how did you do it? I assume this is proper Windows and not WSL.
>>>
>>> On the downloaded source bundle from Github, there were no such
>>> instructions.
>>
>> You've been pointed to the instructions more than once in this
>> thread.
>
> And I've twice said I've found them.

Apparently not.

> I also said how I eventually
> managed to build that program (hint: it didn't involve a makefile).
>
> But what those other commentators have not said is how they would build
> it or have built it.

I told you how /I/ built it on Windows - by following the instructions,
using "make" on Windows. And now in another post I've given even more
details, which I hope will answer all your questions.

> With a working Windows makefile or not? I still
> don't know.

You would have known if you'd read my post yesterday in which I said
that is /exactly/ what I did.

>
> I do know that all 5 projects I mentioned could be trivially built with
> the simplest script. Yet all through the other thread everybody was
> pushing make and makefiles.
>

Probably all projects /could/ be built with scripts - though for many
projects, it would not be trivial. But that does not make scripts the
best choice for building them. And such scripts are certainly not the
best choice when developing projects (as distinct from distributing
complete ready-to-use projects, which is a very different thing).

> But then you always make these drive-past comments in claiming something
> that isn't true, or suggesting I'm lying about something, or saying my
> in-house languages were hobby projects, and never back them up or admit
> you were wrong.
>
> It seems like a personal campaign against me.
>

When you are saying one thing, and everyone else is saying something
different, does it ever occur to you that perhaps /you/ are the one that
is in the wrong?

This is not a "campaign against you". These threads are (for me, at
least), an attempt to educate you and help you at least appreciate why
other people use tools like make and gcc, even if /you/ don't like them.
And they are also to counter misinformation and confusion that you
post - other people might read your posts and think they are accurate or
represent reality for C development.

On 14/08/2023 15:39, Bart wrote:
> On 14/08/2023 13:49, David Brown wrote:
> > On 13/08/2023 15:53, Bart wrote:
> >> OK. I'm surprised (since you say you work on embedded systems) that
> >> software for those can be so elaborate.
> >>
> >
> > I work on embedded systems - mostly microcontroller systems.  But why
> > would that mean few files in a project?  Like most programmers, I
> > organise my source files and split things up in logical sections.  So
> > even the smallest of programs might have 15 or more C files.  And this
> > particular program is not small, and includes things like a network
> > stack, an RTOS, and a large number of manufacturer-supplied driver files
> > in the microcontroller's SDK.  The final binary is about 200 KB in size.
>
> So several different components. Would you really need to build all the
> other components when working on only one of them, if you didn't have a
> makefile to tell you where each belonged?
>

"make" automates the process of figuring out which compilations are
needed. Of course it doesn't do anything that I could not do manually.
And if I change "spi.c" then I know I need to re-compile that, and not
"uart.c", and other files. But that would mean that after editing
"spi.c" I'd have to manually choose to re-compile "spi.c", including the
perhaps 500 or more characters in the command line (lots of warning
flags, carefully chosen options, pre-defined macros, directory paths for
source code, object code, listing files, include paths, etc. - this is
not a "hello.c" toy on a PC). And if I changed the "clocks.h" header,
I'd have to look through dozens of source files to see which ones
included that header and needed re-compiling, and which ones do not.

Or I can type "make". (Or, more commonly, press "ctrl-B" and the IDE
will do "make" and update the source windows with markers for any issues
found.)

Which do you think is a better choice for development?

<snip the irrelevant whining about your inability to use tools everyone
else uses, and claims that your own tools are therefore better even
though they are useless to the rest of the world>

On Tuesday, 15 August 2023 at 10:08:32 UTC+1, David Brown wrote:
> On 14/08/2023 15:39, Bart wrote:
> > On 14/08/2023 13:49, David Brown wrote:
> > > On 13/08/2023 15:53, Bart wrote:
> > >> OK. I'm surprised (since you say you work on embedded systems) that
> > >> software for those can be so elaborate.
> > >>
> > >
> > > I work on embedded systems - mostly microcontroller systems. But why
> > > would that mean few files in a project? Like most programmers, I
> > > organise my source files and split things up in logical sections. So
> > > even the smallest of programs might have 15 or more C files. And this
> > > particular program is not small, and includes things like a network
> > > stack, an RTOS, and a large number of manufacturer-supplied driver files
> > > in the microcontroller's SDK. The final binary is about 200 KB in size.
> >
> > So several different components. Would you really need to build all the
> > other components when working on only one of them, if you didn't have a
> > makefile to tell you where each belonged?
> >
> "make" automates the process of figuring out which compilations are
> needed. Of course it doesn't do anything that I could not do manually.
> And if I change "spi.c" then I know I need to re-compile that, and not
> "uart.c", and other files. But that would mean that after editing
> "spi.c" I'd have to manually choose to re-compile "spi.c", including the
> perhaps 500 or more characters in the command line (lots of warning
> flags, carefully chosen options, pre-defined macros, directory paths for
> source code, object code, listing files, include paths, etc. - this is
> not a "hello.c" toy on a PC). And if I changed the "clocks.h" header,
> I'd have to look through dozens of source files to see which ones
> included that header and needed re-compiling, and which ones do not.
>
> Or I can type "make". (Or, more commonly, press "ctrl-B" and the IDE
> will do "make" and update the source windows with markers for any issues
> found.)
>
> Which do you think is a better choice for development?
>
The problem with that is that the make files will contain 500 or more characters
of lots of warning flags, carefully chosen options, pre-defined macros, directory
paths for source code, object code, listing files, include paths, etc). It's OK
whilst you are developing the project, because everything is set up just so.

But what happens if you need to dust it off some years later? What if something
goes wrong?

I'm not saying there's an easy answer.

But code broke for me just this morning. Someone had added a test to the test suite,
and messed with the CMake script so that it always searched for CppuTest instead
of only when tests were being built. So it broke my build, and I was in the CMake files
and git history, trying to work out what was wrong. But at least CMake gives good errors
and has intuitive syntax.

On 15/08/2023 08:54, David Brown wrote:
> On 14/08/2023 15:58, Bart wrote:
>> On 14/08/2023 14:06, David Brown wrote:
>> > On 13/08/2023 22:45, Ben Bacarisse wrote:
>> >> Bart <bc@freeuk.com> writes:
>> >>
>> >
>> >>> Lua Interpreter: This had a makefile, but gave errors.
>> >>
>> >> Linux software, does not compile without effort on Windows. In
other
>> >> news, bear defecates in the woods.
>> >>
>> >>> A closer look
>> >>> revealed things like "-DLINUX...". I know this builds on Windows,
>> but
>> >>> there
>> >>> was no info as to how that I could see.
>> >>
>> >> They make it hard. It's hidden on the download page under the
>> heading
>> >> "Building" with the confusing link "detailed instructions".
>> >>
>> >> But again, what has this do with make?
>> >>
>> >
>> > I opened a command prompt on my Windows PC, downloaded lua source and
>> > built it according to the "detailed instructions". All told, it took
>> > about a minute, including reading the instructions. "make" on
Windows
>> > works fine.
>>
>> So, how did you do it? I assume this is proper Windows and not WSL.
>>
>
> Yes, "proper" Windows. I have msys2/mingw64 installed. (I haven't used
> it for several years, because I haven't needed it.) I followed the
> instructions - "curl" to download the lua tarball, "tar" to extract it,
> then "cd" into the directory.
" but here is a simple terminal session that downloads the current
release of Lua and builds it in Linux:"

Proper Windows indeed!

> As noted on the "detailed instructions",
> I tried "make" and found it failed to guess the platform exactly. So I
> then - as directed by the instructions - used "make mingw". Then I had
> "lua.exe" and "luac.exe" build.
OK, you got me. There one mention of "mingw" (not "make mingw") on this
page:

https://www.lua.org/manual/5.4/readme.html

It is in a section called Building Lua which starts with:

"In most common UNIX-LIKE platforms, simply do "make". Here are the
details." (My emphasis)

In subsection 3, "mingw" occurs in this list, all well-known versions of
Windows:

"guess aix bsd c89 freebsd generic ios linux linux-readline
macosx mingw posix solaris"

Silly me for not spotting that and looking ahead to a section called:

"Building Lua on other systems"

Which starts with:

"If you're not using the usual Unix tools,"

Not exactly crystal clear is it.

This reminds of forums where people complaing of being caught out on
some parking infringement because the signs were not clear. And others
say of course they were clear: all the rules were explained in the small
print at the bottom of that sign placed 12' up that post, /inside/ the
car park!

Of course, even after all that, I extract a fresh copy of the
'lua-master' folders, do 'make mingw', and it says:

make: *** No rule to make target 'mingw'. Stop.

So NOW what am I doing wrong?

One thing that you must acknowledges is that those build instructions
could surely be less Unix-centric and could even have a special section
for Windows.

It is after all hardly a minor or uncommon OS. You don't really want to
scour it for clues within the 'small print'.

The only mention of Windows on that page is a suggestion to generate a
DLL instead (why?).

>> On the downloaded source bundle from Github, there were no such
>> instructions.
>
> The "readme" file says "For complete information about Lua, visit
lua.org."
>
> Seriously, how much spoonfeeding do you need? Is it /that/ hard to read
> a few lines on a webpage?

How hard is it to just say:

# For building on Windows use 'make mingw'

within the makefile? (Slightly harder is to ensure it works.)

Now I KNOW this is personal. You will not acknowledge that the build
instructions could be better; it HAS to be my fault.

NOTES

(1) Note that under Building Lua it says:

"Open a terminal window and move to the top-level directory, which is
named lua-5.4.6."

My directory isn't called lua-5.4.6. It's called "lua-master". It was
obtained from https://github.com/lua/lua using 'Download ZIP'.

If I go to Releases, then I can get one with the right name, but it's
the same set of files and still doesn't build.

(2) At the end of the day, I did after all get lua.exe, working from the
list of .o files given later on the page.

So no thanks to those earlier instructions, or to 'make'.

> Is it /that/ hard to read a few lines on a webpage?

Hand-on-heart, would you say that page was clearly written for Windows
users?