Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>On 02/02/2024 18:26, Scott Lurndal wrote:
>> bart <bc@freeuk.com> writes:
>>> On 02/02/2024 15:18, Scott Lurndal wrote:
>
>
>To build a "smaller, easier, nicer" make, if that is the goal (and it's
>a very legitimate one),

No, it's not really a legitimate one, since make supports the
single file cases -without a makefile-.

And it supports the largest projects as well (the linux kernel,
for example, is built with make).

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

FYI, on my 64-core 3.4Ghz build machine, it takes an hour
to build our C++ application on a single core. With -j32,
it finishes in a bit under 5 minutes. (32 because it is
a system shared by a number of users, and the compiles
end up I/O bound).

On Sat, 3 Feb 2024 05:52:18 +0000, Malcolm McLean wrote:

> .. but if you were given a UNIX system you were a
> bit special. And that gave UNIX programmers a sense of superiority.
>
> It's a very silly attitude of course.

Naturally. And a company like Microsoft, that is right now trying to turn
Windows into Linux, is simply behaving like a very silly company.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> as is a development tool. So there are two aspects to it. The first is
> deploying as itself. It must be available and capable of being invoked
> on all machines where it needs to be available. It mustn't refuse to
> run correctly because some path somewhere is not set up or it doesn't
> have write permission to output an executable, and so on. That may
> well have been achieved. Typing "as" into the shell on the computer
> I'm typing this on does indeed invoke the program.
>
> But the other side to it that as must make it easy to deploy the
> actual useful end user programs that it is used to develop. So if we
> write an as script, it must be easy to make that script part of an
> executable, place it on the user's machine, and set it up so that the
> user can easily run it and play space invaders or achieve whatever
> else he ultimately wishes to achieve. And what Bart is saying is that
> that is where as is falling down.

"as", as typically provided on Unix-like systems, has a command-line
interface that bart finds distasteful. There is nothing bart wants to
do that he can't do with the as interface, but he doesn't like the way
he has to do it. He has made the false claim that there's something
seriously wrong with "as". (It does have its quirks, but those quirks
are easy to work around, or even to use as intended.)

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

So you've simply assumed, without evidence, that the "as" command line
interface causes all these problems.

It doesn't.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

bart <bc@freeuk.com> writes:
> On 03/02/2024 01:31, Lawrence D'Oliveiro wrote:
>> Hint: it uses the filename extension to determine which language, and
>> which flavour of the language even, it is dealing with.
>
> This is the filename extension which Linux famously ignores, because
> you can use any extension you like?

Yes, this is the filename extension which Linux (whether you're using
the term to refer to the kernel or to the OS) mostly ignores, but which
certain tools like gcc pay attention to.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On 03/02/2024 20:31, Chris M. Thomasson wrote:
> On 2/3/2024 8:03 AM, bart wrote:
> [...]
>
> Do you have a windows installation with a recent version of MSVC
> installed? Give vcpkg a go, and see how it builds things... Then
> automatically integrates them into MSVC. It's pretty nice and about
> time. ;^)

You haven't followed by posts very well. I want to keep as far away from
all that stuff as possible.

(The last time I installed VS, it took 90 minutes. Each time it started
up, usually by inadvertently because of file association, it took 90
seconds. On the same machine, an old one, it took 0.2 seconds to build
my C compiler.)

Everything I am about is managing to do this stuff by the simplest,
leanest means possible. If a program is written in C, then why would you
need anything other than a C compiler to build it?

On 2/3/2024 2:11 PM, bart wrote:
> On 03/02/2024 20:31, Chris M. Thomasson wrote:
>> On 2/3/2024 8:03 AM, bart wrote:
>> [...]
>>
>> Do you have a windows installation with a recent version of MSVC
>> installed? Give vcpkg a go, and see how it builds things... Then
>> automatically integrates them into MSVC. It's pretty nice and about
>> time. ;^)
>
> You haven't followed by posts very well. I want to keep as far away from
> all that stuff as possible.

Okay.

> (The last time I installed VS, it took 90 minutes. Each time it started
> up, usually by inadvertently because of file association, it took 90
> seconds. On the same machine, an old one, it took 0.2 seconds to build
> my C compiler.)

