On 2023-08-19, bart c <bart4858@gmail.com> wrote:
> On Saturday, 19 August 2023 at 15:43:02 UTC+1, Scott Lurndal wrote:
>> Ben Bacarisse <ben.u...@bsb.me.uk> writes:
>> >bart c <bart...@gmail.com> writes:
>> >
>>
>> >>
>> >> on those other programs is anathema.
>> >
>> >Well (if you are talking about having to say gcc prog.c rather than gcc
>> >prog) there are advantages, and none of them have anything to do with
>> >how much one has to type. After all, command completion means I rarely
>> >type a file name explcitly anyway.
>> >
>> It's worth repeating that 'gcc' is a driver program, not a compiler.
>>
>> So:
>>
>> $ gcc -c -o a.o a.s
>>
>> is a perfectly legal and viable way to invoke the assembler.
>>
>> $ gcc -o a a.o
>>
>> is a perfectly legal and viable way to invoke the linker.
>
> You can run the assembler directly using 'as', and the linker using 'ld'.

Not reliably. The gcc driver is configured to use a particular
assembler, not necessarily the one found in you PATH under the
name "as".

You might have an "as" that came from your Unix vendor, but gcc
was built with the GNU assembler.

You could have different installations of gcc with different
versions of an assembler.

> So how do you directly invoke the actual C compiler?

That's an executable usually called cc1. You have to know where
that is. Even if gcc is in your PATH, cc1 won't be.

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

On 2023-08-19, David Brown <david.brown@hesbynett.no> wrote:
> On 19/08/2023 13:39, bart c wrote:
>> That's interesting. One of the limitations of Lua was that it didn't have proper integer type, it used a 64-bit float.
>>
>
> Lua is configurable, and can support different types. When I embedded
> in a 32-bit microcontroller program, I use 32-bit integers as the number
> type.

I don't feel the party has properly started until someone makes that
sort of thing a command line option. Or better yet, environment
variable.

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

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

Then get a coffee while it does all of these in succession.

>> What's more, tab completion in my shell works with make's targets, but
>> I don't think that's at all easy to do if the makefile has to be named
>> in the same command.
>> > like nearly every other command line program.
>>
>> > Yet being able to do
>> >
>> > X Y
>> >
>> > instead of:
>> >
>> > X Y.Z
>> >
>> > on those other programs is anathema.
>> Well (if you are talking about having to say gcc prog.c rather than gcc
>> prog) there are advantages, and none of them have anything to do with
>> how much one has to type. After all, command completion means I rarely
>> type a file name explcitly anyway.
>
> If my C test folder, I had 23 files that started with 'hello'. Although
> they are stepped through in alphabetical order on Windows and .c is near
> the top, you still have to tentatively keep pressing tab, then you go
> too far and need shift-tab .. it is quicker just to type the extension!
> Better however not to have to bother.

A good argument for sensible file naming conventions, one would think.

