Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #172151 > unrolled thread
| Started by | Bart <bc@freeuk.com> |
|---|---|
| First post | 2023-08-13 14:53 +0100 |
| Last post | 2023-08-29 04:43 -0700 |
| Articles | 20 on this page of 306 — 31 participants |
Back to article view | Back to comp.lang.c
Build Systems Bart <bc@freeuk.com> - 2023-08-13 14:53 +0100
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-13 21:45 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-13 23:43 +0100
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-14 01:16 +0100
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-14 00:46 +0000
Re: Build Systems gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-14 01:05 +0000
Re: Build Systems Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-13 18:59 -0700
Dev on Windoze (Was: Build Systems) gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-14 02:44 +0000
Re: Dev on Windoze (Was: Build Systems) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-13 20:53 -0700
Re: Dev on Windoze (Was: Build Systems) Matthew Ernisse <matt@going-flying.com> - 2023-08-17 22:00 +0000
Re: Dev on Windoze (Was: Build Systems) Michael S <already5chosen@yahoo.com> - 2023-08-18 03:51 -0700
Re: Dev on Windoze (Was: Build Systems) bart c <bart4858@gmail.com> - 2023-08-18 04:58 -0700
Re: Dev on Windoze (Was: Build Systems) Matthew Ernisse <matt@going-flying.com> - 2023-08-18 13:02 +0000
Re: Dev on Windoze Phil Carmody <pc+usenet@asdf.org> - 2023-08-20 16:14 +0300
Re: Dev on Windoze "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-20 11:05 -0700
Re: Dev on Windoze (Was: Build Systems) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-18 16:16 -0700
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-14 04:03 +0000
Re: Build Systems gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-14 10:14 +0000
Re: Build Systems Karl Meyer <karlmeyer25@gmail.com> - 2023-08-14 05:16 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-14 10:35 +0100
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-14 15:06 +0200
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-14 14:58 +0100
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-14 15:49 +0000
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-14 18:00 +0100
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-15 11:00 +0200
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-15 11:40 +0100
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-15 15:21 +0200
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-15 16:11 +0100
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-15 15:39 +0000
Re: Build Systems MJ OS_EXAMINE <m6502x64@gmail.com> - 2023-08-15 08:58 -0700
Re: Build Systems gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-15 16:44 +0000
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-15 20:00 +0100
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-15 18:03 +0200
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-15 17:01 +0000
Re: Build Systems gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-15 17:07 +0000
Re: Build Systems Phil Carmody <pc+usenet@asdf.org> - 2023-08-15 23:17 +0300
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-15 22:57 +0200
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-15 18:49 +0100
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-15 13:13 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-15 23:09 +0200
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-15 23:36 +0100
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-15 15:55 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-16 01:05 +0100
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-16 01:39 +0000
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-16 11:37 +0200
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-16 12:15 +0100
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-16 15:16 +0200
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-16 16:34 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-16 18:07 +0100
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-16 17:43 +0000
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-16 18:51 +0100
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-16 21:26 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-16 22:25 +0100
Re: Build Systems Richard Harnden <richard.nospam@gmail.com> - 2023-08-17 00:15 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-17 01:02 +0100
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-17 02:56 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-17 11:21 +0100
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-17 21:26 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-17 23:40 +0100
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-19 00:43 +0100
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-17 15:45 +0200
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-18 00:24 +0100
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-17 17:46 -0700
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-17 18:29 -0700
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-17 19:13 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-18 14:55 +0200
Re: Build Systems "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-18 14:34 -0700
Re: Build Systems "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-18 14:34 -0700
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-18 15:19 -0700
Re: Build Systems "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-18 15:43 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-19 13:19 +0200
Re: Build Systems "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-26 20:56 -0700
Re: Build Systems "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-26 20:57 -0700
Re: Build Systems "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2023-08-27 00:01 -0700
Re: Build Systems candycane@f172.n1.z21.fsxnet (candycane) - 2023-08-27 03:34 +1300
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-27 08:32 +0000
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-27 16:58 +0200
Re: Build Systems "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-27 11:58 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-27 16:52 +0200
Re: Build Systems "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-27 11:59 -0700
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-18 01:49 +0000
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-18 02:19 -0700
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-19 01:21 +0100
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-18 18:36 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-19 13:51 +0200
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-19 05:35 -0700
Re: Build Systems Kelsey Bjarnason <kbjarnason@gmail.com> - 2023-08-19 00:35 -0700
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-19 09:54 -0700
Re: Build Systems Kelsey Bjarnason <kbjarnason@gmail.com> - 2023-08-19 12:30 -0700
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-19 13:44 -0700
Re: Build Systems Kelsey Bjarnason <kbjarnason@gmail.com> - 2023-08-21 17:58 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-22 02:28 +0100
Re: Build Systems Kelsey Bjarnason <kbjarnason@gmail.com> - 2023-08-22 00:12 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-22 11:13 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-22 11:36 +0100
Re: Build Systems Richard Harnden <richard.nospam@gmail.com> - 2023-08-22 13:37 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-22 13:51 +0100
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-22 14:51 +0000
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-22 17:19 +0100
Re: Build Systems Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-22 09:30 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-22 17:51 +0100
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-22 16:36 +0000
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-22 16:50 +0000
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-22 18:06 +0100
Re: Build Systems kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-08-22 20:46 +0000
Re: Build Systems "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-22 12:47 -0700
Re: Build Systems "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-26 21:06 -0700
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-22 17:04 +0000
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-20 00:10 +0100
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-19 17:50 -0700
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-20 20:48 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-20 22:07 +0100
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-21 00:51 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-21 01:26 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-21 02:02 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-21 02:07 +0100
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-21 03:13 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-21 11:09 +0100
Re: Build Systems Richard Harnden <richard.nospam@gmail.com> - 2023-08-21 13:12 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-21 14:12 +0100
Re: Build Systems Richard Harnden <richard.nospam@gmail.com> - 2023-08-21 14:47 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-21 19:06 +0100
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-21 18:40 +0000
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-21 14:39 -0700
Re: Build Systems "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-21 12:23 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-21 21:55 +0100
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-22 01:31 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-22 02:18 +0100
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-22 14:41 +0000
Re: Build Systems Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-22 08:03 -0700
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-22 15:33 +0000
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-22 16:20 +0100
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-22 15:40 +0000
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-22 17:03 +0100
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-23 03:18 +0100
Re: Build Systems "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-22 19:51 -0700
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-25 02:23 +0100
Re: Build Systems "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-24 21:24 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-25 11:31 +0200
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-25 10:53 +0100
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-25 13:55 +0200
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-25 13:54 +0000
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-25 20:55 +0100
Re: Build Systems Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-25 20:49 -0700
Re: Build Systems Richard Harnden <richard.nospam@gmail.com> - 2023-08-23 08:42 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-23 11:37 +0100
Re: Build Systems Anton Shepelev <anton.txt@g{oogle}mail.com> - 2023-08-23 14:02 +0300
Re: Build Systems Richard Harnden <richard.nospam@gmail.com> - 2023-08-23 15:02 +0100
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-25 02:17 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-23 14:28 +0100
Re: Build Systems Anton Shepelev <anton.txt@g{oogle}mail.com> - 2023-08-23 19:54 +0300
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-23 19:33 +0200
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-23 21:13 +0100
Re: Build Systems Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-23 23:09 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-24 15:32 +0200
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-24 15:51 +0000
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-24 18:58 +0100
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-24 18:29 +0000
Re: Build Systems vallor <vallor@cultnix.org> - 2023-08-24 20:41 +0000
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-24 23:08 +0000
Re: Build Systems Rainer Weikusat <rweikusat@talktalk.net> - 2023-08-25 17:22 +0100
Re: Build Systems Spiros Bousbouras <spibou@gmail.com> - 2023-08-25 16:39 +0000
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-25 16:54 +0000
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-25 17:02 +0000
Re: Build Systems Rainer Weikusat <rweikusat@talktalk.net> - 2023-08-25 19:21 +0100
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-25 18:56 +0000
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-24 11:44 -0700
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-24 18:47 +0000
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-24 21:20 +0100
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-24 22:59 +0000
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-25 02:18 +0100
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-24 20:17 -0700
Re: Build Systems Anton Shepelev <anton.txt@g{oogle}mail.com> - 2023-08-24 16:30 +0300
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-23 17:43 +0000
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-23 20:15 +0100
Re: Build Systems Anton Shepelev <anton.txt@gmail.moc> - 2023-08-26 18:19 +0300
Re: Build Systems Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-26 21:47 -0700
Re: Build Systems Anton Shepelev <anton.txt@g{oogle}mail.com> - 2023-08-28 11:31 +0300
Re: Build Systems Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-28 06:48 -0700
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-25 02:11 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-25 11:27 +0100
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-25 13:52 +0000
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-25 15:40 +0100
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-25 20:04 +0200
Re: Build Systems candycane@f172.n1.z21.fsxnet (candycane) - 2023-08-26 00:47 +1300
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-25 21:26 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-26 01:42 +0100
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-27 01:16 +0100
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-25 05:51 +0000
Re: Build Systems Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-24 23:17 -0700
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-21 02:52 +0000
Re: Build Systems vallor <vallor@cultnix.org> - 2023-08-21 03:02 +0000
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-21 06:05 +0000
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-21 11:32 +0100
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-19 14:42 +0000
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-19 08:09 -0700
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-19 15:59 +0000
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-19 09:38 -0700
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-19 18:16 +0000
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-19 21:02 +0000
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-19 14:13 -0700
Re: Build Systems Ike Naar <ike@sdf.org> - 2023-08-19 19:10 +0000
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-19 21:00 +0000
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-19 14:22 -0700
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-19 17:56 -0700
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-19 18:13 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-20 14:13 +0200
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-20 06:05 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-20 16:15 +0200
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-20 09:25 -0700
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-20 13:35 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-21 14:43 +0200
Re: Build Systems Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-21 05:52 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-21 14:30 +0100
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-21 15:18 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-21 23:26 +0100
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-21 16:11 -0700
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-21 14:47 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-21 23:20 +0100
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-21 15:45 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-22 00:57 +0100
Re: Build Systems vallor <vallor@cultnix.org> - 2023-08-20 14:24 +0000
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-20 09:09 -0700
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-20 17:28 +0000
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-19 20:26 +0100
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-18 14:50 +0200
Re: Build Systems Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2023-08-18 13:19 +0000
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-17 17:16 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-17 17:24 +0100
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-18 15:32 +0200
Re: Build Systems Michael S <already5chosen@yahoo.com> - 2023-08-18 07:22 -0700
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-18 07:48 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-18 17:11 +0200
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-18 08:58 -0700
Re: Build Systems "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-18 16:32 -0700
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-20 04:02 -0700
Re: Build Systems "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-22 12:26 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-19 13:56 +0200
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-19 05:43 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-16 11:23 +0200
Re: Build Systems Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-16 02:34 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-16 12:52 +0200
Re: Build Systems Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-16 03:56 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-16 13:23 +0200
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-16 12:55 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-17 15:52 +0200
Re: Build Systems Michael S <already5chosen@yahoo.com> - 2023-08-17 02:14 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-17 15:56 +0200
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-17 16:01 +0000
Re: Build Systems Michael S <already5chosen@yahoo.com> - 2023-08-17 09:07 -0700
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-17 16:20 +0000
Re: Build Systems Michael S <already5chosen@yahoo.com> - 2023-08-17 09:31 -0700
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-17 17:24 +0000
Re: Build Systems Phil Carmody <pc+usenet@asdf.org> - 2023-08-19 14:06 +0300
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-19 04:39 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-19 16:46 +0200
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-19 16:00 +0000
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-20 14:15 +0200
Re: Build Systems Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-20 07:25 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-20 18:03 +0200
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-17 19:51 +0100
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-18 16:44 +0200
Re: Build Systems Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-18 08:21 -0700
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-18 15:39 +0000
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-18 17:47 +0200
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-18 10:49 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-19 15:16 +0200
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-19 07:58 -0700
Re: Build Systems Öö Tiib <ootiib@hot.ee> - 2023-08-19 09:05 -0700
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-15 12:48 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-15 21:36 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-15 21:43 +0100
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-15 14:07 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-16 12:46 +0200
Really? (Was: Build Systems) gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-15 13:15 +0000
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-15 09:54 +0200
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-15 11:07 +0100
Re: Build Systems Öö Tiib <ootiib@hot.ee> - 2023-08-15 03:42 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-15 12:14 +0100
Re: Build Systems Öö Tiib <ootiib@hot.ee> - 2023-08-15 05:53 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-15 15:57 +0100
Re: Build Systems Öö Tiib <ootiib@hot.ee> - 2023-08-15 09:10 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-14 14:49 +0200
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-14 14:39 +0100
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-15 11:08 +0200
Re: Build Systems Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-15 02:56 -0700
Re: Build Systems Öö Tiib <ootiib@hot.ee> - 2023-08-15 03:23 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-15 11:45 +0100
Re: Build Systems Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-15 03:53 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-15 13:15 +0100
Re: Build Systems Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-15 06:22 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-16 01:20 +0100
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-16 12:57 +0200
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-16 12:19 +0100
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-16 15:18 +0200
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-16 18:12 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-16 18:18 +0100
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-16 17:45 +0000
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-15 15:30 +0200
Re: Build Systems Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-15 06:58 -0700
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-15 14:06 +0000
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-15 17:08 +0200
Re: Build Systems Vir Campestris <vir.campestris@invalid.invalid> - 2023-08-15 21:46 +0100
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-14 15:48 +0000
Re: Build Systems Thiago Adams <thiago.adams@gmail.com> - 2023-08-15 12:16 -0700
Re: Build Systems Michael S <already5chosen@yahoo.com> - 2023-08-29 04:43 -0700
Page 5 of 16 — ← Prev page 1 … 3 4 [5] 6 7 … 16 Next page →
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-18 01:49 +0000 |
| Message-ID | <20230817183700.915@kylheku.com> |
| In reply to | #172482 |
On 2023-08-17, Bart <bc@freeuk.com> wrote: > Answer honestly: if 'make' had required an explicit filename from the > start (probably it wouldn't have needed '-f'), would anyone have cared > about having to type it? Yes. You.
[toc] | [prev] | [next] | [standalone]
| From | bart c <bart4858@gmail.com> |
|---|---|
| Date | 2023-08-18 02:19 -0700 |
| Message-ID | <011f0102-1241-464c-b628-0350c0be29fbn@googlegroups.com> |
| In reply to | #172485 |
On Friday, 18 August 2023 at 02:49:38 UTC+1, Kaz Kylheku wrote: > On 2023-08-17, Bart <b...@freeuk.com> wrote: > > Answer honestly: if 'make' had required an explicit filename from the > > start (probably it wouldn't have needed '-f'), would anyone have cared > > about having to type it? > Yes. You. So, nobody who actually uses it. Yet the way it does work is absolutely indispensible and could not possibly be done any other way (like every other C misfeature). That is, you want to be able to type: X and not: X Y like nearly every other command line program. Yet being able to do X Y instead of: X Y.Z on those other programs is anathema. So either 'X Y' is too much to type, or `X Y' is not enough! Even though you will be using the latter case more often. It's fascinating watching psychology and group-think at work.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-08-19 01:21 +0100 |
| Message-ID | <87cyzjx4ob.fsf@bsb.me.uk> |
| In reply to | #172488 |
bart c <bart4858@gmail.com> writes: > On Friday, 18 August 2023 at 02:49:38 UTC+1, Kaz Kylheku wrote: >> On 2023-08-17, Bart <b...@freeuk.com> wrote: >> > Answer honestly: if 'make' had required an explicit filename from the >> > start (probably it wouldn't have needed '-f'), would anyone have cared >> > about having to type it? >> Yes. You. > > So, nobody who actually uses it. You can't infer that from the one answer. > Yet the way it does work is absolutely indispensible and could not > possibly be done any other way Again, no one has said anything approaching that ridiculous straw man. > (like every other C misfeature). "Other"? Make's use of a default file is not a C feature. > That is, you want to be able to type: > > X > > and not: > > X Y No, I want to type make make tests make install make clean make mylib.a depending on what I'm doing rather than make makefile make makefile tests make makefile install make makefile clean make makefile mylib.a What's more, tab completion in my shell works with make's targets, but I don't think that's at all easy to do if the makefile has to be named in the same command. > like nearly every other command line program. > Yet being able to do > > X Y > > instead of: > > X Y.Z > > on those other programs is anathema. Well (if you are talking about having to say gcc prog.c rather than gcc prog) there are advantages, and none of them have anything to do with how much one has to type. After all, command completion means I rarely type a file name explcitly anyway. The main advantage is that there's no need to specify and remember all the rules. Does gcc always add .c? Will it add .c if I type gcc prog.s? Must I avoid any dots in the basename? What happens when several names appear on the command line? > So either 'X Y' is too much to type, or `X Y' is not enough! Even > though you will be using the latter case more often. No. I don't think anyone cares about how much one types (I don't) provided there is some point to it. It's annoying to be forced to type something redundant every time, whereas it's potentially confusing to have gcc pick default extensions. > It's fascinating watching psychology and group-think at work. As usual, you've invented a position (it'a all about the typing) and argued about that instead of taking on board the actualt comments that people have made. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | bart c <bart4858@gmail.com> |
|---|---|
| Date | 2023-08-18 18:36 -0700 |
| Message-ID | <66629235-f2e0-46e0-bcb1-bf3abe1e33cdn@googlegroups.com> |
| In reply to | #172516 |
On Saturday, 19 August 2023 at 01:21:58 UTC+1, Ben Bacarisse wrote: > bart c <bart...@gmail.com> writes: > > That is, you want to be able to type: > > > > X > > > > and not: > > > > X Y > No, I want to type > > make > make tests > make install > make clean > make mylib.a I'm not familiar with how make is used. Do you routinely have to invoke it five times in succession? Maybe that's a deeper problem with it, but as I said I don't use it. > depending on what I'm doing rather than > > make makefile > make makefile tests > make makefile install > make makefile clean > make makefile mylib.a And this actually tells me that the main input is identical in all cases; I'd been wondering what was being done with mylib.a. But whatever it is, the same makefile that does all the other stuff contains some formula for 'mylib.a'? In practice I doubt you would type this five times as normally you'd do line recall then change the last bit. You can also choose to give it a shorter name than 'makefile'! > What's more, tab completion in my shell works with make's targets, but I > don't think that's at all easy to do if the makefile has to be named in > the same command. > > like nearly every other command line program. > > > Yet being able to do > > > > X Y > > > > instead of: > > > > X Y.Z > > > > on those other programs is anathema. > Well (if you are talking about having to say gcc prog.c rather than gcc > prog) there are advantages, and none of them have anything to do with > how much one has to type. After all, command completion means I rarely > type a file name explcitly anyway. If my C test folder, I had 23 files that started with 'hello'. Although they are stepped through in alphabetical order on Windows and .c is near the top, you still have to tentatively keep pressing tab, then you go too far and need shift-tab .. it is quicker just to type the extension! Better however not to have to bother. > The main advantage is that there's no need to specify and remember all > the rules. Does gcc always add .c? Will it add .c if I type gcc > prog.s? Must I avoid any dots in the basename? What happens when > several names appear on the command line? gcc is a bad example to follow since it does too much on the command line and performs multiple functions. So it easy to argue that, because it handles 58 different file types (I've no idea), singling one out to use a default is senseless. But with a simpler product whose primary input files are C source files, then a default .c extension makes a lot of sense. The rules on Windows can be simple: if there is no extension (no dot in the name), then a default extension is added. It's harder with a Linux file system because files "abc" and "abc." are distinct; how to do apply a default extension to "abc" when that could be a valid filename? However on Windows and various other OSes before that over decades, it hasn't really given any problems. > > So either 'X Y' is too much to type, or `X Y' is not enough! Even > > though you will be using the latter case more often. > No. I don't think anyone cares about how much one types (I don't) > provided there is some point to it. It's annoying to be forced to type > something redundant every time, whereas it's potentially confusing to > have gcc pick default extensions. Exactly. I consider the '.c -oprog' in 'gcc prog.c -oprog' to be redundant. Note that on Windows, it will apply the .exe extension to that output. > > It's fascinating watching psychology and group-think at work. > As usual, you've invented a position (it'a all about the typing) and > argued about that instead of taking on board the actual comments that > people have made. The typing is part of it. Using the same default file in this case seem to me to be fragile. Remember the Github Lua with the missing makefile? I didn't know there were supposed to be two, and assume that one called 'makefile' was /the/ makefile. Or someone could simply be in the wrong folder.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-19 13:51 +0200 |
| Message-ID | <ubqabv$pm8r$1@dont-email.me> |
| In reply to | #172518 |
On 19/08/2023 03:36, bart c wrote: > On Saturday, 19 August 2023 at 01:21:58 UTC+1, Ben Bacarisse wrote: >> bart c <bart...@gmail.com> writes: > >>> That is, you want to be able to type: >>> >>> X >>> >>> and not: >>> >>> X Y >> No, I want to type >> >> make >> make tests >> make install >> make clean >> make mylib.a > > I'm not familiar with how make is used. Do you routinely have to invoke it five times in succession? Maybe that's a deeper problem with it, but as I said I don't use it. > So you are not familiar with make, yet you feel qualified to tell those who /do/ use it how terrible it is? Is it any wonder people question your judgements? Perhaps it is just your unfamiliarity with common development practices, but I expect everyone else understood that Ben's list there had implied "or" between the lines - he can type any or all of such commands, as and when he feels it is appropriate as he works. It's quite unusual to make multiple targets one after the other like that (other than perhaps something like "make && make install" or "make clean && make all"). The great thing about dependencies and a tool like make is that you generally only need to specify a single target, and make will build all the parts needed to get there. >> depending on what I'm doing rather than >> >> make makefile >> make makefile tests >> make makefile install >> make makefile clean >> make makefile mylib.a > > And this actually tells me that the main input is identical in all cases; I'd been wondering what was being done with mylib.a. But whatever it is, the same makefile that does all the other stuff contains some formula for 'mylib.a'? > The same makefile will contain rules for how to build all the targets, yes. > In practice I doubt you would type this five times as normally you'd do line recall then change the last bit. You can also choose to give it a shorter name than 'makefile'! > In practice, he would not run a series of different make targets like that, as explained above. And since make uses "makefile" as the default name, that's far better than using a short, cryptic name for the makefile. >> What's more, tab completion in my shell works with make's targets, but I >> don't think that's at all easy to do if the makefile has to be named in >> the same command. >>> like nearly every other command line program. >> >>> Yet being able to do >>> >>> X Y >>> >>> instead of: >>> >>> X Y.Z >>> >>> on those other programs is anathema. >> Well (if you are talking about having to say gcc prog.c rather than gcc >> prog) there are advantages, and none of them have anything to do with >> how much one has to type. After all, command completion means I rarely >> type a file name explcitly anyway. > > If my C test folder, I had 23 files that started with 'hello'. And there's your problem. > Although they are stepped through in alphabetical order on Windows and .c is near the top, you still have to tentatively keep pressing tab, then you go too far and need shift-tab .. it is quicker just to type the extension! Better however not to have to bother. The inadequacies of Window's primitive form of tab completion is not a flaw in gcc. Either use a better shell (they are alternatives available for Windows - and I gather Powershell is less bad here), or avoid making your life harder by picking filenames that don't all start with "hello". > > >> The main advantage is that there's no need to specify and remember all >> the rules. Does gcc always add .c? Will it add .c if I type gcc >> prog.s? Must I avoid any dots in the basename? What happens when >> several names appear on the command line? > > gcc is a bad example to follow since it does too much on the command line and performs multiple functions. So it easy to argue that, because it handles 58 different file types (I've no idea), singling one out to use a default is senseless. > Ah, gcc is bad because it does so much more than your toy compiler? > But with a simpler product whose primary input files are C source files, then a default .c extension makes a lot of sense. > I've used other compilers that are pure C compilers (they have all been Windows-only or DOS-only, not *nix tools). They expected a full filename - it just makes things so much easier and consistent. There is rarely any significant benefit in a default extension for an input file. > The rules on Windows can be simple: if there is no extension (no dot in the name), then a default extension is added. Windows has no such rule - programs do their own thing. When /saving/ files, it is common to add a default extension if the file extension is entirely obvious - that's another matter, and can save a few keystrokes. And then Windows has the utterly insane idea of hiding file extensions by default in its gui tools. This trick has been a godsend to malware writers, who can name their files "readme.txt.exe" or "Nude pictures.jpg.exe", so that people think they are safe to open. And it is a nightmare for anyone using their machine for development, because now your files "hello.c", "hello.h", "hello.o", "hello.exe", "hello.txt" are listed as "hello" five times. The idiocies of Windows are, of course, no relevance to make or gcc - but don't tout Windows or Windows conventions as though they were good examples of developer-friendly practices! > It's harder with a Linux file system because files "abc" and "abc." are distinct; how to do apply a default extension to "abc" when that could be a valid filename? > Why would you want to? On real systems, the type of a file is determined primarily by what the file contains, not some three-letter relic from the 1980's. Filename extensions should be for the convenience of the /user/ - not something for a tool to get flustered about just because I happen to call a file "program_ver.1.02.c". > However on Windows and various other OSes before that over decades, it hasn't really given any problems. > >>> So either 'X Y' is too much to type, or `X Y' is not enough! Even >>> though you will be using the latter case more often. >> No. I don't think anyone cares about how much one types (I don't) >> provided there is some point to it. It's annoying to be forced to type >> something redundant every time, whereas it's potentially confusing to >> have gcc pick default extensions. > > Exactly. I consider the '.c -oprog' in 'gcc prog.c -oprog' to be redundant. Note that on Windows, it will apply the .exe extension to that output. For the limited little world you live in, it might happen to be redundant for you. Since no one but you uses your tools, you have no comparison. Accept that the rest of the world can have different opinions. > > >>> It's fascinating watching psychology and group-think at work. >> As usual, you've invented a position (it'a all about the typing) and >> argued about that instead of taking on board the actual comments that >> people have made. > > The typing is part of it. Using the same default file in this case seem to me to be fragile. Well, I for one will give that thought all the weight it deserves in light of your extensive experience with the tool. > Remember the Github Lua with the missing makefile? I didn't know there were supposed to be two, and assume that one called 'makefile' was /the/ makefile. Or someone could simply be in the wrong folder. > Again, your experience will be given due consideration.
[toc] | [prev] | [next] | [standalone]
| From | bart c <bart4858@gmail.com> |
|---|---|
| Date | 2023-08-19 05:35 -0700 |
| Message-ID | <b55b3282-43c9-4f6b-918a-6dcc00480262n@googlegroups.com> |
| In reply to | #172528 |
On Saturday, 19 August 2023 at 12:51:42 UTC+1, David Brown wrote:
> On 19/08/2023 03:36, bart c wrote:
> > On Saturday, 19 August 2023 at 01:21:58 UTC+1, Ben Bacarisse wrote:
> >> bart c <bart...@gmail.com> writes:
> >
> >>> That is, you want to be able to type:
> >>>
> >>> X
> >>>
> >>> and not:
> >>>
> >>> X Y
> >> No, I want to type
> >>
> >> make
> >> make tests
> >> make install
> >> make clean
> >> make mylib.a
> >
> > I'm not familiar with how make is used. Do you routinely have to invoke it five times in succession? Maybe that's a deeper problem with it, but as I said I don't use it.
> >
> So you are not familiar with make, yet you feel qualified to tell those
> who /do/ use it how terrible it is? Is it any wonder people question
> your judgements?
Call it the equivalent of a 'code smell'.
> Perhaps it is just your unfamiliarity with common development practices,
> but I expect everyone else understood that Ben's list there had implied
> "or" between the lines - he can type any or all of such commands, as and
> when he feels it is appropriate as he works. It's quite unusual to make
> multiple targets one after the other like that (other than perhaps
> something like "make && make install" or "make clean && make all"). The
> great thing about dependencies and a tool like make is that you
> generally only need to specify a single target, and make will build all
> the parts needed to get there.
I use a toy IDE. Once you load a project file, then the command line interface allows simple commands like:
c compile (either whole program, or module for C)
l (link, C only)
r (run)
g (go, just do whatever is needed to run the program)
It has a working context. The way 'make' works is a crude way of creating such a context, from command line. For my taste, it's too crude. It makes my 1980s style IDE look sophisticated.
> > Although they are stepped through in alphabetical order on Windows and .c is near the top, you still have to tentatively keep pressing tab, then you go too far and need shift-tab .. it is quicker just to type the extension! Better however not to have to bother.
> The inadequacies of Window's primitive form of tab completion is not a
> flaw in gcc.
I found Linux tab completion unusable.
> > gcc is a bad example to follow since it does too much on the command line and performs multiple functions. So it easy to argue that, because it handles 58 different file types (I've no idea), singling one out to use a default is senseless.
> >
> Ah, gcc is bad because it does so much more than your toy compiler?
It's a Swiss Army knife; it does everything. You don't have a streamlined way of using it for one task.
I thought Linux was famous for being a collection of tools that each had one simple job? Then you chained them together. gcc breaks that.
> > But with a simpler product whose primary input files are C source files, then a default .c extension makes a lot of sense.
> >
> I've used other compilers that are pure C compilers (they have all been
> Windows-only or DOS-only, not *nix tools). They expected a full
> filename - it just makes things so much easier and consistent.
Yes, I said this. The 1000 times I have to invole Lua on a like name, I've had to type 'lua' twice: 'lua prog.lua'. Redundancy.
Maybe I can use a null extension? I don't know. I do know that I don't want a bunch of files of mixed languages all having no extension! I WANT extensions, but I shouldn't need to type them for a dedicated tool that only works with that extension anyway.
There is
> rarely any significant benefit in a default extension for an input file.
> > The rules on Windows can be simple: if there is no extension (no dot in the name), then a default extension is added.
> Windows has no such rule - programs do their own thing.
>
> When /saving/ files, it is common to add a default extension if the file
> extension is entirely obvious - that's another matter, and can save a
> few keystrokes.
You're making excuses for gcc! I reinstalled gcc 10.3.0 to try this:
gcc -shared -obignum bignum.c
What is the obvious extension here? I expected bignum.dll, it produces bignum.exe.
My bcc product worked like this:
bcc -dll bignum
it produced bignum.dll. It's not rocket science.
> And then Windows has the utterly insane idea of hiding file extensions
> by default in its gui tools.
I agree, that was a stupid idea. I avoid using GUI though mostly for other reasons: they are too fiddly.
> The idiocies of Windows are, of course, no relevance to make or gcc -
> but don't tout Windows or Windows conventions as though they were good
> examples of developer-friendly practices!
An executable called abc.def can be run by typing abc.def.
One called ghi.jkl.exe can be running by typing either ghi.jkl or ghi.jkl.exe. The rules seem to work well, even with embedded periods, unless you try and have a file called ghi.exe.exe and there is also one called ghi.exe (I haven't tried it).
But it means executables can HAVE extensions, which is highly desirable, but you rarely have to type 'gcc.exe' for example. On Linux you /would/ have to type gcc.exe.
> > It's harder with a Linux file system because files "abc" and "abc." are distinct; how to do apply a default extension to "abc" when that could be a valid filename?
> >
> Why would you want to?
Ask the user. There was a huge thread about being able to use - or -? as a filename, so why not both abc and abc.? Note this was on Linux.
> > Remember the Github Lua with the missing makefile? I didn't know there were supposed to be two, and assume that one called 'makefile' was /the/ makefile. Or someone could simply be in the wrong folder.
> >
> Again, your experience will be given due consideration.
I tinkered with make on and off for decades. It never went well. It never bought me anything extra for my own stuff.
[toc] | [prev] | [next] | [standalone]
| From | Kelsey Bjarnason <kbjarnason@gmail.com> |
|---|---|
| Date | 2023-08-19 00:35 -0700 |
| Message-ID | <nv76rj-6r2.ln1@spanky.localhost.net> |
| In reply to | #172518 |
On Fri, 18 Aug 2023 18:36:51 -0700 (PDT), bart c wrote: > On Saturday, 19 August 2023 at 01:21:58 UTC+1, Ben Bacarisse wrote: >> bart c <bart...@gmail.com> writes: > >> > That is, you want to be able to type: >> > >> > X >> > >> > and not: >> > >> > X Y >> No, I want to type >> >> make make tests make install make clean make mylib.a > > I'm not familiar with how make is used. Do you routinely have to invoke > it five times in succession? Maybe that's a deeper problem with it, but > as I said I don't use it. > >> depending on what I'm doing rather than >> >> make makefile make makefile tests make makefile install make makefile >> clean make makefile mylib.a > > And this actually tells me that the main input is identical in all > cases; I'd been wondering what was being done with mylib.a. But whatever > it is, the same makefile that does all the other stuff contains some > formula for 'mylib.a'? > > In practice I doubt you would type this five times as normally you'd do > line recall then change the last bit. You can also choose to give it a > shorter name than 'makefile'! No, normally you'd do something like: make && make tests && make install && make clean && make mylib.a Then get a coffee while it does all of these in succession. >> What's more, tab completion in my shell works with make's targets, but >> I don't think that's at all easy to do if the makefile has to be named >> in the same command. >> > like nearly every other command line program. >> >> > Yet being able to do >> > >> > X Y >> > >> > instead of: >> > >> > X Y.Z >> > >> > on those other programs is anathema. >> Well (if you are talking about having to say gcc prog.c rather than gcc >> prog) there are advantages, and none of them have anything to do with >> how much one has to type. After all, command completion means I rarely >> type a file name explcitly anyway. > > If my C test folder, I had 23 files that started with 'hello'. Although > they are stepped through in alphabetical order on Windows and .c is near > the top, you still have to tentatively keep pressing tab, then you go > too far and need shift-tab .. it is quicker just to type the extension! > Better however not to have to bother. A good argument for sensible file naming conventions, one would think. >> The main advantage is that there's no need to specify and remember all >> the rules. Does gcc always add .c? Will it add .c if I type gcc prog.s? >> Must I avoid any dots in the basename? What happens when several names >> appear on the command line? > > gcc is a bad example to follow since it does too much on the command > line and performs multiple functions. So it easy to argue that, because > it handles 58 different file types (I've no idea), singling one out to > use a default is senseless. > > But with a simpler product whose primary input files are C source files, > then a default .c extension makes a lot of sense. > > The rules on Windows can be simple: if there is no extension (no dot in > the name), then a default extension is added. It's harder with a Linux > file system because files "abc" and "abc." are distinct; how to do apply > a default extension to "abc" when that could be a valid filename? One might think you don't; if I tell a compiler to compile "file", I would expect it to compile "file", not "file.c" or "file.cpp" or "file.asm". If it can't determine the language other than by file extension, then it's up to me to ensure the files have the proper extension, and I tell it which to compile. Using your sort of examples, I might have file.c, file.cpp and file.asm in the directory - which one is it supposed to choose if I tell it to just compile "file"? > However on Windows and various other OSes before that over decades, it > hasn't really given any problems. > >> > So either 'X Y' is too much to type, or `X Y' is not enough! Even >> > though you will be using the latter case more often. >> No. I don't think anyone cares about how much one types (I don't) >> provided there is some point to it. It's annoying to be forced to type >> something redundant every time, whereas it's potentially confusing to >> have gcc pick default extensions. > > Exactly. I consider the '.c -oprog' in 'gcc prog.c -oprog' to be > redundant. Note that on Windows, it will apply the .exe extension to > that output. You don't need to specify -oprog if you don't want; you just wind up with a.out instead of prog as the result. Entirely up to you. >> > It's fascinating watching psychology and group-think at work. >> As usual, you've invented a position (it'a all about the typing) and >> argued about that instead of taking on board the actual comments that >> people have made. > > The typing is part of it. Using the same default file in this case seem > to me to be fragile. Remember the Github Lua with the missing makefile? > I didn't know there were supposed to be two, and assume that one called > 'makefile' was /the/ makefile. Or someone could simply be in the wrong > folder.
[toc] | [prev] | [next] | [standalone]
| From | bart c <bart4858@gmail.com> |
|---|---|
| Date | 2023-08-19 09:54 -0700 |
| Message-ID | <94380001-0115-4e3e-9274-168d3e3a9573n@googlegroups.com> |
| In reply to | #172545 |
On Saturday, 19 August 2023 at 17:03:41 UTC+1, Kelsey Bjarnason wrote:
> On Fri, 18 Aug 2023 18:36:51 -0700 (PDT), bart c wrote:
>
> > On Saturday, 19 August 2023 at 01:21:58 UTC+1, Ben Bacarisse wrote:
> >> bart c <bart...@gmail.com> writes:
> >
> >> > That is, you want to be able to type:
> >> >
> >> > X
> >> >
> >> > and not:
> >> >
> >> > X Y
> >> No, I want to type
> >>
> >> make make tests make install make clean make mylib.a
> >
> > I'm not familiar with how make is used. Do you routinely have to invoke
> > it five times in succession? Maybe that's a deeper problem with it, but
> > as I said I don't use it.
> >
> >> depending on what I'm doing rather than
> >>
> >> make makefile make makefile tests make makefile install make makefile
> >> clean make makefile mylib.a
> >
> > And this actually tells me that the main input is identical in all
> > cases; I'd been wondering what was being done with mylib.a. But whatever
> > it is, the same makefile that does all the other stuff contains some
> > formula for 'mylib.a'?
> >
> > In practice I doubt you would type this five times as normally you'd do
> > line recall then change the last bit. You can also choose to give it a
> > shorter name than 'makefile'!
> No, normally you'd do something like:
>
> make && make tests && make install && make clean && make mylib.a
If only there was a way of scripting that...
Obviously you can't use make and a makefile, since for one thing, 'makefile' has already been used, and using any other name is apparently a no-no.
> Then get a coffee while it does all of these in succession.
I wonder what it is about the stuff I do then I've never had any build process that took long enough to make and consume a cup of coffee. No even when working on machines 1000 times slower than they are now.
> >> What's more, tab completion in my shell works with make's targets, but
> > The rules on Windows can be simple: if there is no extension (no dot in
> > the name), then a default extension is added. It's harder with a Linux
> > file system because files "abc" and "abc." are distinct; how to do apply
> > a default extension to "abc" when that could be a valid filename?
> One might think you don't; if I tell a compiler to compile "file", I would
> expect it to compile "file", not "file.c" or "file.cpp" or "file.asm".
On Windows, "file" and "file." are the same file. So you can omit the extension /and/ period to mean the extension is unspecified. That leaves the app free to apply sensible defaults if the numbers of file types it deals with are restricted.
> If
> it can't determine the language other than by file extension, then it's up
> to me to ensure the files have the proper extension, and I tell it which
> to compile. Using your sort of examples, I might have file.c, file.cpp
> and file.asm in the directory - which one is it supposed to choose if I
> tell it to just compile "file"?
You have one tool that compiles C code, or C++, or ASM files? That's called making a rod for your own back. This is my point about gcc.
However, what input files does the 'as' assembler normally deal with? Isn't it just '.s' files? So that'd be an easy one to guess, would it not?
My own assembler is called 'aa':
aa x y z
this assembles files x.asm, y.asm and z.asm, and writes x.exe. I prefer writing that to:
aa x.asm y.asm z.asm -ox.exe
I'm funny that way.
> You don't need to specify -oprog if you don't want; you just wind up with
> a.out instead of prog as the result. Entirely up to you.
Well, obviously I don't want. Nobody does, except that's what they're told they're going to get, and being lazy bastards like most people (and like me), they don't bother overriding. But then they have to deal with a.out. Or, on Windows (where really, they could have fixed it as there was no prior art), a.exe.
[toc] | [prev] | [next] | [standalone]
| From | Kelsey Bjarnason <kbjarnason@gmail.com> |
|---|---|
| Date | 2023-08-19 12:30 -0700 |
| Message-ID | <drh7rj-1ci.ln1@spanky.localhost.net> |
| In reply to | #172548 |
On Sat, 19 Aug 2023 09:54:49 -0700 (PDT), bart c wrote: > On Saturday, 19 August 2023 at 17:03:41 UTC+1, Kelsey Bjarnason wrote: >> On Fri, 18 Aug 2023 18:36:51 -0700 (PDT), bart c wrote: >> >> > On Saturday, 19 August 2023 at 01:21:58 UTC+1, Ben Bacarisse wrote: >> >> bart c <bart...@gmail.com> writes: >> > >> >> > That is, you want to be able to type: >> >> > >> >> > X >> >> > >> >> > and not: >> >> > >> >> > X Y >> >> No, I want to type >> >> >> >> make make tests make install make clean make mylib.a >> > >> > I'm not familiar with how make is used. Do you routinely have to >> > invoke it five times in succession? Maybe that's a deeper problem >> > with it, but as I said I don't use it. >> > >> >> depending on what I'm doing rather than >> >> >> >> make makefile make makefile tests make makefile install make >> >> makefile clean make makefile mylib.a >> > >> > And this actually tells me that the main input is identical in all >> > cases; I'd been wondering what was being done with mylib.a. But >> > whatever it is, the same makefile that does all the other stuff >> > contains some formula for 'mylib.a'? >> > >> > In practice I doubt you would type this five times as normally you'd >> > do line recall then change the last bit. You can also choose to give >> > it a shorter name than 'makefile'! >> No, normally you'd do something like: >> >> make && make tests && make install && make clean && make mylib.a > > If only there was a way of scripting that... > > Obviously you can't use make and a makefile, since for one thing, > 'makefile' has already been used, and using any other name is apparently > a no-no. That *would be* using a makefile. One with multiple targets. You just specify which target you want to build, or use the default target which is virtually always the relevant, expected output - library, executable, whatever. And why script something when a) it adds nothing of value, and b) you may want to vary what gets built from run to run, so you just specify what you want built instead of editing the script every time? This is actually simpler than using a script. > >> Then get a coffee while it does all of these in succession. > > I wonder what it is about the stuff I do then I've never had any build > process that took long enough to make and consume a cup of coffee. No > even when working on machines 1000 times slower than they are now. Depends on too many factors to evaluate here. I have code that's tens of thousands of lines long and builds in a flash. I have other code that's rather less lengthy and compiles much more slowly. Depends on code, compiler, optimization settings, language involved, dependency resolution, caching, too many things to evaluate unless one does a "clean" comparison of the same code, the same optimization levels, etc. > >> >> What's more, tab completion in my shell works with make's targets, >> >> but > >> > The rules on Windows can be simple: if there is no extension (no dot >> > in the name), then a default extension is added. It's harder with a >> > Linux file system because files "abc" and "abc." are distinct; how to >> > do apply a default extension to "abc" when that could be a valid >> > filename? > >> One might think you don't; if I tell a compiler to compile "file", I >> would expect it to compile "file", not "file.c" or "file.cpp" or >> "file.asm". > > On Windows, "file" and "file." are the same file. So you can omit the > extension /and/ period to mean the extension is unspecified. That leaves > the app free to apply sensible defaults if the numbers of file types it > deals with are restricted. > > >> If it can't determine the language other than by file extension, then >> it's up to me to ensure the files have the proper extension, and I tell >> it which to compile. Using your sort of examples, I might have file.c, >> file.cpp and file.asm in the directory - which one is it supposed to >> choose if I tell it to just compile "file"? > > You have one tool that compiles C code, or C++, or ASM files? That's > called making a rod for your own back. This is my point about gcc. Last I checked. most of the Windows compilers would happily compile C and C++ files, based on extension. So when I say "compile file", do I mean file.c or file.cpp? > However, what input files does the 'as' assembler normally deal with? > Isn't it just '.s' files? So that'd be an easy one to guess, would it > not? > > My own assembler is called 'aa': > > aa x y z > > this assembles files x.asm, y.asm and z.asm, and writes x.exe. I prefer > writing that to: > > aa x.asm y.asm z.asm -ox.exe > > I'm funny that way. Indeed. I'd rather just write "make" and have it all be done, complete with ensuring any out of date intermediate files are properly generated first. It's shorter to write, and it takes care of unintentional oversights. > > >> You don't need to specify -oprog if you don't want; you just wind up >> with a.out instead of prog as the result. Entirely up to you. > > Well, obviously I don't want. Nobody does, except that's what they're > told they're going to get, and being lazy bastards like most people (and > like me), they don't bother overriding. But then they have to deal with > a.out. Or, on Windows (where really, they could have fixed it as there > was no prior art), a.exe. Okay, so you get a.out/a.exe. And? By your logic above, that's preferable to, say, "myprogram.exe" - less typing. So here you want *more* typing, but up there you want less, despite arguing against using the optioon with both the *least* typing and the most output correctness assurance. You should really pick one side of whatever you're arguing for and stick with that; arguing both sides is just silly.
[toc] | [prev] | [next] | [standalone]
| From | bart c <bart4858@gmail.com> |
|---|---|
| Date | 2023-08-19 13:44 -0700 |
| Message-ID | <4d9cd1b8-1323-46c8-947b-5b8481a5b2cdn@googlegroups.com> |
| In reply to | #172552 |
On Saturday, 19 August 2023 at 20:35:53 UTC+1, Kelsey Bjarnason wrote:
> On Sat, 19 Aug 2023 09:54:49 -0700 (PDT), bart c wrote:
>
> > On Saturday, 19 August 2023 at 17:03:41 UTC+1, Kelsey Bjarnason wrote:
> >> On Fri, 18 Aug 2023 18:36:51 -0700 (PDT), bart c wrote:
> >>
> >> > On Saturday, 19 August 2023 at 01:21:58 UTC+1, Ben Bacarisse wrote:
> >> >> bart c <bart...@gmail.com> writes:
> >> >
> >> >> > That is, you want to be able to type:
> >> >> >
> >> >> > X
> >> >> >
> >> >> > and not:
> >> >> >
> >> >> > X Y
> >> >> No, I want to type
> >> >>
> >> >> make make tests make install make clean make mylib.a
> >> >
> >> > I'm not familiar with how make is used. Do you routinely have to
> >> > invoke it five times in succession? Maybe that's a deeper problem
> >> > with it, but as I said I don't use it.
> >> >
> >> >> depending on what I'm doing rather than
> >> >>
> >> >> make makefile make makefile tests make makefile install make
> >> >> makefile clean make makefile mylib.a
> >> >
> >> > And this actually tells me that the main input is identical in all
> >> > cases; I'd been wondering what was being done with mylib.a. But
> >> > whatever it is, the same makefile that does all the other stuff
> >> > contains some formula for 'mylib.a'?
> >> >
> >> > In practice I doubt you would type this five times as normally you'd
> >> > do line recall then change the last bit. You can also choose to give
> >> > it a shorter name than 'makefile'!
> >> No, normally you'd do something like:
> >>
> >> make && make tests && make install && make clean && make mylib.a
> >
> > If only there was a way of scripting that...
> >
> > Obviously you can't use make and a makefile, since for one thing,
> > 'makefile' has already been used, and using any other name is apparently
> > a no-no.
> That *would be* using a makefile. One with multiple targets. You just
> specify which target you want to build, or use the default target which is
> virtually always the relevant, expected output - library, executable,
> whatever.
>
> And why script something when a) it adds nothing of value, and b) you may
> want to vary what gets built from run to run, so you just specify what you
> want built instead of editing the script every time?
Exactly. Doing ad hoc stuff like this:
bcc prog
prog
tcc proc.c
prog
gcc prog.c
a (gcc just HAS to be different!)
gcc prog.c -O3
a
Is easier than messing about with makefiles. But you seem to be under the impression that using a makefile isn't running a script. I don't get it.
Show me how you're do those 4 compilations using make, without a specially written make script.
> > I wonder what it is about the stuff I do then I've never had any build
> > process that took long enough to make and consume a cup of coffee. No
> > even when working on machines 1000 times slower than they are now.
> Depends on too many factors to evaluate here. I have code that's tens of
> thousands of lines long and builds in a flash. I have other code that's
> rather less lengthy and compiles much more slowly. Depends on code,
> compiler, optimization settings, language involved, dependency resolution,
> caching, too many things to evaluate unless one does a "clean" comparison
> of the same code, the same optimization levels, etc.
Has it ever take long enough to /enjoy/ drinking a coffee?
Unfortunately, since most of my stuff builds in 0.1 seconds, it will have finished doing so as soon as I've released the Enter key. Back to work!
> > My own assembler is called 'aa':
> >
> > aa x y z
> >
> > this assembles files x.asm, y.asm and z.asm, and writes x.exe. I prefer
> > writing that to:
> >
> > aa x.asm y.asm z.asm -ox.exe
> >
> > I'm funny that way.
> Indeed. I'd rather just write "make" and have it all be done, complete
> with ensuring any out of date intermediate files are properly generated
> first. It's shorter to write, and it takes care of unintentional
> oversights.
That's scripting! I can just stick that line in a make.bat file and then type:
make
But I don't normally work from the command line except for ad hoc invocations with variable options as already explained. Scripting here works poorly.
> You should really pick one side of whatever you're arguing for and stick
> with that; arguing both sides is just silly.
It's the way that your tools work that is silly, since the direct tools are too verbose, and make is scarily not verbose enough.
On the one hand you have to do:
gcc main.c a.c b.c -omain
On the other, you want to just do:
make
which ... does what? All that stuff is put inside 'makefile' in a form which is even more verbose since it will split it up into dependencies between .c, .h and .o files.
But, now instead of your project being defined as THREE source files, ONE tool and ONE language: {main + a + b, gcc, C}, it is defined as FOUR source files, TWO tools and TWO languages:
{main + a + b + makefile, gcc + make, C + make-syntax}
There is no happy medium such as is used by my product:
bcc main a b
bcc -auto main # using automatic module discovery with a suitably structured project.
In that second example, the project is defined (ie. can be fully described to the build process) as ONE source file, ONE tool and ONE language: {main, bcc, C}
Now, people like David Brown will try and argue that using 'make' like this:
make
The project is also defined as ONE source file, ONE tool, and ONE language: {makefile, make, make-syntax}. Or possibly even as ONE tool and ONE language since the implicit 'makefile' doesn't have to figure in it.
You can believe that if you want. If so, try deleting the C compiler and see if it still builds.
[toc] | [prev] | [next] | [standalone]
| From | Kelsey Bjarnason <kbjarnason@gmail.com> |
|---|---|
| Date | 2023-08-21 17:58 -0700 |
| Message-ID | <mqddrj-g83.ln1@spanky.localhost.net> |
| In reply to | #172555 |
On Sat, 19 Aug 2023 13:44:28 -0700 (PDT), bart c wrote:
> On Saturday, 19 August 2023 at 20:35:53 UTC+1, Kelsey Bjarnason wrote:
>> On Sat, 19 Aug 2023 09:54:49 -0700 (PDT), bart c wrote:
>>
>> > On Saturday, 19 August 2023 at 17:03:41 UTC+1, Kelsey Bjarnason
>> > wrote:
>> >> On Fri, 18 Aug 2023 18:36:51 -0700 (PDT), bart c wrote:
>> >>
>> >> > On Saturday, 19 August 2023 at 01:21:58 UTC+1, Ben Bacarisse
>> >> > wrote:
>> >> >> bart c <bart...@gmail.com> writes:
>> >> >
>> >> >> > That is, you want to be able to type:
>> >> >> >
>> >> >> > X
>> >> >> >
>> >> >> > and not:
>> >> >> >
>> >> >> > X Y
>> >> >> No, I want to type
>> >> >>
>> >> >> make make tests make install make clean make mylib.a
>> >> >
>> >> > I'm not familiar with how make is used. Do you routinely have to
>> >> > invoke it five times in succession? Maybe that's a deeper problem
>> >> > with it, but as I said I don't use it.
>> >> >
>> >> >> depending on what I'm doing rather than
>> >> >>
>> >> >> make makefile make makefile tests make makefile install make
>> >> >> makefile clean make makefile mylib.a
>> >> >
>> >> > And this actually tells me that the main input is identical in all
>> >> > cases; I'd been wondering what was being done with mylib.a. But
>> >> > whatever it is, the same makefile that does all the other stuff
>> >> > contains some formula for 'mylib.a'?
>> >> >
>> >> > In practice I doubt you would type this five times as normally
>> >> > you'd do line recall then change the last bit. You can also choose
>> >> > to give it a shorter name than 'makefile'!
>> >> No, normally you'd do something like:
>> >>
>> >> make && make tests && make install && make clean && make mylib.a
>> >
>> > If only there was a way of scripting that...
>> >
>> > Obviously you can't use make and a makefile, since for one thing,
>> > 'makefile' has already been used, and using any other name is
>> > apparently a no-no.
>> That *would be* using a makefile. One with multiple targets. You just
>> specify which target you want to build, or use the default target which
>> is virtually always the relevant, expected output - library,
>> executable, whatever.
>>
>> And why script something when a) it adds nothing of value, and b) you
>> may want to vary what gets built from run to run, so you just specify
>> what you want built instead of editing the script every time?
>
> Exactly. Doing ad hoc stuff like this:
>
> bcc prog prog tcc proc.c prog gcc prog.c a (gcc just
> HAS to be different!)
> gcc prog.c -O3 a
>
> Is easier than messing about with makefiles. But you seem to be under
> the impression that using a makefile isn't running a script. I don't get
> it.
Call it a script if you like. The point remains, it does rather more than
merely "gcc -oprog prog.c"; for one, it ensures (assuming proper rules are
in place) both that modified dependencies get rebuilt, and that unmodified
ones don't unless told to.
So just as a trivial example, assume we have a dependency tree like so:
types.h
interface.h
interface.c
chess.h
engine.c
Now interface.h gets modified. Make would cause interface.c to be rebuilt
and the final output (executable, presumably) to be rebuilt, but not
engine.c.
How does your script manage this - rebuilding what is necessary to
rebuild, but *only* what is necessary to rebuild?
> Show me how you're do those 4 compilations using make, without a
> specially written make script.
>
>> > I wonder what it is about the stuff I do then I've never had any
>> > build process that took long enough to make and consume a cup of
>> > coffee. No even when working on machines 1000 times slower than they
>> > are now.
>> Depends on too many factors to evaluate here. I have code that's tens
>> of thousands of lines long and builds in a flash. I have other code
>> that's rather less lengthy and compiles much more slowly. Depends on
>> code, compiler, optimization settings, language involved, dependency
>> resolution,
>> caching, too many things to evaluate unless one does a "clean"
>> comparison of the same code, the same optimization levels, etc.
>
> Has it ever take long enough to /enjoy/ drinking a coffee?
Yes. See elsethread.
>
> Unfortunately, since most of my stuff builds in 0.1 seconds, it will
> have finished doing so as soon as I've released the Enter key. Back to
> work!
>
>
>> > My own assembler is called 'aa':
>> >
>> > aa x y z
>> >
>> > this assembles files x.asm, y.asm and z.asm, and writes x.exe. I
>> > prefer writing that to:
>> >
>> > aa x.asm y.asm z.asm -ox.exe
>> >
>> > I'm funny that way.
>
>> Indeed. I'd rather just write "make" and have it all be done, complete
>> with ensuring any out of date intermediate files are properly generated
>> first. It's shorter to write, and it takes care of unintentional
>> oversights.
>
> That's scripting! I can just stick that line in a make.bat file and then
> type:
>
> make
>
> But I don't normally work from the command line except for ad hoc
> invocations with variable options as already explained. Scripting here
> works poorly.
>
>> You should really pick one side of whatever you're arguing for and
>> stick with that; arguing both sides is just silly.
>
> It's the way that your tools work that is silly, since the direct tools
> are too verbose, and make is scarily not verbose enough.
>
> On the one hand you have to do:
>
> gcc main.c a.c b.c -omain
>
> On the other, you want to just do:
>
> make
>
> which ... does what? All that stuff is put inside 'makefile' in a form
> which is even more verbose since it will split it up into dependencies
> between .c, .h and .o files.
>
> But, now instead of your project being defined as THREE source files,
> ONE tool and ONE language: {main + a + b, gcc, C}, it is defined as FOUR
> source files, TWO tools and TWO languages:
>
> {main + a + b + makefile, gcc + make, C + make-syntax}
>
> There is no happy medium such as is used by my product:
>
> bcc main a b bcc -auto main # using automatic module discovery
> with a suitably structured project.
>
> In that second example, the project is defined (ie. can be fully
> described to the build process) as ONE source file, ONE tool and ONE
> language: {main, bcc, C}
>
> Now, people like David Brown will try and argue that using 'make' like
> this:
>
> make
>
> The project is also defined as ONE source file, ONE tool, and ONE
> language: {makefile, make, make-syntax}. Or possibly even as ONE tool
> and ONE language since the implicit 'makefile' doesn't have to figure in
> it.
>
> You can believe that if you want. If so, try deleting the C compiler and
> see if it still builds.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-22 02:28 +0100 |
| Message-ID | <uc12vt$245uh$2@dont-email.me> |
| In reply to | #172649 |
On 22/08/2023 01:58, Kelsey Bjarnason wrote: > On Sat, 19 Aug 2023 13:44:28 -0700 (PDT), bart c wrote: >> Is easier than messing about with makefiles. But you seem to be under >> the impression that using a makefile isn't running a script. I don't get >> it. > > Call it a script if you like. The point remains, it does rather more than > merely "gcc -oprog prog.c"; for one, it ensures (assuming proper rules are > in place) both that modified dependencies get rebuilt, and that unmodified > ones don't unless told to. > > So just as a trivial example, assume we have a dependency tree like so: > > types.h > interface.h > interface.c > chess.h > engine.c > > Now interface.h gets modified. Make would cause interface.c to be rebuilt > and the final output (executable, presumably) to be rebuilt, but not > engine.c. > > How does your script manage this - rebuilding what is necessary to > rebuild, but *only* what is necessary to rebuild? It wouldn't. At the point /I/ come across makefiles, I only want to build the app from scratch. So everything will need compiling anyway. I don't need all those complications. I've made this point half a dozen times.
[toc] | [prev] | [next] | [standalone]
| From | Kelsey Bjarnason <kbjarnason@gmail.com> |
|---|---|
| Date | 2023-08-22 00:12 -0700 |
| Message-ID | <mo3erj-n3c.ln1@spanky.localhost.net> |
| In reply to | #172651 |
On Tue, 22 Aug 2023 02:28:29 +0100, Bart wrote: > On 22/08/2023 01:58, Kelsey Bjarnason wrote: >> On Sat, 19 Aug 2023 13:44:28 -0700 (PDT), bart c wrote: > >>> Is easier than messing about with makefiles. But you seem to be under >>> the impression that using a makefile isn't running a script. I don't >>> get it. >> >> Call it a script if you like. The point remains, it does rather more >> than merely "gcc -oprog prog.c"; for one, it ensures (assuming proper >> rules are in place) both that modified dependencies get rebuilt, and >> that unmodified ones don't unless told to. >> >> So just as a trivial example, assume we have a dependency tree like so: >> >> types.h >> interface.h >> interface.c >> chess.h >> engine.c >> >> Now interface.h gets modified. Make would cause interface.c to be >> rebuilt and the final output (executable, presumably) to be rebuilt, >> but not engine.c. > > > >> How does your script manage this - rebuilding what is necessary to >> rebuild, but *only* what is necessary to rebuild? > > It wouldn't. At the point /I/ come across makefiles, I only want to > build the app from scratch. So everything will need compiling anyway. I > don't need all those complications. > > I've made this point half a dozen times. That's great if you only work on toy-sized apps. I've worked on apps where it took the combined effort of an entire network of machines half a day to do a complete rebuild, which is obviously not viable if you have multiple coders modifying multiple files and needing to keep changes up to date and in sync. But rebuilding just the few bits which have been modified, or have had their dependencies modified, becomes trivial with a proper makefile. You type "make", wait for the few modules to build, then carry on. Maybe a couple minutes. And you're not working to outdated objects, because of dependency checking. I'm sure you could do the same with a script, as well, but then you're just trading one "build language" for another, less well known, less well established one.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-22 11:13 +0100 |
| Message-ID | <uc21oo$2caqg$1@dont-email.me> |
| In reply to | #172653 |
On 22/08/2023 08:12, Kelsey Bjarnason wrote: > On Tue, 22 Aug 2023 02:28:29 +0100, Bart wrote: >> It wouldn't. At the point /I/ come across makefiles, I only want to >> build the app from scratch. So everything will need compiling anyway. I >> don't need all those complications. >> >> I've made this point half a dozen times. > > That's great if you only work on toy-sized apps. > > I've worked on apps where it took the combined effort of an entire network > of machines half a day to do a complete rebuild, which is obviously not > viable if you have multiple coders modifying multiple files and needing to > keep changes up to date and in sync. But rebuilding just the few bits > which have been modified, or have had their dependencies modified, becomes > trivial with a proper makefile. You type "make", wait for the few modules > to build, then carry on. Maybe a couple minutes. And you're not working > to outdated objects, because of dependency checking. What happens when you send me all the sources and I have to build from scratch; how does /my/ build-time benefit for a one-off compilation? > > I'm sure you could do the same with a script, as well, but then you're > just trading one "build language" for another, less well known, less well > established one. > What you're advising is to fly by 747 for all journeys even when a train, bus, car, bike or going on foot would be more apt. Have a look at the projects I've mentioned in this thread. The longest gcc-O0 from-scratch build, where it worked, was 23 seconds. (I'm not including the autoconf crap.) By all means use 'make' for your ginormous applications, but don't foist it on everybody and everything. (Where are these giant programs anyway? I once did a survey of all the EXEs and DLLS on my machine. I think 99% of all such files were under 10MB, or some such figures. My usual compilers can generate 10MB binaries in seconds. The largest binary was some 160MB, a DLL connected with Firefox I think, which almost certainly was a collection of smaller components.)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-22 11:36 +0100 |
| Message-ID | <uc232l$2cgpc$1@dont-email.me> |
| In reply to | #172654 |
On 22/08/2023 11:13, Bart wrote:
> On 22/08/2023 08:12, Kelsey Bjarnason wrote:
> (Where are these giant programs anyway? I once did a survey of all the
> EXEs and DLLS on my machine. I think 99% of all such files were under
> 10MB, or some such figures.
Looking only at my windows/system32 folder:
99.3% of EXEs were under 10MB, and 94% under 1MB
99.7% of DLLs were under 10MB, and 89% under 1MB
About 4000 files in total.
If you (KB) are talking about a system of EXEs and DLLS, then such files
are usually already independent from each other, or at least, any
dependencies are coarser.
You wouldn't use a make filefile that contains both the 1000 modules of
A.DLL, and the 1400 modules of B.DLL, simply because because A imports
B. At that rate you'd end up putting the modules of half those DLLs into
one makefile.
[toc] | [prev] | [next] | [standalone]
| From | Richard Harnden <richard.nospam@gmail.com> |
|---|---|
| Date | 2023-08-22 13:37 +0100 |
| Message-ID | <uc2a64$2diiv$1@dont-email.me> |
| In reply to | #172655 |
On 22/08/2023 11:36, Bart wrote: > On 22/08/2023 11:13, Bart wrote: >> On 22/08/2023 08:12, Kelsey Bjarnason wrote: > >> (Where are these giant programs anyway? I once did a survey of all the >> EXEs and DLLS on my machine. I think 99% of all such files were under >> 10MB, or some such figures. > > Looking only at my windows/system32 folder: > > 99.3% of EXEs were under 10MB, and 94% under 1MB > 99.7% of DLLs were under 10MB, and 89% under 1MB > > About 4000 files in total. > > If you (KB) are talking about a system of EXEs and DLLS, then such files > are usually already independent from each other, or at least, any > dependencies are coarser. > > You wouldn't use a make filefile that contains both the 1000 modules of > A.DLL, and the 1400 modules of B.DLL, simply because because A imports > B. At that rate you'd end up putting the modules of half those DLLs into > one makefile. > What do you mean by "module"?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-22 13:51 +0100 |
| Message-ID | <uc2b03$2dln7$1@dont-email.me> |
| In reply to | #172661 |
On 22/08/2023 13:37, Richard Harnden wrote: > On 22/08/2023 11:36, Bart wrote: >> On 22/08/2023 11:13, Bart wrote: >>> On 22/08/2023 08:12, Kelsey Bjarnason wrote: >> >>> (Where are these giant programs anyway? I once did a survey of all >>> the EXEs and DLLS on my machine. I think 99% of all such files were >>> under 10MB, or some such figures. >> >> Looking only at my windows/system32 folder: >> >> 99.3% of EXEs were under 10MB, and 94% under 1MB >> 99.7% of DLLs were under 10MB, and 89% under 1MB >> >> About 4000 files in total. >> >> If you (KB) are talking about a system of EXEs and DLLS, then such >> files are usually already independent from each other, or at least, >> any dependencies are coarser. >> >> You wouldn't use a make filefile that contains both the 1000 modules >> of A.DLL, and the 1400 modules of B.DLL, simply because because A >> imports B. At that rate you'd end up putting the modules of half those >> DLLs into one makefile. >> > > What do you mean by "module"? > In the current context it can mean every .c and .h that is identified by name in a makefile. Although when I wrote 'module' I loosely had in mind the translation unit, the assembly of .c and .h files, that comprise a single named .c source when it is processed by a compiler. Because my own script mention only explicit .c files, and not indirectly included .c and .h files.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-08-22 14:51 +0000 |
| Message-ID | <zX3FM.455985$U3w1.225957@fx09.iad> |
| In reply to | #172654 |
Bart <bc@freeuk.com> writes: >On 22/08/2023 08:12, Kelsey Bjarnason wrote: >(Where are these giant programs anyway? I once did a survey of all the >EXEs and DLLS on my machine. I think 99% of all such files were under >10MB, or some such figures. What makes your machine representative of the entire population of machines?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-22 17:19 +0100 |
| Message-ID | <uc2n6d$2fulv$1@dont-email.me> |
| In reply to | #172669 |
On 22/08/2023 15:51, Scott Lurndal wrote: > Bart <bc@freeuk.com> writes: >> On 22/08/2023 08:12, Kelsey Bjarnason wrote: > >> (Where are these giant programs anyway? I once did a survey of all the >> EXEs and DLLS on my machine. I think 99% of all such files were under >> 10MB, or some such figures. > > What makes your machine representative of the entire population of > machines? What makes yours representative? The system32 folder on my Windows 11 machine is representative of the vast population of the Windows machines. But you're welcome to post your own observations. You seem to be claiming that the majority of projects represented by a makefile are for huge projects. /I/ am claiming that most individual binaries you see in the wild are comparatively small.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-22 09:30 -0700 |
| Message-ID | <4f679261-dffa-4bd9-864b-3c19e0656907n@googlegroups.com> |
| In reply to | #172677 |
On Tuesday, 22 August 2023 at 17:19:40 UTC+1, Bart wrote: > On 22/08/2023 15:51, Scott Lurndal wrote: > > Bart <b...@freeuk.com> writes: > >> On 22/08/2023 08:12, Kelsey Bjarnason wrote: > > > >> (Where are these giant programs anyway? I once did a survey of all the > >> EXEs and DLLS on my machine. I think 99% of all such files were under > >> 10MB, or some such figures. > > > > What makes your machine representative of the entire population of > > machines? > What makes yours representative? > > The system32 folder on my Windows 11 machine is representative of the > vast population of the Windows machines. > > But you're welcome to post your own observations. > > You seem to be claiming that the majority of projects represented by a > makefile are for huge projects. > > /I/ am claiming that most individual binaries you see in the wild are > comparatively small. > That's on a PC used mainly for routine personal computing. Some programs are massive. But they do things like predict the weather or run spacecraft. You wouldn't have one on your personal system.
[toc] | [prev] | [next] | [standalone]
Page 5 of 16 — ← Prev page 1 … 3 4 [5] 6 7 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web