It boots right up for me, less than two seconds, even though it is
pretty damn fat.

> Everything I am about is managing to do this stuff by the simplest,
> leanest means possible. If a program is written in C, then why would you
> need anything other than a C compiler to build it?

Can you C compiler handle C11? If so, that would be great. This one can
do it, MSVC well, nope. MSVC handles C11 atomics, but not threads! GRRRRR.

http://www.smorgasbordet.com/pellesc

On 04/02/2024 00:24, Chris M. Thomasson wrote:
> On 2/3/2024 2:11 PM, bart wrote:
>> On 03/02/2024 20:31, Chris M. Thomasson wrote:
>>> On 2/3/2024 8:03 AM, bart wrote:
>>> [...]
>>>
>>> Do you have a windows installation with a recent version of MSVC
>>> installed? Give vcpkg a go, and see how it builds things... Then
>>> automatically integrates them into MSVC. It's pretty nice and about
>>> time. ;^)
>>
>> You haven't followed by posts very well. I want to keep as far away
>> from all that stuff as possible.
>
> Okay.
>
>
>> (The last time I installed VS, it took 90 minutes. Each time it
>> started up, usually by inadvertently because of file association, it
>> took 90 seconds. On the same machine, an old one, it took 0.2 seconds
>> to build my C compiler.)
>
> It boots right up for me, less than two seconds, even though it is
> pretty damn fat.

It might be faster now on my SSD drive. However my own stuff didn't need
an SSD drive; that's part of the point of keeping things small.

>
>
>> Everything I am about is managing to do this stuff by the simplest,
>> leanest means possible. If a program is written in C, then why would
>> you need anything other than a C compiler to build it?
>
> Can you C compiler handle C11? If so, that would be great. This one can
> do it, MSVC well, nope. MSVC handles C11 atomics, but not threads! GRRRRR.

It compiles some undefined subset of C. But I haven't touched that side
of it for years. That last update of it changed the backend.

MCC is anyway now a private tool. Either programs work with it or they
don't.

But the problem being discussed at length is getting that input into the
compiler in the first place!

Everybody says use makefiles; well they don't work. They tend to be
heavily skewed towards the use of gcc. My compiler isn't gcc.

AFAIK the C standard doesn't mention gcc (nor, probably, makefiles!).

So I'm disappointed there isn't a better, simpler solution to a very,
very simple problem: what exactly goes in place of ... when building any
complete program:

cc ...

And after 100s of posts, still nobody gets it. Oh, just use an
invariably Linux-centric, gcc-centric script in a different language.
How about an OS-neutral, compiler-neutral solution that doesn't involve
a third-party language? (English - or Norwegian - accepted.)

On 2/3/2024 5:19 PM, bart wrote:
[...]
> Everybody says use makefiles; well they don't work. They tend to be
> heavily skewed towards the use of gcc. My compiler isn't gcc.

Shit happens. What else can I say? ;^o

[...]

On 04/02/2024 12:19, bart wrote:
> On 04/02/2024 00:24, Chris M. Thomasson wrote:
>> On 2/3/2024 2:11 PM, bart wrote:
>>> On 03/02/2024 20:31, Chris M. Thomasson wrote:
>>>> On 2/3/2024 8:03 AM, bart wrote:
>>>> [...]
>>>>
>>>> Do you have a windows installation with a recent version of MSVC
>>>> installed? Give vcpkg a go, and see how it builds things... Then
>>>> automatically integrates them into MSVC. It's pretty nice and about
>>>> time. ;^)
>>>
>>> You haven't followed by posts very well. I want to keep as far away
>>> from all that stuff as possible.
>>
>> Okay.
>>
>>
>>> (The last time I installed VS, it took 90 minutes. Each time it
>>> started up, usually by inadvertently because of file association, it
>>> took 90 seconds. On the same machine, an old one, it took 0.2 seconds
>>> to build my C compiler.)
>>
>> It boots right up for me, less than two seconds, even though it is
>> pretty damn fat.
>
> It might be faster now on my SSD drive. However my own stuff didn't need
> an SSD drive; that's part of the point of keeping things small.
>
>>
>>
>>> Everything I am about is managing to do this stuff by the simplest,
>>> leanest means possible. If a program is written in C, then why would
>>> you need anything other than a C compiler to build it?
>>
>> Can you C compiler handle C11? If so, that would be great. This one
>> can do it, MSVC well, nope. MSVC handles C11 atomics, but not threads!
>> GRRRRR.
>
> It compiles some undefined subset of C. But I haven't touched that side
> of it for years. That last update of it changed the backend.
>
> MCC is anyway now a private tool. Either programs work with it or they
> don't.
>
> But the problem being discussed at length is getting that input into the
> compiler in the first place!
>
> Everybody says use makefiles; well they don't work. They tend to be
> heavily skewed towards the use of gcc. My compiler isn't gcc.
>
> AFAIK the C standard doesn't mention gcc (nor, probably, makefiles!).
>
> So I'm disappointed there isn't a better, simpler solution to a very,
> very simple problem: what exactly goes in place of ... when building any
> complete program:
>
>     cc ...
>
> And after 100s of posts, still nobody gets it. Oh, just use an
> invariably Linux-centric, gcc-centric script in a different language.
> How about an OS-neutral, compiler-neutral solution that doesn't involve
> a third-party language? (English - or Norwegian - accepted.)
>
>
Oh, you mean FORTRAN-IV?