>> The main advantage is that there's no need to specify and remember all
>> the rules. Does gcc always add .c? Will it add .c if I type gcc prog.s?
>> Must I avoid any dots in the basename? What happens when several names
>> appear on the command line?
>
> gcc is a bad example to follow since it does too much on the command
> line and performs multiple functions. So it easy to argue that, because
> it handles 58 different file types (I've no idea), singling one out to
> use a default is senseless.
>
> But with a simpler product whose primary input files are C source files,
> then a default .c extension makes a lot of sense.
>
> The rules on Windows can be simple: if there is no extension (no dot in
> the name), then a default extension is added. It's harder with a Linux
> file system because files "abc" and "abc." are distinct; how to do apply
> a default extension to "abc" when that could be a valid filename?

One might think you don't; if I tell a compiler to compile "file", I would
expect it to compile "file", not "file.c" or "file.cpp" or "file.asm". If
it can't determine the language other than by file extension, then it's up
to me to ensure the files have the proper extension, and I tell it which
to compile. Using your sort of examples, I might have file.c, file.cpp
and file.asm in the directory - which one is it supposed to choose if I
tell it to just compile "file"?

> However on Windows and various other OSes before that over decades, it
> hasn't really given any problems.
>
>> > So either 'X Y' is too much to type, or `X Y' is not enough! Even
>> > though you will be using the latter case more often.
>> No. I don't think anyone cares about how much one types (I don't)
>> provided there is some point to it. It's annoying to be forced to type
>> something redundant every time, whereas it's potentially confusing to
>> have gcc pick default extensions.
>
> Exactly. I consider the '.c -oprog' in 'gcc prog.c -oprog' to be
> redundant. Note that on Windows, it will apply the .exe extension to
> that output.

You don't need to specify -oprog if you don't want; you just wind up with
a.out instead of prog as the result. Entirely up to you.

>> > It's fascinating watching psychology and group-think at work.
>> As usual, you've invented a position (it'a all about the typing) and
>> argued about that instead of taking on board the actual comments that
>> people have made.
>
> The typing is part of it. Using the same default file in this case seem
> to me to be fragile. Remember the Github Lua with the missing makefile?
> I didn't know there were supposed to be two, and assume that one called
> 'makefile' was /the/ makefile. Or someone could simply be in the wrong
> folder.

On Saturday, 19 August 2023 at 17:58:15 UTC+3, bart c wrote:
> On Saturday, 19 August 2023 at 14:17:15 UTC+1, David Brown wrote:

> >
> > So if you were to post saying you'd made a nice little bytecode
> > interpreter for a small IL/IR, suitable for some kinds of simple
> > scripting, I might say that's great. When you then say your tool is
> > practically the same as llvm and the llvm developers are clearly
> > incompetent and inefficient, /then/ you get the negative feedback.
>
> And I asked you what was the difference between getting the task done by my product, and the same task via LLVM. You haven't answered that.
>
But that is trivial as everything is different, no difference how
to look at it ... nothing matches.
Workforce: Single person might get tired and his confronting
everything around is bad signal.
Tools: You claim all tools are bad.
Optimizations: LLVM is designed for compile-time, link-time,
run-time, and "idle-time" optimization.
Compatibility: LLVM is potentially compatible with any architecture.

On Saturday, 19 August 2023 at 16:59:16 UTC+1, Kaz Kylheku wrote:
> On 2023-08-19, bart c <bart...@gmail.com> wrote:
> > On Saturday, 19 August 2023 at 15:43:02 UTC+1, Scott Lurndal wrote:
> >> Ben Bacarisse <ben.u...@bsb.me.uk> writes:
> >> >bart c <bart...@gmail.com> writes:
> >> >
> >>
> >> >>
> >> >> on those other programs is anathema.
> >> >
> >> >Well (if you are talking about having to say gcc prog.c rather than gcc
> >> >prog) there are advantages, and none of them have anything to do with
> >> >how much one has to type. After all, command completion means I rarely
> >> >type a file name explcitly anyway.
> >> >
> >> It's worth repeating that 'gcc' is a driver program, not a compiler.
> >>
> >> So:
> >>
> >> $ gcc -c -o a.o a.s
> >>
> >> is a perfectly legal and viable way to invoke the assembler.
> >>
> >> $ gcc -o a a.o
> >>
> >> is a perfectly legal and viable way to invoke the linker.
> >
> > You can run the assembler directly using 'as', and the linker using 'ld'.
> Not reliably. The gcc driver is configured to use a particular
> assembler, not necessarily the one found in you PATH under the
> name "as".
>
> You might have an "as" that came from your Unix vendor, but gcc
> was built with the GNU assembler.
>
> You could have different installations of gcc with different
> versions of an assembler.
> > So how do you directly invoke the actual C compiler?
> That's an executable usually called cc1. You have to know where
> that is. Even if gcc is in your PATH, cc1 won't be.

I found cc1, but how do you use it? There's no conventional CLI. You can do:

cc1 <hello.c

but it needs a bunch of options. 'cci --help' produces a list of 1700 options, which is as helpful as saying that this week's winning lottery numbers are in the set 1 to 49.

I get the feeling it is not meant to be used from the command line like 'as' and 'ld'.

So, there /is/ no proper C-specific compiler with a normal interface; we're stuck with that driver.

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.

> Then get a coffee while it does all of these in succession.

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.

> >> What's more, tab completion in my shell works with make's targets, but

> > The rules on Windows can be simple: if there is no extension (no dot in
> > the name), then a default extension is added. It's harder with a Linux
> > file system because files "abc" and "abc." are distinct; how to do apply
> > a default extension to "abc" when that could be a valid filename?

> One might think you don't; if I tell a compiler to compile "file", I would
> expect it to compile "file", not "file.c" or "file.cpp" or "file.asm".

On Windows, "file" and "file." are the same file. So you can omit the extension /and/ period to mean the extension is unspecified. That leaves the app free to apply sensible defaults if the numbers of file types it deals with are restricted.

> If
> it can't determine the language other than by file extension, then it's up
> to me to ensure the files have the proper extension, and I tell it which
> to compile. Using your sort of examples, I might have file.c, file.cpp
> and file.asm in the directory - which one is it supposed to choose if I
> tell it to just compile "file"?

You have one tool that compiles C code, or C++, or ASM files? That's called making a rod for your own back. This is my point about gcc.

However, what input files does the 'as' assembler normally deal with? Isn't it just '.s' files? So that'd be an easy one to guess, would it not?

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.

> You don't need to specify -oprog if you don't want; you just wind up with
> a.out instead of prog as the result. Entirely up to you.

Well, obviously I don't want. Nobody does, except that's what they're told they're going to get, and being lazy bastards like most people (and like me), they don't bother overriding. But then they have to deal with a.out. Or, on Windows (where really, they could have fixed it as there was no prior art), a.exe.

On 2023-08-19, bart c <bart4858@gmail.com> wrote:
> On Saturday, 19 August 2023 at 16:59:16 UTC+1, Kaz Kylheku wrote:
>> On 2023-08-19, bart c <bart...@gmail.com> wrote:
>> > On Saturday, 19 August 2023 at 15:43:02 UTC+1, Scott Lurndal wrote:
>> >> Ben Bacarisse <ben.u...@bsb.me.uk> writes:
>> >> >bart c <bart...@gmail.com> writes:
>> >> >
>> >>
>> >> >>
>> >> >> on those other programs is anathema.
>> >> >
>> >> >Well (if you are talking about having to say gcc prog.c rather than gcc
>> >> >prog) there are advantages, and none of them have anything to do with
>> >> >how much one has to type. After all, command completion means I rarely
>> >> >type a file name explcitly anyway.
>> >> >
>> >> It's worth repeating that 'gcc' is a driver program, not a compiler.
>> >>
>> >> So:
>> >>
>> >> $ gcc -c -o a.o a.s
>> >>
>> >> is a perfectly legal and viable way to invoke the assembler.
>> >>
>> >> $ gcc -o a a.o
>> >>
>> >> is a perfectly legal and viable way to invoke the linker.
>> >
>> > You can run the assembler directly using 'as', and the linker using 'ld'.
>> Not reliably. The gcc driver is configured to use a particular
>> assembler, not necessarily the one found in you PATH under the
>> name "as".
>>
>> You might have an "as" that came from your Unix vendor, but gcc
>> was built with the GNU assembler.
>>
>> You could have different installations of gcc with different
>> versions of an assembler.
>> > So how do you directly invoke the actual C compiler?
>> That's an executable usually called cc1. You have to know where
>> that is. Even if gcc is in your PATH, cc1 won't be.
>
> I found cc1, but how do you use it? There's no conventional CLI. You can do:
>
> cc1 <hello.c

I don't think it's documented for use.

If you want to see what arguments are being passed to cc1, you can
use the "strace" utility on Linux or similar syscall tracers elsewhere.

> I get the feeling it is not meant to be used from the command line like 'as' and 'ld'.
>
> So, there /is/ no proper C-specific compiler with a normal interface; we're stuck with that driver.

That's correct.

Let's try:

$ strace -s 4096 -o gcc.log -f gcc foo.c -o foo
$ grep cc1 gcc.log
25364 stat64("/usr/lib/gcc/i686-linux-gnu/7/cc1", {st_mode=S_IFREG|0755, st_size=22895720, ...}) = 0
25364 access("/usr/lib/gcc/i686-linux-gnu/7/cc1", X_OK) = 0
25365 execve("/usr/lib/gcc/i686-linux-gnu/7/cc1", ["/usr/lib/gcc/i686-linux-gnu/7/cc1", "-quiet", "-imultiarch", "i386-linux-gnu", "foo.c", "-quiet", "-dumpbase", "foo.c", "-mtune=generic", "-march=i686", "-auxbase", "foo", "-fstack-protector-strong", "-Wformat", "-Wformat-security", "-o", "/tmp/ccKrG8uQ.s"], 0x8cad030 /* 62 vars */ <unfinished ...>

Looks like cc1 isn't being given a huge number of many options.

cc1 must be doing the preprocessing since it's getting foo.c as
input. I don't see any arguments which would tell it where the header
files are, so it must be getting that configuration in some
other ways. (I looked into the environment with strace -v too;
didn't see it.)

There is also another intermediary program called "collect2" which I
think handles the details of linking. In the above trace, there is an
invocation of collect2 after cc1.

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

On 2023-08-19, bart c <bart4858@gmail.com> wrote:
> On Saturday, 19 August 2023 at 15:43:02 UTC+1, Scott Lurndal wrote:
>> Ben Bacarisse <ben.u...@bsb.me.uk> writes:
>>
>> $ gcc -c -o a.o a.s
>>
>> is a perfectly legal and viable way to invoke the assembler.
>>
>> $ gcc -o a a.o
>>
>> is a perfectly legal and viable way to invoke the linker.
>
> You can run the assembler directly using 'as', and the linker using 'ld'.
>
> So how do you directly invoke the actual C compiler?

Running gcc with the -v or --verbose option will show the substeps it invokes.

scott@slp53.sl.home (Scott Lurndal) writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>bart c <bart4858@gmail.com> writes:
>>>
>>> on those other programs is anathema.
>>
>>Well (if you are talking about having to say gcc prog.c rather than gcc
>>prog) there are advantages, and none of them have anything to do with
>>how much one has to type. After all, command completion means I rarely
>>type a file name explcitly anyway.
>>
>
> It's worth repeating that 'gcc' is a driver program, not a compiler.
>
> So:
>
> $ gcc -c -o a.o a.s
>
> is a perfectly legal and viable way to invoke the assembler.

Yes. I assumed Bart would know this. It was implicit in my remark
about running "gcc prog.s", but it better to make it explicit.

--
Ben.

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?

This is actually simpler than using a script.

>
>> Then get a coffee while it does all of these in succession.
>
> 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.

>
>> >> What's more, tab completion in my shell works with make's targets,
>> >> but
>
>> > The rules on Windows can be simple: if there is no extension (no dot
>> > in the name), then a default extension is added. It's harder with a
>> > Linux file system because files "abc" and "abc." are distinct; how to
>> > do apply a default extension to "abc" when that could be a valid
>> > filename?
>
>> One might think you don't; if I tell a compiler to compile "file", I
>> would expect it to compile "file", not "file.c" or "file.cpp" or
>> "file.asm".
>
> On Windows, "file" and "file." are the same file. So you can omit the
> extension /and/ period to mean the extension is unspecified. That leaves
> the app free to apply sensible defaults if the numbers of file types it
> deals with are restricted.
>
>
>> If it can't determine the language other than by file extension, then
>> it's up to me to ensure the files have the proper extension, and I tell
>> it which to compile. Using your sort of examples, I might have file.c,
>> file.cpp and file.asm in the directory - which one is it supposed to
>> choose if I tell it to just compile "file"?
>
> You have one tool that compiles C code, or C++, or ASM files? That's
> called making a rod for your own back. This is my point about gcc.

Last I checked. most of the Windows compilers would happily compile C and
C++ files, based on extension. So when I say "compile file", do I mean
file.c or file.cpp?

> However, what input files does the 'as' assembler normally deal with?
> Isn't it just '.s' files? So that'd be an easy one to guess, would it
> not?
>
> 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.

>
>
>> You don't need to specify -oprog if you don't want; you just wind up
>> with a.out instead of prog as the result. Entirely up to you.
>
> Well, obviously I don't want. Nobody does, except that's what they're
> told they're going to get, and being lazy bastards like most people (and
> like me), they don't bother overriding. But then they have to deal with
> a.out. Or, on Windows (where really, they could have fixed it as there
> was no prior art), a.exe.

Okay, so you get a.out/a.exe. And? By your logic above, that's
preferable to, say, "myprogram.exe" - less typing.

So here you want *more* typing, but up there you want less, despite
arguing against using the optioon with both the *least* typing and the
most output correctness assurance.

You should really pick one side of whatever you're arguing for and stick
with that; arguing both sides is just silly.

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.

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?

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.

bart c <bart4858@gmail.com> writes:
>On Saturday, 19 August 2023 at 15:43:02 UTC+1, Scott Lurndal wrote:
>> Ben Bacarisse <ben.u...@bsb.me.uk> writes:
>> >bart c <bart...@gmail.com> writes:
>> >
>>
>> >>
>> >> on those other programs is anathema.
>> >
>> >Well (if you are talking about having to say gcc prog.c rather than gcc
>> >prog) there are advantages, and none of them have anything to do with
>> >how much one has to type. After all, command completion means I rarely
>> >type a file name explcitly anyway.
>> >
>> It's worth repeating that 'gcc' is a driver program, not a compiler.
>>
>> So:
>>
>> $ gcc -c -o a.o a.s
>>
>> is a perfectly legal and viable way to invoke the assembler.
>>
>> $ gcc -o a a.o
>>
>> is a perfectly legal and viable way to invoke the linker.
>
>You can run the assembler directly using 'as', and the linker using 'ld'.
>
>So how do you directly invoke the actual C compiler?

As if you don't already know.

$ gcc -o a.o a.c

or

$ gcc -o a a.c

Kaz Kylheku <864-117-4973@kylheku.com> writes:
>On 2023-08-19, bart c <bart4858@gmail.com> wrote:
>> On Saturday, 19 August 2023 at 16:59:16 UTC+1, Kaz Kylheku wrote:
>>> On 2023-08-19, bart c <bart...@gmail.com> wrote:
>>> > On Saturday, 19 August 2023 at 15:43:02 UTC+1, Scott Lurndal wrote:
>>> >> Ben Bacarisse <ben.u...@bsb.me.uk> writes:
>>> >> >bart c <bart...@gmail.com> writes:
>>> >> >
>>> >>
>>> >> >>
>>> >> >> on those other programs is anathema.
>>> >> >
>>> >> >Well (if you are talking about having to say gcc prog.c rather than gcc
>>> >> >prog) there are advantages, and none of them have anything to do with
>>> >> >how much one has to type. After all, command completion means I rarely
>>> >> >type a file name explcitly anyway.
>>> >> >
>>> >> It's worth repeating that 'gcc' is a driver program, not a compiler.
>>> >>
>>> >> So:
>>> >>
>>> >> $ gcc -c -o a.o a.s
>>> >>
>>> >> is a perfectly legal and viable way to invoke the assembler.
>>> >>
>>> >> $ gcc -o a a.o
>>> >>
>>> >> is a perfectly legal and viable way to invoke the linker.
>>> >
>>> > You can run the assembler directly using 'as', and the linker using 'ld'.
>>> Not reliably. The gcc driver is configured to use a particular
>>> assembler, not necessarily the one found in you PATH under the
>>> name "as".
>>>
>>> You might have an "as" that came from your Unix vendor, but gcc
>>> was built with the GNU assembler.
>>>
>>> You could have different installations of gcc with different
>>> versions of an assembler.
>>> > So how do you directly invoke the actual C compiler?
>>> That's an executable usually called cc1. You have to know where
>>> that is. Even if gcc is in your PATH, cc1 won't be.
>>
>> I found cc1, but how do you use it? There's no conventional CLI. You can do:
>>
>> cc1 <hello.c
>
>I don't think it's documented for use.
>
>If you want to see what arguments are being passed to cc1, you can
>use the "strace" utility on Linux or similar syscall tracers elsewhere.
>
>> I get the feeling it is not meant to be used from the command line like 'as' and 'ld'.
>>
>> So, there /is/ no proper C-specific compiler with a normal interface; we're stuck with that driver.
>
>That's correct.
>
>Let's try:
>
>$ strace -s 4096 -o gcc.log -f gcc foo.c -o foo
>$ grep cc1 gcc.log
>25364 stat64("/usr/lib/gcc/i686-linux-gnu/7/cc1", {st_mode=S_IFREG|0755, st_size=22895720, ...}) = 0
>25364 access("/usr/lib/gcc/i686-linux-gnu/7/cc1", X_OK) = 0
>25365 execve("/usr/lib/gcc/i686-linux-gnu/7/cc1", ["/usr/lib/gcc/i686-linux-gnu/7/cc1", "-quiet", "-imultiarch", "i386-linux-gnu", "foo.c", "-quiet", "-dumpbase", "foo.c", "-mtune=generic", "-march=i686", "-auxbase", "foo", "-fstack-protector-strong", "-Wformat", "-Wformat-security", "-o", "/tmp/ccKrG8uQ.s"], 0x8cad030 /* 62 vars */ <unfinished ...>
>
>Looks like cc1 isn't being given a huge number of many options.
>
>cc1 must be doing the preprocessing since it's getting foo.c as
>input. I don't see any arguments which would tell it where the header
>files are, so it must be getting that configuration in some
>other ways. (I looked into the environment with strace -v too;
>didn't see it.)
>
>There is also another intermediary program called "collect2" which I
>think handles the details of linking. In the above trace, there is an
>invocation of collect2 after cc1.

IIRC collect is the optimization pass.

Kaz Kylheku <864-117-4973@kylheku.com> writes:
[...]
> If you want to see what arguments are being passed to cc1, you can
> use the "strace" utility on Linux or similar syscall tracers elsewhere.

"gcc -v" shows the invoked programs and arguments.

--
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 Saturday, 19 August 2023 at 22:01:09 UTC+1, Scott Lurndal wrote:
> bart c <bart...@gmail.com> writes:
> >On Saturday, 19 August 2023 at 15:43:02 UTC+1, Scott Lurndal wrote:
> >> Ben Bacarisse <ben.u...@bsb.me.uk> writes:
> >> >bart c <bart...@gmail.com> writes:
> >> >
> >>
> >> >>
> >> >> on those other programs is anathema.
> >> >
> >> >Well (if you are talking about having to say gcc prog.c rather than gcc
> >> >prog) there are advantages, and none of them have anything to do with
> >> >how much one has to type. After all, command completion means I rarely
> >> >type a file name explcitly anyway.
> >> >
> >> It's worth repeating that 'gcc' is a driver program, not a compiler.
> >>
> >> So:
> >>
> >> $ gcc -c -o a.o a.s
> >>
> >> is a perfectly legal and viable way to invoke the assembler.
> >>
> >> $ gcc -o a a.o
> >>
> >> is a perfectly legal and viable way to invoke the linker.
> >
> >You can run the assembler directly using 'as', and the linker using 'ld'..
> >
> >So how do you directly invoke the actual C compiler?
> As if you don't already know.
>
> $ gcc -o a.o a.c
>
> or
>
> $ gcc -o a a.c

I thought you said gcc was the driver program?

I wonder why there has to be such a big mystery about gcc (like, is it an actual compiler), why it has to work that way, or why everything to do with building C has to revolve around how Unix and gcc (and cc before that) work.. Is it all decreed in the C standard?

If I do this:

pico hello.c

the process is entirely different. But it's still C.

bart c <bart4858@gmail.com> writes:

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

You have very strong opinions about something you don't know much about.

> Do you routinely have to
> invoke it five times in succession?

No. I am giving typical example invocations.

> Maybe that's a deeper problem with
> it, but as I said I don't use it.

Obviously.

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

Yes, it's somewhat like a configuration file.

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

Presumably.

> In practice I doubt you would type this five times as normally you'd
> do line recall then change the last bit.

Yes. I hope we can agree one thing: how much one types is almost
entirely irrelevant on modern systems. You kept going on about it, but
the typing has never been the issue.

> You can also choose to give it a shorter name than 'makefile'!

Yes, but the typing is not, and never has been, the issue. If the name
is not defaulted everyone has to guess where the rules for this project
are stored. And it's redundant and intrusive to keep specifying the
configuration, even if it's easy to type.

>> What's more, tab completion in my shell works with make's targets, but I
>> don't think that's at all easy to do if the makefile has to be named in
>> the same command.
>> > like nearly every other command line program.
>>
>> > Yet being able to do
>> >
>> > X Y
>> >
>> > instead of:
>> >
>> > X Y.Z
>> >
>> > on those other programs is anathema.
>> Well (if you are talking about having to say gcc prog.c rather than gcc
>> prog) there are advantages, and none of them have anything to do with
>> how much one has to type. After all, command completion means I rarely
>> type a file name explcitly anyway.
>
> If my C test folder, I had 23 files that started with
> 'hello'. Although they are stepped through in alphabetical order on
> Windows and .c is near the top, you still have to tentatively keep
> pressing tab, then you go too far and need shift-tab .. it is quicker
> just to type the extension! Better however not to have to bother.

As I say, it's not about saving two key presses, it's about:

>> The main advantage is that there's no need to specify and remember all
>> the rules. Does gcc always add .c? Will it add .c if I type gcc
>> prog.s? Must I avoid any dots in the basename? What happens when
>> several names appear on the command line?
>
> gcc is a bad example to follow since it does too much on the command
> line and performs multiple functions.

But it's what you were talking about. You seem to want it to do less.
I don't.

>> > It's fascinating watching psychology and group-think at work.
>>
>> As usual, you've invented a position (it'a all about the typing) and
>> argued about that instead of taking on board the actual comments that
>> people have made.
>
> The typing is part of it.

For you. Not for me. It seems you care enough about it to champion a
compiler driver that isn't very flexible. I don't.

--
Ben.

On Sunday, 20 August 2023 at 00:10:38 UTC+1, Ben Bacarisse wrote:
> bart c <bart...@gmail.com> writes:
> > 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.
> You have very strong opinions about something you don't know much about.

Well, I'm being brow-beaten by so many people into using something I don't want to use. Or I'm obliged to use it in building open-source software (something I'm rapidly losing interest in).

I'm seen enough of it to know that I don't like it and it's not for me. Giving you case studies of all the cases where following the build rules generally results in failure seems to cut no ice; the problem can't possibly be a fragile and error prone process, people have to get personal.

The makefile syntax is obscure enough that if something goes wrong, I can't fix it. (I've suggested that a build-system for a one-off end-user build of a working product should use a streamlined process and a simpler makefile; that fell on deaf ears.)

Clearly some of you use 'make' for routine development. I don't; for real projects I use my IDE. For things that don't quite fit that routine, I might use my own scripts especially if I need repeatability. Or I type directly from the command line where even scripts are too formal.

It is in the latter cases where I was coming across invocations of programs like gcc where it has invented its own rules and folklore. I find that a nuisance.

This is where the suggestions start: nobody cares how you invoke gcc, it's usually invoked from a makefile script. So I'm slowly drawn into something that is 100 times worse than that minor nuisance of typing file extensions and providing options that should not be needed.

> > Do you routinely have to
> > invoke it five times in succession?
> No. I am giving typical example invocations.
> > Maybe that's a deeper problem with
> > it, but as I said I don't use it.
> Obviously.
> >> 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;
> Yes, it's somewhat like a configuration file.

One that explains how a project is to work rather than the tool?

> > You can also choose to give it a shorter name than 'makefile'!
> Yes, but the typing is not, and never has been, the issue. If the name
> is not defaulted everyone has to guess where the rules for this project
> are stored.

Tool Projectname

> And it's redundant and intrusive to keep specifying the
> configuration, even if it's easy to type.

Well, you have to type something five times, whether it's 'make', 'make makefile', 'make lua', or a dedicated script called 'makelua', I don't see much difference.

Having the project name as part of the invocation I see as useful information and confirmation of what you are doing. You don't want to click on the wrong terminal window out of 6, type 'make', and you find it, a bit later, you're building the wrong project.

> > gcc is a bad example to follow since it does too much on the command
> > line and performs multiple functions.
> But it's what you were talking about. You seem to want it to do less.
> I don't.

I want it to compile C code, not any other language. But if I invoke it 10,000 times, I have to type .c 10,000 times (times the average number of modules) to tell it I'm compiling C and not C++, Ada or Fortran. If nothing else, it's not ergonomic.

I can fix this by providing wrapper to give the behaviour I want, but this seems wrong: gcc is already a driver program, and it's already huge, yet I have to provide yet another layer to make it usable?

Just deleting it and forgetting about C seems very attractive. You guys seem to want to 'own' C and its collection of idiosyncratic, *nix based tools and don't want to allow any other way of doing things. Just because 'that's how it's always been done.'

scott@slp53.sl.home (Scott Lurndal) writes:
> bart c <bart4858@gmail.com> writes:
[...]
>>So how do you directly invoke the actual C compiler?
>
> As if you don't already know.
>
> $ gcc -o a.o a.c

That creates an executable named "a.o". Bad idea.

> or
>
> $ gcc -o a a.c

That invokes the compiler and the linker.

To invoke just the compiler:

gcc -c a.c

which creates an object file named "a.o". If for some odd reason you
want the object file to have a different name:

gcc -c a.c -o foo.o

Giving an object file a name not ending in ".o" is almost certainly a
bad idea. (That's for Unix-like systems; other systems might have a
different convention like ".obj".)

--
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 Sunday, 20 August 2023 at 01:57:13 UTC+1, Keith Thompson wrote:
> sc...@slp53.sl.home (Scott Lurndal) writes:
> > bart c <bart...@gmail.com> writes:
> [...]
> >>So how do you directly invoke the actual C compiler?
> >
> > As if you don't already know.
> >
> > $ gcc -o a.o a.c
> That creates an executable named "a.o". Bad idea.
> > or
> >
> > $ gcc -o a a.c
> That invokes the compiler and the linker.
>
> To invoke just the compiler:
>
> gcc -c a.c
>
> which creates an object file named "a.o". If for some odd reason you
> want the object file to have a different name:
>
> gcc -c a.c -o foo.o
>
> Giving an object file a name not ending in ".o" is almost certainly a
> bad idea. (That's for Unix-like systems; other systems might have a
> different convention like ".obj".)

Also, none of these /directly/ invoke the compiler. Using your suggestion, gcc uses an invocation like this, on Windows:

C:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/10.3.0/cc1.exe -quiet -v -iprefix C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/ -D_REENTRANT hello.c -quiet -dumpbase hello.c -mtune=generic -march=x86-64 -auxbase hello -version -o C:\Users\xxxxx\AppData\Local\Temp\ccJo76DR.s

It doesn't look very user friendly.

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

On 20/08/2023 03:13, bart c wrote:
> On Sunday, 20 August 2023 at 01:57:13 UTC+1, Keith Thompson wrote:
>> sc...@slp53.sl.home (Scott Lurndal) writes:
>>> bart c <bart...@gmail.com> writes:
>> [...]
>>>> So how do you directly invoke the actual C compiler?
>>>
>>> As if you don't already know.
>>>
>>> $ gcc -o a.o a.c
>> That creates an executable named "a.o". Bad idea.
>>> or
>>>
>>> $ gcc -o a a.c
>> That invokes the compiler and the linker.
>>
>> To invoke just the compiler:
>>
>> gcc -c a.c
>>
>> which creates an object file named "a.o". If for some odd reason you
>> want the object file to have a different name:
>>
>> gcc -c a.c -o foo.o
>>
>> Giving an object file a name not ending in ".o" is almost certainly a
>> bad idea. (That's for Unix-like systems; other systems might have a
>> different convention like ".obj".)
>
> Also, none of these /directly/ invoke the compiler. Using your suggestion, gcc uses an invocation like this, on Windows:
>
> C:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/10.3.0/cc1.exe -quiet -v -iprefix C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/ -D_REENTRANT hello.c -quiet -dumpbase hello.c -mtune=generic -march=x86-64 -auxbase hello -version -o C:\Users\xxxxx\AppData\Local\Temp\ccJo76DR.s
>
> It doesn't look very user friendly.

It isn't user friendly - nor is it intended to be. It is intended that
you use "gcc" (or "g++", "gfortran", or other drivers that are
convenient for other gcc languages) as the driver program that will then
invoke "cc1" with whatever options are needed. The options and
interface for "cc1" are not considered user documentation - they are
internal, might not be complete, and may change wildly between versions
of gcc. It is the options for "gcc" that are documented for user usage.

On 19/08/2023 18:00, Kaz Kylheku wrote:
> On 2023-08-19, David Brown <david.brown@hesbynett.no> wrote:
>> On 19/08/2023 13:39, bart c wrote:
>>> That's interesting. One of the limitations of Lua was that it didn't have proper integer type, it used a 64-bit float.
>>>
>>
>> Lua is configurable, and can support different types. When I embedded
>> in a 32-bit microcontroller program, I use 32-bit integers as the number
>> type.
>
> I don't feel the party has properly started until someone makes that
> sort of thing a command line option. Or better yet, environment
> variable.
>

I don't think something like that would be remotely helpful for Lua, but
that is possibly due to my lack of experience with the language. You'd
get a more complete answer from a Lua newsgroup.

On Sunday, 20 August 2023 at 13:14:00 UTC+1, David Brown wrote:
> On 20/08/2023 03:13, bart c wrote:
> > On Sunday, 20 August 2023 at 01:57:13 UTC+1, Keith Thompson wrote:
> >> sc...@slp53.sl.home (Scott Lurndal) writes:
> >>> bart c <bart...@gmail.com> writes:
> >> [...]
> >>>> So how do you directly invoke the actual C compiler?
> >>>
> >>> As if you don't already know.
> >>>
> >>> $ gcc -o a.o a.c
> >> That creates an executable named "a.o". Bad idea.
> >>> or
> >>>
> >>> $ gcc -o a a.c
> >> That invokes the compiler and the linker.
> >>
> >> To invoke just the compiler:
> >>
> >> gcc -c a.c
> >>
> >> which creates an object file named "a.o". If for some odd reason you
> >> want the object file to have a different name:
> >>
> >> gcc -c a.c -o foo.o
> >>
> >> Giving an object file a name not ending in ".o" is almost certainly a
> >> bad idea. (That's for Unix-like systems; other systems might have a
> >> different convention like ".obj".)
> >
> > Also, none of these /directly/ invoke the compiler. Using your suggestion, gcc uses an invocation like this, on Windows:
> >
> > C:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/10.3.0/cc1.exe -quiet -v -iprefix C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/ -D_REENTRANT hello..c -quiet -dumpbase hello.c -mtune=generic -march=x86-64 -auxbase hello -version -o C:\Users\xxxxx\AppData\Local\Temp\ccJo76DR.s
> >
> > It doesn't look very user friendly.
> It isn't user friendly - nor is it intended to be. It is intended that
> you use "gcc" (or "g++", "gfortran", or other drivers that are
> convenient for other gcc languages) as the driver program that will then
> invoke "cc1" with whatever options are needed. The options and
> interface for "cc1" are not considered user documentation - they are
> internal, might not be complete, and may change wildly between versions
> of gcc. It is the options for "gcc" that are documented for user usage.

How about 'ld'; is that supposed to be directly usable? The gcc -v option doesn't show the arguments to 'ld'; I have to determine those myself. For 'gcc hello.c', they are these (number `1 is the invocation):

