On 21/08/2023 14:12, Bart wrote:
> On 21/08/2023 13:12, Richard Harnden wrote:
>> On 21/08/2023 11:09, Bart wrote:
>
>>> Start here: https://libjpeg.sourceforge.net/
>>>
>>> (The configure file needed /bin/sh changed to /bin/bash)
>>
>>
>> Or, jpeg-turbo:
>> git clone https://github.com/libjpeg-turbo/libjpeg-turbo.git
>
> That last one uses CMake.
>
> Among the highly varied build instructions, the ones for MingW are:
>
>   cd {build_directory}
>   cmake -G"MSYS Makefiles" [additional CMake flags] {source_directory}
>   make
>
> I experimented with various incantations of that middle line (I
> understand that [] means optional, and {} is a placeholder for an actual
> path), but got nowhere.

(
I would've used [] for optional and <> for a place-holder,
and {} for a group/set of things
)

For me, this worked:
cd libjpeg-turbo
cmake -G"Unix Makefiles"
make
make test

>
> > That is from 1998.
> >
> > Better is http://ijg.org/, then download jpegsrc.v9e.tar.gz (or
> > jpegsr9e.zip)
>
> At first this looks very similar to the 1998 version. But in the INSTALL
> file, there is something magical:
>
>   Configuring the software by hand
>   --------------------------------
>
>   First, generate a jconfig.h file.  If you are moderately familiar
> with C,
>   the comments in jconfig.txt should be enough information to do this;
> just
>   copy jconfig.txt to jconfig.h and edit it appropriately.  Otherwise,
> you may...
>
> I copied jconfig.txt to jconfig.h. Now I need a list of files. It
> suggests using makefile.ansi for the makefile, which I will try first.
>
> I did that, and 'make' now finally works.
>
> The difference here is a project explains things in English and shows
> how to get around the need for things like 'configure'.
>
> jconfig.h, if comments are stripped, is 38 lines. I didn't need to
> change anything.
>
> The build process creates 5 utility programs from 73 .c files. What's
> still missing is a list of the modules for each program. Without that, I
> had to rely on the makefile working. This time, it did.
>
> The build process to build from scratch could be summarised in a few
> lines. If I capture the output of make, then the summary involves these
> files:
>
> ar rc libjpeg.a  jcapimin.o jcapistd.o jcarith.o jctrans.o jcparam.o
> jdatadst.o jcinit.o jcmaster.o jcmarker.o jcmainct.o jcprepct.o
> jccoefct.o jccolor.o jcsample.o jchuff.o jcdctmgr.o jfdctfst.o
> jfdctflt.o jfdctint.o jdapimin.o jdapistd.o jdarith.o jdtrans.o
> jdatasrc.o jdmaster.o jdinput.o jdmarker.o jdhuff.o jdmainct.o
> jdcoefct.o jdpostct.o jddctmgr.o jidctfst.o jidctflt.o jidctint.o
> jdsample.o jdcolor.o jquant1.o jquant2.o jdmerge.o jaricom.o jcomapi.o
> jutils.o jerror.o jmemmgr.o jmemnobs.o
> cc  -o djpeg djpeg.o wrppm.o wrgif.o wrtarga.o wrrle.o wrbmp.o
> rdcolmap.o cdjpeg.o libjpeg.a
> cc  -o jpegtran jpegtran.o rdswitch.o cdjpeg.o transupp.o libjpeg.a
> cc  -o cjpeg cjpeg.o rdppm.o rdgif.o rdtarga.o rdrle.o rdbmp.o
> rdswitch.o cdjpeg.o libjpeg.a
> cc  -o rdjpgcom rdjpgcom.o
> cc  -o wrjpgcom wrjpgcom.o
>
> For 'cc', if I change .o to .c, I could probably build directly from
> sources.
>
> I didn't expect that libjpeg.a file and I'm not familiar with that. But
> I expect that where libjpeg.a is used, I can substitute the list of .c
> files that comprise it.
>
> I will try that experiment first with the existing .o files like this:
>
>  gcc  -o djpeg djpeg.o wrppm.o wrgif.o wrtarga.o wrrle.o wrbmp.o
> rdcolmap.o cdjpeg.o  jcapimin.o jcapistd.o jcarith.o jctrans.o jcparam.o
> jdatadst.o jcinit.o jcmaster.o jcmarker.o jcmainct.o jcprepct.o
> jccoefct.o jccolor.o jcsample.o jchuff.o jcdctmgr.o jfdctfst.o
> jfdctflt.o jfdctint.o jdapimin.o jdapistd.o jdarith.o jdtrans.o
> jdatasrc.o jdmaster.o jdinput.o jdmarker.o jdhuff.o jdmainct.o
> jdcoefct.o jdpostct.o jddctmgr.o jidctfst.o jidctflt.o jidctint.o
> jdsample.o jdcolor.o jquant1.o jquant2.o jdmerge.o jaricom.o jcomapi.o
> jutils.o jerror.o jmemmgr.o jmemnobs.o
>  gcc  -o jpegtran jpegtran.o rdswitch.o cdjpeg.o transupp.o  jcapimin.o
> jcapistd.o jcarith.o jctrans.o jcparam.o jdatadst.o jcinit.o jcmaster.o
> jcmarker.o jcmainct.o jcprepct.o jccoefct.o jccolor.o jcsample.o
> jchuff.o jcdctmgr.o jfdctfst.o jfdctflt.o jfdctint.o jdapimin.o
> jdapistd.o jdarith.o jdtrans.o jdatasrc.o jdmaster.o jdinput.o
> jdmarker.o jdhuff.o jdmainct.o jdcoefct.o jdpostct.o jddctmgr.o
> jidctfst.o jidctflt.o jidctint.o jdsample.o jdcolor.o jquant1.o
> jquant2.o jdmerge.o jaricom.o jcomapi.o jutils.o jerror.o jmemmgr.o
> jmemnobs.o
>  gcc  -o cjpeg cjpeg.o rdppm.o rdgif.o rdtarga.o rdrle.o rdbmp.o
> rdswitch.o cdjpeg.o  jcapimin.o jcapistd.o jcarith.o jctrans.o jcparam.o
> jdatadst.o jcinit.o jcmaster.o jcmarker.o jcmainct.o jcprepct.o
> jccoefct.o jccolor.o jcsample.o jchuff.o jcdctmgr.o jfdctfst.o
> jfdctflt.o jfdctint.o jdapimin.o jdapistd.o jdarith.o jdtrans.o
> jdatasrc.o jdmaster.o jdinput.o jdmarker.o jdhuff.o jdmainct.o
> jdcoefct.o jdpostct.o jddctmgr.o jidctfst.o jidctflt.o jidctint.o
> jdsample.o jdcolor.o jquant1.o jquant2.o jdmerge.o jaricom.o jcomapi.o
> jutils.o jerror.o jmemmgr.o jmemnobs.o
>  gcc  -o rdjpgcom rdjpgcom.o
>  gcc  -o wrjpgcom wrjpgcom.o
>
> That worked. Now I replace those .o by .c, delete all .o and .exe files,
> and try again. It takes a bit longer, but still works!
>
> So the minimal need to build this project on Windows and mingws is a
> 6-line script in /any/ language (like above but with .c, and using -s),
> and a 38-line jconfig.h file.
>
> The actual makefile is 200 lines (times 15) plus 16000 lines of configure.
>
> Of course, I needed a working makefile to extract this information. It
> would be nice to have those six lines as a default or fall-back method.
>