On 02.02.2024 18:29, Kaz Kylheku wrote:
> On 2024-02-02, Kenny McCormack <gazelle@shell.xmission.com> wrote:
>> In article <20240202165335.0000384a@yahoo.com>,
>> Michael S <already5chosen@yahoo.com> wrote:
>> ...
>>>> I have no idea who that is, so I'll take your word for it.
>>>>
>>>
>>> Inventor of make
>>
>> At Bell Labs, in 1976.
>>
>> Currently, like quite a few ex-Bell Labs people, a big wheel at Google.

Also fired from AT&T/Bell Labs like the/some other Unix pioneers?

>
> It's like a cargo cult. If we hire old Unix geezers and prop them up in
> chairs, be they dead or alive, magic will happen.

Certainly no magic. But I'd also not disdain their experience.
It has its price, and management typically considers that most.
Google might have more money to afford the expenses.

Janis

On 04/02/2024 01:19, bart wrote:
>
> So I'm disappointed there isn't a better, simpler solution to a very,
> very simple problem: what exactly goes in place of ... when building any
> complete program:
>
>     cc ...
>
> And after 100s of posts, still nobody gets it. Oh, just use an
> invariably Linux-centric, gcc-centric script in a different language.
> How about an OS-neutral, compiler-neutral solution that doesn't involve
> a third-party language? (English - or Norwegian - accepted.)
>
>
No. I get it. Over complicated build systems which break. Very serious
issue. I've had builds break on me and I'm very surprised more people
haven't had the same experience and don't easily understand what you are
saying.

But where David Brown is right is that it is one thing to diagnose the
problem, quite another to solve it. That is extremely difficult and I
don't think we'll find the answer easily. But continue to discuss.

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

On 2/3/2024 8:56 PM, Malcolm McLean wrote:
> On 04/02/2024 01:19, bart wrote:
>>
>> So I'm disappointed there isn't a better, simpler solution to a very,
>> very simple problem: what exactly goes in place of ... when building
>> any complete program:
>>
>>      cc ...
>>
>> And after 100s of posts, still nobody gets it. Oh, just use an
>> invariably Linux-centric, gcc-centric script in a different language.
>> How about an OS-neutral, compiler-neutral solution that doesn't
>> involve a third-party language? (English - or Norwegian - accepted.)
>>
>>
> No. I get it. Over complicated build systems which break. Very serious
> issue. I've had builds break on me and I'm very surprised more people
> haven't had the same experience and don't easily understand what you are
> saying.

I have had some bad experiences, but it was all my fault. One time I
forgot to install a prerequisite to a lib, that was a prerequisite for
another lib. Pissed me off! Then, I have had some interesting linker errors.

>
> But where David Brown is right is that it is one thing to diagnose the
> problem, quite another to solve it. That is extremely difficult and I
> don't think we'll find the answer easily. But continue to discuss.
>

