Bart <bc@freeuk.com> writes:
>On 31/08/2023 18:36, David Brown wrote:
>> On 31/08/2023 16:30, Bart wrote:
>>> On 31/08/2023 13:36, David Brow
>
>>> But putting it in the current directory is sloppy. The current
>>> location can be arbitrary (or it might not be writeable):
>>>
>>>   c:\random>gcc \proj1\foo.c
>>>   c:\random>gcc \proj2\bar.c
>>>
>>
>> So don't do that.
>>
>> Make sure you are in the appropriate directory, then compile - or give
>> the output file name directly.  As I said, whatever default you use, it
>> will be wrong sometimes.
>
>But it's an extra thing that could be easily have been done right.
>Compilers work for us, not us for them.
>
>Suppose gcc decided to put the output files in a root directory, or some
>place where it would be a very bad idea to write or overwrite a file.

Why do you thing gcc would "decide" to do anything? You do understand
that non-root users cannot "put the output files in a root directory",
right?

And developers don't run as root. Linux is far more secure than windows.

Bart <bc@freeuk.com> writes:
>On 31/08/2023 18:36, David Brown wrote:
>
>> Nor is it helpful for the compiler to tell me what it is doing -
>
>If the compiler is doing multiple files, especially a slow compiler,
>then it is highly useful to know where it's up to, or what it's stuck on.

$ ps -ef | grep gcc

>
>But this seems to be a Linux thing: if I do 'cp *.c dest', then nothing
>is output, until you get the prompt back. So, did work, did it copy
>anything, was it one big file, or lots of small ones?

If it doesn't say anything, it worked. If it doesn't work it will
say something. If your really want to know what it's doing, use
-v.

>The defaults are backwards.

No.

On 31/08/2023 21:17, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> If the compiler is doing multiple files, especially a slow compiler,
>> then it is highly useful to know where it's up to, or what it's stuck
>> on.
>>
>> But this seems to be a Linux thing: if I do 'cp *.c dest', then
>> nothing is output, until you get the prompt back. So, did work, did it
>> copy anything, was it one big file, or lots of small ones?
>>
>> If I do 'copy *.c test' on Windows, it shows each file copied, and it
>> tells how many files were copied in all. The 'cp' command needs '-v'
>> to force to show what it's doing.
>>
>> The defaults are backwards.
> [...]
>
> I acknowledge that you prefer tools to be verbose,

Not at all. 'Verbose' might refer to the approx 5KB of output I get from
'gcc hello.c -v', as shown below.

I don't want that at all. What I'm asking for is more of an
acknowledgement and confirmation of what I'm asked the tool to do. That
seems reasonable enough to me.

Typing 'bcc hello' simply gives me this:

Compiling hello.c to hello.exe

Presumably you consider /that/ verbose? If so then what do you call all
that crap below!

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

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=C:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/13.2.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: /gcc-13.2.0/configure --prefix=/w64devkit
--with-sysroot=/w64devkit/x86_64-w64-mingw32
--with-native-system-header-dir=/include --target=x86_64-w64-mingw32
--host=x86_64-w64-mingw32 --enable-static --disable-shared --with-pic
--with-gmp-include=/deps/include --with-gmp-lib=/deps/lib
--with-mpc-include=/deps/include --with-mpc-lib=/deps/lib
--with-mpfr-include=/deps/include --with-mpfr-lib=/deps/lib
--enable-languages=c,c++ --enable-libgomp --enable-threads=posix
--enable-version-specific-runtime-libs --disable-dependency-tracking
--disable-multilib --disable-nls --disable-win32-registry
--enable-mingw-wildcard CFLAGS_FOR_TARGET=-Os CXXFLAGS_FOR_TARGET=-Os
LDFLAGS_FOR_TARGET=-s CFLAGS=-Os CXXFLAGS=-Os LDFLAGS=-s
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.2.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a-'
C:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/13.2.0/cc1.exe -quiet -v
-iprefix C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/ -isysroot
C:/tdm/bin/../x86_64-w64-mingw32 -D_REENTRANT hello.c -quiet -dumpdir a-
-dumpbase hello.c -dumpbase-ext .c -mtune=generic -march=x86-64 -version
-o C:\Users\xxxxx\AppData\Local\Temp\ccHzEGHk.s
GNU C17 (GCC) version 13.2.0 (x86_64-w64-mingw32)
compiled by GNU C version 13.2.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring duplicate directory
"C:/tdm/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.2.0/include"
ignoring nonexistent directory
"C:/tdm/bin/../x86_64-w64-mingw32/w64devkit/lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../include"
ignoring duplicate directory
"C:/tdm/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.2.0/include-fixed"
ignoring duplicate directory
"C:/tdm/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/include"
ignoring nonexistent directory
"C:/tdm/bin/../x86_64-w64-mingw32/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/include
C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/include-fixed
C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/include
End of search list.
Compiler executable checksum: 055af4833c5f81a4fd6295dedebfeca6
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a-'
as -v -o C:\Users\xxxxx\AppData\Local\Temp\ccDDjtgp.o
C:\Users\xxxxx\AppData\Local\Temp\ccHzEGHk.s
GNU assembler version 2.40 (x86_64-w64-mingw32) using BFD version (GNU
Binutils) 2.40
COMPILER_PATH=C:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/13.2.0/;C:/tdm/bin/../libexec/gcc/
LIBRARY_PATH=C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/;C:/tdm/bin/../lib/gcc/;C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/lib/../lib/;C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../lib/;C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/lib/;C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a.'
C:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/13.2.0/collect2.exe
-plugin
C:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/13.2.0/liblto_plugin.dll
-plugin-opt=C:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/13.2.0/lto-wrapper.exe
-plugin-opt=-fresolution=C:\Users\xxxxx\AppData\Local\Temp\cc9Tr00r.res
-plugin-opt=-pass-through=-lmingw32 -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lmoldname -plugin-opt=-pass-through=-lmingwex
-plugin-opt=-pass-through=-lmsvcrt -plugin-opt=-pass-through=-lkernel32
-plugin-opt=-pass-through=-lpthread -plugin-opt=-pass-through=-ladvapi32
-plugin-opt=-pass-through=-lshell32 -plugin-opt=-pass-through=-luser32
-plugin-opt=-pass-through=-lkernel32 -plugin-opt=-pass-through=-lmingw32
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lmoldname
-plugin-opt=-pass-through=-lmingwex -plugin-opt=-pass-through=-lmsvcrt
-plugin-opt=-pass-through=-lkernel32
--sysroot=C:/tdm/bin/../x86_64-w64-mingw32 -m i386pep -Bdynamic
C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/lib/../lib/crt2.o
C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/crtbegin.o
-LC:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0
-LC:/tdm/bin/../lib/gcc
-LC:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/lib/../lib
-LC:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../lib
-LC:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/lib
-LC:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../..
C:\Users\xxxxx\AppData\Local\Temp\ccDDjtgp.o -lmingw32 -lgcc -lmoldname
-lmingwex -lmsvcrt -lkernel32 -lpthread -ladvapi32 -lshell32 -luser32
-lkernel32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -lkernel32
C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/crtend.o
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a.'

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>Bart <bc@freeuk.com> writes:
>[...]
>> I can confirm that I've started an overhaul of the project, which will
>> have a working title of 'DD' to distinguish it from 'CC'. The first
>> stage is to get it to generate a new intermediate (IL) code (perhaps
>> within a week).
>
>There's a common Unix file conversion tool called "dd". Do whatever you
>like with that information.

