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

Perhaps he doesn't want windows, particuarly for such a lame reason.

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

>> What sort of answers are you looking for?
>
> Start with the question you evaded "Why should he care how easily unix/linux
> software is built on windows".

Where did I say that BB personally should care?

I /have/ remarked on why, if he doesn't care because it doesn't affect
him, why be so antagonistic, and why participate at all?

My posts are about easily ANY software is built on Windows, where either
it is supposed to do so, or there is no reason why it shouldn't.

You people wonder why /I/ am so antagonistic towards C. And it is those
possessive attitudes as much as anything else.

C is /your/ language; it was designed for and on /your/ beloved Unixes;
it mainly uses /your/ compilers (where MSVC is seen as the enemy, and
Mingw as some watered-down imitation of gcc and friends); and of course
it makes full use of all the toys Unix provides (as much as possible,
just out of spite!)

You also make no secret of how much you despise Windows. Why would
anyone even want to run C on Windows? It's only for Unix! Who cares
whether any programs work on such a 'shitty' operating system? One that
you actually have to ... buy?

So your attitude is, Just use C at your own risk, but we're not going to
make it easy for you. To compile code, just install half of Linux
because we're not going to lift a finger otherwise to make it simpler.

That's what I get from this thread, and from you and BB in particular.

Is that about right! Windows users are third class citizens that no body
ought to care about?

If so, that is despical. I'm glad I don't use your fucking 'make'.

Kaz Kylheku <864-117-4973@kylheku.com> writes:

[...]

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

I routinely remove these from any source tree I seriously need to work
with because sooner or later, changes to all the autosomething files
will become necessary and intermediate autosomething files generated
from the others tend to get in the way then.

On Fri, 25 Aug 2023 17:22:54 +0100
Rainer Weikusat <rweikusat@talktalk.net> wrote:
> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>
> [...]
>
> > If you're unfortunate enough to work with AutoTools, then for pete's
> > sake, generate the configure script, and the Makefile.in and whatnot,
> > and check them into the repository. Do that every time they change.
>
> I routinely remove these from any source tree I seriously need to work
> with because sooner or later, changes to all the autosomething files
> will become necessary and intermediate autosomething files generated
> from the others tend to get in the way then.

git supports the gitignore file to cover such situations :
https://git-scm.com/docs/gitignore .So you can add all the automatically
generated files to a gitgnore file.

On 2023-08-25, Spiros Bousbouras <spibou@gmail.com> wrote:
> On Fri, 25 Aug 2023 17:22:54 +0100
> Rainer Weikusat <rweikusat@talktalk.net> wrote:
>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>
>> [...]
>>
>> > If you're unfortunate enough to work with AutoTools, then for pete's
>> > sake, generate the configure script, and the Makefile.in and whatnot,
>> > and check them into the repository. Do that every time they change.
>>
>> I routinely remove these from any source tree I seriously need to work
>> with because sooner or later, changes to all the autosomething files
>> will become necessary and intermediate autosomething files generated
>> from the others tend to get in the way then.
>
> git supports the gitignore file to cover such situations :
> https://git-scm.com/docs/gitignore .So you can add all the automatically
> generated files to a gitgnore file.

I think, gitignore doesn't cover the situation when some of those files
are tracked in git, but you disagree.

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

On 2023-08-25, Rainer Weikusat <rweikusat@talktalk.net> wrote:
> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>
> [...]
>
>> If you're unfortunate enough to work with AutoTools, then for pete's
>> sake, generate the configure script, and the Makefile.in and whatnot,
>> and check them into the repository. Do that every time they change.
>
> I routinely remove these from any source tree I seriously need to work
> with because sooner or later, changes to all the autosomething files
> will become necessary and intermediate autosomething files generated
> from the others tend to get in the way then.

If you have to change the configuration, you have to make a commit for
that and check in the updated files.

That maintains the repository in a configurable, buildable state
for a downstream user who deosn't have AutoTools installed.

If you use the same version of the tools as what was previously used,
then the diffs in those files will be minimized.

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