On 2/3/2024 9:36 PM, Chris M. Thomasson wrote:
> On 2/3/2024 8:56 PM, Malcolm McLean wrote:
>> On 04/02/2024 01:19, bart wrote:
>>>
>>> So I'm disappointed there isn't a better, simpler solution to a very,
>>> very simple problem: what exactly goes in place of ... when building
>>> any complete program:
>>>
>>>      cc ...
>>>
>>> And after 100s of posts, still nobody gets it. Oh, just use an
>>> invariably Linux-centric, gcc-centric script in a different language.
>>> How about an OS-neutral, compiler-neutral solution that doesn't
>>> involve a third-party language? (English - or Norwegian - accepted.)
>>>
>>>
>> No. I get it. Over complicated build systems which break. Very serious
>> issue. I've had builds break on me and I'm very surprised more people
>> haven't had the same experience and don't easily understand what you
>> are saying.
>
> I have had some bad experiences, but it was all my fault. One time I
> forgot to install a prerequisite to a lib, that was a prerequisite for
> another lib. Pissed me off! Then, I have had some interesting linker
> errors.

A couple of decades a go, I remember having a linker issue. I was
banging my head against the wall saying why won't this god damn bastard
link! Turns out that I forgot that I had altered one of the makefiles to
use a directory I was using for experiments. Totally forgot about it.
Uughhhh, damn it. Anyway, I finally fixed it in the makefile, and
everything linked up fine, and passed all unit tests. Grrr!

>
>
>
>>
>> But where David Brown is right is that it is one thing to diagnose the
>> problem, quite another to solve it. That is extremely difficult and I
>> don't think we'll find the answer easily. But continue to discuss.
>>
>

On Sat, 3 Feb 2024 15:44:29 +0000, Malcolm McLean wrote:

> On the other had, if you want a GUI, the Windows system is all set up
> for you and you just have to call the right functions.

Except the Win32 GUI functions are pretty low-level, so everybody uses
some kind of toolkit. Only it’s not clear which toolkit is Microsoft’s
official recommendation this week--is it MAUI? Dotnet? WinForms? Something
else I haven’t even heard of?

On Sat, 3 Feb 2024 12:02:48 +0000, bart wrote:

> I guess you're not curious about WHY a project that builds easily on
> Unix causes problems on Windows?

Fundamental NT kernel limitations, going back decades and seemingly
unfixable. Like poll(2)/select(2) not being able to work on pipes. Like
why WSL1 had to be abandoned (in spite of Microsoft’s best efforts), and a
proper Linux kernel brought in with WSL2.

The irony is, the Cygwin folk have been able to build a better POSIX
emulation layer than Microsoft has been able to manage.

On Sat, 3 Feb 2024 14:59:14 +0000, bart wrote:

> I'm concerned about increasing bloat and complexity everywhere. So I'm
> just making a stand by developing my own small, human-scale products.

And you run your stuff on what is probably the most bloated, monolithic,
inflexible, unwieldy, clumsy, overcomplicated, inefficient and bug-ridden
OS in existence--Microsoft Windows.

On 04/02/2024 06:51, Lawrence D'Oliveiro wrote:
> On Sat, 3 Feb 2024 14:59:14 +0000, bart wrote:
>
>> I'm concerned about increasing bloat and complexity everywhere. So I'm
>> just making a stand by developing my own small, human-scale products.
>
> And you run your stuff on what is probably the most bloated, monolithic,
> inflexible, unwieldy, clumsy, overcomplicated, inefficient and bug-ridden
> OS in existence--Microsoft Windows.

I'm sure others can give it a run for its money too. I remember my
Android phone taking 3 minutes to do a restart.

However that vast complexity doesn't get in the way of building C
programs which is what this is about.

But the complexity of Linux CAN get in the way of that, since many build
processes like to utilise half of its features, and that complexity then
needs to be replicated on Windows it I want to build something there.

So while your hatred of Windows is irrational; my dislike of Linux is
rational, since it directly affects the subject of the thread.

