On 22/08/2023 15:41, Scott Lurndal 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.
>>
>> 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 may be true. It is likely wishful thinking on your part, however.

Well, it works for me. That's all I want.

> However, you seem to think that useful code can be developed
> just using the facilities defined by the C standard. Which is almost
> never the case.

Code /can/ be developed without requiring half of the utilities provided
by Linux. Those developers just don't know how.

Certainly, source code can be deployed without those facilties. Because
you have to ask, if a certain C application actually written in C, or is
it really written also in Bash, M4 and Make-syntax?

> As the C language predated windows by a decade or more, windows is
> the johnny-come-lately here, and your expectation that C software developers
> must accomodate windows systems is flawed.

What sort of accommodation?

I'm only asking that a C application uses a C compiler. The OS doesn't
come into it (that's a detail for the C implementation for the platform).

Or is C not really that portable?

The first time I ported a C program from Windows to Linux (an
18,000-line interpreter), it worked pretty much full time.

Presumably, porting an identical application from Linux to Windows would
be impossible without dragging half of Linux with it?

How come /I/ can do it and no one else can't? I've given an example of
the Pico C interpreter requiring a VS installation to compile on Windows
(but I could trivially compile it anyway, no thanks to the build
instructions).

>
>> (I'm not replying to your other points as you are not receptive to what
>> I am trying to do.
>
> Is anyone other than yourself obsessed with executable size,
> compile times or easy command line use?

Oh course they are, don't be silly:

* Massive development has gone into optimisation passes of gcc to get
the best performance and/or minimum size of applications. Applications
which obviously include compilers.

(Have gcc.exe/cc1.exe etc been compiled with optimisation enabled?
Obviously, but to what purpose, since you seem to think that no-one cares?)

* An extraordinary amount of effort has gone into makefiles to determine
inter-dependencies between files, in order to minimise unnecessary
compilation. Why would anyone do that unless compilation was an overhead
to be avoided as much as possible.

* And apparently a lot of work has gone into paralleling builds.

I guess that's done for no reason at all?

So yeah, these products are a LOT more obsessed with it than I am! My
own compilers don't even optimise.

>> You are just shrugging your shoulders at Windows. So
>> is nearly everyone. You are part of the problem.
>
> It's a problem to you. It doesn't appear to be a problem to
> others.

How do you know that? Something must have happened to libjpeg between
version 6 and 9 to result in that helpful addition to the INSTALL file.
An addition which enabled me to build the product.

Oh, I understand. It's not something that's ever happened to YOU
(probably because you don't use Windows), therefore it's not a problem
full stop.

>>
>> I think you were even cheeky enough to suggest that I because I don't
>> pay for this software, I can't complain if its build process is rubbish.
>
> It is a valid point. You can complain all you want (which you do),
> but nobody is required to listen.

And a pig's ear of a build system will remain so. Especially if no one
says anything.

>
>>
>> I bet if I was providing anything similar /as free software/, and
>> claimed it worked for platform X, then I would darn well make sure it
>> was as simple, foolproof and effortless as I could make it.)
>
> The point of configure was to provide that capability across a wide
> range of unix and unix-like systems.

Which Kaz says is now completely pointless. It is testing capabilities
of C systems which are now in widespread use!

And in any case it is something that ought to be done once and for all
per C implementation, ideally by the install process (or already done
and built-in), not each time you install any applications.

I notice that if you do ./configure again, it repeats the same tests.
(How does it know what C compiler you have in mind anyway?)

>
>> It also has #includes for dozens of libraries that I've never heard of,
>> are not included in the source bundle, and are not part of Windows.
>
> And why would you expect otherwise?
>
> You mentioned 'open' vs 'fopen' in another post - open(2) provides
> useful functionality that fopen(3) doesn't, including far better
> I/O performance. Why shouldn't an application that requires the
> functionality provided by open(2) use it?

What stops fopen() being implemented as a thin wrapper around open() on
systems where that exists?

I don't know what extra functionality you have in mind. But I suspect
the vast majority of uses of open() could be met by fopen().

I mean, on Windows nobody uses OpenFile (I probaby last saw it used in
Petzold's book); it's too much of a palaver. I've used C's fopen
(usually not /from/ C) since the mid-90s. I don't recall any limitations.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>On Tuesday, 22 August 2023 at 15:41:51 UTC+1, Scott Lurndal wrote:
>>
>> As the C language predated windows by a decade or more, windows is
>> the johnny-come-lately here, and your expectation that C software developers
>> must accomodate windows systems is flawed.
>>
>You have to live in the real world. Windows is very widely used, and often you
>have to support it, because that's where your users are.

"Must" != "Can"

Bart <bc@freeuk.com> writes:
>On 22/08/2023 15:41, Scott Lurndal wrote:

>> You mentioned 'open' vs 'fopen' in another post - open(2) provides
>> useful functionality that fopen(3) doesn't, including far better
>> I/O performance. Why shouldn't an application that requires the
>> functionality provided by open(2) use it?
>
>What stops fopen() being implemented as a thin wrapper around open() on
>systems where that exists?

https://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html

Indeed, fopen() simply calls open() on posix systems. However, fopen()
only uses a very small subset of the capabilities supported by open(),
including the ability to use such functionality as 'mmap'.

But far worse is the performance impact of using stdio for I/O; the
data is buffered first in the kernel, then in libc, then finally
in the application - open bypasses the stdio buffering and on
linux systems support O_DIRECT to bypass _all_ buffering.

On 22/08/2023 16:40, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 22/08/2023 15:41, Scott Lurndal wrote:
>
>>> You mentioned 'open' vs 'fopen' in another post - open(2) provides
>>> useful functionality that fopen(3) doesn't, including far better
>>> I/O performance. Why shouldn't an application that requires the
>>> functionality provided by open(2) use it?
>>
>> What stops fopen() being implemented as a thin wrapper around open() on
>> systems where that exists?
>
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html
>
> Indeed, fopen() simply calls open() on posix systems. However, fopen()
> only uses a very small subset of the capabilities supported by open(),
> including the ability to use such functionality as 'mmap'.
>
> But far worse is the performance impact of using stdio for I/O; the
> data is buffered first in the kernel, then in libc, then finally
> in the application - open bypasses the stdio buffering and on
> linux systems support O_DIRECT to bypass _all_ buffering.
>

Presumably compilers like gcc and rustc use open(), that's why they're
so fast?

With my languages, reading and writing files is an insignificant
propertion of compile-time (like, 0-2%). With optimising compilers, it
would be nothing at all.

I still contend that Linux programmers use open() out of a combination
of laziness, ignorance and lack of interest in portability. Not for its
advanced capabilities.

Basically, most of the time you just want to read in a frigging 10KB
config file. But use open instead of fopen, and you rule out Windows for
no good reason.

On 22/08/2023 15:51, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 22/08/2023 08:12, Kelsey Bjarnason wrote:
>
>> (Where are these giant programs anyway? I once did a survey of all the
>> EXEs and DLLS on my machine. I think 99% of all such files were under
>> 10MB, or some such figures.
>
> What makes your machine representative of the entire population of
> machines?

What makes yours representative?

The system32 folder on my Windows 11 machine is representative of the
vast population of the Windows machines.

But you're welcome to post your own observations.

You seem to be claiming that the majority of projects represented by a
makefile are for huge projects.

/I/ am claiming that most individual binaries you see in the wild are
comparatively small.

On Tuesday, 22 August 2023 at 17:19:40 UTC+1, Bart wrote:
> On 22/08/2023 15:51, Scott Lurndal wrote:
> > Bart <b...@freeuk.com> writes:
> >> On 22/08/2023 08:12, Kelsey Bjarnason wrote:
> >
> >> (Where are these giant programs anyway? I once did a survey of all the
> >> EXEs and DLLS on my machine. I think 99% of all such files were under
> >> 10MB, or some such figures.
> >
> > What makes your machine representative of the entire population of
> > machines?
> What makes yours representative?
>
> The system32 folder on my Windows 11 machine is representative of the
> vast population of the Windows machines.
>
> But you're welcome to post your own observations.
>
> You seem to be claiming that the majority of projects represented by a
> makefile are for huge projects.
>
> /I/ am claiming that most individual binaries you see in the wild are
> comparatively small.
>
That's on a PC used mainly for routine personal computing.
Some programs are massive. But they do things like predict the weather or
run spacecraft. You wouldn't have one on your personal system.

Bart <bc@freeuk.com> writes:
>On 22/08/2023 15:51, Scott Lurndal wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 22/08/2023 08:12, Kelsey Bjarnason wrote:
>>
>>> (Where are these giant programs anyway? I once did a survey of all the
>>> EXEs and DLLS on my machine. I think 99% of all such files were under
>>> 10MB, or some such figures.
>>
>> What makes your machine representative of the entire population of
>> machines?
>
>What makes yours representative?

That is not a responsive answer. That's a deflection.

Bart <bc@freeuk.com> writes:
>On 22/08/2023 15:51, Scott Lurndal wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 22/08/2023 08:12, Kelsey Bjarnason wrote:
>>
>>> (Where are these giant programs anyway? I once did a survey of all the
>>> EXEs and DLLS on my machine. I think 99% of all such files were under
>>> 10MB, or some such figures.
>>
>> What makes your machine representative of the entire population of
>> machines?
>
>What makes yours representative?
>
>The system32 folder on my Windows 11 machine is representative of the
>vast population of the Windows machines.
>
>But you're welcome to post your own observations.
>
>You seem to be claiming that the majority of projects represented by a
>makefile are for huge projects.
>
>/I/ am claiming that most individual binaries you see in the wild are
>comparatively small.

Again with the obsession about the size of the binaries.

I'll point out that a 10mb text section implies a very substantial amount
source code, which generally is partitioned into many source files
(hundreds or even thousands). libQtGui.so has the largest text section.

$ (cd /lib64; size -t -- $(ls *.so))

text data bss dec hex filename
126707 5088 456 132251 2049b ld-2.18.so
145454 13376 80 158910 26cbe libADM_UIQT46.so

.... 37 lines elided

11091608 298416 13256 11403280 ae0010 libQtGui.so

.... 350 lines elided

3591750 254240 1664 3847654 3ab5e6 libxerces-c-3.1.so
33680 2272 80 36032 8cc0 libxfce4kbd-private-2.so
69130 3320 208 72658 11bd2 libxfce4ui-1.so
50838 1576 4360 56774 ddc6 libxfce4util.so
70679 2456 184 73319 11e67 libxfconf-0.so
491478 18480 1144 511102 7cc7e libxml.so
1429702 37380 5272 1472354 167762 libxml2.so
83241 1304 8 84553 14a49 libz.so
61096 1440 96 62632 f4a8 libzip.so
244450 37648 1008 283106 451e2 p11-kit-proxy.so
198282 41992 672 240946 3ad32 p11-kit-trust.so
36523 1332 2696 40551 9e67 preloadable_libintl.so

187795031 9387338 12548895 209731264 c803ec0 (TOTALS)

Of course, not all of the text section will be loaded into memory
for any of these libraries due to the not even modern innovation of
demand paging.

On 22/08/2023 17:30, Malcolm McLean wrote:
> On Tuesday, 22 August 2023 at 17:19:40 UTC+1, Bart wrote:
>> On 22/08/2023 15:51, Scott Lurndal wrote:
>>> Bart <b...@freeuk.com> writes:
>>>> On 22/08/2023 08:12, Kelsey Bjarnason wrote:
>>>
>>>> (Where are these giant programs anyway? I once did a survey of all the
>>>> EXEs and DLLS on my machine. I think 99% of all such files were under
>>>> 10MB, or some such figures.
>>>
>>> What makes your machine representative of the entire population of
>>> machines?
>> What makes yours representative?
>>
>> The system32 folder on my Windows 11 machine is representative of the
>> vast population of the Windows machines.
>>
>> But you're welcome to post your own observations.
>>
>> You seem to be claiming that the majority of projects represented by a
>> makefile are for huge projects.
>>
>> /I/ am claiming that most individual binaries you see in the wild are
>> comparatively small.
>>
> That's on a PC used mainly for routine personal computing.
> Some programs are massive. But they do things like predict the weather or
> run spacecraft. You wouldn't have one on your personal system.

I'm sure those exist. (Although I expect the ones running /on board/
spacecraft are not as massive as you suggest.)

But that is a reason why /some/ people need to have complex build systems.

It is not a reason why /I/ need to do deal with makefiles to deal with
comparatively small projects that I want to build. That libjpeg project
is only 700KB in total (it took bcc just over a second to build that).

Your 'BBX' project (ie. the RC) was 2MB, which also took bcc under 1.5
seconds to build. In both these cases, I was able to do so thanks to
having or deriving the necessary build information, that would underwise
be completely buried beneath piles of arcane syntax.

Or, in the case of 'configure'-driven projects, the info would only come
into existence (and in an even more impenetable form) once you've run
that script on a Linux machine, which is crazy.

On 2023-08-22, Kelsey Bjarnason <kbjarnason@gmail.com> wrote:
> On Tue, 22 Aug 2023 02:28:29 +0100, Bart wrote:
>
>> On 22/08/2023 01:58, Kelsey Bjarnason wrote:
>>> On Sat, 19 Aug 2023 13:44:28 -0700 (PDT), bart c wrote:
>>
>>>> Is easier than messing about with makefiles. But you seem to be under
>>>> the impression that using a makefile isn't running a script. I don't
>>>> get it.
>>>
>>> Call it a script if you like. The point remains, it does rather more
>>> than merely "gcc -oprog prog.c"; for one, it ensures (assuming proper
>>> rules are in place) both that modified dependencies get rebuilt, and
>>> that unmodified ones don't unless told to.
>>>
>>> So just as a trivial example, assume we have a dependency tree like so:
>>>
>>> types.h
>>> interface.h
>>> interface.c
>>> chess.h
>>> engine.c
>>>
>>> Now interface.h gets modified. Make would cause interface.c to be
>>> rebuilt and the final output (executable, presumably) to be rebuilt,
>>> but not engine.c.
>>
>>
>>
>>> How does your script manage this - rebuilding what is necessary to
>>> rebuild, but *only* what is necessary to rebuild?
>>
>> It wouldn't. At the point /I/ come across makefiles, I only want to
>> build the app from scratch. So everything will need compiling anyway. I
>> don't need all those complications.
>>
>> I've made this point half a dozen times.
>
> That's great if you only work on toy-sized apps.
>
> I've worked on apps where it took the combined effort of an entire network
> of machines half a day to do a complete rebuild, which is obviously not
> viable if you have multiple coders modifying multiple files and needing to
> keep changes up to date and in sync. But rebuilding just the few bits
> which have been modified, or have had their dependencies modified, becomes
> trivial with a proper makefile. You type "make", wait for the few modules
> to build, then carry on. Maybe a couple minutes. And you're not working
> to outdated objects, because of dependency checking.
>
>
> I'm sure you could do the same with a script, as well, but then you're
> just trading one "build language" for another, less well known, less well
> established one.

Not if it's a POSIX script. Make is based on recipes written in the
shell language, so they are both equally established.

Instead of a rule like:

compiler: lexer.o parser.o main.o
...

we could write a script like:

if older compiler lexer.o parser.o main.o; then
...
fi

Where older is something like:

older()
{
# let's use Bash locals
local target=$1 ; shift

while [ $# -gt 0 ] ; do
if [ "$target" -ot "$1" ]; then
return 0
fi
shift
fi

return 0
}

For large projects, the script would get long and it would take quite a
bit of time for it to all these checks. Make has to do the checks too,
but it's compiled. There have existed compilers for shell scripts which
could level some of the difference. Comeau used to sell one?

With suitably defined functions, we could condense the actual rules
quite a bit.

One advatnage over Make would be that our script could deal with
filenames that have spaces and funny characters.

Build recipes would naturally be single script fragments rather than
individual shell invocations.

Here documents could be used. There are problems using shell here
documents out of makefiles. I can't remember which but it's either
impossible or impractically contorted.

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

On 22/08/2023 17:50, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 22/08/2023 15:51, Scott Lurndal wrote:
>>> Bart <bc@freeuk.com> writes:
>>>> On 22/08/2023 08:12, Kelsey Bjarnason wrote:
>>>
>>>> (Where are these giant programs anyway? I once did a survey of all the
>>>> EXEs and DLLS on my machine. I think 99% of all such files were under
>>>> 10MB, or some such figures.
>>>
>>> What makes your machine representative of the entire population of
>>> machines?
>>
>> What makes yours representative?
>>
>> The system32 folder on my Windows 11 machine is representative of the
>> vast population of the Windows machines.
>>
>> But you're welcome to post your own observations.
>>
>> You seem to be claiming that the majority of projects represented by a
>> makefile are for huge projects.
>>
>> /I/ am claiming that most individual binaries you see in the wild are
>> comparatively small.
>
> Again with the obsession about the size of the binaries.

It's more your obsession since you and others are claiming that, because
/some/ projects are very large and greatly benefit from a makefile, that
/all/ projects should do so.

>
> I'll point out that a 10mb text section implies a very substantial amount
> source code,

As a rule of thumb, about 1Mloc for x64.

Note that my 10MB figure was the total image size, not the code section.

The largest EXE file in system32 folder is MRT.EXE, at 175MB. But 174MB
of that is .data; the code is only 0.3MB.

> which generally is partitioned into many source files
> (hundreds or even thousands). libQtGui.so has the largest text section.
>
>
> $ (cd /lib64; size -t -- $(ls *.so))
>
> text data bss dec hex filename
> 126707 5088 456 132251 2049b ld-2.18.so
> 145454 13376 80 158910 26cbe libADM_UIQT46.so
>
> ... 37 lines elided
>
> 11091608 298416 13256 11403280 ae0010 libQtGui.so
>
> ... 350 lines elided
>
> 3591750 254240 1664 3847654 3ab5e6 libxerces-c-3.1.so
> 33680 2272 80 36032 8cc0 libxfce4kbd-private-2.so
> 69130 3320 208 72658 11bd2 libxfce4ui-1.so
> 50838 1576 4360 56774 ddc6 libxfce4util.so
> 70679 2456 184 73319 11e67 libxfconf-0.so
> 491478 18480 1144 511102 7cc7e libxml.so
> 1429702 37380 5272 1472354 167762 libxml2.so
> 83241 1304 8 84553 14a49 libz.so
> 61096 1440 96 62632 f4a8 libzip.so
> 244450 37648 1008 283106 451e2 p11-kit-proxy.so
> 198282 41992 672 240946 3ad32 p11-kit-trust.so
> 36523 1332 2696 40551 9e67 preloadable_libintl.so
>
> 187795031 9387338 12548895 209731264 c803ec0 (TOTALS)

So, 402 .so files in all, with a /combined/ code size of 188MB. If you
take away those 4 largest sizes (16MB), that means the remaining 398 .so
files have an average code size of 0.43MB (or some 40Kloc according to
my rule).

Somewhat bigger than one of my compilers, which can general build in 0.1
seconds. But a lot of those you list are much smaller.

So your figures, for shared libraries at least, bear out mine.

On 8/20/2023 4:02 AM, bart c wrote:
> On Saturday, 19 August 2023 at 00:32:39 UTC+1, Chris M. Thomasson wrote:
>> On 8/18/2023 8:58 AM, bart c wrote:
>>> On Friday, 18 August 2023 at 16:11:35 UTC+1, David Brown wrote:
>>>> On 18/08/2023 16:48, bart c wrote:
>>>>> On Friday, 18 August 2023 at 14:33:08 UTC+1, David Brown wrote:
>>>>>> On 17/08/2023 18:16, Bart wrote:
>>>>
>>>>>>> This is an analogy I have used before regarding LLVM, which is a backend
>>>>>>> for language implementations. It is quite large and complex.
>>>>>>>
>>>>>>> Once I needed a side-gate for my house. I made it myself, and ended up
>>>>>>> with a 6' high wooden gate, of just the right size.
>>>>>>>
>>>>>>> Now if I'd gone to the LLVM shop as a solution, the gate would have been
>>>>>>> 9 miles high - if I could ever figure it out.
>>>>>>>
>>>>>> As analogies go, that's a particularly silly one.
>>>>>
>>>>> LLVM in concept is simple: feed it some IL (or it calls it IR), and it turns it into a runnable binary. The actuality is very different.
>>>>>
>>>>> I created my own similar product in 2021, which was a 0.2MB binary. The downloads needs to get started with LLVM are some 2.3GB. That's how you get from 6 feet to 9 miles. But the biggest obstacle is the sheer complexity, with 100 /sets/ of documentation.
>>>>>
>>>> Doesn't the quantity of documentation in llvm give you a hint that
>>>> perhaps your product is /not/ similar?
>>>
>>> The point of using LLVM is similar to that of targetting C:
>>>
>>> * You don't want the bother of writing the backend of a compiler
>>>
>>> * You want portability by not generating different code for x64/arm, Linux/Windows etc
>>>
>>> * You want to take advantage of optimisation
>>>
>>> You don't however need that amount of documentation to use C; so C is far simpler.
>>>
>>> An IL would be a much simpler language than C.
>>>
>>> For the IL I use (based on a stack-based VM), a portable interpreter can be written in 0.1MB. A program to turn it into native code would be 0.2MB per target.
>>>
>>> The task is just not complex. Unless you want code that is optimised, but it might be a magnitude bigger task to get it good enough; it won't be several magnitudes bigger.
>>>
>>>
>> Fwiw, remember when you told me that my experimental C cipher code did
>> not compile in Tiny C. Then, we worked together and it did end up
>> compiling? Remember that thread?
>
> Sure. It's still one of my favourite C tests. It was just the right size for tests and demos of building a 3-module project.
>
> And it was also perfectly structured (because the .c and .h files are tidily matched in pairs) to try an experimental feature of my compiler:
>
> bcc -auto cipher
>
> instead of:
>
> bcc cipher hmac sha2
>
> But, even that is better than gcc's:
>
> gcc cipher.c hmac.c sha2.c -ocipher -O3
>
> That last option is not needed, but the main reason for using gcc in a routine build is to benefit from its optimiser.
>
> (Please no one mention the M-word again! I've had enough of prehistoric build methods and dinosaur compilers.)

Well, you helped me make it compile and work on several compilers by
telling me that it would not compile on some of them. Btw, have you ever
tried out Pelles C?

http://www.smorgasbordet.com/pellesc

Search their forums for my last name. I found some anomalies in their
compiler. :^)

You would say, something akin to 'it won't compiler here on this
compiler'. Then I downloaded the compiler, made my code compile on my
end. Then, you would try it and it would compile on your end wrt said
compiler. So, that is great! Thanks again, Bart. :^)

On 8/22/2023 9:19 AM, Bart wrote:
> On 22/08/2023 15:51, Scott Lurndal wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 22/08/2023 08:12, Kelsey Bjarnason wrote:
>>
>>> (Where are these giant programs anyway? I once did a survey of all the
>>> EXEs and DLLS on my machine. I think 99% of all such files were under
>>> 10MB, or some such figures.
>>
>> What makes your machine representative of the entire population of
>> machines?
>
> What makes yours representative?
>
> The system32 folder on my Windows 11 machine is representative of the
> vast population of the Windows machines.

Stay far away from the system32 folder, imvho.

Don't overwrite anything in there (yikes!), and try not to store
anything in there.

>
> But you're welcome to post your own observations.
>
> You seem to be claiming that the majority of projects represented by a
> makefile are for huge projects.
>
> /I/ am claiming that most individual binaries you see in the wild are
> comparatively small.
>
>

Bart <bc@freeuk.com> wrote:
> It's more your obsession since you and others are
> claiming that, because /some/ projects are very
> large and greatly benefit from a makefile, that
> /all/ projects should do so.

It is a virtue in the UNIX world to be a minimalist and
favour efficiency. Or at least it used to be so, since
I know many programs that started out as a pretty small
that have become bloated. I guess it was Kernighan and
Ritchie who called this phenomenon "creeping featurism"?

I may remember wrong, though, but it was certainly
some UNIX gurus who said that.

Linus Torvalds has also said that his original idea was
that his Linux kernel would be "streamlined" a program.
He now freely admits it is bloated with a huge amount
of features, but I guess this is also true with BSDs,
Solaris, and so on.

Anyway, Makefiles reflect the minimalist UNIX attitude.
It expresses dependencies, so running "make" should
build only what it is necessary. Building everything
is frowned upon, since it is a waste of resources even
though small programs can now be compiled quickly with
modern hardware. And of course Makefiles were invented
back in the 1970s when most hardware was slow, so many
programs benefitted from their ability to control the
builds.

I am not a Makefile expert, but have used Linux/UNIX
long enough to be quite familiar with them. Hell, I have
even used GNU Autotools to generate "configure" scripts.

I have found it pretty easy to understand many Makefiles.
Of course they can be massive and complicated, but it
does not have to be so. I must confess that I even like
having Makefiles.

br,
KK

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?

--
Ben.
. Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Ben Bacarisse <ben.usenet@bsb.me.uk>
Newsgroups: comp.lang.c
Subject: Re: Build Systems
Date: Wed, 23 Aug 2023 03:18:36 +0100
Organization: A noiseless patient Spider
Lines: 36
Message-ID: <87lee2qz5v.fsf@bsb.me.uk>
References: <uban99$1rnpb$1@dont-email.me> <ubi5do$38ii5$1@dont-email.me>
<ubib54$39aqa$1@dont-email.me> <ubii7m$3acds$1@dont-email.me>
<ubivp8$3cjsl$1@dont-email.me> <ubl89c$3prfv$1@dont-email.me>
<ubma81$3upnp$1@dont-email.me> <20230817183700.915@kylheku.com>
<011f0102-1241-464c-b628-0350c0be29fbn@googlegroups.com>
<87cyzjx4ob.fsf@bsb.me.uk>
<66629235-f2e0-46e0-bcb1-bf3abe1e33cdn@googlegroups.com>
<87edjyvdba.fsf@bsb.me.uk>
<038f3d41-228f-4f22-9086-8596e9022057n@googlegroups.com>
<87edjxts00.fsf@bsb.me.uk> <ubtvb0$1hpq8$1@dont-email.me>
<87wmxps26h.fsf@bsb.me.uk> <ubub09$1jeo1$1@dont-email.me>
<87r0nxrvm1.fsf@bsb.me.uk> <ubvd3u$1roqh$1@dont-email.me>
<87zg2jrk7t.fsf@bsb.me.uk> <uc12e1$245uh$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Info: dont-email.me; posting-host="7fbce5ccc5941f82fc42db09ce86b67d";
logging-data="2907691"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+yUIS8whEsS+k89CTjIzjkvepmNDt8o6Y="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
Cancel-Lock: sha1:VOm1M/Eggix/88ENBVkSOUgPmoA=
sha1:Lmcm3ujCKILEcd0OAba5YUiaRFI=
X-BSB-Auth: 1.dd613ae474ce9c8cd34c.20230823031836BST.87lee2qz5v.fsf@bsb.me.uk
Xref: rslight2 comp.lang.c:28077

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?

--
Ben.
. Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Ben Bacarisse <ben.usenet@bsb.me.uk>
Newsgroups: comp.lang.c
Subject: Re: Build Systems
Date: Wed, 23 Aug 2023 03:18:36 +0100
Organization: A noiseless patient Spider
Lines: 36
Message-ID: <87lee2qz5v.fsf@bsb.me.uk>
References: <uban99$1rnpb$1@dont-email.me> <ubi5do$38ii5$1@dont-email.me>
<ubib54$39aqa$1@dont-email.me> <ubii7m$3acds$1@dont-email.me>
<ubivp8$3cjsl$1@dont-email.me> <ubl89c$3prfv$1@dont-email.me>
<ubma81$3upnp$1@dont-email.me> <20230817183700.915@kylheku.com>
<011f0102-1241-464c-b628-0350c0be29fbn@googlegroups.com>
<87cyzjx4ob.fsf@bsb.me.uk>
<66629235-f2e0-46e0-bcb1-bf3abe1e33cdn@googlegroups.com>
<87edjyvdba.fsf@bsb.me.uk>
<038f3d41-228f-4f22-9086-8596e9022057n@googlegroups.com>
<87edjxts00.fsf@bsb.me.uk> <ubtvb0$1hpq8$1@dont-email.me>
<87wmxps26h.fsf@bsb.me.uk> <ubub09$1jeo1$1@dont-email.me>
<87r0nxrvm1.fsf@bsb.me.uk> <ubvd3u$1roqh$1@dont-email.me>
<87zg2jrk7t.fsf@bsb.me.uk> <uc12e1$245uh$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Info: dont-email.me; posting-host="7fbce5ccc5941f82fc42db09ce86b67d";
logging-data="2907691"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+yUIS8whEsS+k89CTjIzjkvepmNDt8o6Y="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
Cancel-Lock: sha1:VOm1M/Eggix/88ENBVkSOUgPmoA=
sha1:Lmcm3ujCKILEcd0OAba5YUiaRFI=
X-BSB-Auth: 1.dd613ae474ce9c8cd34c.20230823031836BST.87lee2qz5v.fsf@bsb.me.uk
Xref: rslight2 comp.lang.c:28077

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?

--
Ben.
. Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Ben Bacarisse <ben.usenet@bsb.me.uk>
Newsgroups: comp.lang.c
Subject: Re: Build Systems
Date: Wed, 23 Aug 2023 03:18:36 +0100
Organization: A noiseless patient Spider
Lines: 36
Message-ID: <87lee2qz5v.fsf@bsb.me.uk>
References: <uban99$1rnpb$1@dont-email.me> <ubi5do$38ii5$1@dont-email.me>
<ubib54$39aqa$1@dont-email.me> <ubii7m$3acds$1@dont-email.me>
<ubivp8$3cjsl$1@dont-email.me> <ubl89c$3prfv$1@dont-email.me>
<ubma81$3upnp$1@dont-email.me> <20230817183700.915@kylheku.com>
<011f0102-1241-464c-b628-0350c0be29fbn@googlegroups.com>
<87cyzjx4ob.fsf@bsb.me.uk>
<66629235-f2e0-46e0-bcb1-bf3abe1e33cdn@googlegroups.com>
<87edjyvdba.fsf@bsb.me.uk>
<038f3d41-228f-4f22-9086-8596e9022057n@googlegroups.com>
<87edjxts00.fsf@bsb.me.uk> <ubtvb0$1hpq8$1@dont-email.me>
<87wmxps26h.fsf@bsb.me.uk> <ubub09$1jeo1$1@dont-email.me>
<87r0nxrvm1.fsf@bsb.me.uk> <ubvd3u$1roqh$1@dont-email.me>
<87zg2jrk7t.fsf@bsb.me.uk> <uc12e1$245uh$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Info: dont-email.me; posting-host="7fbce5ccc5941f82fc42db09ce86b67d";
logging-data="2907691"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+yUIS8whEsS+k89CTjIzjkvepmNDt8o6Y="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
Cancel-Lock: sha1:VOm1M/Eggix/88ENBVkSOUgPmoA=
sha1:Lmcm3ujCKILEcd0OAba5YUiaRFI=
X-BSB-Auth: 1.dd613ae474ce9c8cd34c.20230823031836BST.87lee2qz5v.fsf@bsb.me.uk
Xref: rslight2 comp.lang.c:28077

On 8/22/2023 7:18 PM, 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?
>

Install windows, download MSVC; download vcpkg; okay, search vcpkg for
your 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. ;^)

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>

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

.
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Richard Harnden <richard.nospam@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: Build Systems
Date: Wed, 23 Aug 2023 08:42:52 +0100
Organization: A noiseless patient Spider
Lines: 39
Message-ID: <uc4d9s$2r6mr$1@dont-email.me>
References: <uban99$1rnpb$1@dont-email.me> <ubi5do$38ii5$1@dont-email.me>
<ubib54$39aqa$1@dont-email.me> <ubii7m$3acds$1@dont-email.me>
<ubivp8$3cjsl$1@dont-email.me> <ubl89c$3prfv$1@dont-email.me>
<ubma81$3upnp$1@dont-email.me> <20230817183700.915@kylheku.com>
<011f0102-1241-464c-b628-0350c0be29fbn@googlegroups.com>
<87cyzjx4ob.fsf@bsb.me.uk>
<66629235-f2e0-46e0-bcb1-bf3abe1e33cdn@googlegroups.com>
<87edjyvdba.fsf@bsb.me.uk>
<038f3d41-228f-4f22-9086-8596e9022057n@googlegroups.com>
<87edjxts00.fsf@bsb.me.uk> <ubtvb0$1hpq8$1@dont-email.me>
<87wmxps26h.fsf@bsb.me.uk> <ubub09$1jeo1$1@dont-email.me>
<87r0nxrvm1.fsf@bsb.me.uk> <ubvd3u$1roqh$1@dont-email.me>
<87zg2jrk7t.fsf@bsb.me.uk> <uc12e1$245uh$1@dont-email.me>
<87lee2qz5v.fsf@bsb.me.uk>
Reply-To: nospam.harnden@gmail.com
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 23 Aug 2023 07:42:52 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="b1275108e42065e4760fd00b980a54d6";
logging-data="2988763"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18EtmXNaBrfyDulhtmEvqfNt77odfRl9Wg="
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
Gecko/20100101 Thunderbird/102.14.0
Cancel-Lock: sha1:/2W7sylnT5gAFQ+SUlLQTpKfT1I=
In-Reply-To: <87lee2qz5v.fsf@bsb.me.uk>
Xref: rslight2 comp.lang.c:28080

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>

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

.
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Richard Harnden <richard.nospam@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: Build Systems
Date: Wed, 23 Aug 2023 08:42:52 +0100
Organization: A noiseless patient Spider
Lines: 39
Message-ID: <uc4d9s$2r6mr$1@dont-email.me>
References: <uban99$1rnpb$1@dont-email.me> <ubi5do$38ii5$1@dont-email.me>
<ubib54$39aqa$1@dont-email.me> <ubii7m$3acds$1@dont-email.me>
<ubivp8$3cjsl$1@dont-email.me> <ubl89c$3prfv$1@dont-email.me>
<ubma81$3upnp$1@dont-email.me> <20230817183700.915@kylheku.com>
<011f0102-1241-464c-b628-0350c0be29fbn@googlegroups.com>
<87cyzjx4ob.fsf@bsb.me.uk>
<66629235-f2e0-46e0-bcb1-bf3abe1e33cdn@googlegroups.com>
<87edjyvdba.fsf@bsb.me.uk>
<038f3d41-228f-4f22-9086-8596e9022057n@googlegroups.com>
<87edjxts00.fsf@bsb.me.uk> <ubtvb0$1hpq8$1@dont-email.me>
<87wmxps26h.fsf@bsb.me.uk> <ubub09$1jeo1$1@dont-email.me>
<87r0nxrvm1.fsf@bsb.me.uk> <ubvd3u$1roqh$1@dont-email.me>
<87zg2jrk7t.fsf@bsb.me.uk> <uc12e1$245uh$1@dont-email.me>
<87lee2qz5v.fsf@bsb.me.uk>
Reply-To: nospam.harnden@gmail.com
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 23 Aug 2023 07:42:52 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="b1275108e42065e4760fd00b980a54d6";
logging-data="2988763"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18EtmXNaBrfyDulhtmEvqfNt77odfRl9Wg="
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
Gecko/20100101 Thunderbird/102.14.0
Cancel-Lock: sha1:/2W7sylnT5gAFQ+SUlLQTpKfT1I=
In-Reply-To: <87lee2qz5v.fsf@bsb.me.uk>
Xref: rslight2 comp.lang.c:28080

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>

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

.
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Richard Harnden <richard.nospam@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: Build Systems
Date: Wed, 23 Aug 2023 08:42:52 +0100
Organization: A noiseless patient Spider
Lines: 39
Message-ID: <uc4d9s$2r6mr$1@dont-email.me>
References: <uban99$1rnpb$1@dont-email.me> <ubi5do$38ii5$1@dont-email.me>
<ubib54$39aqa$1@dont-email.me> <ubii7m$3acds$1@dont-email.me>
<ubivp8$3cjsl$1@dont-email.me> <ubl89c$3prfv$1@dont-email.me>
<ubma81$3upnp$1@dont-email.me> <20230817183700.915@kylheku.com>
<011f0102-1241-464c-b628-0350c0be29fbn@googlegroups.com>
<87cyzjx4ob.fsf@bsb.me.uk>
<66629235-f2e0-46e0-bcb1-bf3abe1e33cdn@googlegroups.com>
<87edjyvdba.fsf@bsb.me.uk>
<038f3d41-228f-4f22-9086-8596e9022057n@googlegroups.com>
<87edjxts00.fsf@bsb.me.uk> <ubtvb0$1hpq8$1@dont-email.me>
<87wmxps26h.fsf@bsb.me.uk> <ubub09$1jeo1$1@dont-email.me>
<87r0nxrvm1.fsf@bsb.me.uk> <ubvd3u$1roqh$1@dont-email.me>
<87zg2jrk7t.fsf@bsb.me.uk> <uc12e1$245uh$1@dont-email.me>
<87lee2qz5v.fsf@bsb.me.uk>
Reply-To: nospam.harnden@gmail.com
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 23 Aug 2023 07:42:52 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="b1275108e42065e4760fd00b980a54d6";
logging-data="2988763"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18EtmXNaBrfyDulhtmEvqfNt77odfRl9Wg="
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
Gecko/20100101 Thunderbird/102.14.0
Cancel-Lock: sha1:/2W7sylnT5gAFQ+SUlLQTpKfT1I=
In-Reply-To: <87lee2qz5v.fsf@bsb.me.uk>
Xref: rslight2 comp.lang.c:28080

On 23/08/2023 08:42, Richard Harnden wrote:
> 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>

OK, I give up. I spent an interesting few minutes figuring out what the
hell you're suppose to do with that link.

Loads of information on how to obtain a message-id, but how do you turn
that message-id into the actual message?!

Googlegroups doesn't want to know (I think it discovered your post!).

Google can't find anything.

There's no obvious option in my Thunderbird program.

Prepending 'news://' and feeding it to a browser didn't help.

I would normally give a link to a Googlegroups version, but that takes
some effort and it will show a hacked version of my post.

Since I normally display posts in linear order, ordered by date, I
thought the date and time would be enough. Obviously not.

(It won't cut any ice anyway. BB is determined to misunderstand me and
to find issue with everything I'm trying to do. He's accused me of being
a politician; he's more like a prosecuting lawyer!)

Bart:
> Richard Harnden:
>
> > It was Message-ID: <ubvnsg$1tkml$1@dont-email.me>
>
> OK, I give up. I spent an interesting few minutes figuring
> out what the hell you're suppose to do with that link.
>
> Loads of information on how to obtain a message-id, but
> how do you turn that message-id into the actual message?!

You either search by it within your newsreader, or using
external tools, such as al.howardknight.net. The message
above is archived at:

http://al.howardknight.net/?ID=169278852700

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

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.

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.

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

It's my turn then not to be surprised that Linux is so highly favoured
in build systems if your attitude is typical but Windows gets the second
or third class treatment:

- Give it its own makefile (which of course doesn't work), or a dozen
compiler-specific makefiles

- Apply CMake (I don't know if that's a solution; I see it as another
thing to go wrong!)

- Use sln/vcxproj files instead so that people must use VS products

- Supply BAT files (which might then assume a MSVC installation)

- Do nothing; just tell people to use or install enough of Linux to
go the ./configure route

The projects I have managed to build were via a method that's simpler
than all that and that works or that can be trivially adapted, because
it's so transparent, on either kind of OS.

This is hint that maybe build methods can gravitate towards such
approaches (and FGS get rid of autoconf files). But you seem to think I
should personally take charge of every such project on the planet, and
then maintain it for every, even though they are not my projects.

The latter is nonsensical and, given the reaction in this thread, the
former is not going to change either. Build systems will get more
complex and impenetrable, not simpler and more transparent.

On 23/08/2023 12:02, Anton Shepelev wrote:
> Bart:
>> Richard Harnden:
>>
>>> It was Message-ID: <ubvnsg$1tkml$1@dont-email.me>
>>
>> OK, I give up. I spent an interesting few minutes figuring
>> out what the hell you're suppose to do with that link.
>>
>> Loads of information on how to obtain a message-id, but
>> how do you turn that message-id into the actual message?!
>
> You either search by it within your newsreader, or using
> external tools, such as al.howardknight.net. The message
> above is archived at:
>
> http://al.howardknight.net/?ID=169278852700
>

Google Groups used to have an advanced-search page where you could
search for message-ids, but, in their quest to make GG compeletly
useless, they removed it.

<https://groups.google.com/g/comp.lang.c/c/YgV-dQI9MZ0/m/8A6EfUR-BwAJ>

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.

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

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.

Anton Shepelev <anton.txt@g{oogle}mail.com> writes:
>Bart quoth:
>
>> Build systems will get more complex and impenetrable, not
>> simpler and more transparent.
>
>Bart's law.

Sure, whatever you say. I'd call it an effect
of the second law of thermodynamics, myself.

>
>Borland and Free Pascal compilers do not require a separate
>build system (nor a project file, or solution) to build a
>large modular program.

Have any "large modular" programs ever been built in the modern
era using either of those compilers? What is your definition
of both large and modular?

I challenge Bart to try to build qemu without a makefile, or
the linux kernel, or vmware, or the cert stack for Verisign
enterprise certificate generation.

The application I'm working on has an executable driver or
can be dynamically linked with python or other applications and consists
of a very small executable, a large shared object and a
few dozen run-time loadable shared objects that are optionally
loaded depending on run-time configuration of the application.

It consists of about 9 million source lines of code across a few
hundred source files. Stored, of course in a set of hierarchical
directories.

Yet for all that build complexity, the actual makefiles are
small, readable and maintainable.

I challenge Bart to build it using 'bcc *.cpp' or even 'bcc *.cpp */*.cpp */*/*.cpp'

On 23/08/2023 18:43, Scott Lurndal wrote:
> Anton Shepelev <anton.txt@g{oogle}mail.com> writes:
>> Bart quoth:
>>
>>> Build systems will get more complex and impenetrable, not
>>> simpler and more transparent.
>>
>> Bart's law.
>
> Sure, whatever you say. I'd call it an effect
> of the second law of thermodynamics, myself.
>
>>
>> Borland and Free Pascal compilers do not require a separate
>> build system (nor a project file, or solution) to build a
>> large modular program.
>
> Have any "large modular" programs ever been built in the modern
> era using either of those compilers? What is your definition
> of both large and modular?
>
> I challenge Bart to try to build qemu without a makefile, or
> the linux kernel, or vmware, or the cert stack for Verisign
> enterprise certificate generation.

That's like challenging me to travel to the moon using my car.

I think that is a 'strawman' argument. You create an extreme version of
the tasks for which I believe makefiles are unnecessarily used, then
claim that /my/ simpler approach to those tasks won't work.

Yet, my car is perfectly adequate for a school run; I don't need a Saturn V.

> The application I'm working on has an executable driver or
> can be dynamically linked with python or other applications and consists
> of a very small executable, a large shared object and a
> few dozen run-time loadable shared objects that are optionally
> loaded depending on run-time configuration of the application.
>
> It consists of about 9 million source lines of code across a few
> hundred source files. Stored, of course in a set of hierarchical
> directories.
>
> Yet for all that build complexity, the actual makefiles are
> small, readable and maintainable.

> I challenge Bart to build it using 'bcc *.cpp' or even 'bcc *.cpp */*.cpp */*/*.cpp'

Compilers like my 'mm.exe' product accomplish only one task: producing a
single .EXE binary file. To that end, they are given the name of the
lead source module, and from that point everything is automatic.

So building an app presented as multiple components will need a simple
script.

However, C is different: compilers need to be told the files that
comprise each binary. That in itself does not cause complexity; that's
just a simple list.

But makefiles take that simple list and expand it into a graph of
inter-dependencies. (Which information also has to be imparted by
external means; make isn't that clever.)

They further expose intermediate representations such as .o files, which
should be the business of the compiler.

The whole is then further polluted with matters of installation and
maintenance. And then all buried under impenetrable syntax.

Now I don't know the details of your project, or what you consider
'small' and 'readable'. But if it is that small, you can probably use a
simple script.

You might also consider what an emergency build process might look like,
where you've lost all binaries and want to quickly compile everything
without effing about with dependency graphs. The sort of thing that I've
been claiming should accompany packaged sources of working applications.