On 25/08/2023 16:40, Bart wrote:
> On 25/08/2023 14:52, Scott Lurndal wrote:
>> Bart <bc@freeuk.com> writes:
>
>>> What sort of answers are you looking for?
>>
>> Start with the question you evaded "Why should he care how easily
>> unix/linux
>> software is built on windows".
>
> Where did I say that BB personally should care?
>
> I /have/ remarked on why, if he doesn't care because it doesn't affect
> him, why be so antagonistic, and why participate at all?
>
> My posts are about easily ANY software is built on Windows, where either
> it is supposed to do so, or there is no reason why it shouldn't.
>
> You people wonder why /I/ am so antagonistic towards C. And it is those
> possessive attitudes as much as anything else.
>
> C is /your/ language; it was designed for and on /your/ beloved Unixes;
> it mainly uses /your/ compilers (where MSVC is seen as the enemy, and
> Mingw as some watered-down imitation of gcc and friends); and of course
> it makes full use of all the toys Unix provides (as much as possible,
> just out of spite!)
>
> You also make no secret of how much you despise Windows. Why would
> anyone even want to run C on Windows? It's only for Unix! Who cares
> whether any programs work on such a 'shitty' operating system? One that
> you actually have to ... buy?
>
> So your attitude is, Just use C at your own risk, but we're not going to
> make it easy for you. To compile code, just install half of Linux
> because we're not going to lift a finger otherwise to make it simpler.
>
> That's what I get from this thread, and from you and BB in particular.
>
> Is that about right! Windows users are third class citizens that no body
> ought to care about?
>
> If so, that is despical. I'm glad I don't use your fucking 'make'.
>

You might want to cut down on the hallucinogenics - they are making you
paranoid. There is pretty much nothing in that rant that has a
foundation in reality or in posts in this thread. You seem to be
reading what you want to read, or expect to read - not what is actually
written.

Kaz Kylheku <864-117-4973@kylheku.com> writes:
> On 2023-08-25, Rainer Weikusat <rweikusat@talktalk.net> wrote:
>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>
>> [...]
>>
>>> If you're unfortunate enough to work with AutoTools, then for pete's
>>> sake, generate the configure script, and the Makefile.in and whatnot,
>>> and check them into the repository. Do that every time they change.
>>
>> I routinely remove these from any source tree I seriously need to work
>> with because sooner or later, changes to all the autosomething files
>> will become necessary and intermediate autosomething files generated
>> from the others tend to get in the way then.
>
> If you have to change the configuration, you have to make a commit for
> that and check in the updated files.
>
> That maintains the repository in a configurable, buildable state
> for a downstream user who deosn't have AutoTools installed.

Downstream users are a problem I don't have. Nevertheless, I think a
repository is something supposed to be used for development, ie, it
should be expected that users of it will make changes to .ac and .am
files. If the files generated from these are also in the repository,
nuisance git dances will have to be performed to deal with them and this
will also cause nuisance merge conflicts for updates.

On 2023-08-25, Rainer Weikusat <rweikusat@talktalk.net> wrote:
> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>> That maintains the repository in a configurable, buildable state
>> for a downstream user who deosn't have AutoTools installed.
>
> Downstream users are a problem I don't have.
>
> Nevertheless, I think a
> repository is something supposed to be used for development, ie, it
> should be expected that users of it will make changes to .ac and .am
> files.

A repository should easily support all parties. Someone who wants to
build the program for their own use, package it for a distro, or work on
it.

Downstream users are a problem that open source projects have.

> If the files generated from these are also in the repository,
> nuisance git dances will have to be performed to deal with them and this
> will also cause nuisance merge conflicts for updates.

If you merge parallel changes to a primary file from which a secondary
file is generated, you must regenerate the secondary file. The seconary
file should not be merged. (That would be editing, and generated files
are "generated, do not edit", right?)

The problem is not that you get a conflict in the secondary file. The
problem is that you might *not* get a conflict in it, but (1) it's a bad
merge (even though the merge of the primary file is good) and (2) it
happens that the badly merged secondary has a newer timestamp than the
primary, so the build system doesn't notice that it needs to be
regenerated.

So, in fact, it's probably a good idea for a generated file to include
some boilerplate header with the time and date (or hash of the primary
file), so that it will cause a merge conflict on puprpose, preventing a
silent bad merge!

E.g.:

//
// foo.c: generated from foo.x: do not edit!
//
// If you get a merge conflict in the following line, do not try
// to resolve it (see "do not edit!) above; regenerate the file using
// "make foo.c":
//
// 0828aa34e7d8bf5c8007e897ce12459912e7ee491e1c17377432c8bf204704be

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

Bart <bc@freeuk.com> writes:

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

No sane person would have a different attitude, but you jumped to the
conclusion that I have a problem with paying for Windows. I don't. If
I needed it, I'd buy it.

> but presumably are OK with paying for hardware.

False dichotomy. I also have a problem with paying for certain types
of hardware. I hope you do to.

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

Eh? Are you suggesting someone should buy a cheap PC to get Windows
11. You can't be. The simplest way is to buy from MS -- about £43.
That's what I'd do if I wanted to buy it.

> My point is that the cost, whatever it is, isn't extortionate.

And my point was simply that there /is/ a cost, and that "install
Windows" is therefor a slightly misleading instruction. However, if, as
has been suggested, an unregistered copy is usable for most things, I
might have jumped the gun on that.

--
Ben.

Bart <bc@freeuk.com> writes:

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

Clearly, that's a "no". You didn't answer the question nine lines up,
nor the one asking if would answer any. For the record: I don't care
what sort of answer, provided that the words used constitute what as
reasonable reader would call an answer.

>>> But you also say that I should put on my cape and single-handedly fix all
>>> the myriad projects where it could be handled better.
>> No I did not say that. In fact I said something very different
>>
>>> So you acknowledge that some apps build poorly on Windows, but are not
>>> surprised, and also don't appear to care since you don't use Windows.
>>>
>>> Then I'm not quite sure why you're taking part in this thread. It seems to
>>> be one giant <shrug>.
>> I participated because you didn't know what make is, how it is used or
>> the benefits it brings to the people who use it. I hope you are, at
>> least, a little better informed on these topics
>
> I understand now that people use it to solve certain types of problems
> where there are no commonly used alternatives.
>
> I disagree about some of the problems, and have generally used
> alternatives. Those alternatives also tend to be simpler and shorter.
>
> I understand that given the choice of one tool, and typical patterns of use
> (pack /everything/ into one hard-to-understand file), people will get into
> the habit of using it for everything, even when simple alternatives will
> work just as well.

I get the impression that you still don't know why people use make. You
have certainly offered no alternative.

> There could easily be an option in a makefile (if not, than redirecting the
> output will do most of it) where the commands needed to do a clean build,
> with certain defaults, can be captured into a shell script.
>
> Then just supply that script with a source bundle (as well as the
> makefile). That could be a more foolproof backup.

What problem do you think this will solve? On a typical system targeted
by the authors, just typing make will probably just work. If you think
it will help with an unsupported build like Algol 68G on Windows, I can
capture the commands and send them to you to try.

>>> It's my turn then not to be surprised that Linux is so highly favoured in
>>> build systems
>> Linux is favoured by the build systems because all the examples you
>> picked were for Linux software. Is there no similar healthy ecosystem
>> of Windows software? If so, I image very little of it would build on
>> Linux without some work.
>
> I don't actively seek out Windows software. But most attempts to use
> libraries seem to end up in some rabbit-hole which always leads back to
> Linux.

If it is not just you, but a much more widely help opinion that most
"attempts to use libraries" eventually depend on Linux software, then
Linux (or maybe GNU) has won. I can't say I'm not pleased to hear this,
but I appreciate it must be awkward for people developing on Windows.

--
Ben.

On 25/08/2023 21:26, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:

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

> Clearly, that's a "no". You didn't answer the question nine lines up,
> nor the one asking if would answer any.

You want me to tell you why should care? In what capacity of yours would
that be?

Obviously I care, and it's not just because of my personal needs. I see
the current solutions as poor.

You obviously don't care when a solution involves an autocong-generated
script of nearly forty thousand lines that does countless largely
pointless tests.

If you can't see anything Wrong with that then there's nothing much
further I can say to you.