I just did ...
tar xvzf jpegsrc.v9e.tar.gz
cd jpeg-9e
../configure
make
make test
.... and it was happy.

I guess it's alot easier on linux.

On 21/08/2023 14:47, Richard Harnden wrote:
> On 21/08/2023 14:12, Bart wrote:
>> On 21/08/2023 13:12, Richard Harnden wrote:
>>> On 21/08/2023 11:09, Bart wrote:
>>
>>>> Start here: https://libjpeg.sourceforge.net/
>>>>
>>>> (The configure file needed /bin/sh changed to /bin/bash)
>>>
>>>
>>> Or, jpeg-turbo:
>>> git clone https://github.com/libjpeg-turbo/libjpeg-turbo.git
>>
>> That last one uses CMake.
>>
>> Among the highly varied build instructions, the ones for MingW are:
>>
>>    cd {build_directory}
>>    cmake -G"MSYS Makefiles" [additional CMake flags] {source_directory}
>>    make
>>
>> I experimented with various incantations of that middle line (I
>> understand that [] means optional, and {} is a placeholder for an
>> actual path), but got nowhere.
>
> (
> I would've used [] for optional and <> for a place-holder,
> and {} for a group/set of things
> )
>
> For me, this worked:
> cd libjpeg-turbo
> cmake -G"Unix Makefiles"

For Windows?

I tried it anyway. It says it doesn't match the previously matched "MSYS
Makefile". I won't take it further as the chance of success is low.

>> Of course, I needed a working makefile to extract this information. It
>> would be nice to have those six lines as a default or fall-back method.
>>
>
> I just did ...
> tar xvzf jpegsrc.v9e.tar.gz
> cd jpeg-9e
> ./configure
> make
> make test
> ... and it was happy.

But I'm on Windows. It's harder on Windows because they make it so.

However I will try that on WSL:

* First it didn't like /bin/sh, I had to change it to /bin/bash

* Then it didn't like /bin/sh inside config.sub; I changed that

* Then it showed a bunch of odd messages, ending with:

././config.guess: 73: Syntax error: word unexpected (expecting "in")
configure: error: cannot guess build type; you must specify one