1: C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe
2: -plugin
3: C:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/10.3.0/liblto_plugin-0.dll
4: -plugin-opt=C:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/10.3.0/lto-wrapper.exe
5: -plugin-opt=-fresolution=C:\Users\44775\AppData\Local\Temp\ccZgT4Qq.res
6: -plugin-opt=-pass-through=-lmingw32
7: -plugin-opt=-pass-through=-lgcc
8: -plugin-opt=-pass-through=-lpthread
9: -plugin-opt=-pass-through=-lgcc
10: -plugin-opt=-pass-through=-lkernel32
11: -plugin-opt=-pass-through=-lmoldname
12: -plugin-opt=-pass-through=-lmingwex
13: -plugin-opt=-pass-through=-lmsvcrt
14: -plugin-opt=-pass-through=-lkernel32
15: -plugin-opt=-pass-through=-lpthread
16: -plugin-opt=-pass-through=-ladvapi32
17: -plugin-opt=-pass-through=-lshell32
18: -plugin-opt=-pass-through=-luser32
19: -plugin-opt=-pass-through=-lkernel32
20: -plugin-opt=-pass-through=-lmingw32
21: -plugin-opt=-pass-through=-lgcc
22: -plugin-opt=-pass-through=-lpthread
23: -plugin-opt=-pass-through=-lgcc
24: -plugin-opt=-pass-through=-lkernel32
25: -plugin-opt=-pass-through=-lmoldname
26: -plugin-opt=-pass-through=-lmingwex
27: -plugin-opt=-pass-through=-lmsvcrt
28: -plugin-opt=-pass-through=-lkernel32
29: -m
30: i386pep
31: --exclude-libs=libpthread.a
32: --undefined=__xl_f
33: -Bdynamic
34: C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/../../../../x86_64-w64-mingw32/lib/../lib/crt2.o
35: C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/crtbegin.o
36: -LC:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0
37: -LC:/tdm/bin/../lib/gcc
38: -LC:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/../../../../x86_64-w64-mingw32/lib/../lib
39: -LC:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/../../../../lib
40: -LC:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/../../../../x86_64-w64-mingw32/lib
41: -LC:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/../../..
42: C:\Users\44775\AppData\Local\Temp\ccS1MzGi.o
43: -lmingw32
44: -lgcc
45: -lpthread
46: -lgcc
47: -lkernel32
48: -lmoldname
49: -lmingwex
50: -lmsvcrt
51: -lkernel32
52: -lpthread
53: -ladvapi32
54: -lshell32
55: -luser32
56: -lkernel32
57: -lmingw32
58: -lgcc
59: -lpthread
60: -lgcc
61: -lkernel32
62: -lmoldname
63: -lmingwex
64: -lmsvcrt
65: -lkernel32
66: C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/../../../../x86_64-w64-mingw32/lib/../lib/default-manifest.o
67: C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/crtend.o