On 03/02/2024 18:02, Malcolm McLean wrote:
> On 03/02/2024 16:03, bart wrote:
>> On 03/02/2024 15:44, Malcolm McLean wrote:
>>>
>>> On the other had, if you want a GUI, the Windows system is all set up
>>> for you and you just have to call the right functions. On Unix you
>>> have to configure some sort of front end to X, there's a lot more
>>> messing about, and the GUI elements aren't consistent.
>>
>> For GUI they're both a nightmare unless you use a simpler library that
>> sits on top. Or are you saying that X is even worse than WinAPI?
>
> I've programmed for both and Windows GUI is quite a bit easier to use.
> You have to enter a library name explictly to get the common controls,
> for some stupid reason, but once you do that the whole system is set up
> for you. Just call the API more or less as you would any other C
> function (except for tiny message loop interface), you've got a rich set
> of controls, and they are well designed and harmonised with the rest of
> the programs on the system.
>
> X - if you try to program to Xlib directly you're messing about with
> colur maps and goodness knows what just to get up a window. And if you
> don't it's dependency land and all that that entails, with some popular
> widget toolsets but no real standards. And often you find that these
> will break. However nowadays you can use QT. Which is alot better but
> still not very well designed with a non-canonical slot / message system
> and poor facilites for layout. That's why I was driven to write Baby X.
> A simple clean interface to Xlib that would allow you to get graphics up
> quickly and easily. You shouldn't have to do that, of course.
>

No sane person ever programs directly using Xlib or WinAPI for a gui
unless they have extremely niche requirements. People program using QT,
wxWidgets, GTK, SDL, or a range of other toolkits - almost all of which
are cross-platform and also support a range of language bindings. (Few
people program gui apps in C.)

On 04/02/2024 05:56, Malcolm McLean wrote:
> On 04/02/2024 01:19, bart wrote:
>>
>> So I'm disappointed there isn't a better, simpler solution to a very,
>> very simple problem: what exactly goes in place of ... when building
>> any complete program:
>>

> No. I get it. Over complicated build systems which break. Very serious
> issue. I've had builds break on me and I'm very surprised more people
> haven't had the same experience and don't easily understand what you are
> saying.
>
> But where David Brown is right is that it is one thing to diagnose the
> problem, quite another to solve it. That is extremely difficult and I
> don't think we'll find the answer easily. But continue to discuss.
>

I'm glad you think I am right - and I agree that as a general point,
solving issues is usually harder than diagnosing them. But I did not
say anything remotely like that in any posts, as far as I am aware.

In particular, I am not aware of any "diagnosis" of fundamental issues
with build tools that need solving - certainly not "solving" by Bart's
solution. (I am aware that /Bart/ has trouble using common tools, and
that his solution might help /him/ - which is fine, and I wish him luck
with it for fixing his own issues.) Some people might use tools badly,
and some people publish projects where others find the builds difficult
on different systems. That's a matter of use, not the tools - others
find they work fine. (No tool is perfect, of course, and there's always
scope for improvement.)

So if you want to use my name, I'd rather you did it in reference to
things I have actually said.

On 03/02/2024 15:16, bart wrote:

> MSDOS and Windows were intended for direct use by ordinary consumers.
> Unix was intended for developers.
>

There is a bit of truth in that - though Unix was also targeted at
serious computer users, workstation users (such as for CAD, simulations,
and other demanding work), server usage, and other "big" things. DOS
and Windows were targeted at simpler consumer usage, office applications
and games.

As Linux gained traction, it became perfectly good for "ordinary
consumers" too.

My mother-in-law has used Linux for the last 15 years or so, for email,
browsing, writing letters, banking, and suchlike. And she is as far
from being a "computer nerd" as you can get!

(Given your statement here, why do you find it so hard to accept that
people find Linux a much better platform for developers than Windows?)

> Few ordinary consumers directly use a Unix-like system unless it is made
> to look like MacOS or Android. Or they run a GUI desktop that makes it
> look a bit like Windows.
>