So it's not that foolproof. But even when it works, it needs to run a
configuration file of 16,000 lines, which generates a makefile of
unknown length and complexity (as it didn't work).

And /then/ it will end up generating those binaries.

On other OS, I showed that you need 5 invocations of gcc to create those
binaries, which can be in a script of 5 (not 6) longish lines.

On 2023-08-21, Bart <bc@freeuk.com> wrote:
> But I'm on Windows. It's harder on Windows because they make it so.
>
> However I will try that on WSL:
>
> * First it didn't like /bin/sh, I had to change it to /bin/bash
>
> * Then it didn't like /bin/sh inside config.sub; I changed that
>
> * Then it showed a bunch of odd messages, ending with:
>
> ././config.guess: 73: Syntax error: word unexpected (expecting "in")
> configure: error: cannot guess build type; you must specify one

This happens when the argument of a case expands to multiple words,
and corresponds to the diagnostic wording used by Dash:

Bash:

$ bash -c 'case a b in foo ) asdf ;; esac'
bash: -c: line 0: syntax error near unexpected token `b'
bash: -c: line 0: `case a b in foo ) asdf ;; esac'

Dash:

$ dash -c 'case a b in foo ) asdf ;; esac'
dash: 1: Syntax error: word unexpected (expecting "in")

Looks like config.sub is being given some argument with whitespace in it
(and you didn't successfully switch config.sub to Bash). The case
statement is expecting a single word:

case $1 in ...

so it must be that $1 is expanding to multiple arguments. It can likely
be traced to something being weird in WSL.

However, that script should be quoting the expansion as "$1"
all the same, so that if there is somethign wrong with the
argument, at least it is processed properly and diagnosed,
rather than causing a syntax error.

This is just one small example of the many ways in which Autoconf
is a pile of crap.

I have no idea why the authors of this small amojunt of JPEG code
decided to inflict Autoconf on their project instead of a tidy
hand-written Makefile.

Autoconf once served a purpose, but it has long outlived it.
(And while serving that purpose, it was a pile of shit,
but now it's an unnecessary pile of crap that is a blight on
every project that stupidly adopts it.)

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

On 8/21/2023 11:06 AM, Bart wrote:
> On 21/08/2023 14:47, Richard Harnden wrote:
>> On 21/08/2023 14:12, Bart wrote:
>>> On 21/08/2023 13:12, Richard Harnden wrote:
>>>> On 21/08/2023 11:09, Bart wrote:
>>>
>>>>> Start here: https://libjpeg.sourceforge.net/
[...]

vcpkg has it, libjpeg-turbo:

https://i.ibb.co/h7wCkXM/image.png

:^)

On 21/08/2023 14:12, Bart wrote:

[Building libjpeg project]

> That worked. Now I replace those .o by .c, delete all .o and .exe files,
> and try again. It takes a bit longer, but still works!
>
> So the minimal need to build this project on Windows and mingws is a
> 6-line script in /any/ language (like above but with .c, and using -s),
> and a 38-line jconfig.h file.

Another advantage of such a file is that it can be trivially modified to
run my bcc compiler, which otherwise doesn't fit in the traditional pattern.

It took 1.2 seconds to build the five EXEs, while gcc -O0 took 23 seconds.

(I briefly tried bcc-compiled djpeg.exe to convert a JPG to a PPM file.
The result showed odd colour banding and horizontal shifting. A bug in
my compiler? Quite likely. But I then tried the gcc-compiled version and
it was the same.)

I'm not familiar with this product and it's possible that the libjpeg.a
file is for incorporating into user programs.

If so then that library needs to be retained (the script goes back to 6
lines from 5). But a .a file is not generally useful. Much better is a
..dll file. And that adaptation is easy to make when in this simple form.

Then, the sizes of all the binaries reduce from 1.2MB to 0.7MB.

And, I have a libjpeg.dll file that exports 170 functions, that I could
conceivably use from either of my own languages. (Although from the
names of them, they look more like internal functions shared by the five
main programs.)

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

To summarise, this project shows how things can be done, although it
could go further.

It has the traditional build methods, but also describes the process in
English.

What's missing, although I was able to capture the info from the working
makefile, are the sets of C files that comprise each of the 5-6 binaries.

Armed with this info, I could apply my non-standard compiler. I could
also trivially change it to produce a shared library DLL instead of a
mingw-specific .a archive.

I didn't need to use 'configure', and eventually could dispense with a
makefile.

I used this build-script for gcc (the %1 allows for an optiomising option):