(This is 10.3.0; 13.2 has 'only' 53.)

I suppose this is not really relevant, so long as somebody can climb to the top of this heap of complexity and plant a flag saying only 'Make`. Then it doesn't matter if its Mount Everest or an anthill. Or does it?

BTW 'gcc hello.c' creates a 367KB executable; 'tcc hello.c' created a 2KB executable. Just saying...

Maybe there is also a reason why -lgcc is specified four times.

Matthew Ernisse <matt@going-flying.com> writes:
> On Mon, 14 Aug 2023 02:44:16 -0000 (UTC), Kenny McCormack wrote:
>> In article <8fb22829-9b5e-4108-a513-df3b72391405n@googlegroups.com>,
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>> ...
>>>> DOS/Windows (and Mac similarly) has *never* shipped with any sort of
>>>> development environment, so arguing that it doesn't have "make" is kind of
>>>> pointless.
>>
>> I may actually have mis-spoken here. DOS did originally come with GWBASIC,
>> so you could, at least write and run programs back then.
>
> Later DOS version (I think 6+) came with QBASIC which was pretty close to
> an early IDE, reasoned individuals may debate whether it is a development
> environment but I believe I recall single-stepping in it.

DOS 5 came with GORILLA.BAS, that I do remember.

Phil
--
We are no longer hunters and nomads. No longer awed and frightened, as we have
gained some understanding of the world in which we live. As such, we can cast
aside childish remnants from the dawn of our civilization.
-- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/

