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