gcc -shared -s %1 -o libjpeg.dll jcapimin.c jcapistd.c jcarith.c
jctrans.c jcparam.c jdatadst.c jcinit.c jcmaster.c jcmarker.c jcmainct.c
jcprepct.c jccoefct.c jccolor.c jcsample.c jchuff.c jcdctmgr.c
jfdctfst.c jfdctflt.c jfdctint.c jdapimin.c jdapistd.c jdarith.c
jdtrans.c jdatasrc.c jdmaster.c jdinput.c jdmarker.c jdhuff.c jdmainct.c
jdcoefct.c jdpostct.c jddctmgr.c jidctfst.c jidctflt.c jidctint.c
jdsample.c jdcolor.c jquant1.c jquant2.c jdmerge.c jaricom.c jcomapi.c
jutils.c jerror.c jmemmgr.c jmemnobs.c
gcc -s %1 -o djpeg djpeg.c wrppm.c wrgif.c wrtarga.c wrrle.c wrbmp.c
rdcolmap.c cdjpeg.c libjpeg.dll
gcc -s %1 -o jpegtran jpegtran.c rdswitch.c cdjpeg.c transupp.c
libjpeg.dll
gcc -s %1 -o cjpeg cjpeg.c rdppm.c rdgif.c rdtarga.c rdrle.c rdbmp.c
rdswitch.c cdjpeg.c libjpeg.dll
gcc -s %1 -o rdjpgcom rdjpgcom.c
gcc -s %1 -o wrjpgcom wrjpgcom.c

(Notice that the first module names in the lines building EXEs, match
the name of the EXE in each case. A rule that used the name of the first
module for the EXE could have dispensed with the -o option.

I didn't arrange them like that; that's how they are in the makefile.)

Kaz Kylheku <864-117-4973@kylheku.com> writes:
> On 2023-08-21, Bart <bc@freeuk.com> wrote:
[...]
>> * Then it showed a bunch of odd messages, ending with:
>>
>> ././config.guess: 73: Syntax error: word unexpected (expecting "in")
>> configure: error: cannot guess build type; you must specify one
>
> This happens when the argument of a case expands to multiple words,
> and corresponds to the diagnostic wording used by Dash:
>
> Bash:
>
> $ bash -c 'case a b in foo ) asdf ;; esac'
> bash: -c: line 0: syntax error near unexpected token `b'
> bash: -c: line 0: `case a b in foo ) asdf ;; esac'
>
> Dash:
>
> $ dash -c 'case a b in foo ) asdf ;; esac'
> dash: 1: Syntax error: word unexpected (expecting "in")
>
> Looks like config.sub is being given some argument with whitespace in it
> (and you didn't successfully switch config.sub to Bash). The case
> statement is expecting a single word:
>
> case $1 in ...
>
> so it must be that $1 is expanding to multiple arguments. It can likely
> be traced to something being weird in WSL.

It's not that simple.

If you write:
case foo bar in
you'll get a syntax error, but if it's a parameter expansion like $1
there's no error, even if the expansion is multiple words.

For example, this script prints "ok" with bash, dash, ksh, zsh, and
busybox sh on Ubuntu, and with bash and dash on WSL/Ubuntu. (On both,
/bin/sh is a symlink to dash.)

x='foo bar'
case $x in
'foo bar') echo ok ;;
esac

I was surprised that it behaves this way, and I haven't (so far) found
anything that definitively says that it's supposed to. (I would have
written "$1" rather than $1 myself, but apparently it's not necessary).

I was unable to get config.guess to produce the error Bart reports.

The reported error is consistent with the way I *thought* a shell case
statement would treat its argument. Perhaps Bart is somehow using a
shell that behaves differently than all the ones I've tried.

The config.guess script published by GNU has "#!/bin/sh" as its
first line. It should work with bash, but there should be no need
to change it.

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

bart c <bart4858@gmail.com> writes:
[...]
> The C compilers I've used most often are complete, self-contained
> solutions. Mine doesn't even have or use a linker.
[...]

Really? How does that work?

For example, this source file compiles without error:
```
extern void no_such_function(void);

int main(void) {
no_such_function();
} ```
but if I try to generate an executable from it I get an error from the
linker. If you try to generate an executable using your compiler, what
reports the error? Or is it not reported until you try to run the
program?

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

Bart <bc@freeuk.com> writes:
[...]
> So what /is/ a C compiler? What exactly does it comprise? What,
> exactly, does it do?
>
> Does it really not include stdio.h? Where would you even get stdio.h,
> or windows.h, if supplied separately?

This has been patiently explained to you many times. I would answer if
I believed you were interested in learning from an answer. I don't.

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

On 21/08/2023 22:47, Keith Thompson wrote:
> bart c <bart4858@gmail.com> writes:
> [...]
>> The C compilers I've used most often are complete, self-contained
>> solutions. Mine doesn't even have or use a linker.
> [...]
>
> Really? How does that work?
>
> For example, this source file compiles without error:
> ```
> extern void no_such_function(void);
>
> int main(void) {
> no_such_function();
> }
> ```
> but if I try to generate an executable from it I get an error from the
> linker. If you try to generate an executable using your compiler, what
> reports the error? Or is it not reported until you try to run the
> program?
>

It doesn't have a conventional linker that works with OBJ files.

Because C allows modules to be independently compiled, there needs to be
a mechanism to compile several such outputs, then combining them into an
executable.

But instead of .obj files (or .s then .o like gcc uses), it uses only
..asm files.

There are two types of external symbols that need to resolved:

(1) Symbols exported by one C module of the app and imported by another