(BTW that 38Kloc configure file was for gzip. That one failed on 'make'
with a missing aclocal-1.16. After online searching I was able to get
around that using:

apt install autoconf

followed by:

autoreconf -f -i

Now make (using a generated 2.5Kloc makefile) proceeds, apparently doing
many of the same tests that ./configure has done, for example:

checking how to run the C preprocessor... gcc -E

Then it fails with being unable to makeinfo or MAKEINFO. Installing
either didn't work. Again, an online search suggested the real package
needed is texinfo:

apt-get install texinfo

Now make eventually completes. What it has created is unclear, I have to
do a directory listing to find it has produced a 440KB executable, a
640KB archive (which seems to include its own versions of functions like
'fopen' and 'printf'), and a number of small bash scripts.

My trick of trying to capture the actual gcc commands doesn't work here;
it is just too deviant. All I can tell you is that libgzip.a probably
comprises 56 .c files, and gzip about another dozen files.)

>> I understand that given the choice of one tool, and typical patterns of use
>> (pack /everything/ into one hard-to-understand file), people will get into
>> the habit of using it for everything, even when simple alternatives will
>> work just as well.
>
> I get the impression that you still don't know why people use make. You
> have certainly offered no alternative.

I've concentrated on one type of task: doing a remote build from source
of a working resource by someone who will be a user, not developer or
maintainer.

And for that, I have mentioned many approaches I have used. Plus of
course I have been building programs of my own for a very long time
without problems and without resorting to such elaborate build methods.
I Keep Things Simple.

>> There could easily be an option in a makefile (if not, than redirecting the
>> output will do most of it) where the commands needed to do a clean build,
>> with certain defaults, can be captured into a shell script.
>>
>> Then just supply that script with a source bundle (as well as the
>> makefile). That could be a more foolproof backup.
>
> What problem do you think this will solve?

Probably nothing. Spending 30 minutes dealing with that Gzip thing has
drained me completely.

Is this the the state-of-the-art in building software? Labyrinthine
scripts in multiple layers which are intent on hiding their tracks.

I really despair. The binaries produced are about 1MB. I can build a 1MB
executable from source in a fraction of second with no fuss at all - I
must be doing something wrong!

If you and others think this gzip business: 38,000 lines of Bash, 2,500
lines of obscure makefile, a million things going on, requiring multiple
extensions to the remote Ubuntu system, is THE way to /distribute/
software from source, then I'm wasting my time.

> If it is not just you, but a much more widely help opinion that most
> "attempts to use libraries" eventually depend on Linux software, then
> Linux (or maybe GNU) has won. I can't say I'm not pleased to hear this,
> but I appreciate it must be awkward for people developing on Windows.

It only affects me when building other people's software, then it is
just frustrating in how complex and, yes, backward some of this stuff it.

Especially how few understand the difference between a developer's
build, and the streamlined one needed by a user:

level 1 lib.dll
level 2 lib.c needs gcc -shared -olib.dll lib.c
level 3 *.c in one linear folder
level 4 *.c in multiple nested folders
level 5 ???? configure scripts, obscure makefiles,
synthesised makefiles, synthesised source
files, needs additional tools, ...