For consistency, since 'cc' stands for 'C Compiler', he should
use 'dc', for 'D Compiler'. But that conflicts with the standard
'desktop RPN calculator' application, dc.

On 31/08/2023 23:07, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 31/08/2023 18:36, David Brown wrote:
>>
>>> Nor is it helpful for the compiler to tell me what it is doing -
>>
>> If the compiler is doing multiple files, especially a slow compiler,
>> then it is highly useful to know where it's up to, or what it's stuck on.
>
> $ ps -ef | grep gcc
>
>>
>> But this seems to be a Linux thing: if I do 'cp *.c dest', then nothing
>> is output, until you get the prompt back. So, did work, did it copy
>> anything, was it one big file, or lots of small ones?
>
> If it doesn't say anything, it worked. If it doesn't work it will
> say something. If your really want to know what it's doing, use
> -v.

<Literally both face palms on face>

If it doesn't say anything, it worked? Since Windows 10, a crashing
program doesn't say anything; it silently fails.

And when there is a lot going on with gcc, you can get loads of warnings
and other crap scrolling up the screen. So, was there an "error:" in
there or not? I've no idea if it worked!

I have to see if there is a recent .exe just created.

Or sometimes I get a clue by there being a pause after the last message,
meaning it's doing the rest of it.

(Or maybe it's just crashed.)

Or I have to supply options to tell it to stop after one error (I have
to find it first).

Or I have to capture the output twice (first with >, second after I've
remembered it's 2>), so that I can use a text editor to search for
"error:" strings.

What an effing palaver.

gcc is not the only program like that, but it seems typical of where it
came from.

>> The defaults are backwards.
>
> No.

Delude yourself if you like.

Bart <bc@freeuk.com> writes:
> On 31/08/2023 21:17, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> If the compiler is doing multiple files, especially a slow compiler,
>>> then it is highly useful to know where it's up to, or what it's stuck
>>> on.
>>>
>>> But this seems to be a Linux thing: if I do 'cp *.c dest', then
>>> nothing is output, until you get the prompt back. So, did work, did it
>>> copy anything, was it one big file, or lots of small ones?
>>>
>>> If I do 'copy *.c test' on Windows, it shows each file copied, and it
>>> tells how many files were copied in all. The 'cp' command needs '-v'
>>> to force to show what it's doing.
>>>
>>> The defaults are backwards.
>> [...]
>> I acknowledge that you prefer tools to be verbose,
>
> Not at all. 'Verbose' might refer to the approx 5KB of output I get
> from 'gcc hello.c -v', as shown below.

Your preference is for tools to be more verbose than what a lot of other
people prefer.

Printing one line of output for a successful compilation or file copy is
more verbose than printing nothing.

> I don't want that at all. What I'm asking for is more of an
> acknowledgement and confirmation of what I'm asked the tool to
> do. That seems reasonable enough to me.

And I just acknowledged that your preference is valid.

> Typing 'bcc hello' simply gives me this:
>
> Compiling hello.c to hello.exe
>
> Presumably you consider /that/ verbose? If so then what do you call
> all that crap below!

I consider that more verbose than my own preference, which is for it to
print nothing on success. If gcc printed the one-line status report
that you prefer, it wouldn't particularly bother me, but I'm content
with its current behavior.

Let me clarify: I have no preference for what bcc should print, since I
don't use it. If I did, I probably wouldn't bother to figure out how to
suppress the "Compiling ..." message.

I suppose it would be nice if gcc had an option to print output that's
less verbose than what it prints with "-v", perhaps one terse line for
each program it invokes. Since I'm not a gcc maintainer, I'm not in a
position to do anything about it. Since the current behavior doesn't
bother me, I'm not going to ask the gcc maintainers to do anything about
it.

The point of my previous post was to ask you to acknowledge that others
may have valid preferences that differ from yours. You refuse to do
so. Got 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 <bc@freeuk.com> writes:
>On 31/08/2023 23:07, Scott Lurndal wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 31/08/2023 18:36, David Brown wrote:
>>>
>>>> Nor is it helpful for the compiler to tell me what it is doing -
>>>
>>> If the compiler is doing multiple files, especially a slow compiler,
>>> then it is highly useful to know where it's up to, or what it's stuck on.
>>
>> $ ps -ef | grep gcc
>>
>>>
>>> But this seems to be a Linux thing: if I do 'cp *.c dest', then nothing
>>> is output, until you get the prompt back. So, did work, did it copy
>>> anything, was it one big file, or lots of small ones?
>>
>> If it doesn't say anything, it worked. If it doesn't work it will
>> say something. If your really want to know what it's doing, use
>> -v.
>
>
><Literally both face palms on face>
>
>If it doesn't say anything, it worked? Since Windows 10, a crashing
>program doesn't say anything; it silently fails.

You're talking about building unix/linux tools. On *nix, a crashing program
_will_ say something (if not directly, then indirectly via the
shell return status $?).

$ cc -o /tmp/a /tmp/a.c
$ /tmp/a
Memory fault
$ printf '0x%x\n' $(( $? ))
0x10b <----- Signal 11 (SIGSEGV)

$ cat /tmp/a.c
int
main(int argc, const char **argv, const char **envp)
{ const char *cp = (const char *)0;
return *cp;
}

https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_13

>
>And when there is a lot going on with gcc, you can get loads of warnings
>and other crap scrolling up the screen.\

Acually, I don't get any warnings. -Wall -Werror.

$ pwd
/work/ws/vsim/20220509/vsim
$ make -s HUSHCOMPILE=@
VSIM_BUILT
COMPILE bct.cpp
COMPILE command_table.cpp
COMPILE contention_protocol.cpp
COMPILE dcp.cpp
COMPILE dcp_header.cpp
COMPILE disassembler.cpp
COMPILE ebcdic.cpp
COMPILE file_logger.cpp
COMPILE mcs.cpp
COMPILE mux_logger.cpp
COMPILE netport.cpp
COMPILE osdep.cpp
COMPILE pollselect.cpp
COMPILE pool.cpp
COMPILE protocol.cpp
COMPILE serialport.cpp
COMPILE station.cpp
COMPILE syslog_logger.cpp
COMPILE thread.cpp
COMPILE timer.cpp
COMPILE timer_manager.cpp
COMPILE dlp.cpp
COMPILE iocb.cpp
COMPILE card_unit.cpp
COMPILE tape_unit.cpp
COMPILE disk_unit.cpp
COMPILE file_card_unit.cpp
COMPILE file_tape_unit.cpp
COMPILE st_tape_unit.cpp
COMPILE file_disk_unit.cpp
COMPILE fips_tape_dlp.cpp
COMPILE gcr_dlp.cpp
COMPILE scsi_disk_dlp.cpp
COMPILE 5n_dlp.cpp
COMPILE odt_dlp.cpp
COMPILE uniline_dlp.cpp
COMPILE htseq_dlp.cpp
COMPILE card_reader_dlp.cpp
COMPILE train_printer_dlp.cpp
COMPILE ssp_dlp.cpp
COMPILE ssp.cpp
COMPILE qwik_dlp.cpp
COMPILE buffered_printer_dlp.cpp
COMPILE card_punch_dlp.cpp
COMPILE ht_dcp_dlp.cpp
COMPILE ht_dpdc_dlp.cpp
COMPILE isc_dlp.cpp
COMPILE scsi_tape_dlp.cpp
COMPILE telcom_dlp.cpp
BUILD ../../lib/libdlp_5n.so
BUILD ../../lib/libdlp_buffered_printer.so
BUILD ../../lib/libdlp_fips_tape.so
BUILD ../../lib/libdlp_gcr.so
BUILD ../../lib/libdlp_ht_dcp.so
BUILD ../../lib/libdlp_ht_dpdc.so
BUILD ../../lib/libdlp_htseq.so
BUILD ../../lib/libdlp_isc.so
BUILD ../../lib/libdlp_qwik.so
BUILD ../../lib/libdlp_punch.so
BUILD ../../lib/libdlp_reader.so
BUILD ../../lib/libdlp_scsi_disk.so
BUILD ../../lib/libdlp_scsi_tape.so
BUILD ../../lib/libdlp_ssp.so
BUILD ../../lib/libdlp_telcom.so
BUILD ../../lib/libdlp_tpr.so
BUILD ../../lib/libdlp_odt.so
BUILD ../../lib/libdlp_uniline.so
COMPILE system.cpp
COMPILE blt.cpp
COMPILE memory.cpp
COMPILE processor.cpp
COMPILE processor_rd.cpp
COMPILE index_register.cpp
COMPILE operand.cpp
COMPILE misc_ops.cpp
COMPILE arith_ops.cpp
COMPILE compare_ops.cpp
COMPILE branch_ops.cpp
COMPILE move_ops.cpp
COMPILE search_ops.cpp
COMPILE omega_ops.cpp
COMPILE hardware_call.cpp
COMPILE time_ops.cpp
COMPILE environment.cpp
COMPILE environment_table.cpp
COMPILE kernel_data_area.cpp
COMPILE float.cpp
COMPILE mop.cpp
COMPILE toggles.cpp
COMPILE intflags.cpp
HOSTCOMPILE makedigits
COMPILE digits.cpp
COMPILE add.cpp
COMPILE sub.cpp
COMPILE op_acm.cpp
COMPILE op_add.cpp
COMPILE op_and.cpp
COMPILE op_asp.cpp
COMPILE op_ate.cpp
COMPILE op_b2d.cpp
COMPILE op_bct.cpp
COMPILE op_brt.cpp
COMPILE op_brv.cpp
COMPILE op_brv_reva.cpp
COMPILE op_bst.cpp
COMPILE op_cio.cpp
COMPILE op_cio_reva.cpp
COMPILE op_cpn.cpp
COMPILE op_cps.cpp
COMPILE op_d2b.cpp
COMPILE op_dec.cpp
COMPILE op_edt.cpp
COMPILE op_ext.cpp
COMPILE op_hbk.cpp
COMPILE op_hbr.cpp
COMPILE op_hcl.cpp
COMPILE op_hsh.cpp
COMPILE op_iad.cpp
COMPILE op_ias.cpp
COMPILE op_idl.cpp
COMPILE op_iio.cpp
COMPILE op_ild.cpp
COMPILE op_ils.cpp
COMPILE op_imi.cpp
COMPILE op_ims.cpp
COMPILE op_imu.cpp
COMPILE op_inc.cpp
COMPILE op_ioc.cpp
COMPILE op_ioc_reva.cpp
COMPILE op_ipc.cpp
COMPILE op_iss.cpp
COMPILE op_ist.cpp
COMPILE op_isu.cpp
COMPILE op_ker.cpp
COMPILE op_lix.cpp
COMPILE op_lok.cpp
COMPILE op_mls.cpp
COMPILE op_mop.cpp
COMPILE op_mvc.cpp
COMPILE op_mvd.cpp
COMPILE op_mvl.cpp
COMPILE op_mvr.cpp
COMPILE op_mvs.cpp
COMPILE op_mvw.cpp
COMPILE op_not.cpp
COMPILE op_ntr.cpp
COMPILE op_orr.cpp
COMPILE op_piq.cpp
COMPILE op_raa.cpp
COMPILE op_rad.cpp
COMPILE op_ras.cpp
COMPILE op_rds.cpp
COMPILE op_rdt.cpp
COMPILE op_rdv.cpp
COMPILE op_ret.cpp
COMPILE op_rld.cpp
COMPILE op_rms.cpp
COMPILE op_rmu.cpp
COMPILE op_rss.cpp
COMPILE op_rst.cpp
COMPILE op_rsu.cpp
COMPILE op_sde.cpp
COMPILE op_sea.cpp
COMPILE op_six.cpp
COMPILE op_sll.cpp
COMPILE op_slt.cpp
COMPILE op_smf.cpp
COMPILE op_spio.cpp
COMPILE op_sst.cpp
COMPILE op_srd.cpp
COMPILE op_stb.cpp
COMPILE op_stt.cpp
COMPILE op_sub.cpp
COMPILE op_sze.cpp
COMPILE op_trn.cpp
COMPILE op_tst.cpp
COMPILE op_ven.cpp
COMPILE op_whr.cpp
COMPILE analyze.cpp
COMPILE base.cpp
COMPILE breakpoint.cpp
COMPILE cf.cpp
COMPILE channel.cpp
COMPILE clear.cpp
COMPILE command.cpp
COMPILE control.cpp
COMPILE delete.cpp
COMPILE dis.cpp
COMPILE dump.cpp
COMPILE exchange.cpp
COMPILE haltwait.cpp
COMPILE iocbdump.cpp
COMPILE iodump.cpp
COMPILE load.cpp
COMPILE mem.cpp
COMPILE mp.cpp
COMPILE quit.cpp
COMPILE rle.cpp
COMPILE run.cpp
COMPILE save.cpp
COMPILE search.cpp
COMPILE so.cpp
COMPILE start.cpp
COMPILE state.cpp
COMPILE status.cpp
COMPILE step.cpp
COMPILE stop.cpp
COMPILE table.cpp
COMPILE to.cpp
COMPILE trace.cpp
COMPILE main.cpp
COMPILE hub.cpp
CONVERT td830.bdf
CONVERT td830B.bdf
COMPILE main.cpp
COMPILE t27.cpp
COMPILE env.cpp
COMPILE menu.cpp
COMPILE vsim_dcomm.cpp
COMPILE tapecopy.c
COMPILE tapedump.c
COMPILE vdir.c
COMPILE ebc2asc.c
COMPILE deblock.c
COMPILE tapeconvert.c
COMPILE main.cpp
COMPILE b974.cpp
COMPILE rw_alfa.cpp
COMPILE rw_arap.cpp
COMPILE rw_cdat.cpp
COMPILE rw_clab.cpp
COMPILE rw_cnst.cpp
COMPILE rw_corp.cpp
COMPILE rw_ctim.cpp
COMPILE rw_cuid.cpp
COMPILE rw_data.cpp
COMPILE rw_dlab.cpp
COMPILE rw_dom.cpp
COMPILE rw_envf.cpp
COMPILE rw_eqiv.cpp
COMPILE rw_infl.cpp
COMPILE rw_kats.cpp
COMPILE rw_lngh.cpp
COMPILE rw_mod.cpp
COMPILE rw_numr.cpp
COMPILE rw_orig.cpp
COMPILE rw_para.cpp
COMPILE rw_pict.cpp
COMPILE rw_proc.cpp
COMPILE rw_ptnm.cpp
COMPILE rw_scon.cpp
COMPILE rw_stak.cpp
COMPILE rw_stru.cpp
COMPILE rw_sync.cpp
COMPILE rw_urts.cpp
COMPILE rw_var.cpp
COMPILE op_default.cpp
COMPILE op_lix.cpp
COMPILE op_vv.cpp
COMPILE op_vvvv.cpp
COMPILE op_aaaaaa.cpp
COMPILE op_afbf_aaaaaa.cpp
COMPILE op_afbf_aaaaaa_bbbbbb.cpp
COMPILE op_afbf_aaaaaa_bbbbbb_cccccc.cpp
COMPILE assembler.cpp
COMPILE codegen.cpp
COMPILE field_length.cpp
COMPILE icm5.cpp
COMPILE line.cpp
COMPILE lister.cpp
COMPILE main.cpp
COMPILE memimage.cpp
COMPILE symbol.cpp
COMPILE symbol_table.cpp
COMPILE linker.cpp
COMPILE lmain.cpp
COMPILE main.cpp
COMPILE so.cpp
COMPILE to.cpp
COMPILE submit.cpp
COMPILE help.cpp
COMPILE spo.cpp
COMPILE quit.cpp
COMPILE rje.cpp
COMPILE main.cpp
$ file vsim
vsim: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=e863f72a2f645bf4c00a77935a1433e39967e7a7, not stripped

On 2023-08-31, Bart <bc@freeuk.com> wrote:
> On 31/08/2023 20:17, Kaz Kylheku wrote:
>> On 2023-08-31, Bart <bc@freeuk.com> wrote:
>>> On 31/08/2023 13:36, David Brown wrote:
>>>> So whatever your default here - whether it is generating the object file
>>>> in the same directory as the source file, or generating it in the
>>>> current directory - it will be convenient in some cases, and completely
>>>> wrong in other cases.
>>>
>>> But putting it in the current directory is sloppy. The current location
>>> can be arbitrary (or it might not be writeable):
>>>
>>> c:\random>gcc \proj1\foo.c
>>> c:\random>gcc \proj2\bar.c
>>>
>>> Here, both compilations generate a.exe. But to cap that, both end up in
>>> c:\random; the second overwrites the first, something you might be
>>> unaware of.
>>
>> Nobody cares about this in the world of building components from C.
>
> I guess that's because people using off-the-shelf tools are forced to do
> things the way the tools dictate. They don't have a choice!

That is false; the tools are quite flexible and will do things according
to someone else's preferences.

The tools won't do that by default; that would break them for everyone
who relies on them to behave in their default way.

> After a while they become inured enough to think that's the only way it
> can be.
>
>>
>> The build systems by and large operate from the assumption that
>> the current working directory is the top-level build directory.
>
> So, you have to build things in-situ.

No you don't; but it works well that way given how the system is
designed. Why swim against the tidee if there is no benefit.

> To build multiple projects, you
> have to navigate from folder to folder.

The biggest consumers of multipel projects are distros and distro
maintainers. GNU/Linux (and other) distros are certainly not built by
someone who manually navigates from folder to folder.

The distro build does that.

From the build person's point of view, that's one thing to run,
in one place.

> Whereas I can build all my language projects from one location, for example:
>
> c:\demo>mm \ax\aa
> Compiling \ax\aa.m------ to \ax\aa.exe

gcc does this for object files:

gcc path/to/foo.c -c

produces path/to/foo.o.

The default executable is a.out, or else whatever you pass to -o
is taken verbatim.

It's common for .o files to be together with the .c files,
but for the linked executable to be in the root directory
of the project.

However, the -c option isn't useful if we want to have
separate build and source directories, or separate object
directories for different architectures.

The default build recipe does the trick; you just set up
the dependencies correctly, e.g.

objs/x86_64/parser/scanner.o: src/parser/scanner.c

The recipe will compile src/parser/scanner.c and
use -o objs/x86_64/parser/scanner.o .

> c:\demo>mm \cx\cc
> Compiling \cx\cc.m------ to \cx\cc.exe
>
> c:\demo>mm \qx\qq
> Compiling \qx\qq.m------ to \qx\qq.exe
>
> c:\demo>mm \mx\mm
> Compiling \mx\mm.m------ to \mx\mm.exe

That's just your preference, it would be better to have cc.exe, qe.exe
and mm.exe right here in this directory instead of being buried in
subdirectories.

There are Makefiles that bury things that way; they are irksome.
Hey, make worked; where is the program??? Ah, in src/output,
whatever for ...

>> If you do
>>
>> $ make -f /path/to/project/build/Makefile
>>
>> it will not work.
>
> Why doesn't the tool just navigate to that path?

Well, because it's a file, and not a directory.

So the question is why doesn't it navigate to the path
/path/to/project/build and then run Makefile?

Because navigating to a directory is what the -C option does,
and only that option.

(If you don't like those conventions, you can write a mymake
script which recognizes your preferred conventions and then
generates an equivalent call to make.)

> And maybe, navigate
> back to the start point when it's done?

That's not necessary; when a child process does chdir(), the parent
is not affected. When you run a tool that changes directory, your
current directory is not affected.

I'm pretty sure Windows works that way too.

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

On 2023-08-31, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <87o7in7yqm.fsf@nosuchdomain.example.com>,
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> ...
>>I acknowledge that you prefer tools to be verbose, and that you have
>>perfectly valid reasons to want a compiler to show what it's doing and
>>for a file copying program to print the name of each file as it's
>>copying it.
>>
>>Please acknowledge that others have valid preferences that differ from
>>yours. I'm not even asking you to understand why, or to like it, just
>>that different valid preferences exist.
>
> Yes, but...
>
> The problem with this form of argumentation is that it fails to acknowledge
> the difference between actual constructive belief and mere defense of the
> status quo.
>
> I.e., one often (and by "often", I mean almost universally) gets the
> impression that people who criticize posters like "Bart" aren't doing so
> out of a genuine belief that they are right and Bart is wrong, but rather

I genuinely believe that I'm right when I say that

1. The environment is infinitely flexible; you can shape it to work
how you want.

2. There is no unanimous agreement that its default behaviors and conventions
are the "correct" ones.

3. Talk about how default behaviors and conventions should be otherwise
is largely unproductive. Refere to (1).

> out of general fear of change (i;e., the fear of the cognitive dissonance
> that acceptance of Bart's ideas would cause them).

Not really. In the world of C an Unix, there are enough loonies that
over the years you end up working with a large number of different
preferences for this and that.

Most people who have weird or alternative preferences just code them up
into their build system instead of complaining that Their Way isn't the
default one imposed on everyone else, so that everyone else should
customize, rather than they.

Bart could easily do the same: make Unix and Linux suit his preferences
by writing scripts that work with his conventions and translate that to
suitable invocations of the tools.

If you want "gcc foo/bar.c" o produce a program "foo/bar", you
can just have a wrapper. Etc.

Now, of course, setting up your own environment how you like doesn't fix
other people's projects that you're trying to build.

Building other people's projects can suck. It sucks not just for
Bart but for the rest of us who don't mind the defaults and conventions.

FOSS projects are written by volunteers. They don't owe you anything,
including a build system that works how you would like.

It's sad that people do counterproductive things to their programs, like
vandalize their build systems with Autoconf, just because that's what
others have done and they read about it in some blog or tutorial.

Most FOSS maintainers don't read this newsgroup so you literally
don't achive a thing by complaining here about how FOSS projects
are hard bo build.

If you think that some FOSS program is really useful to you and
you regularly engage its build system, which sucks, you can contribute
a better one. Better to ask first whether they would be interested,
before wasting your time.

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

Bart <bc@freeuk.com> writes:
> On 31/08/2023 23:07, Scott Lurndal wrote:
[...]
>> If it doesn't say anything, it worked. If it doesn't work it will
>> say something. If your really want to know what it's doing, use
>> -v.
>
> <Literally both face palms on face>
>
> If it doesn't say anything, it worked? Since Windows 10, a crashing
> program doesn't say anything; it silently fails.
[...]

If gcc fails, it returns a status that indicates failure. If you're
using a Bourne-like shell, you can examine the value of $?. In a
Windows command shell, `echo %errorlevel%`. In PowerShell, $? is True
or False, and $LASTEXITCODE is the status value.

I've configured bash to show me any non-zero exit value after running a
command. I don't know whether you can do that on Windows.

--
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 01/09/2023 00:46, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 31/08/2023 23:07, Scott Lurndal wrote:
> [...]
>>> If it doesn't say anything, it worked. If it doesn't work it will
>>> say something. If your really want to know what it's doing, use
>>> -v.
>>
>> <Literally both face palms on face>
>>
>> If it doesn't say anything, it worked? Since Windows 10, a crashing
>> program doesn't say anything; it silently fails.
> [...]
>
> If gcc fails, it returns a status that indicates failure. If you're
> using a Bourne-like shell, you can examine the value of $?. In a
> Windows command shell, `echo %errorlevel%`. In PowerShell, $? is True
> or False, and $LASTEXITCODE is the status value.
>
> I've configured bash to show me any non-zero exit value after running a
> command. I don't know whether you can do that on Windows.
>

You're sort of missing the point. Is it really that hard to do:

puts("Compilation failed");
exit(1);

rather than:

exit(1);

Are you so averse to 'verbosity' then a one-line message reporting a
failure cannot be tolerated?

I find it bizarre that you like your programs so silent that you need to
employ external means to find if they ran successfully or not!

I think the most output I've had from a compiler was nearly 30,000 lines
of warnings and notes. But no errors; it had produced a working
executable. However that was not obvious.

So despite being so verbose (pointlessly so, since WTH am I supposed to
do with all that output) I still wasn't sure whether it had worked.

I guess, yet another wrapper needed to take care of yet another task
that is the compiler's job? I might as well write my own compiler! (Oh,
wait...)

On Friday, September 1, 2023 at 8:44:20 AM UTC+8, Bart wrote:

> You're sort of missing the point. Is it really that hard to do:
>
> puts("Compilation failed");
> exit(1);

That is already being done - an error message is printed
when there is an error.

What is not being done is:

puts("Compilation succeeded");
exit(0);

So on Windows - if there was a crash - not a deliberate
exit - you don't know if it was successful or not.

But if Windows had the ability to display "crashed", the
same as that Unix option, you would know.

I personally run everything under "pdmake" and any non-zero
exit code - or Windows crash - causes pdmake to complain and
terminate.

BFN. Paul.

P.S. I have replied to your email - please check your spam folder if
you didn't receive it, or return the conversation to here if we are
having communication issues.

On 8/31/2023 6:09 PM, Paul Edwards wrote:
> On Friday, September 1, 2023 at 8:44:20 AM UTC+8, Bart wrote:
>
>> You're sort of missing the point. Is it really that hard to do:
>>
>> puts("Compilation failed");
>> exit(1);
>
> That is already being done - an error message is printed
> when there is an error.
>
> What is not being done is:
>
> puts("Compilation succeeded");
> exit(0);
>
> So on Windows - if there was a crash - not a deliberate
> exit - you don't know if it was successful or not.

You mean blue screen?

>
> But if Windows had the ability to display "crashed", the
> same as that Unix option, you would know.
>
> I personally run everything under "pdmake" and any non-zero
> exit code - or Windows crash - causes pdmake to complain and
> terminate.
>
> BFN. Paul.
>
>
> P.S. I have replied to your email - please check your spam folder if
> you didn't receive it, or return the conversation to here if we are
> having communication issues.

On Friday, September 1, 2023 at 9:11:15 AM UTC+8, Chris M. Thomasson wrote:
> On 8/31/2023 6:09 PM, Paul Edwards wrote:
> > On Friday, September 1, 2023 at 8:44:20 AM UTC+8, Bart wrote:
> >
> >> You're sort of missing the point. Is it really that hard to do:
> >>
> >> puts("Compilation failed");
> >> exit(1);
> >
> > That is already being done - an error message is printed
> > when there is an error.
> >
> > What is not being done is:
> >
> > puts("Compilation succeeded");
> > exit(0);
> >
> > So on Windows - if there was a crash - not a deliberate
> > exit - you don't know if it was successful or not.
> You mean blue screen?

Real life example on Windows 10:

printf("before\n");
ggg = hashtab->max_load_factor * hashtab->size;
printf("after\n");

C:\devel\pdos\pdmake>pdmake --help
before

C:\devel\pdos\pdmake>

Did my program work?

Looks fine to me. No error message.

BFN. Paul.

On 01/09/2023 00:12, Kaz Kylheku wrote:
> On 2023-08-31, Bart <bc@freeuk.com> wrote:

> The tools won't do that by default; that would break them for everyone
> who relies on them to behave in their default way.

That's tool1.exe
>> Whereas I can build all my language projects from one location, for example:
>>
>> c:\demo>mm \ax\aa
>> Compiling \ax\aa.m------ to \ax\aa.exe
>
> gcc does this for object files:
>
> gcc path/to/foo.c -c
>
> produces path/to/foo.o.

Not on my machine. This is why I raised the issue.

Using gcc -c, the .o file is always placed in the "." path, irrespective
of the path prepended to the input filename.

That's how it behaves on Windows and under WSL.

>> c:\demo>mm \cx\cc
>> Compiling \cx\cc.m------ to \cx\cc.exe
>>
>> c:\demo>mm \qx\qq
>> Compiling \qx\qq.m------ to \qx\qq.exe
>>
>> c:\demo>mm \mx\mm
>> Compiling \mx\mm.m------ to \mx\mm.exe
>
> That's just your preference, it would be better to have cc.exe, qe.exe
> and mm.exe right here in this directory instead of being buried in
> subdirectories.

(My normal process is to build within the development directory, and use
a script to move a production executable to where it normally lives.

The behaviour that you describe could result in multiple mm.exe files in
assorted locations, which is undesirable.

Because I mostly work on compilers, I may be testing this new compiler
on one within a different set of folders. I don't want the executables
from that one to contaminate any here, even if they have different names.)

> There are Makefiles that bury things that way; they are irksome.
> Hey, make worked; where is the program??? Ah, in src/output,
> whatever for ...

Oh, if only there was a way for the compiler to just tell you where it's
going to put the output!

>> And maybe, navigate
>> back to the start point when it's done?
>
> That's not necessary;

It might be if you decided to run the command again. But with a
different start location, who knows what might happen?

when a child process does chdir(), the parent
> is not affected. When you run a tool that changes directory, your
> current directory is not affected.
>
> I'm pretty sure Windows works that way too.

I find it hard to change the CWD programmatically, at least
persistently. But these are scripts where you can issue actual CD commands.

On 2023-09-01, Bart <bc@freeuk.com> wrote:
> Are you so averse to 'verbosity' then a one-line message reporting a
> failure cannot be tolerated?

I don't know about Keith, but I don't want to see "compilation failed",
bcause I want to see something else.

I want to see specific diagnostics, pinpointed to locations in the
file.

If there is nothing to diagnose, then the compilation should be
successful.

If there is something to diagnose, the failed message is redundant.
If all the diagnostics are warning: then we have success; if any
of them are error: then not.

What is your repro test case for a quiet gcc run that has failed?
(I missed it).

What I don't want is diagnostics on *success*:

C:\> copy hello.txt con
Hello
1 file(s) copied

Yikes. I said copy the content sof hello.txt to con, and it copied
that plus something else I didn't ask for.

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

On 2023-09-01, Paul Edwards <mutazilah@gmail.com> wrote:
> Real life example on Windows 10:
>
> printf("before\n");
> ggg = hashtab->max_load_factor * hashtab->size;
> printf("after\n");
>
> C:\devel\pdos\pdmake>pdmake --help
> before
>
> C:\devel\pdos\pdmake>
>
>
> Did my program work?
>
> Looks fine to me. No error message.

That's a garbage OS / shell problem.

A reasonable job control language must inform you if a job
terminateed abnormally ("abended" in old graybeard language).

You should never have to put in inane chatter into programs
just to confirm that they worked.

It's better to fix that in one place (the command interpreter)
rather than in millions of programs.

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

On 01/09/2023 02:09, Paul Edwards wrote:
> On Friday, September 1, 2023 at 8:44:20 AM UTC+8, Bart wrote:
>
>> You're sort of missing the point. Is it really that hard to do:
>>
>> puts("Compilation failed");
>> exit(1);
>
> That is already being done - an error message is printed
> when there is an error.
>
> What is not being done is:
>
> puts("Compilation succeeded");
> exit(0);
>
> So on Windows - if there was a crash - not a deliberate
> exit - you don't know if it was successful or not.

Where this is an issue: I can't tell whether a program has failed or
passed, I will put in such a message.

On my compilers, on a 20-year-old one it says:

Compilation Complete

On recent ones, a terminating message is not shown (or it is subtle,
like adding a full-stop when done, or it needs -v).

Because they usually finish instantly, I can tell if there has been a
crash because it takes a second or so to terminate.

> But if Windows had the ability to display "crashed", the
> same as that Unix option, you would know.

It used to say that; I've no idea why it doesn't do so now.

>
> P.S. I have replied to your email - please check your spam folder if
> you didn't receive it, or return the conversation to here if we are
> having communication issues.

OK.

Bart <bc@freeuk.com> writes:
> On 01/09/2023 00:46, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 31/08/2023 23:07, Scott Lurndal wrote:
>> [...]
>>>> If it doesn't say anything, it worked. If it doesn't work it will
>>>> say something. If your really want to know what it's doing, use
>>>> -v.
>>>
>>> <Literally both face palms on face>
>>>
>>> If it doesn't say anything, it worked? Since Windows 10, a crashing
>>> program doesn't say anything; it silently fails.
>> [...]
>> If gcc fails, it returns a status that indicates failure. If you're
>> using a Bourne-like shell, you can examine the value of $?. In a
>> Windows command shell, `echo %errorlevel%`. In PowerShell, $? is True
>> or False, and $LASTEXITCODE is the status value.
>> I've configured bash to show me any non-zero exit value after
>> running a
>> command. I don't know whether you can do that on Windows.
>
> You're sort of missing the point.

No, I'm making a different point. I was *explaining* to you how gcc
behaves.

I don't think I've ever seen you learn something and be happy about it.
I find that bizarre.

> Is it really that hard to do:
>
> puts("Compilation failed");
> exit(1);
>
> rather than:
>
> exit(1);

No, of course it's not hard to do. gcc doesn't do that, but for
reasons that have nothing to do with any difficulty of implementing it.
And you're angry at me for not being angry about it.

I won't cause you further pain by trying to explain the reasons.

> Are you so averse to 'verbosity' then a one-line message reporting a
> failure cannot be tolerated?

No.

In another message in this thread, I wrote:

I acknowledge that you prefer tools to be verbose, and that you have
perfectly valid reasons to want a compiler to show what it's doing
and for a file copying program to print the name of each file as
it's copying it.

I believe you are capable of understanding that. You choose to pretend
that you don't.

> I find it bizarre that you like your programs so silent that you need
> to employ external means to find if they ran successfully or not!

I'm sure you do.

[...]

--
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 */

Kaz Kylheku <864-117-4973@kylheku.com> writes:
[...]
> gcc does this for object files:
>
> gcc path/to/foo.c -c
>
> produces path/to/foo.o.
>
> The default executable is a.out, or else whatever you pass to -o
> is taken verbatim.

Can you double check that? Here's what I get on my system
(Ubuntu 22.04.3, gcc 11.4.0).

$ find . -type f
../path/to/foo.c
$ gcc path/to/foo.c -c
$ find . -type f
../path/to/foo.c
../foo.o
$

--
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 Friday, 1 September 2023 at 00:32:03 UTC+1, Kaz Kylheku wrote:
>
> Building other people's projects can suck. It sucks not just for
> Bart but for the rest of us who don't mind the defaults and conventions.
>
> FOSS projects are written by volunteers. They don't owe you anything,
> including a build system that works how you would like.
>
> It's sad that people do counterproductive things to their programs, like
> vandalize their build systems with Autoconf, just because that's what
> others have done and they read about it in some blog or tutorial.
>
Bart's basic complaint is right. It's too hard to build many projects, and
if the build system breaks, it's too hard to fix it. Or the build requires
an unacceptable installation of dependencies into your global workspace.

Generally big projects are OK. They are well maintained, and when people
complain of glitches in the build system, they are ironed out. But small
projects are very likely to have build issues.

On Thursday, August 31, 2023 at 10:43:25 PM UTC+8, Paul Edwards wrote:
> On Thursday, August 31, 2023 at 9:45:14 PM UTC+8, Bart wrote:
>
> > I realise the code generator on BCC is poor, and is buggy, which is why
> > I kept it as a private tool. (/My/ C code is very conservative; there it
> > works fine!)

> Ok, thanks. I'll see if I can rework the C code to be conservative.

It took a while, but I was successful:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdcc/cpplib/directs.c

/* cc64 goes haywire when this is a const - it treats the array as
a character array, so indexing goes up by 1 character instead of
element size. And sizeof returns the padded size, but the data
is stored without padding, which made diagnosing very difficult */
#ifdef __CC64__
#define const
#endif

static const directive directives[] = {
DIRECTIVE_TABLE
};

#ifdef __CC64__
#undef const
#endif

(note that this problem is unrelated to the problem I sent via
email - as far as I am aware, anyway).

BFN. Paul.

On 01/09/2023 00:09, Scott Lurndal wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> I can confirm that I've started an overhaul of the project, which will
>>> have a working title of 'DD' to distinguish it from 'CC'. The first
>>> stage is to get it to generate a new intermediate (IL) code (perhaps
>>> within a week).
>>
>> There's a common Unix file conversion tool called "dd". Do whatever you
>> like with that information.
>
> For consistency, since 'cc' stands for 'C Compiler', he should
> use 'dc', for 'D Compiler'. But that conflicts with the standard
> 'desktop RPN calculator' application, dc.
>

And there is also an existing language called D. (I don't know if there
is a standard name for a D compiler.)

"bc" is also taken, otherwise that might have been a good choice.

On 31/08/2023 21:26, Bart wrote:
> On 31/08/2023 18:36, David Brown wrote:
>> On 31/08/2023 16:30, Bart wrote:
>>> On 31/08/2023 13:36, David Brow
>
>>> But putting it in the current directory is sloppy. The current
>>> location can be arbitrary (or it might not be writeable):
>>>
>>>   c:\random>gcc \proj1\foo.c
>>>   c:\random>gcc \proj2\bar.c
>>>
>>
>> So don't do that.
>>
>> Make sure you are in the appropriate directory, then compile - or give
>> the output file name directly.  As I said, whatever default you use,
>> it will be wrong sometimes.
>
> But it's an extra thing that could be easily have been done right.
> Compilers work for us, not us for them.

Agreed.

A compiler that put its object files in the source directory would be
working against me, not for me.

Can you really not understand that people don't always agree with your
subjective opinions? Different people want different things. The
defaults you pick for your tool written by you and for you, are
(hopefully) going to work well for /you/. But that doesn't mean they
are of any use to anyone else.

Personally, I think it might be better to have fewer defaults at all for
this kind of thing. I'd be quite happy for a compiler to require an
explicit output file for compilation or linking (if it also handles
linking). Maybe when compiling, it would accept just an output
directory and have a default object file name. If there are no
defaults, there are no misunderstandings. (For the record, there are
lots of things that gcc has defaults for that I would prefer to be
explicit.)

>
> Suppose gcc decided to put the output files in a root directory, or some
> place where it would be a very bad idea to write or overwrite a file.
>

Suppose bcc had decided to put the output files in "c:\Program
Files\bcc\" ? Or better - suppose we /don't/ try to think about worse
choices that no tool has made?

> You can't just fob people off with 'So don't do that'; it needs to be
> fixed. But then neither can you further fob them off with: 'It's always
> done that, and further, one person in 1000, or some makefile from 1974,
> depends on it, so we can't change it, ever'.
>

Putting object files in the current directory is a useful default. It
won't suit everyone, but it will suit some people. And since almost
anyone who has an "everything in one directory" structure will be in
that directory when they run their compiler (or make, or whatever), it
would give the same effect as your compiler's default choice.

I really don't understand what you have against it - other than your
knee-jerk reaction of "gcc does it, therefore it must be terrible and I
must invent absurd situations to justify myself".

>
>>> Here, both compilations generate a.exe. But to cap that, both end up
>>> in c:\random; the second overwrites the first, something you might be
>>> unaware of.
>>
>> If you are not aware of that, you'll learn pretty quickly!
>
> It may not have crossed your mind, or if it had, your might assume that
> two distinct a.exe files were produced.
>

True. And you'll learn very quickly.

>>>
>>> If I do:
>>>
>>>   c:\random[gcc \proj1\foo.c
>>>   c:\random>gcc \proj2\bar.c
>>>
>>> then there are three differences from gcc:
>>>
>>>   (1) The executables are called foo.exe and bar.exe respectively
>>>   (2) They are written to their respective folders
>>>   (3) The compiler will report exactly what it is doing so there
>>>       are fewer surprises:
>>>
>>>       Compiling \proj1\foo.c to \proj2\foo.exe
>>>
>>> You can use -v with gcc, but it is not helpful!
>>
>> Nor is it helpful for the compiler to tell me what it is doing -
>
> If the compiler is doing multiple files, especially a slow compiler,
> then it is highly useful to know where it's up to, or what it's stuck on.

That is not my experience. And I thought the point of your compiler was
to be absurdly fast? Still, I've nothing against compilers giving such
messages - I just personally prefer not to see them, so I at least want
a way to hide them (without hiding useful messages). I have happily
used compilers with a "-quiet" flag in the makefile.

>
> But this seems to be a Linux thing: if I do 'cp *.c dest', then nothing
> is output, until you get the prompt back. So, did work, did it copy
> anything, was it one big file, or lots of small ones?

It certainly is a common Unix practice that you get told when things
failed, and sometimes when things worked, but rarely get told that the
program is about to do what you asked it to do. And in cases where more
information is useful, you use "-v".

So you can assume "cp *.c dest" worked - it did what you asked it to do.
You did not ask how many files there were, or how big they are - there
are other commands to do that.

Unix philosophy (which is not always followed) is for one program to do
one thing. "cp" copies files - if you want a listing of files, use "ls".

Windows philosophy (which is also not always followed) is for every
program to re-invent the wheel in a different way and do all sorts of
things, because there are no common practices, few common libraries, and
most stuff is closed source.

>
> If I do 'copy *.c test' on Windows, it shows each file copied, and it
> tells how many files were copied in all. The 'cp' command needs '-v' to
> force to show what it's doing.
>
> The defaults are backwards.

Then add "alias cp='cp -v'" to your .bashrc. Choice is a wonderful
thing. (And so is google, so that you don't need to remember the
details here.)

>
>> generally I know what it is doing - it is doing what I told it to do.
>> It is only if it can't do that (due to some error) that I want to be
>> told.
>>
>> Again, different defaults suit different uses and different people.
>> Plenty of gcc's defaults are inappropriate for me, and I think should
>> be different - but your compiler's defaults are no better.  You only
>> /think/ that your compiler's defaults are good, because they suit you
>> personally
>
> No, they make more sense for casual use from a command line for anybody.

I'm sorry, but you are simply wrong here - in /my/ opinion. Your
opinion is your own, but you do not speak for anyone but yourself.

>
>> Do you also have a "-quiet" option to hide non-essential messages?
>> That's also something I like in compilers and other tools, if it is
>> not the default - though again, preferences vary.
>
> Yes, I think it's -q. If a lot of files are being processed, then you
> might want to turn it off (or if timing, it can make a small difference).
>

Good. If I were using your compiler, I would add that to my makefile -
giving me the options I want rather than the defaults you like.

> However gcc's -v option generates 40 times as much output as my compiler
> without -q. So it's either far too verbose, or not enough.
>

I still don't see why a compiler should print out a line to say it is
compiling the file you asked it to compile. If I want that information,
I have it in the command I typed in. (Or I would have my makefile show
the command before it is run.)

As for "gcc -v" being verbose - yes, it certainly is. It's not
something I have often used. It provides a lot of information that can
vary between systems, which is occasionally useful to know about. (I
have, for example, used it to see the include search paths used in
embedded gcc toolchains.)

On 01/09/2023 00:18, Bart wrote:
> On 31/08/2023 23:07, Scott Lurndal wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 31/08/2023 18:36, David Brown wrote:
>>>
>>>> Nor is it helpful for the compiler to tell me what it is doing -
>>>
>>> If the compiler is doing multiple files, especially a slow compiler,
>>> then it is highly useful to know where it's up to, or what it's stuck
>>> on.
>>
>> $ ps -ef | grep gcc
>>
>>>
>>> But this seems to be a Linux thing: if I do 'cp *.c dest', then nothing
>>> is output, until you get the prompt back. So, did work, did it copy
>>> anything, was it one big file, or lots of small ones?
>>
>> If it doesn't say anything, it worked.  If it doesn't work it will
>> say something.   If your really want to know what it's doing, use
>> -v.
>
>
> <Literally both face palms on face>
>
> If it doesn't say anything, it worked?

Yes.

> Since Windows 10, a crashing
> program doesn't say anything; it silently fails.

A decent OS will tell you if something has crashed.

>
> And when there is a lot going on with gcc, you can get loads of warnings
> and other crap scrolling up the screen. So, was there an "error:" in
> there or not? I've no idea if it worked!

Fix the problems in your source code (or choice of flags to the
compiler) - if you are getting screenfuls of errors or warnings, it is
irrelevant whether an output file was generated or not.

I certainly fail to see how the situation would be improved by a message
at the start saying "Compiling hello.c to hello.o" !

When you have lots of errors or warnings like this, some suggestions are:

1. Use a terminal that lets you scroll back to the start. Try something
other than Window's amateur terminal - or at least, change the default
settings from tiny scroll buffer to something useful.

2. Pipe the output into "less" (or "more", if you are limited to
Window's own tools).

3. Use an editor or IDE from this century - then all your errors or
warnings will be shown in your source code, so that you go straight to
the problems.

4. Use "-fmax-errors=5" to stop after the first 5 errors, or
"-Wfatal-errors" to halt on any problems, or "-Werror" to make warnings
into errors (combine with "-fmax-errors="). These are all documented,
unsurprisingly, under "Options to Request or Suppress Warnings".

>
> I have to see if there is a recent .exe just created.
>
> Or sometimes I get a clue by there being a pause after the last message,
> meaning it's doing the rest of it.
>
> (Or maybe it's just crashed.)

You'll get a message if there is a crash.

>
> Or I have to supply options to tell it to stop after one error (I have
> to find it first).

See above. Or try google - it tends to be far more efficient than
whining and moaning.

>
> Or I have to capture the output twice (first with >, second after I've
> remembered it's 2>), so that I can use a text editor to search for
> "error:" strings.
>
> What an effing palaver.

What do you expect to get if you have lots of errors in your code? A
pat on the back and a Blue Peter badge?

>
> gcc is not the only program like that, but it seems typical of where it
> came from.
>
>
>>> The defaults are backwards.
>>
>> No.
>
> Delude yourself if you like.
>

I bet you were in the army cadets when you were a kid, and your mum
would watch the parade and tell people how everyone else is out of step
except for her little Bart. Is that why you refuse to acknowledge other
people think differently from you?