(2) Symbols imported from an external library

The assembler I use performs the job of resolving type (1) symbols
imported from other modules: it reads multiple .asm files and produces
one .exe file.

Type (2) symbols can only come from DLL shared libraries. They are
checked off by the part that creates the EXE image, which contains a
list of DLL dependencies, and the symbols imported from each.

The parts of the assembler responsonsible for (1) and (2) probably
require 10KB of code. The LD linker is 1500KB, and the LLVM one about
64000KB.

This assembler forms part of BCC as well as being an independent tool.

Static 'linking' of OBJ files from other compilers is not possible. (Tcc
might have the same limitation.) I used to be able to do it by getting
my assembler to generate OBJ format (one file for the whole program),
and then employing a third party, real linker. That's fallen into disuse.

On 21/08/2023 23:18, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> So what /is/ a C compiler? What exactly does it comprise? What,
>> exactly, does it do?
>>
>> Does it really not include stdio.h? Where would you even get stdio.h,
>> or windows.h, if supplied separately?
>
> This has been patiently explained to you many times. I would answer if
> I believed you were interested in learning from an answer. I don't.
>

I'm interested in knowing the answer. (But I'm more interested in
knowing why you think I would know it. I had to create my own headers!
So there was an easy resource to download them from; who knew?)

So where DO the standard headers for a Windows C compiler come from?

Where does windows.h come from, as that is also required? I don't
believe every compiler pinches them from the Windows SDK, as they are
all different, from 20K lines to 200K lines, from one header file, to
165 unique headers.

Bart <bc@freeuk.com> writes:
> On 21/08/2023 22:47, Keith Thompson wrote:
>> bart c <bart4858@gmail.com> writes:
>> [...]
>>> The C compilers I've used most often are complete, self-contained
>>> solutions. Mine doesn't even have or use a linker.
>> [...]
>> Really? How does that work?
[...]
> It doesn't have a conventional linker that works with OBJ files.
[...]
> The assembler I use performs the job of resolving type (1) symbols
> imported from other modules: it reads multiple .asm files and produces
> one .exe file.
[...]

So the "linker" is incorporated into the assembler.

(This is just an observation. I'm not saying there's anything wrong
with that approach.)

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

Bart <bc@freeuk.com> writes:
> On 21/08/2023 23:18, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> So what /is/ a C compiler? What exactly does it comprise? What,
>>> exactly, does it do?
>>>
>>> Does it really not include stdio.h? Where would you even get stdio.h,
>>> or windows.h, if supplied separately?
>>
>> This has been patiently explained to you many times. I would answer
>> if I believed you were interested in learning from an answer. I
>> don't.
>
> I'm interested in knowing the answer. (But I'm more interested in
> knowing why you think I would know it. I had to create my own headers!
> So there was an easy resource to download them from; who knew?)

stdio.h really is not part of the compiler. Both stdio.h and a C
compiler are part of a C implementation.

That's the part that I'm saying has been patiently explained to you.
The details of where stdio.h comes from for a given implementation
are a different matter. I should have made that distinction more
clearly.

(A C compiler could implement the standard headers internally,
so that its response to `#include <stdio.h>` would be to insert a
collection of symbols internally rather than reaading an external
file. That would be an odd implementation, but it could be perfectly
valid. But it would still need to be able to use other headers.)