Ideally the user wants just the binary. Sometimes (for example gmail
doesn't like sending .dll attachments), one step back from that is
better, so still one file, but of C source code.

I used to provide level 1 and 2 (either for Windows, level 2 for Linux).

But not everyone has the means to produce an amalgamated file, so level
3 is acceptable. This is a simple list of C files in the same place.

Most open source software however is made available as level 4, and I
seem also to come across lots of level 5 where anything goes.

On Windows I usually work with libraries that exist as DLL binaries.
Then it is enough work creating bindings for those (for my languages'
FFIs) when the APIs are presented as C header files.

Ones that need building from source, I stay clear of.

On Friday, 25 August 2023 at 20:55:52 UTC+1, Ben Bacarisse wrote:
> Bart <b...@freeuk.com> writes:
>
> > On 25/08/2023 02:23, Ben Bacarisse wrote:
> >> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
> >>
> >>> On 8/22/2023 7:18 PM, Ben Bacarisse wrote:
> >>>> Bart <b...@freeuk.com> writes:
> >>
> >>>>> (I'm not replying to your other points as you are not receptive to what I
> >>>>> am trying to do. You are just shrugging your shoulders at Windows. So is
> >>>>> nearly everyone. You are part of the problem.
> >>>>
> >>>> What should I do "at Windows". You seem to think I should care about
> >>>> how easily Unix/Linux software builds on it. Why should I?
> >>>
> >>> Install windows, download MSVC; download vcpkg; okay, search vcpkg for
> >>> your
> >> /Buy/ and install windows. I don't think it's now free is it?
> >
> > Ok, you seem to have a problem with paying for certain types of
> > software,
> No sane person would have a different attitude, but you jumped to the
> conclusion that I have a problem with paying for Windows. I don't. If
> I needed it, I'd buy it.
>
It's hard to buy a Linux machine. Often it's easier and even cheaper to
just buy a Windows box and delete Windows.
But the problem with something like Windows is that if you are in my
situation, for example, you need it. There is no choice. So that's an
uncomfortable situation to be in. The supplier can gouge.
>
> > but presumably are OK with paying for hardware.
> False dichotomy. I also have a problem with paying for certain types
> of hardware. I hope you do to.
> > The cheapest desktop PC I could find in the UK with a minute or two's
> > search was £250 ($300?). It includes Windows 11.
> Eh? Are you suggesting someone should buy a cheap PC to get Windows
> 11. You can't be. The simplest way is to buy from MS -- about £43.
> That's what I'd do if I wanted to buy it.
> > My point is that the cost, whatever it is, isn't extortionate.
> And my point was simply that there /is/ a cost, and that "install
> Windows" is therefor a slightly misleading instruction. However, if, as
> has been suggested, an unregistered copy is usable for most things, I
> might have jumped the gun on that.
>
Microsoft make most of their money from the Office suite and other
services to businesses. They're not trying to get a lot for Windows itself,
fortunately. Though 43 pounds is still quite a bit of money for something
which sells in the millions and has a marginal cost of zero.

Since most people who use Windows will use it every day, it's really
worth registering.

Scott Lurndal to Anton Shepelev

> > Borland and Free Pascal compilers do not require a
> > separate build system (nor a project file, or solution)
> > to build a large modular program.
>
> Have any "large modular" programs ever been built in the
> modern era using either of those compilers?

What do you ask specifically about the modern era, limiting
the entire history of computing to the tiny slice of its
current state? FreePascal is a modern language and
compiler, for that matter, and the majority of programs
written in that require no dedicated build system.

> What is your definition of both large and modular?

A modular program is one comprising two or more moules, such
as introduced in Modula and supported by the Borlad dialect
of Pascal (as "units"), and now present in the majority of
modern languages, such as Python, Julia, and C#. You know
what they are. C's source files are not modules, although I
wish there were, see:

Date: Thu, 1 Nov 2018 01:11:42 +0300
From: Anton Shepelev <anton.txt@gmail.com>
Newsgroups: comp.lang.c
Message-Id: <20181101011142.368f7c22ba2b54779b99f69a@gmail.com>

`large' is not a technical term and needs no personal
definition from me. Do you ask for quantitive criteria? But
I don't think they matter in our case because it is not the
size of a project that makes it need a dedicated build tool.
The FreePascal compiler does the basic job of buidling the
dependency tree and recompiling only the changed files,
whereas the compiler settings and library pathds are stored
in a simple config file.

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

Great, but the majority of popular open-source software has
horrible makefiles.

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

I fear participation in such a challenge will take an
unreasonable amount of effort. Is it not easier to discuss
the specific tasks that your makefiles peform and what Bart
proposes instead? I, for one, had the impression that Bart
objects to (ab)using complicated build systems with
relatively small and simple programs, rather than the Linux
kernel...

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

Bart <bc@freeuk.com> writes:

> On 25/08/2023 21:26, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>
>>>>>> 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?
>
>> Clearly, that's a "no". You didn't answer the question nine lines up,
>> nor the one asking if would answer any.
>
> You want me to tell you why should care? In what capacity of yours would
> that be?

I don't know. I'm not sure what you mean. I'm just someone who trains
dogs a couple of days a week and writes code for fun every now and then.

> Obviously I care, and it's not just because of my personal needs. I see the
> current solutions as poor.

I see them as failed -- at least I take your word for it that the
examples you tried failed. Maybe we misunderstand "caring"? In some
very abstract sense I care. I'd like everything in the world to work
perfectly for everyone. But, to me, caring is active. Should I do
something about the fact that a lot of Unix/Linux software does not
build easily on Windows? And, if so, why?

> You obviously don't care when a solution involves an autocong-generated
> script of nearly forty thousand lines that does countless largely pointless
> tests.

I never said that.

>>> I understand that given the choice of one tool, and typical patterns of use
>>> (pack /everything/ into one hard-to-understand file), people will get into
>>> the habit of using it for everything, even when simple alternatives will
>>> work just as well.
>> I get the impression that you still don't know why people use make. You
>> have certainly offered no alternative.
>
> I've concentrated on one type of task: doing a remote build from source of
> a working resource by someone who will be a user, not developer or
> maintainer.

Yes. That will, inevitably, lead to some deep misunderstanding of why
people use make. I don't think there's much point in examining this in
detail though.

>>> There could easily be an option in a makefile (if not, than redirecting the
>>> output will do most of it) where the commands needed to do a clean build,
>>> with certain defaults, can be captured into a shell script.
>>>
>>> Then just supply that script with a source bundle (as well as the
>>> makefile). That could be a more foolproof backup.
>> What problem do you think this will solve?
>
> Probably nothing.

That makes it a very odd suggestion. But thank you for giving a direct
answer.

> If you and others think this gzip business: 38,000 lines of Bash, 2,500
> lines of obscure makefile, a million things going on, requiring multiple
> extensions to the remote Ubuntu system, is THE way to /distribute/ software
> from source, then I'm wasting my time.

Spin. There are obviously other ways with different costs and benefits.

>> If it is not just you, but a much more widely help opinion that most
>> "attempts to use libraries" eventually depend on Linux software, then
>> Linux (or maybe GNU) has won. I can't say I'm not pleased to hear this,
>> but I appreciate it must be awkward for people developing on Windows.
>
> It only affects me when building other people's software, then it is just
> frustrating in how complex and, yes, backward some of this stuff it.

It's been weirdly successful. Like C itself. A good critique would
include some examination of the reasons for that success.

--
Ben.

On 8/19/2023 4:19 AM, David Brown wrote:
> On 18/08/2023 23:34, Chris M. Thomasson wrote:
>
>>
>> Have you ever forgot to use a tab in a makefile?
>
> I don't think so, because I use tabs generally for spacing.

That's a good thing (for sure). Well, I had this nice make file I
created, and it would not work. God damn it David, it was a missing tab.
Ahh shit. Well, been there done that. I am glad that you have never had
to mess around with that type of error in your makefiles, in your own
work! Yikes!

  (Some
> people prefer spaces, others tabs.)  But I /have/ had an editor convert
> tabs to spaces, or spaces to tabs, on saving a makefile - and that
> really does screw things up.
>
> I doubt if there is anyone that considers the distinction between tabs
> and spaces in makefiles to be a good idea.  That includes the original
> author of make.
>

On 8/19/2023 4:19 AM, David Brown wrote:
> On 18/08/2023 23:34, Chris M. Thomasson wrote:
>
>>
>> Have you ever forgot to use a tab in a makefile?
>
> I don't think so, because I use tabs generally for spacing.  (Some
> people prefer spaces, others tabs.)  But I /have/ had an editor convert
> tabs to spaces, or spaces to tabs, on saving a makefile - and that
> really does screw things up.
>
> I doubt if there is anyone that considers the distinction between tabs
> and spaces in makefiles to be a good idea.  That includes the original
> author of make.
>

Tabs for spacing, humm, as in tap tab and 4 spaces are generated, right?

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

Stay away from the system32 folder!

Anton Shepelev <anton.txt@gmail.moc> writes:

> Scott Lurndal to Anton Shepelev

>> What is your definition of [...] modular?
>
> A modular program is one comprising two or more moules, such
> as introduced in Modula [...]

Modules appeared earlier in the programming language Mesa.
Modula copied them from Mesa.

On Saturday, August 26, 2023 at 11:57:36 PM UTC-4, Chris M. Thomasson wrote:
> On 8/19/2023 4:19 AM, David Brown wrote:
> > On 18/08/2023 23:34, Chris M. Thomasson wrote:
> >
> >>
> >> Have you ever forgot to use a tab in a makefile?
> >
> > I don't think so, because I use tabs generally for spacing. (Some
> > people prefer spaces, others tabs.) But I /have/ had an editor convert
> > tabs to spaces, or spaces to tabs, on saving a makefile - and that
> > really does screw things up.
> >
> > I doubt if there is anyone that considers the distinction between tabs
> > and spaces in makefiles to be a good idea. That includes the original
> > author of make.
> >
> Tabs for spacing, humm, as in tap tab and 4 spaces are generated, right?

Yes, that's the conversion that David was referring to, that screws up
makefiles. What's needed is an editor where tapping tab places a tab
character (and NOT 4 spaces) in the saved makefile.

ja> Yes, that's the conversion that David was referring to, that screws up
ja> makefiles. What's needed is an editor where tapping tab places a tab
ja> character (and NOT 4 spaces) in the saved makefile.

As a last resort, you could use a hex editor to switch it out.

-----------------------------------
user is generated from /dev/urandom

On 2023-08-27, james...@alumni.caltech.edu <jameskuyper@alumni.caltech.edu> wrote:
> Yes, that's the conversion that David was referring to, that screws up
> makefiles. What's needed is an editor where tapping tab places a tab
> character (and NOT 4 spaces) in the saved makefile.

If your programer's editor does not recognize "Makefile" or
"whatever.mk" and adjust its settings for makefile editing, here
is a dime kid ...

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

On 27/08/2023 05:57, Chris M. Thomasson wrote:
> On 8/19/2023 4:19 AM, David Brown wrote:
>> On 18/08/2023 23:34, Chris M. Thomasson wrote:
>>
>>>
>>> Have you ever forgot to use a tab in a makefile?
>>
>> I don't think so, because I use tabs generally for spacing.  (Some
>> people prefer spaces, others tabs.)  But I /have/ had an editor
>> convert tabs to spaces, or spaces to tabs, on saving a makefile - and
>> that really does screw things up.
>>
>> I doubt if there is anyone that considers the distinction between tabs
>> and spaces in makefiles to be a good idea.  That includes the original
>> author of make.
>>
>
> Tabs for spacing, humm, as in tap tab and 4 spaces are generated, right?

No - press the tab key, and a tab character is generated. I generally
view files at 4 spaces per tab. But I mostly use real tab characters in
my files. However, consistency is very important - if I'm working with
a file with spaces, I keep it as spaces (unless I am making so many
changes that I do a spaces-to-tab operation in my editor).

On 27/08/2023 10:32, Kaz Kylheku wrote:
> On 2023-08-27, james...@alumni.caltech.edu <jameskuyper@alumni.caltech.edu> wrote:
>> Yes, that's the conversion that David was referring to, that screws up
>> makefiles. What's needed is an editor where tapping tab places a tab
>> character (and NOT 4 spaces) in the saved makefile.
>
> If your programer's editor does not recognize "Makefile" or
> "whatever.mk" and adjust its settings for makefile editing, here
> is a dime kid ...
>

Most editors can handle that. But I have used a large number of editors
over the years, on different OS's - some sophisticated, some less so,
depending on my needs at the time. And sometime I've accidentally
triggered a tab-to-space conversion.

On 8/27/2023 7:58 AM, David Brown wrote:
> On 27/08/2023 10:32, Kaz Kylheku wrote:
>> On 2023-08-27, james...@alumni.caltech.edu
>> <jameskuyper@alumni.caltech.edu> wrote:
>>> Yes, that's the conversion that David was referring to, that screws up
>>> makefiles. What's needed is an editor where tapping tab places a tab
>>> character (and NOT 4 spaces) in the saved makefile.
>>
>> If your programer's editor does not recognize "Makefile" or
>> "whatever.mk" and adjust its settings for makefile editing, here
>> is a dime kid ...
>>
>
> Most editors can handle that.

Yup. MSVC handles that. A tab is 4 spaces in my personal C++ code.
Actually, there is a funny scene in Silicon Valley about this very issue:

https://youtu.be/SsoOG6ZeyUI

> But I have used a large number of editors
> over the years, on different OS's - some sophisticated, some less so,
> depending on my needs at the time.  And sometime I've accidentally
> triggered a tab-to-space conversion.
>
>