Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #136342 > unrolled thread
| Started by | Bart <bc@freeuk.com> |
|---|---|
| First post | 2018-10-06 15:13 +0100 |
| Last post | 2018-10-11 23:18 -0700 |
| Articles | 20 on this page of 147 — 22 participants |
Back to article view | Back to comp.lang.c
software disenchantment Bart <bc@freeuk.com> - 2018-10-06 15:13 +0100
Re: software disenchantment David Kleinecke <dkleinecke@gmail.com> - 2018-10-06 09:54 -0700
Re: software disenchantment Thiago Adams <thiago.adams@gmail.com> - 2018-10-06 10:26 -0700
Re: software disenchantment fir <profesor.fir@gmail.com> - 2018-10-14 04:26 -0700
Re: software disenchantment antispam@math.uni.wroc.pl - 2018-10-09 18:20 +0000
Re: software disenchantment David Kleinecke <dkleinecke@gmail.com> - 2018-10-09 11:54 -0700
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-09 21:22 +0100
Re: software disenchantment David Kleinecke <dkleinecke@gmail.com> - 2018-10-09 17:47 -0700
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-10 11:28 +0100
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-10 11:38 +0100
Re: software disenchantment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-10 05:49 -0700
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-10 15:47 +0200
Re: software disenchantment "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-10 09:58 -0400
Re: software disenchantment scott@slp53.sl.home (Scott Lurndal) - 2018-10-10 14:39 +0000
Re: software disenchantment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-10 09:42 -0700
Re: software disenchantment "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-10 13:18 -0400
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-10 20:31 +0100
Re: software disenchantment BGB <cr88192@hotmail.com> - 2018-10-10 17:53 -0500
Re: software disenchantment Wouter Verhelst <w@uter.be> - 2018-10-11 10:06 +0200
Re: software disenchantment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-11 02:34 -0700
Re: software disenchantment Wouter Verhelst <w@uter.be> - 2018-10-11 12:03 +0200
Re: software disenchantment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-11 03:59 -0700
Re: software disenchantment Wouter Verhelst <w@uter.be> - 2018-10-11 16:56 +0200
Re: software disenchantment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-11 09:02 -0700
Re: software disenchantment Wouter Verhelst <w@uter.be> - 2018-10-11 19:39 +0200
Re: software disenchantment Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-10-15 19:53 +0000
Re: software disenchantment BGB <cr88192@hotmail.com> - 2018-10-16 03:54 -0500
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-11 20:25 +0200
Re: software disenchantment scott@slp53.sl.home (Scott Lurndal) - 2018-10-11 13:16 +0000
Re: software disenchantment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-11 07:15 -0700
Re: software disenchantment Wouter Verhelst <w@uter.be> - 2018-10-11 17:05 +0200
Re: software disenchantment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-11 09:15 -0700
Re: software disenchantment scott@slp53.sl.home (Scott Lurndal) - 2018-10-11 17:33 +0000
Re: software disenchantment Wouter Verhelst <w@uter.be> - 2018-10-11 19:53 +0200
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-11 17:59 +0100
Re: software disenchantment nobody@example.org (Scott) - 2018-10-10 16:53 +0000
Re: software disenchantment BGB <cr88192@hotmail.com> - 2018-10-10 12:45 -0500
Re: software disenchantment Thiago Adams <thiago.adams@gmail.com> - 2018-10-10 11:04 -0700
Re: software disenchantment BGB <cr88192@hotmail.com> - 2018-10-10 14:22 -0500
Re: software disenchantment "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-10 15:53 -0400
Re: software disenchantment Ian Collins <ian-news@hotmail.com> - 2018-10-11 09:06 +1300
Re: software disenchantment "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-10 13:21 -0700
Re: software disenchantment scott@slp53.sl.home (Scott Lurndal) - 2018-10-10 20:27 +0000
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-10 22:54 +0100
Re: software disenchantment Ian Collins <ian-news@hotmail.com> - 2018-10-11 11:01 +1300
Re: software disenchantment Ian Collins <ian-news@hotmail.com> - 2018-10-11 11:05 +1300
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-10 23:16 +0100
Re: software disenchantment Ian Collins <ian-news@hotmail.com> - 2018-10-11 11:22 +1300
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-10 23:28 +0100
Re: software disenchantment Ian Collins <ian-news@hotmail.com> - 2018-10-11 11:33 +1300
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-11 11:37 +0200
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-11 11:50 +0100
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-11 14:10 +0200
Re: software disenchantment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-11 05:24 -0700
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-11 15:12 +0200
Re: software disenchantment scott@slp53.sl.home (Scott Lurndal) - 2018-10-11 13:13 +0000
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-11 14:44 +0100
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-11 16:38 +0200
Re: software disenchantment mark.bluemel@gmail.com - 2018-10-11 08:09 -0700
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-11 17:43 +0100
Re: software disenchantment scott@slp53.sl.home (Scott Lurndal) - 2018-10-11 17:36 +0000
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-11 18:56 +0100
Re: software disenchantment Keith Thompson <kst-u@mib.org> - 2018-10-11 11:54 -0700
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-11 20:09 +0100
Re: software disenchantment scott@slp53.sl.home (Scott Lurndal) - 2018-10-12 13:10 +0000
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-13 12:57 +0200
Re: software disenchantment BGB <cr88192@hotmail.com> - 2018-10-11 14:27 -0500
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-11 22:03 +0200
Re: software disenchantment BGB <cr88192@hotmail.com> - 2018-10-11 15:56 -0500
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-12 11:30 +0200
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-11 23:34 +0100
Re: software disenchantment Keith Thompson <kst-u@mib.org> - 2018-10-11 16:24 -0700
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-12 01:46 +0100
Re: software disenchantment Keith Thompson <kst-u@mib.org> - 2018-10-11 18:58 -0700
Re: software disenchantment Wouter Verhelst <w@uter.be> - 2018-10-12 08:50 +0200
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-12 11:12 +0100
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-12 12:55 +0200
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-12 12:10 +0100
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-12 13:29 +0200
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-12 13:06 +0100
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-12 14:30 +0200
Re: software disenchantment James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-10-12 08:53 -0400
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-12 15:11 +0200
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-12 13:55 +0100
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-12 15:13 +0200
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-12 16:10 +0100
Re: software disenchantment scott@slp53.sl.home (Scott Lurndal) - 2018-10-12 15:22 +0000
Re: software disenchantment Keith Thompson <kst-u@mib.org> - 2018-10-12 09:12 -0700
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-13 13:00 +0200
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-13 12:52 +0100
Re: software disenchantment Ian Collins <ian-news@hotmail.com> - 2018-10-14 08:44 +1300
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-13 21:03 +0100
Re: software disenchantment Ian Collins <ian-news@hotmail.com> - 2018-10-14 10:13 +1300
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-13 23:02 +0100
Re: software disenchantment Keith Thompson <kst-u@mib.org> - 2018-10-13 16:47 -0700
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-14 01:05 +0100
Re: software disenchantment David Kleinecke <dkleinecke@gmail.com> - 2018-10-13 18:12 -0700
Re: software disenchantment Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-14 03:05 +0100
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-14 20:14 +0200
Re: software disenchantment Thiago Adams <thiago.adams@gmail.com> - 2018-10-14 11:25 -0700
Re: software disenchantment scott@slp53.sl.home (Scott Lurndal) - 2018-10-12 13:17 +0000
Re: software disenchantment scott@slp53.sl.home (Scott Lurndal) - 2018-10-12 13:16 +0000
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-12 14:36 +0100
Re: software disenchantment scott@slp53.sl.home (Scott Lurndal) - 2018-10-12 14:25 +0000
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-12 15:55 +0100
Re: software disenchantment scott@slp53.sl.home (Scott Lurndal) - 2018-10-12 15:22 +0000
Re: software disenchantment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-12 08:26 -0700
Re: software disenchantment scott@slp53.sl.home (Scott Lurndal) - 2018-10-12 15:51 +0000
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-13 13:06 +0200
Re: software disenchantment Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-10-15 19:30 +0000
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-12 12:39 +0200
Re: software disenchantment Wouter Verhelst <w@uter.be> - 2018-10-12 08:44 +0200
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-12 13:01 +0200
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-11 20:41 +0200
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-11 20:02 +0100
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-11 22:13 +0200
Re: software disenchantment BGB <cr88192@hotmail.com> - 2018-10-11 13:03 -0500
Re: software disenchantment "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-11 11:33 -0700
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-11 21:04 +0200
Re: software disenchantment BGB <cr88192@hotmail.com> - 2018-10-11 20:15 -0500
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-12 13:17 +0200
Re: software disenchantment scott@slp53.sl.home (Scott Lurndal) - 2018-10-11 13:10 +0000
Re: software disenchantment BGB <cr88192@hotmail.com> - 2018-10-10 19:22 -0500
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-11 10:58 +0200
Re: software disenchantment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-11 02:37 -0700
Re: software disenchantment Wouter Verhelst <w@uter.be> - 2018-10-11 12:06 +0200
Re: software disenchantment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-11 04:00 -0700
Re: software disenchantment Cecil Bayona <cbayona@cbayona.com> - 2018-10-11 13:03 -0500
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-11 19:36 +0100
Re: software disenchantment Cecil Bayona <cbayona@cbayona.com> - 2018-10-11 15:37 -0500
Re: software disenchantment Thiago Adams <thiago.adams@gmail.com> - 2018-10-10 14:01 -0700
Re: software disenchantment Ian Collins <ian-news@hotmail.com> - 2018-10-11 09:02 +1300
Re: software disenchantment Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-10-10 19:11 +0000
Re: software disenchantment David Kleinecke <dkleinecke@gmail.com> - 2018-10-10 13:08 -0700
Re: software disenchantment Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-10-11 14:52 +0000
Re: software disenchantment scott@slp53.sl.home (Scott Lurndal) - 2018-10-11 14:58 +0000
Re: software disenchantment Wouter Verhelst <w@uter.be> - 2018-10-11 17:19 +0200
Re: software disenchantment Dan Purgert <dan@djph.net> - 2018-10-12 09:49 +0000
Re: software disenchantment Wouter Verhelst <w@uter.be> - 2018-10-13 09:30 +0200
Re: software disenchantment Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-10-15 08:53 +0000
Re: software disenchantment Dan Purgert <dan@djph.net> - 2018-10-15 09:44 +0000
Re: software disenchantment Jens Stuckelberger <Jens_Stuckelberger@nowhere.net> - 2018-10-10 13:36 +0000
Re: software disenchantment "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-10-10 13:51 -0700
Re: software disenchantment nobody@example.org (Scott) - 2018-10-11 01:53 +0000
Re: software disenchantment Dan Purgert <dan@djph.net> - 2018-10-11 10:20 +0000
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-11 12:53 +0100
Re: software disenchantment "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-10-11 23:18 -0700
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-10-11 17:36 +0000 |
| Message-ID | <8SLvD.288744$Ac3.256427@fx45.iad> |
| In reply to | #136662 |
Bart <bc@freeuk.com> writes: >On 11/10/2018 15:38, David Brown wrote: >BTW how does 'make' know which project to build, if there are several >possibilities? You know, there's a shipload of documentation and examples for 'make' on the internet. Spend some time learning to use it before you criticise it. $ make <target-name> A properly built make system will also allow $ make subdir/sourcefile.o to build a single file in subdir.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-11 18:56 +0100 |
| Message-ID | <k9MvD.91151$NK5.18304@fx02.am4> |
| In reply to | #136667 |
On 11/10/2018 18:36, Scott Lurndal wrote: > Bart <bc@freeuk.com> writes: >> On 11/10/2018 15:38, David Brown wrote: > >> BTW how does 'make' know which project to build, if there are several >> possibilities? > > You know, there's a shipload of documentation and examples for 'make' > on the internet. Spend some time learning to use it before you > criticise it. How am I criticising it here? It just seems odd that every single source file you submit to a /C/ compiler [except mine, naturally], needs the .c extension otherwise it hasn't got a clue what you had in mind. Yet with 'make', you don't even need to bother with the filename. > $ make <target-name> > > A properly built make system will also allow > > $ make subdir/sourcefile.o > > to build a single file in subdir. It's OK, I'm not going to use it. It's one of these programs that's never going to work for me. I recently upgraded to gcc 8.1.0 on Windows and for a change, everything was included: standard headers, linker, libraries etc. But there is no program called 'make', unless it's the 3.7MB executable called 'gnatmake.exe'. (Which, BTW, if I type 'gnatmake fred', it says: gnatmake: "fred" not found Just the same terse message you complained about in my program. And this is a 3.7MB application. But at least it tells you the name of the file, or so you think; if I try 'gnatmake \a\b\c\d\fred', it also says: gnatmake: "fred" not found ) -- bart
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-10-11 11:54 -0700 |
| Message-ID | <lnva68wbyb.fsf@kst-u.example.com> |
| In reply to | #136670 |
Bart <bc@freeuk.com> writes:
[...]
> How am I criticising it here?
>
> It just seems odd that every single source file you submit to a /C/
> compiler [except mine, naturally], needs the .c extension otherwise it
> hasn't got a clue what you had in mind.
>
> Yet with 'make', you don't even need to bother with the filename.
There are good reasons for that, which I would explain if I thought you
were interested.
[...]
> It's OK, I'm not going to use it. It's one of these programs that's
> never going to work for me.
If you're not going to use it, that's fine, but your ignorant comments
about it are annoying. Being ignorant about it ok. Being ignorant and
complaining that it doesn't work the way you think it should is odd.
> I recently upgraded to gcc 8.1.0 on Windows and for a change, everything
> was included: standard headers, linker, libraries etc.
>
> But there is no program called 'make', unless it's the 3.7MB executable
> called 'gnatmake.exe'.
No, that's not "make". It's the gcc Ada compiler front-end. I could
explain further, but you're not interested.
"make" is not part of gcc. It's a separate tool. Someone who doesn't
intend to use make would not be as concerned as you seem to be by the
fact that it's not included in whatever bundle you installed on Windows.
Those of us who use "make" either already have it, or know how to find
and install it, or can find out easily enough.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-11 20:09 +0100 |
| Message-ID | <wdNvD.26944$ZZ3.12798@fx18.am4> |
| In reply to | #136686 |
On 11/10/2018 19:54, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: >> But there is no program called 'make', unless it's the 3.7MB executable >> called 'gnatmake.exe'. > > No, that's not "make". It's the gcc Ada compiler front-end. I could > explain further, but you're not interested. > > "make" is not part of gcc. It's a separate tool. Someone who doesn't > intend to use make would not be as concerned as you seem to be by the > fact that it's not included in whatever bundle you installed on Windows. > Those of us who use "make" either already have it, or know how to find > and install it, or can find out easily enough. > Well, I've never specifically downloaded make, but sometimes it's there and something it isn't. For something most consider so fundamental to C development, that is a surprise. And when it was included, it was called mingw2-make.exe. So just typing 'make' (apart from clashing with make.exe from multiple compilers) would never even have made it to first base.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-10-12 13:10 +0000 |
| Message-ID | <331wD.90176$SG2.86133@fx29.iad> |
| In reply to | #136690 |
Bart <bc@freeuk.com> writes: > >Well, I've never specifically downloaded make, but sometimes it's there >and something it isn't. For something most consider so fundamental to C >development, that is a surprise. > >And when it was included, it was called mingw2-make.exe. > >So just typing 'make' (apart from clashing with make.exe from multiple >compilers) would never even have made it to first base. > Make, of course, is a unix tool. It's not a windows tool (nmake). If you want it, download it. If you don't, don't complain about it.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-10-13 12:57 +0200 |
| Message-ID | <ppsj2r$h9b$1@dont-email.me> |
| In reply to | #136726 |
On 12/10/18 15:10, Scott Lurndal wrote: > Bart <bc@freeuk.com> writes: > >> >> Well, I've never specifically downloaded make, but sometimes it's there >> and something it isn't. For something most consider so fundamental to C >> development, that is a surprise. >> >> And when it was included, it was called mingw2-make.exe. >> >> So just typing 'make' (apart from clashing with make.exe from multiple >> compilers) would never even have made it to first base. >> > > > Make, of course, is a unix tool. make comes from the *nix world, but has been available cross-platform since the days of DOS. > It's not a windows tool (nmake). nmake is Microsoft's own somewhat incompatible version of make. Most people looking for a "normal" make tool on Windows use a port of gnu make, just as they do on all *nix systems. > > If you want it, download it. If you don't, don't complain about it. > Agreed.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2018-10-11 14:27 -0500 |
| Message-ID | <ppo86e$9fe$1@news.albasani.net> |
| In reply to | #136670 |
On 10/11/2018 12:56 PM, Bart wrote: > On 11/10/2018 18:36, Scott Lurndal wrote: >> Bart <bc@freeuk.com> writes: >>> On 11/10/2018 15:38, David Brown wrote: >> >>> BTW how does 'make' know which project to build, if there are several >>> possibilities? >> >> You know, there's a shipload of documentation and examples for 'make' >> on the internet. Spend some time learning to use it before you >> criticise it. > > How am I criticising it here? > > It just seems odd that every single source file you submit to a /C/ > compiler [except mine, naturally], needs the .c extension otherwise it > hasn't got a clue what you had in mind. > Well, do sorta need file extensions... > Yet with 'make', you don't even need to bother with the filename. > Because 'make' hard-codes a lot of stuff by default (though not nearly as bad as CMake, which seems IMO to try to be too clever for its own good). If I could change annoyances with make, it would be to have it support a "make with implied Makefile suffix" mode, and maybe make it more natural to separate out target-specific stuff from target-agnostic parts. Maybe also make it able to deal with relative naming (so that larger codebases don't need to resort to invoking it recursively). I originally had a sort of limited build system in my compiler, but in current use it is mostly invoked from a Makefile (and can to some extent mimic both MSVC and GCC style command-line arguments; but is currently more using the MSVC style). There are some differences, such that mine will typically infer what sort of output to generate based on the file extension: ".exe": PE/COFF binary output ".elf": ELF binary output ".dll": PE/COFF DLL ".so": ELF Shared Object ".rom": Flat ROM style dump (*1). ".o"/".ril": RIL3 bytecode IL ".s": assembler dump *1: Though, this mode may need an explicit memory model and/or memory-map to be given (may imply the memory-map via the memory model though). For PE/COFF or similar this is less important as generally relevant details can be inferred and the produced image supports base relocs by default. In this case, options like "-s" or "-c" (or "/Fa", "/Fo") are mostly redundant. Similarly, unlike GCC, "-lfoo" mostly just gets rewritten during command-line parsing to "libfoo.ril" (because this is currently the only supported library format apart from linking against DLL's). File loading is a little naive (ignores file extensions), and will currently check for known magic numbers or a UTF-8/16 BOM and similar to determine any text normalization or similar (or whether the input is a known binary format). Dealing with untagged text/data is a bit more expensive (requires a pass over the data to try to identify it). >> $ make <target-name> >> >> A properly built make system will also allow >> >> $ make subdir/sourcefile.o >> >> to build a single file in subdir. > > It's OK, I'm not going to use it. It's one of these programs that's > never going to work for me. > > I recently upgraded to gcc 8.1.0 on Windows and for a change, everything > was included: standard headers, linker, libraries etc. > > But there is no program called 'make', unless it's the 3.7MB executable > called 'gnatmake.exe'. > > (Which, BTW, if I type 'gnatmake fred', it says: > > gnatmake: "fred" not found > > Just the same terse message you complained about in my program. And this > is a 3.7MB application. But at least it tells you the name of the file, > or so you think; if I try 'gnatmake \a\b\c\d\fred', it also says: > > gnatmake: "fred" not found > ) >
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-10-11 22:03 +0200 |
| Message-ID | <ppoabd$elc$1@dont-email.me> |
| In reply to | #136691 |
On 11/10/18 21:27, BGB wrote: > On 10/11/2018 12:56 PM, Bart wrote: >> On 11/10/2018 18:36, Scott Lurndal wrote: >>> Bart <bc@freeuk.com> writes: >>>> On 11/10/2018 15:38, David Brown wrote: >>> >>>> BTW how does 'make' know which project to build, if there are several >>>> possibilities? >>> >>> You know, there's a shipload of documentation and examples for 'make' >>> on the internet. Spend some time learning to use it before you >>> criticise it. >> >> How am I criticising it here? >> >> It just seems odd that every single source file you submit to a /C/ >> compiler [except mine, naturally], needs the .c extension otherwise it >> hasn't got a clue what you had in mind. >> > > Well, do sorta need file extensions... gcc is quite happy with whatever file extensions you want - including no file extension. But if you don't use a file extension to indicate the language (gcc supports several), you need to use a flag like "-x c" to say "treat this as a C file". You don't even need a filename at all - gcc can use stdin (again, you need a "-x" flag). I have used other compilers that are as flexible. > > >> Yet with 'make', you don't even need to bother with the filename. >> > > Because 'make' hard-codes a lot of stuff by default (though not nearly > as bad as CMake, which seems IMO to try to be too clever for its own good). > No, that is not why "make" doesn't need a filename. The usual parameter to "make" is a /target/, not necessarily a file, and if no parameter is given then the first target is taken by default.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2018-10-11 15:56 -0500 |
| Message-ID | <ppoddf$si8$1@news.albasani.net> |
| In reply to | #136692 |
On 10/11/2018 3:03 PM, David Brown wrote: > On 11/10/18 21:27, BGB wrote: >> On 10/11/2018 12:56 PM, Bart wrote: >>> On 11/10/2018 18:36, Scott Lurndal wrote: >>>> Bart <bc@freeuk.com> writes: >>>>> On 11/10/2018 15:38, David Brown wrote: >>>> >>>>> BTW how does 'make' know which project to build, if there are several >>>>> possibilities? >>>> >>>> You know, there's a shipload of documentation and examples for 'make' >>>> on the internet. Spend some time learning to use it before you >>>> criticise it. >>> >>> How am I criticising it here? >>> >>> It just seems odd that every single source file you submit to a /C/ >>> compiler [except mine, naturally], needs the .c extension otherwise >>> it hasn't got a clue what you had in mind. >>> >> >> Well, do sorta need file extensions... > > gcc is quite happy with whatever file extensions you want - including no > file extension. But if you don't use a file extension to indicate the > language (gcc supports several), you need to use a flag like "-x c" to > say "treat this as a C file". You don't even need a filename at all - > gcc can use stdin (again, you need a "-x" flag). > > I have used other compilers that are as flexible. > OK. Mine assumes file extensions, and doesn't support pipes. It is flexible enough though, that it can be invoked different ways: bgbcc /Fefoo.exe foo1.c foo2.c ... /mBJX2 /I. /L../barlib /lbar or: bgbcc -o foo.exe foo1.c foo2.c ... -mBJX2 -I. -L../barlib -lbar or: bgbcc -c -o foo1.o foo1.c -mBJX2 -I. or: ... The /m or -m option is needed to give the intended CPU arch, otherwise it will either use a default target given in a config file or default to an "unknown target" arch which is limited to producing "generic" RIL3 output (doesn't specialize for type sizes and lacks any target-specific #define's), and which is unable to produce binaries. >> >> >>> Yet with 'make', you don't even need to bother with the filename. >>> >> >> Because 'make' hard-codes a lot of stuff by default (though not nearly >> as bad as CMake, which seems IMO to try to be too clever for its own >> good). >> > > No, that is not why "make" doesn't need a filename. The usual parameter > to "make" is a /target/, not necessarily a file, and if no parameter is > given then the first target is taken by default. > It hard-codes to look for "Makefile" by default, and also various default build patterns. You can type "make -C foolib -f Makefile.lnx foo.elf", but this doesn't change that a lot of things in its behavior are coded-in. This is in contrast to something like a shell-script where the shell only really knows what is given via environment variables and similar (and most of its commands are normal programs found via "PATH").
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-10-12 11:30 +0200 |
| Message-ID | <ppppka$t4d$1@dont-email.me> |
| In reply to | #136696 |
On 11/10/18 22:56, BGB wrote: > On 10/11/2018 3:03 PM, David Brown wrote: >> On 11/10/18 21:27, BGB wrote: >>> On 10/11/2018 12:56 PM, Bart wrote: >>>> On 11/10/2018 18:36, Scott Lurndal wrote: >>>>> Bart <bc@freeuk.com> writes: >>>>>> On 11/10/2018 15:38, David Brown wrote: >>>>> >>>>>> BTW how does 'make' know which project to build, if there are several >>>>>> possibilities? >>>>> >>>>> You know, there's a shipload of documentation and examples for 'make' >>>>> on the internet. Spend some time learning to use it before you >>>>> criticise it. >>>> >>>> How am I criticising it here? >>>> >>>> It just seems odd that every single source file you submit to a /C/ >>>> compiler [except mine, naturally], needs the .c extension otherwise >>>> it hasn't got a clue what you had in mind. >>>> >>> >>> Well, do sorta need file extensions... >> >> gcc is quite happy with whatever file extensions you want - including >> no file extension. But if you don't use a file extension to indicate >> the language (gcc supports several), you need to use a flag like "-x >> c" to say "treat this as a C file". You don't even need a filename at >> all - gcc can use stdin (again, you need a "-x" flag). >> >> I have used other compilers that are as flexible. >> > > OK. > > Mine assumes file extensions, and doesn't support pipes. > Fair enough. File extensions are certainly convenient. > It is flexible enough though, that it can be invoked different ways: > bgbcc /Fefoo.exe foo1.c foo2.c ... /mBJX2 /I. /L../barlib /lbar > or: > bgbcc -o foo.exe foo1.c foo2.c ... -mBJX2 -I. -L../barlib -lbar > or: > bgbcc -c -o foo1.o foo1.c -mBJX2 -I. > or: > ... > > The /m or -m option is needed to give the intended CPU arch, otherwise > it will either use a default target given in a config file or default to > an "unknown target" arch which is limited to producing "generic" RIL3 > output (doesn't specialize for type sizes and lacks any target-specific > #define's), and which is unable to produce binaries. > > >>> >>> >>>> Yet with 'make', you don't even need to bother with the filename. >>>> >>> >>> Because 'make' hard-codes a lot of stuff by default (though not >>> nearly as bad as CMake, which seems IMO to try to be too clever for >>> its own good). >>> >> >> No, that is not why "make" doesn't need a filename. The usual >> parameter to "make" is a /target/, not necessarily a file, and if no >> parameter is given then the first target is taken by default. >> > > It hard-codes to look for "Makefile" by default, and also various > default build patterns. Yes. > > You can type "make -C foolib -f Makefile.lnx foo.elf", but this doesn't > change that a lot of things in its behavior are coded-in. > Personally, I don't use the default build patterns - I always have them overridden by my own ones. It makes no difference to my builds if I use the "-r" flag (which disables all built-in implicit rules) or not. > This is in contrast to something like a shell-script where the shell > only really knows what is given via environment variables and similar > (and most of its commands are normal programs found via "PATH"). The built-in rules for make are for convenience, and some people like it. If you need your own rules, just write them - they will override the defaults.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-11 23:34 +0100 |
| Message-ID | <_dQvD.14566$xH4.8158@fx33.am4> |
| In reply to | #136692 |
On 11/10/2018 21:03, David Brown wrote:
> On 11/10/18 21:27, BGB wrote:
>> On 10/11/2018 12:56 PM, Bart wrote:
>>> It just seems odd that every single source file you submit to a /C/
>>> compiler [except mine, naturally], needs the .c extension otherwise
>>> it hasn't got a clue what you had in mind.
>>>
>>
>> Well, do sorta need file extensions...
>
> gcc is quite happy with whatever file extensions you want - including no
> file extension. But if you don't use a file extension to indicate the
> language (gcc supports several), you need to use a flag like "-x c" to
> say "treat this as a C file". You don't even need a filename at all -
> gcc can use stdin (again, you need a "-x" flag).
>
> I have used other compilers that are as flexible.
My comment was about assuming a default extension when one is not supplied.
Most compilers, interpreters etc of any language, will usually insist on
a file extension being provided. Even for a program intended to be used
primarily in interactive mode.
So to run the Lua interpeter on prog.lua, you have to type:
lua prog.lua
every single time. Same with Python. Same with almost any C compiler,
even if it is capable of doing nothing else except process .c files.
What would be the big deal in being able to type this:
cc prog
and it would assume prog.c?
Most of my programs make use of such default extensions except where
there is no obvious default (like a text editor).
gcc appears to have a bit of an excuse in working for multiple
languages, but even when it can only support C, you /still/ have to
specify the language.
(I expect the reason is going to come down to some limitation of Unix,
for example the following shows how extensions or lack of can be
interpreted:
Windows Unix
prog.c "prog.c" "prog.c"
prog Missing extension? "prog"
prog. "prog" [no extension] "prog." [with trailing dot]
On Windows, the extension on 'prog' can be assumed to be left out, so
one can be added, eg. "prog.c". Because an actual empty extension can be
specified as "prog.".
Not so on Unix, where "prog" and "prog." are distinct file names.
Result: a lot of people wasting a lot of time typing in patently obvious
extension to files.)
--
bart
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-10-11 16:24 -0700 |
| Message-ID | <lnin28vzha.fsf@kst-u.example.com> |
| In reply to | #136699 |
Bart <bc@freeuk.com> writes:
[...]
> So to run the Lua interpeter on prog.lua, you have to type:
>
> lua prog.lua
>
> every single time. Same with Python. Same with almost any C compiler,
> even if it is capable of doing nothing else except process .c files.
Only if the script file is named "prog.lua". It's perfectly
reasonable and common to name it "prog". Or, at least on Unix-like
systems, to add "#!/usr/bin/lua" on the first line and invoke it
as just "prog" or "./prog".
"lua prog" and "lua prog.lua" are two different commands, and either
or both could be valid.
There's no reason a user of a Lua script (or Perl, or Python,
or bash) should have to care what language it's written in.
[snip]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-12 01:46 +0100 |
| Message-ID | <k9SvD.36378$kh6.25561@fx32.am4> |
| In reply to | #136702 |
On 12/10/2018 00:24, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> So to run the Lua interpeter on prog.lua, you have to type:
>>
>> lua prog.lua
>>
>> every single time. Same with Python. Same with almost any C compiler,
>> even if it is capable of doing nothing else except process .c files.
>
> Only if the script file is named "prog.lua". It's perfectly
> reasonable and common to name it "prog". Or, at least on Unix-like
> systems, to add "#!/usr/bin/lua" on the first line and invoke it
> as just "prog" or "./prog".
>
> "lua prog" and "lua prog.lua" are two different commands, and either
> or both could be valid.
>
> There's no reason a user of a Lua script (or Perl, or Python,
> or bash) should have to care what language it's written in.
So, the way around the nuisance of having to type in file extensions, is
to get rid of them?
That would make for a interesting directory display of mixed files since
many will share the same null extension! You wouldn't be able to have
prog.c, prog.obj, prog.exe, prog.s etc in the same place.
Two of my programs are invoked like this:
bcc prog # prog.c to prog.asm (default .c)
ax prog # prog.asm to prog.exe (default .asm)
If they /required/ an extension, then I would not be able to use "prog"
for both input files.
--
bart
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-10-11 18:58 -0700 |
| Message-ID | <lnefcwvscv.fsf@kst-u.example.com> |
| In reply to | #136703 |
Bart <bc@freeuk.com> writes:
> On 12/10/2018 00:24, Keith Thompson wrote:
[...]
>> There's no reason a user of a Lua script (or Perl, or Python,
>> or bash) should have to care what language it's written in.
>
> So, the way around the nuisance of having to type in file extensions, is
> to get rid of them?
No. I suggested getting rid of the extension because it's unnecessary.
Of course if you want it for some reason, feel free to name your files
whatever you like.
I don't find typing file extensions to be a nuisance. You obviously do.
I am neither inclined nor able to change your mind.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Wouter Verhelst <w@uter.be> |
|---|---|
| Date | 2018-10-12 08:50 +0200 |
| Message-ID | <ars59f-m6r.ln1@gangtai.home.grep.be> |
| In reply to | #136703 |
On 12/10/18 02:46, Bart wrote: > On 12/10/2018 00:24, Keith Thompson wrote: >> Bart <bc@freeuk.com> writes: >> [...] >>> So to run the Lua interpeter on prog.lua, you have to type: >>> >>> lua prog.lua >>> >>> every single time. Same with Python. Same with almost any C compiler, >>> even if it is capable of doing nothing else except process .c files. >> >> Only if the script file is named "prog.lua". It's perfectly >> reasonable and common to name it "prog". Or, at least on Unix-like >> systems, to add "#!/usr/bin/lua" on the first line and invoke it >> as just "prog" or "./prog". >> >> "lua prog" and "lua prog.lua" are two different commands, and either >> or both could be valid. >> >> There's no reason a user of a Lua script (or Perl, or Python, >> or bash) should have to care what language it's written in. > > So, the way around the nuisance of having to type in file extensions, is > to get rid of them? Yes. Unix doesn't know file extensions. They're a DOS concept (and a Windows concept, by extension -- pun intended). In order to figure out what the type of a file is, historically a Unix program would inspect the file contents. Unix, however, does allow almost every character in a filename (the only exception being the directory separator character, '/'), including dots. Since the extension concept isn't that bad, most Unix software nowadays assumes they are there. But it's not required, and therefore programs usually make allowances for them not being there. So if you don't want to type them, then don't. Ever. You'll have to figure out another way to know that a particular file is of a particular type, however.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-12 11:12 +0100 |
| Message-ID | <ks_vD.22058$6N5.3768@fx29.am4> |
| In reply to | #136707 |
On 12/10/2018 07:50, Wouter Verhelst wrote: > On 12/10/18 02:46, Bart wrote: >> On 12/10/2018 00:24, Keith Thompson wrote: >>> Bart <bc@freeuk.com> writes: >>> [...] >>>> So to run the Lua interpeter on prog.lua, you have to type: >>>> >>>> lua prog.lua >>>> >>>> every single time. Same with Python. Same with almost any C compiler, >>>> even if it is capable of doing nothing else except process .c files. >>> >>> Only if the script file is named "prog.lua". It's perfectly >>> reasonable and common to name it "prog". Or, at least on Unix-like >>> systems, to add "#!/usr/bin/lua" on the first line and invoke it >>> as just "prog" or "./prog". >>> >>> "lua prog" and "lua prog.lua" are two different commands, and either >>> or both could be valid. >>> >>> There's no reason a user of a Lua script (or Perl, or Python, >>> or bash) should have to care what language it's written in. >> >> So, the way around the nuisance of having to type in file extensions, is >> to get rid of them? > > Yes. > > Unix doesn't know file extensions. They're a DOS concept (and a Windows > concept, by extension -- pun intended). In order to figure out what the > type of a file is, historically a Unix program would inspect the file > contents. > > Unix, however, does allow almost every character in a filename (the only > exception being the directory separator character, '/'), including dots. > Since the extension concept isn't that bad, most Unix software nowadays > assumes they are there. But it's not required, and therefore programs > usually make allowances for them not being there. > > So if you don't want to type them, then don't. Ever. You'll have to > figure out another way to know that a particular file is of a particular > type, however. Seriously? So we do away with the difference between .c and .h files for example? And, on github, we can no longer tell which files on the list are .c, .h, .m4, .py, .md, .def etc. Instead, to figure out which file is which, we need to load and display the entire file (not fast on github for large source files) and try and figure it out from the contents. Note that on github, if a file happens to be an image file, it will just display the image, with no opportunity to know whether it's jpg or png or whatever (I don't know if github needs the extension for this purpose). It will be interesting of the image turns out to be a rendering of a C source file. Extensions, whether they implemented as part of a file name or form a separate attribute, or a jolly good idea. My point was that for an application where the primary input is the name of a particular kind of file, it should not be necessary to have to type the ".c" at the end of the name, if 99.999% of names will have, for example, the ".c" at the end. -- bart
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-10-12 12:55 +0200 |
| Message-ID | <pppui9$dik$1@dont-email.me> |
| In reply to | #136713 |
On 12/10/18 12:12, Bart wrote: > On 12/10/2018 07:50, Wouter Verhelst wrote: >> On 12/10/18 02:46, Bart wrote: >>> On 12/10/2018 00:24, Keith Thompson wrote: >>>> Bart <bc@freeuk.com> writes: >>>> [...] >>>>> So to run the Lua interpeter on prog.lua, you have to type: >>>>> >>>>> lua prog.lua >>>>> >>>>> every single time. Same with Python. Same with almost any C compiler, >>>>> even if it is capable of doing nothing else except process .c files. >>>> >>>> Only if the script file is named "prog.lua". It's perfectly >>>> reasonable and common to name it "prog". Or, at least on Unix-like >>>> systems, to add "#!/usr/bin/lua" on the first line and invoke it >>>> as just "prog" or "./prog". >>>> >>>> "lua prog" and "lua prog.lua" are two different commands, and either >>>> or both could be valid. >>>> >>>> There's no reason a user of a Lua script (or Perl, or Python, >>>> or bash) should have to care what language it's written in. >>> >>> So, the way around the nuisance of having to type in file extensions, is >>> to get rid of them? >> >> Yes. >> >> Unix doesn't know file extensions. They're a DOS concept (and a Windows >> concept, by extension -- pun intended). In order to figure out what the >> type of a file is, historically a Unix program would inspect the file >> contents. Some *nix programs inspect the file - but for many kinds of file, automatic inspection is not reliable enough. How do you tell that a file is a C header and not a C source file, or a C++ source file? How do you tell the type of a text file that has been created but is not yet written? Thus some programs use file extensions as a short-cut for identifying file type when typical usage makes it hard to do so automatically. >> >> Unix, however, does allow almost every character in a filename (the only >> exception being the directory separator character, '/'), including dots. >> Since the extension concept isn't that bad, most Unix software nowadays >> assumes they are there. But it's not required, and therefore programs >> usually make allowances for them not being there. >> >> So if you don't want to type them, then don't. Ever. You'll have to >> figure out another way to know that a particular file is of a particular >> type, however. > > Seriously? > File extensions are part of the name of the file in the *nix world - they are not there to define the type of a file as in Windows. So use them when they are useful in the name, and not when they are not needed. > So we do away with the difference between .c and .h files for example? > > And, on github, we can no longer tell which files on the list are .c, > .h, .m4, .py, .md, .def etc. It is often very handy to know what might be in a file, by looking at its name. So you have file extensions for user convenience, just as the rest of the name is for user convenience. The OS would be happy with "file1", "file2", "file3", but users want "readme", "main.c", etc. > > Instead, to figure out which file is which, we need to load and display > the entire file (not fast on github for large source files) and try and > figure it out from the contents. It is usually possible to figure out the type of a file from the first line or the first 40 bytes or so. (Read on the web how the *nix "file" command works.) If you can't distinguish by then, you are not going to distinguish at all in an easy and reliable manner - such as figuring out if code is C or C++. > > Note that on github, if a file happens to be an image file, it will just > display the image, with no opportunity to know whether it's jpg or png > or whatever (I don't know if github needs the extension for this > purpose). It will be interesting of the image turns out to be a > rendering of a C source file. Standard graphics formats all have convenient "magic numbers" at the start so that you can tell the file type independently of the extension. (I don't know if github uses that, or filename extensions.) > > Extensions, whether they implemented as part of a file name or form a > separate attribute, or a jolly good idea. They are often convenient and useful. They are not essential. It is a bad idea to automatically add or assume a file extension when none exists - this is a misfeature from DOS. > > My point was that for an application where the primary input is the name > of a particular kind of file, it should not be necessary to have to type > the ".c" at the end of the name, if 99.999% of names will have, for > example, the ".c" at the end. Are you really that bothered about having to type an extra two characters? Get yourself a shell with tab filename completion, and cut your troubles in half.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-12 12:10 +0100 |
| Message-ID | <6j%vD.22059$6N5.6641@fx29.am4> |
| In reply to | #136716 |
On 12/10/2018 11:55, David Brown wrote:
> On 12/10/18 12:12, Bart wrote:
> Are you really that bothered about having to type an extra two
> characters?
Yes. When it is completely pointless to do so.
> Get yourself a shell with tab filename completion, and cut
> your troubles in half.
That doesn't work. You still have press Tab. And if I do so at this
point in my C directory:
gcc test
the first file I get is "test" (ie. no extension). The next is test.bas.
Then test.bat. And /then/ test.c. (Which is lucky, as there are 16 more
files starting with "test", being a popular filename.) I don't know if
it uses alphabetical order, but if I started from here:
python test
I would have to press Tab 17 times to get to python.py. On the other
hand, I can do this:
bcc test
and it will know (because it knows it's a C compiler and it's one
parameter is going to be the name of a C source file) to look for
test.c. No need to press Tab and then to pause to check whether it's the
right file before pressing Enter.
It's called being user-friendly. Just another example of a misfeature
from Linux (which is decidedly unfriendly) permeating everywhere else.
--
bart
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-10-12 13:29 +0200 |
| Message-ID | <ppq0i1$pin$1@dont-email.me> |
| In reply to | #136718 |
On 12/10/18 13:10, Bart wrote: > On 12/10/2018 11:55, David Brown wrote: >> On 12/10/18 12:12, Bart wrote: > >> Are you really that bothered about having to type an extra two >> characters? > > Yes. When it is completely pointless to do so. Since we have now established that there /is/ a point to typing file extensions, that complaint is now moot. > > It's called being user-friendly. Just another example of a misfeature > from Linux (which is decidedly unfriendly) permeating everywhere else. > You really are stuck in a groove, aren't you? What the rest of us see as features, or at least as necessities, you see as a critical problem leading to the downfall of the programming world - just because you associate it with Linux or C. Whether it actually /is/ related to Linux, or C, is utterly irrelevant to you. You just need some vague excuse to feed your daily addiction to moaning, whining, and complaining about your two pet hates.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-12 13:06 +0100 |
| Message-ID | <Z60wD.27668$ZZ3.17938@fx18.am4> |
| In reply to | #136721 |
On 12/10/2018 12:29, David Brown wrote: > On 12/10/18 13:10, Bart wrote: >> On 12/10/2018 11:55, David Brown wrote: >>> On 12/10/18 12:12, Bart wrote: >> >>> Are you really that bothered about having to type an extra two >>> characters? >> >> Yes. When it is completely pointless to do so. > > Since we have now established that there /is/ a point to typing file > extensions, Have we? I think we agreed there's a point to /having/ file extensions, which Unix seems to have grudgingly acknowledged. > that complaint is now moot. >> >> It's called being user-friendly. Just another example of a misfeature >> from Linux (which is decidedly unfriendly) permeating everywhere else. >> > > You really are stuck in a groove, aren't you? What the rest of us see > as features, or at least as necessities, you see as a critical problem > leading to the downfall of the programming world - just because you > associate it with Linux or C. Whether it actually /is/ related to > Linux, or C, is utterly irrelevant to you. You just need some vague > excuse to feed your daily addiction to moaning, whining, and complaining > about your two pet hates. So why do you type 'make' and not 'make file' or 'make target'? It sounds like you are happy for the convenience when it suits you or when everyone else is doing the same. And when the application allows it. Yes, this is a minor irritation (especially for me as it only comes up with other people's software). And I admit that what's more interesting is not the irritation itself, but the attitudes towards it in this group: It's not a nuisance. It's only two characters. It's a feature. You can fix it by doing away with extensions completely. There is a reason for it [which seems to have eluded me]. gcc needs it to figure out which language it's compiling [even when a particular gcc only supports C]. You can get around it by pressing Tab half a dozen times instead. Etc. Everything except admit that it is stupid spending a lifetime entering pointless extensions when 99.99% of the time, the application can deduce it. -- bart
[toc] | [prev] | [next] | [standalone]
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web