The C standard (I'm sure you have a copy of a draft) specifies
8 translation phases in section 5.1.1.2 (the number might vary
in different editions). Phases 1-4 (or maybe 1-5 or 1-6) are
typically implemented in a preprocessor, though it doesn't have to
be a separate program. Phases 1-7 are the compiler. Phase 8 is
the linker. The standard specifically says that many of the phases
are typically folded together; an implementation must behave *as if*
it implemented the phases as described.

Can you acknowledge that you understand that? It could save some time
in future discussions.

I don't know what headers you say you had to create. If you're
creating a complete C implementation, you might have to write
your own standard headers if none of the existing ones suited
your purposes.

> So where DO the standard headers for a Windows C compiler come from?

It depends on the particular implementation.

Probably the most popular C development system for Windows
is Microsoft Visual Studio (though it's mostly used for C++).
It includes multiple components, all installed together, including
a compiler, libraries, header files, a linker, etc. -- and of course
an IDE with a lot of bells and whistles.

> Where does windows.h come from, as that is also required? I don't
> believe every compiler pinches them from the Windows SDK, as they are
> all different, from 20K lines to 200K lines, from one header file, to
> 165 unique headers.

Again, it depends on the implementation. ("windows.h" is very probably
a single file; it may #include other header files.)

Windows C implementations tend to be packaged together, with the
package incorporating a compiler, runtime library, headers, etc.

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

On 21/08/2023 23:45, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 21/08/2023 22:47, Keith Thompson wrote:
>>> bart c <bart4858@gmail.com> writes:
>>> [...]
>>>> The C compilers I've used most often are complete, self-contained
>>>> solutions. Mine doesn't even have or use a linker.
>>> [...]
>>> Really? How does that work?
> [...]
>> It doesn't have a conventional linker that works with OBJ files.
> [...]
>> The assembler I use performs the job of resolving type (1) symbols
>> imported from other modules: it reads multiple .asm files and produces
>> one .exe file.
> [...]
>
> So the "linker" is incorporated into the assembler.
>
> (This is just an observation. I'm not saying there's anything wrong
> with that approach.)

Another way of implementing C, even less conventional, is to emulate
whole-program compilation.

Such a compiler would need all source modules (that form a single EXE or
DLL) to be submitted at the same time. Then there is no need to produce
discrete ASM files. 'Linking' symbols between modules is done via a
global symbol table.

Then the concept of independent compilation disappears too.

(Within my current bcc compiler, unless -S or -c options are used, the
..asm files it produces are nominal: they are generated in-memory and
read in-memory. So it is half-way there.)

Bart <bc@freeuk.com> writes:

> On 21/08/2023 03:13, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>
>> Yes, why? We should take an example and look at it in detail, but you
>> just keep moving on. Portable C is very hard to write (100% portable
>> that is). If you crack that, the makefile is irrelevant. So is any
>> configure script. Just compile the C.
>
> I can't just compile the C because the info I need is hidden in the
> makefile! Sometimes the makefile doesn't exist and the now even more
> indirect instructions are inside a bash script, of which 99% is irrelevant
> noise.
>
> It is very frustrating.

Yes, I can imagine. How much work do you think you are owed by the
authors of such software?

>> Unfortunately, Windows users expect *.txt to be expanded by the program
>> and Unix users don't. Unix users expect -flags and Windows users expect
>> /flags.
>
> See my last remarks below. People will know how to invoke their own
> compilers (unless they /only/ know how to type 'make'!). This is a
> non-issue.

You missed the point of that remark entirely. But you've cut so much
context I don't see the point in my trying to make it again.

>>> Libjpeg library. This is an old one from 1998. There are 15 makefile.xxx
>>> files for multiple, mostly obsolete compilers. The docs for non-Unix look
>>> horrendous; I will not bother.
>> Post the link so I can at least see what you are talking about if this
>> is the example you want me to examine. I think I know the library you
>> mean, but I don't know the exact source you are looking at.
>
> Start here: https://libjpeg.sourceforge.net/
>
> (The configure file needed /bin/sh changed to /bin/bash)

One.

>>> Gzlib. A compression utility.
>> Post the link if this is the one you want to look at in depth.
>
> I think it was 'gzip' not gzlib. I used second from the last link here:
> https://ftp.nluug.nl/pub/gnu/gzip/.

Two.

Which one do you want to look at in depth?

>>> I've suggested easy ways of building C programs such as the ones in my
>>> example. Forgetting 'make' would be a first step (I suspect makefiles are
>>> IDE-generated some of the time).
>> Your solution is to write portable C. Is that it?
>
> A lot of stuff is already portable since I can build it given the basic
> build info. If people want to use open() and not fopen(), that's up to
> them, but then their product is likely not cross-platform.

Still don't know what your solution is other than "write portable C".
That's hard and often not possible.

>>> Here's one from the past: I wanted to build Algol68 Genie (A68G).
>> Another one! Can we stick to one example?
>
> My contention is that C projects with makefiles are generally troublesome
> on Windows, which is why I always look at them askance.

And my contention is that if we look at an example we'll see that it's
troublesome because it's Linux or Unix software.

> The 4-5 examples based around my OP weren't enough to convince
> anybody.

No, because you don't examine any of them in enough detail. Make is a
good red flag for you because it indicates Unix software. If there is
no "build.bat" file even better -- it's Unix software where the authors
have not done the work for you so it's going to be a good example to
cite.

> Enough gaslighting has been going on that I'm not sure myself. I
> need more examples of projects with makefiles that build effortlessly under
> Windows by simply following instructions.

>>> Now, why couldn't the docs just say that in the first place! Just submit
>>> this list of C files to the nearest C compiler.
>> If this is the example you want to look at in depth? I can't answer
>
> It is really very simple. The basic info needed to build a program from C
> modules is just a list of those modules and where they are located.

Context (did you deliberately remove it?): this the Algol 68G
compiler/interpreter you are taking about. It's firmly a Unix program.
The build system installs things in /usr/local/bin and so on. The
configure script has more than 20 options to configure the build to use
things like curl, GSL, GNU plot, R, MPFR and so on. All of these are
Linux/Unix libraries and systems. You might have some or all of them on
your Windows system, but how you get a68g to find them is a mystery.
You might be able to "cc *.c" and get something to work but goodness
knows what is you will have built. Nothing the authors will want to
take responsibility for, that's for sure.

They kindly offer a windows binary. The fact that they don't give the
build process suggest that it's not trivial. Since you have a solution
to these problems, maybe you could provide it for them?

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

--
Ben.

On Sat, 19 Aug 2023 13:44:28 -0700 (PDT), bart c wrote:

> On Saturday, 19 August 2023 at 20:35:53 UTC+1, Kelsey Bjarnason wrote:
>> On Sat, 19 Aug 2023 09:54:49 -0700 (PDT), bart c wrote:
>>
>> > On Saturday, 19 August 2023 at 17:03:41 UTC+1, Kelsey Bjarnason
>> > wrote:
>> >> On Fri, 18 Aug 2023 18:36:51 -0700 (PDT), bart c wrote:
>> >>
>> >> > On Saturday, 19 August 2023 at 01:21:58 UTC+1, Ben Bacarisse
>> >> > wrote:
>> >> >> bart c <bart...@gmail.com> writes:
>> >> >
>> >> >> > That is, you want to be able to type:
>> >> >> >
>> >> >> > X
>> >> >> >
>> >> >> > and not:
>> >> >> >
>> >> >> > X Y
>> >> >> No, I want to type
>> >> >>
>> >> >> make make tests make install make clean make mylib.a
>> >> >
>> >> > I'm not familiar with how make is used. Do you routinely have to
>> >> > invoke it five times in succession? Maybe that's a deeper problem
>> >> > with it, but as I said I don't use it.
>> >> >
>> >> >> depending on what I'm doing rather than
>> >> >>
>> >> >> make makefile make makefile tests make makefile install make
>> >> >> makefile clean make makefile mylib.a
>> >> >
>> >> > And this actually tells me that the main input is identical in all
>> >> > cases; I'd been wondering what was being done with mylib.a. But
>> >> > whatever it is, the same makefile that does all the other stuff
>> >> > contains some formula for 'mylib.a'?
>> >> >
>> >> > In practice I doubt you would type this five times as normally
>> >> > you'd do line recall then change the last bit. You can also choose
>> >> > to give it a shorter name than 'makefile'!
>> >> No, normally you'd do something like:
>> >>
>> >> make && make tests && make install && make clean && make mylib.a
>> >
>> > If only there was a way of scripting that...
>> >
>> > Obviously you can't use make and a makefile, since for one thing,
>> > 'makefile' has already been used, and using any other name is
>> > apparently a no-no.
>> That *would be* using a makefile. One with multiple targets. You just
>> specify which target you want to build, or use the default target which
>> is virtually always the relevant, expected output - library,
>> executable, whatever.
>>
>> And why script something when a) it adds nothing of value, and b) you
>> may want to vary what gets built from run to run, so you just specify
>> what you want built instead of editing the script every time?
>
> Exactly. Doing ad hoc stuff like this:
>
> bcc prog prog tcc proc.c prog gcc prog.c a (gcc just
> HAS to be different!)
> gcc prog.c -O3 a
>
> 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?

> Show me how you're do those 4 compilations using make, without a
> specially written make script.

>
>> > I wonder what it is about the stuff I do then I've never had any
>> > build process that took long enough to make and consume a cup of
>> > coffee. No even when working on machines 1000 times slower than they
>> > are now.
>> Depends on too many factors to evaluate here. I have code that's tens
>> of thousands of lines long and builds in a flash. I have other code
>> that's rather less lengthy and compiles much more slowly. Depends on
>> code, compiler, optimization settings, language involved, dependency
>> resolution,
>> caching, too many things to evaluate unless one does a "clean"
>> comparison of the same code, the same optimization levels, etc.
>
> Has it ever take long enough to /enjoy/ drinking a coffee?

Yes. See elsethread.

>
> Unfortunately, since most of my stuff builds in 0.1 seconds, it will
> have finished doing so as soon as I've released the Enter key. Back to
> work!
>
>
>> > My own assembler is called 'aa':
>> >
>> > aa x y z
>> >
>> > this assembles files x.asm, y.asm and z.asm, and writes x.exe. I
>> > prefer writing that to:
>> >
>> > aa x.asm y.asm z.asm -ox.exe
>> >
>> > I'm funny that way.
>
>> Indeed. I'd rather just write "make" and have it all be done, complete
>> with ensuring any out of date intermediate files are properly generated
>> first. It's shorter to write, and it takes care of unintentional
>> oversights.
>
> That's scripting! I can just stick that line in a make.bat file and then
> type:
>
> make
>
> But I don't normally work from the command line except for ad hoc
> invocations with variable options as already explained. Scripting here
> works poorly.
>
>> You should really pick one side of whatever you're arguing for and
>> stick with that; arguing both sides is just silly.
>
> It's the way that your tools work that is silly, since the direct tools
> are too verbose, and make is scarily not verbose enough.
>
> On the one hand you have to do:
>
> gcc main.c a.c b.c -omain
>
> On the other, you want to just do:
>
> make
>
> which ... does what? All that stuff is put inside 'makefile' in a form
> which is even more verbose since it will split it up into dependencies
> between .c, .h and .o files.
>
> But, now instead of your project being defined as THREE source files,
> ONE tool and ONE language: {main + a + b, gcc, C}, it is defined as FOUR
> source files, TWO tools and TWO languages:
>
> {main + a + b + makefile, gcc + make, C + make-syntax}
>
> There is no happy medium such as is used by my product:
>
> bcc main a b bcc -auto main # using automatic module discovery
> with a suitably structured project.
>
> In that second example, the project is defined (ie. can be fully
> described to the build process) as ONE source file, ONE tool and ONE
> language: {main, bcc, C}
>
> Now, people like David Brown will try and argue that using 'make' like
> this:
>
> make
>
> The project is also defined as ONE source file, ONE tool, and ONE
> language: {makefile, make, make-syntax}. Or possibly even as ONE tool
> and ONE language since the implicit 'makefile' doesn't have to figure in
> it.
>
> You can believe that if you want. If so, try deleting the C compiler and
> see if it still builds.

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 is unusual, but note that this was version 9 of that project; that
info was not present on version 6. One wonders what feedback they got to
make them change the INSTALL file to be more helpful.

Maybe there is more than one person like me having difficulty.

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

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.

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

-----

As for A68G, the current version
(https://github.com/NevilleDNZ/algol68g-mirror) is a lot more
complicated than I what played with. 'make' gives an error even on WSL
Ubuntu.

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.

There are just too many dependencies, many apparently Linux-centric.

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.

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.

On 22/08/2023 08:12, Kelsey Bjarnason wrote:
> On Tue, 22 Aug 2023 02:28:29 +0100, Bart wrote:

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

What happens when you send me all the sources and I have to build from
scratch; how does /my/ build-time benefit for a one-off compilation?

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

What you're advising is to fly by 747 for all journeys even when a
train, bus, car, bike or going on foot would be more apt.

Have a look at the projects I've mentioned in this thread. The longest
gcc-O0 from-scratch build, where it worked, was 23 seconds. (I'm not
including the autoconf crap.)

By all means use 'make' for your ginormous applications, but don't foist
it on everybody and everything.

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

My usual compilers can generate 10MB binaries in seconds. The largest
binary was some 160MB, a DLL connected with Firefox I think, which
almost certainly was a collection of smaller components.)

On 22/08/2023 11:13, Bart wrote:
> 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.

Looking only at my windows/system32 folder:

99.3% of EXEs were under 10MB, and 94% under 1MB
99.7% of DLLs were under 10MB, and 89% under 1MB

About 4000 files in total.

If you (KB) are talking about a system of EXEs and DLLS, then such files
are usually already independent from each other, or at least, any
dependencies are coarser.

You wouldn't use a make filefile that contains both the 1000 modules of
A.DLL, and the 1400 modules of B.DLL, simply because because A imports
B. At that rate you'd end up putting the modules of half those DLLs into
one makefile.

On 22/08/2023 11:36, Bart wrote:
> On 22/08/2023 11:13, Bart wrote:
>> 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.
>
> Looking only at my windows/system32 folder:
>
>    99.3% of EXEs were under 10MB, and 94% under 1MB
>    99.7% of DLLs were under 10MB, and 89% under 1MB
>
> About 4000 files in total.
>
> If you (KB) are talking about a system of EXEs and DLLS, then such files
> are usually already independent from each other, or at least, any
> dependencies are coarser.
>
> You wouldn't use a make filefile that contains both the 1000 modules of
> A.DLL, and the 1400 modules of B.DLL, simply because because A imports
> B. At that rate you'd end up putting the modules of half those DLLs into
> one makefile.
>

What do you mean by "module"?

On 22/08/2023 13:37, Richard Harnden wrote:
> On 22/08/2023 11:36, Bart wrote:
>> On 22/08/2023 11:13, Bart wrote:
>>> 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.
>>
>> Looking only at my windows/system32 folder:
>>
>>     99.3% of EXEs were under 10MB, and 94% under 1MB
>>     99.7% of DLLs were under 10MB, and 89% under 1MB
>>
>> About 4000 files in total.
>>
>> If you (KB) are talking about a system of EXEs and DLLS, then such
>> files are usually already independent from each other, or at least,
>> any dependencies are coarser.
>>
>> You wouldn't use a make filefile that contains both the 1000 modules
>> of A.DLL, and the 1400 modules of B.DLL, simply because because A
>> imports B. At that rate you'd end up putting the modules of half those
>> DLLs into one makefile.
>>
>
> What do you mean by "module"?
>

In the current context it can mean every .c and .h that is identified by
name in a makefile.

Although when I wrote 'module' I loosely had in mind the translation
unit, the assembly of .c and .h files, that comprise a single named .c
source when it is processed by a compiler.

Because my own script mention only explicit .c files, and not indirectly
included .c and .h files.

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.

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.

Therefore, applications generally use operating system specific
functionality (POSIX, WIN32/WIN64 APIs) to get the functionality and/or
performance that the application requires.

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.

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

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

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

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

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

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?

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.