On 20/08/2023 15:05, bart c wrote:
> On Sunday, 20 August 2023 at 13:14:00 UTC+1, David Brown wrote:
>> On 20/08/2023 03:13, bart c wrote:
>>> On Sunday, 20 August 2023 at 01:57:13 UTC+1, Keith Thompson wrote:
>>>> sc...@slp53.sl.home (Scott Lurndal) writes:
>>>>> bart c <bart...@gmail.com> writes:
>>>> [...]
>>>>>> So how do you directly invoke the actual C compiler?
>>>>>
>>>>> As if you don't already know.
>>>>>
>>>>> $ gcc -o a.o a.c
>>>> That creates an executable named "a.o". Bad idea.
>>>>> or
>>>>>
>>>>> $ gcc -o a a.c
>>>> That invokes the compiler and the linker.
>>>>
>>>> To invoke just the compiler:
>>>>
>>>> gcc -c a.c
>>>>
>>>> which creates an object file named "a.o". If for some odd reason you
>>>> want the object file to have a different name:
>>>>
>>>> gcc -c a.c -o foo.o
>>>>
>>>> Giving an object file a name not ending in ".o" is almost certainly a
>>>> bad idea. (That's for Unix-like systems; other systems might have a
>>>> different convention like ".obj".)
>>>
>>> Also, none of these /directly/ invoke the compiler. Using your suggestion, gcc uses an invocation like this, on Windows:
>>>
>>> C:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/10.3.0/cc1.exe -quiet -v -iprefix C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/ -D_REENTRANT hello.c -quiet -dumpbase hello.c -mtune=generic -march=x86-64 -auxbase hello -version -o C:\Users\xxxxx\AppData\Local\Temp\ccJo76DR.s
>>>
>>> It doesn't look very user friendly.
>> It isn't user friendly - nor is it intended to be. It is intended that
>> you use "gcc" (or "g++", "gfortran", or other drivers that are
>> convenient for other gcc languages) as the driver program that will then
>> invoke "cc1" with whatever options are needed. The options and
>> interface for "cc1" are not considered user documentation - they are
>> internal, might not be complete, and may change wildly between versions
>> of gcc. It is the options for "gcc" that are documented for user usage.
>
> How about 'ld'; is that supposed to be directly usable?

"ld" is not part of gcc. It is part of an independent project,
binutils, that is often used alongside gcc. (You know this, of course,
and only feign ignorance.) For user convenience, gcc configurations can
generally invoke a system linker or other configured linker from the gcc
driver program - and in many, but not all, gcc toolchains, that will be
binutils "ld".

So "ld" is very much designed to be usable directly - you'll find
documentation for it in the documentation for the "binutils" project.