I run a gui that makes my computer look like a computer - instead of
Windows which tries to make it look like a giant schizophrenic telephone
(after having gone through stages such as XP's Teletubbies interface).

Of course, with Linux you have a choice - you can pick a giant telephone
gui if you like.

On 04/02/2024 12:53, David Brown wrote:
> On 03/02/2024 15:16, bart wrote:
>
>> MSDOS and Windows were intended for direct use by ordinary consumers.
>> Unix was intended for developers.
>>
>
> There is a bit of truth in that - though Unix was also targeted at
> serious computer users, workstation users (such as for CAD,

(My company specialised in low-end CAD products, one of them running on
an 8-bit computer using CP/M. I think at one CAD/CAM trade show, we had
the cheapest product by far.)

> (Given your statement here, why do you find it so hard to accept that
> people find Linux a much better platform for developers than Windows?)

I didn't quite say that. I meant that Unix with its abstruse interface
was more suited to technical people such as developers, but also those
in academia or industry. Who could also afford such a machine (because
somebody else was paying).

Some aspects of it, such as case-sensitive commands and file system,
would have caused difficulties. Real-life is not usually case-sensitive.
Even now, ordinary people's exposure to it seems to be mainly with
passwords.

(I did a lot of telephone support walking people through dialogs on a
terminal. A case-sensitive OS would have made things considerably harder.)

But it does seem as though Unix was a breeding ground for multitudinous
developer tools. Plus there was little demarcation between user
commands, C development tools, C libraries and OS.

Somebody who's used to that environment is surely going to have trouble
on an OS like MSDOS or Windows where they have to start from nothing.
Even if most of the tools are now free.

On 04/02/2024 12:44, David Brown wrote:
> On 04/02/2024 05:56, Malcolm McLean wrote:
>> On 04/02/2024 01:19, bart wrote:
>>>
>>> So I'm disappointed there isn't a better, simpler solution to a very,
>>> very simple problem: what exactly goes in place of ... when building
>>> any complete program:
>>>
>
>> No. I get it. Over complicated build systems which break. Very serious
>> issue. I've had builds break on me and I'm very surprised more people
>> haven't had the same experience and don't easily understand what you
>> are saying.
>>
>> But where David Brown is right is that it is one thing to diagnose the
>> problem, quite another to solve it. That is extremely difficult and I
>> don't think we'll find the answer easily. But continue to discuss.
>>
>
> I'm glad you think I am right - and I agree that as a general point,
> solving issues is usually harder than diagnosing them.  But I did not
> say anything remotely like that in any posts, as far as I am aware.
>
> In particular, I am not aware of any "diagnosis" of fundamental issues
> with build tools that need solving - certainly not "solving" by Bart's
> solution.  (I am aware that /Bart/ has trouble using common tools, and
> that his solution might help /him/ - which is fine, and I wish him luck
> with it for fixing his own issues.)  Some people might use tools badly,
> and some people publish projects where others find the builds difficult
> on different systems.  That's a matter of use, not the tools - others
> find they work fine.  (No tool is perfect, of course, and there's always
> scope for improvement.)
>
> So if you want to use my name, I'd rather you did it in reference to
> things I have actually said.
>

You've said repeatedly and at great length that Bart's proposed
solutions won't work. You haven't actually admitted that he has
diagnosed a problem which needs to be solved and maybe I should have
made that clearer. Where you're right is that writing a better build
system than make is hard. Bart referenced Norwegian, which obviously
meant you, and so I didn't introduce your name.

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

On 02/02/2024 10:05, David Brown wrote:
> On 02/02/2024 00:30, Lawrence D'Oliveiro wrote:
>> On Thu, 1 Feb 2024 22:34:36 +0100, David Brown wrote:
>>
>>> I am, however, considering CMake (which works at a
>>> higher level, and outputs makefiles, ninja files or other project
>>> files).
>>
>> Ninja was created as an alternative to Make.
>
> It is an alternative to some uses of make - but by no means all uses.
>
>> Basically, if your Makefiles
>> are going to be generated by a meta-build system like CMake or
Meson, then
>> they don’t need to support the kinds of niceties that facilitate writing
>> them by hand. So you strip it write down to the bare-bones
functionality,
>> which makes your builds fast while consuming minimal resources, and that
>> is Ninja.
>
> Yes.
>
> It is not normal to write ninja files by hand - the syntax is
relatively simple, but quite limited. So it covers the lower level bits
of "make", but not the higher level bits.
>
>
> Perhaps ninja is the tool that Bart is looking for? For the kinds of
things he is doing, I don't think it would be hard to write the ninja
files by hand.

I've had a look. It doesn't look much simpler to me. But even if it was
(in that I could trivially extract the necessary info), open source
projects would need to use it.

This is from its manual:

"Ninja is yet another build system. It takes as input the
interdependencies of files (typically source code and output
executables) and orchestrates building them, quickly.

Ninja joins a sea of other build systems. Its distinguishing goal is to
be fast. It is born from my work on the Chromium browser project, which
has over 30,000 source files ... "

The projects I'm into are 100 to 1000 times smaller than that.

(On my machine, the binaries for Chrome are 20 files totalling 320MB.
But 230MB of that is in one giant DLL file. I wouldn't have taken that
approach. There are ways to split it up into more discrete binaries, and
yet still present one monolithic DLL.

BTW that 230MB DLL exports these 6 functions:

0 00CF1480 13571200 Fun ChromeMain
1 06DBE4B0 115074224 Fun CrashForExceptionInNonABICompliantCodeRange
2 02423320 37892896 Fun GetHandleVerifier
3 031AB2F0 52081392 Fun IsSandboxedProcess
4 0240DCD0 37805264 Fun RelaunchChromeBrowserWithNewCommandLineIfNeeded
5 08EF8C40 149916736 Fun sqlite3_dbdata_init
)

On 2024-02-03, bart <bc@freeuk.com> wrote:
> On 03/02/2024 18:17, Kaz Kylheku wrote:
>> On 2024-02-03, bart <bc@freeuk.com> wrote:
>
>>> Don't you see that using only Unix-like systems is also a bubble?
>>
>> Don't you see that living on Earth is literally being in bubble?
>>
>> Your bubble contains only one person.
>>
>> The Unix-like bubble is pertty huge, full of economic opportunities,
>> spanning from embedded to server.
>
> You're missing my point. Unix imposes a certain mindset, mainly that
> there is only ONE way to things, and that is the Unix way.
^^^

I had to laugh. Others criticise the linux/unix world for having TOO
many ways of doing things, which makes things difficult :-)

On 04/02/2024 16:50, Malcolm McLean wrote:
> On 04/02/2024 12:44, David Brown wrote:
>> On 04/02/2024 05:56, Malcolm McLean wrote:
>>> On 04/02/2024 01:19, bart wrote:
>>>>
>>>> So I'm disappointed there isn't a better, simpler solution to a
>>>> very, very simple problem: what exactly goes in place of ... when
>>>> building any complete program:
>>>>
>>
>>> No. I get it. Over complicated build systems which break. Very
>>> serious issue. I've had builds break on me and I'm very surprised
>>> more people haven't had the same experience and don't easily
>>> understand what you are saying.
>>>
>>> But where David Brown is right is that it is one thing to diagnose
>>> the problem, quite another to solve it. That is extremely difficult
>>> and I don't think we'll find the answer easily. But continue to discuss.
>>>
>>
>> I'm glad you think I am right - and I agree that as a general point,
>> solving issues is usually harder than diagnosing them.  But I did not
>> say anything remotely like that in any posts, as far as I am aware.
>>
>> In particular, I am not aware of any "diagnosis" of fundamental issues
>> with build tools that need solving - certainly not "solving" by Bart's
>> solution.  (I am aware that /Bart/ has trouble using common tools, and
>> that his solution might help /him/ - which is fine, and I wish him
>> luck with it for fixing his own issues.)  Some people might use tools
>> badly, and some people publish projects where others find the builds
>> difficult on different systems.  That's a matter of use, not the tools
>> - others find they work fine.  (No tool is perfect, of course, and
>> there's always scope for improvement.)
>>
>> So if you want to use my name, I'd rather you did it in reference to
>> things I have actually said.
>>
>
> You've said repeatedly and at great length that Bart's proposed
> solutions won't work.

No, I have said repeatedly that it would not work for /me/.

> You haven't actually admitted that he has
> diagnosed a problem which needs to be solved

Why would I "admit" something I don't believe?

> and maybe I should have
> made that clearer.

It's not a matter of clarity - you said explicitly and clearly that I
had talked about "diagnosing the problem".

> Where you're right is that writing a better build
> system than make is hard. Bart referenced Norwegian, which obviously
> meant you, and so I didn't introduce your name.
>

I think Bart referenced Norwegian as something of a joke, as a pun on
programming languages and human languages and a reference to the
wandering topics we've had here recently.