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 3 of 16 — ← Prev page 1 2 [3] 4 5 … 16 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-15 23:36 +0100 |
| Message-ID | <ubgulr$3095n$1@dont-email.me> |
| In reply to | #172339 |
On 15/08/2023 22:09, David Brown wrote: > On 15/08/2023 19:49, Bart wrote: > >> You know, one thing is going 100% certain in this thread: you are >> never for one minute going to admit that I'm right in there being >> something wrong with those Github ZIPs. >> >> You didn't see the problem because you either obtained the source >> bundle elsewhere, or would have used only the .tar.gz version. >> > > Look, I have no idea if these are the same or different. I don't know, > and don't care. The only reason I was at the lua website at all was > because /you/ picked it as something that "proves" that make never works > on Windows. I went to the lua website, followed the instructions on how > to build lua on Windows, and it worked - using "make". /You/ did not > not follow the instructions, I downloaded an open source project like I've done a hundred others: from Github. It's usually expected to have everything needed to build the project, except for the actual tools. > and you got in trouble. No doubt you'd > have got in trouble even if you did follow the instructions, because you > are always so determined to have everything fail. You don't see the failures because most open source software is developed for Unix-like OSes, so build systems are well-tested because so many will be using that and will have reported failures. In addition, even for software that runs on Windows, you hide behind a wall of Linux utilities; using MSYS2 or WSL. So really, it's not surprising that everything works for you with hardly needing to lift a finger. >> You know, I don't believe you actually know how to do this under plain >> Windows! Otherwise you would have done so; you must know that's what I >> use.) >> > > By /my/ ruling, any system with "bcc" or "tcc" is not plain Windows. > Therefore you failed. Huh? Those are compilers. You need a C compiler to turn .c files into .exe files. You don't need that other crap. >> So, what have /you/ achieved? >> > > I did exactly what you claimed was impossible I said when I tried it, it failed. > - used "make" to build Lua on windows. So did I in the end. But I'd long since done it anyway: * Without even needing the 'proper' source file bundle: the Github version was fine * Without using 'make' or the right makefile * Without using MSYS2 or CYGWIN * Without using WSL All in all I did better without using 'make'. I could even switch instantly between GCC and TCC. AND I built in with my BCC, which cannot be used from a makefile, not the one here anyway, because it expects a C compiler to work in a certain way.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-15 15:55 -0700 |
| Message-ID | <87pm3nlxuu.fsf@nosuchdomain.example.com> |
| In reply to | #172341 |
Bart <bc@freeuk.com> writes:
> On 15/08/2023 22:09, David Brown wrote:
>> On 15/08/2023 19:49, Bart wrote:
>>> You know, one thing is going 100% certain in this thread: you are
>>> never for one minute going to admit that I'm right in there being
>>> something wrong with those Github ZIPs.
>>>
>>> You didn't see the problem because you either obtained the source
>>> bundle elsewhere, or would have used only the .tar.gz version.
>>>
>>
>> Look, I have no idea if these are the same or different. I don't know,
>> and don't care. The only reason I was at the lua website at all was
>> because /you/ picked it as something that "proves" that make never works
>> on Windows. I went to the lua website, followed the instructions on how
>> to build lua on Windows, and it worked - using "make". /You/ did not
>> not follow the instructions,
>
> I downloaded an open source project like I've done a hundred others:
> from Github. It's usually expected to have everything needed to build
> the project, except for the actual tools.
And now you've learned that the "release" .tar.gz and .zip files
provided by GitHub are just snapshots of the git repo. Official source
releases are often generated from the git repo, with things like
documentation and configure scripts generated by the maintainers of the
project. Whether you can easily build something from a GitHub release
file depends on the project.
I suspect you resorted to the GitHub "release" files because lua.org
doesn't provide a zip file.
It's an understandable error -- and it gave you an excuse to complain
and insult people.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-16 01:05 +0100 |
| Message-ID | <ubh3s8$30v7t$1@dont-email.me> |
| In reply to | #172342 |
On 15/08/2023 23:55, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: >> On 15/08/2023 22:09, David Brown wrote: >>> On 15/08/2023 19:49, Bart wrote: >>>> You know, one thing is going 100% certain in this thread: you are >>>> never for one minute going to admit that I'm right in there being >>>> something wrong with those Github ZIPs. >>>> >>>> You didn't see the problem because you either obtained the source >>>> bundle elsewhere, or would have used only the .tar.gz version. >>>> >>> >>> Look, I have no idea if these are the same or different. I don't know, >>> and don't care. The only reason I was at the lua website at all was >>> because /you/ picked it as something that "proves" that make never works >>> on Windows. I went to the lua website, followed the instructions on how >>> to build lua on Windows, and it worked - using "make". /You/ did not >>> not follow the instructions, >> >> I downloaded an open source project like I've done a hundred others: >> from Github. It's usually expected to have everything needed to build >> the project, except for the actual tools. > > And now you've learned that the "release" .tar.gz and .zip files > provided by GitHub are just snapshots of the git repo. Official source > releases are often generated from the git repo, with things like > documentation and configure scripts generated by the maintainers of the > project. Whether you can easily build something from a GitHub release > file depends on the project. > > I suspect you resorted to the GitHub "release" files because lua.org > doesn't provide a zip file. > > It's an understandable error -- and it gave you an excuse to complain > and insult people. But it's not understood by David Brown, and it gave him an excuse to insult /me/. In his book, it's impossible for anything to go wrong, so if I can't get something to work, it HAS to be my fault. It can NEVER be the extra opportunities for error that complex makefiles provide, or even simple ones. No docs are too obscure or misleading (like lumping the 'mingw' parameter needed for Windows under Unix-like systems) And if can't make something work under ordinary Windows, my mistake is not using Linux-like layers to keep the build process happy. If even he has trouble pinning something on me (maybe somebody else encountered the problem!) then of course it's because Windows is rubbish. So, basically, I cannot win.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-16 01:39 +0000 |
| Message-ID | <20230815181254.731@kylheku.com> |
| In reply to | #172343 |
On 2023-08-16, Bart <bc@freeuk.com> wrote: > On 15/08/2023 23:55, Keith Thompson wrote: >> Bart <bc@freeuk.com> writes: >>> On 15/08/2023 22:09, David Brown wrote: >>>> On 15/08/2023 19:49, Bart wrote: >>>>> You know, one thing is going 100% certain in this thread: you are >>>>> never for one minute going to admit that I'm right in there being >>>>> something wrong with those Github ZIPs. >>>>> >>>>> You didn't see the problem because you either obtained the source >>>>> bundle elsewhere, or would have used only the .tar.gz version. >>>>> >>>> >>>> Look, I have no idea if these are the same or different. I don't know, >>>> and don't care. The only reason I was at the lua website at all was >>>> because /you/ picked it as something that "proves" that make never works >>>> on Windows. I went to the lua website, followed the instructions on how >>>> to build lua on Windows, and it worked - using "make". /You/ did not >>>> not follow the instructions, >>> >>> I downloaded an open source project like I've done a hundred others: >>> from Github. It's usually expected to have everything needed to build >>> the project, except for the actual tools. >> >> And now you've learned that the "release" .tar.gz and .zip files >> provided by GitHub are just snapshots of the git repo. Official source >> releases are often generated from the git repo, with things like >> documentation and configure scripts generated by the maintainers of the >> project. Whether you can easily build something from a GitHub release >> file depends on the project. >> >> I suspect you resorted to the GitHub "release" files because lua.org >> doesn't provide a zip file. >> >> It's an understandable error -- and it gave you an excuse to complain >> and insult people. > > But it's not understood by David Brown, and it gave him an excuse to > insult /me/. > > In his book, it's impossible for anything to go wrong, so if I can't get > something to work, it HAS to be my fault. It can NEVER be the extra > opportunities for error that complex makefiles provide, or even simple ones. > > No docs are too obscure or misleading (like lumping the 'mingw' > parameter needed for Windows under Unix-like systems) > > And if can't make something work under ordinary Windows, my mistake is > not using Linux-like layers to keep the build process happy. The main C cross-platform problem between POSIX and Windows isn't building, but the platforms being vastly different. One way to port POSIX programs to Windows is to have a run-time environment that has the needed POSIX support. The projects which provide that tend to have the build environment also, and of course that also helps. If the library functions were there, but no build environment with make and shell, that would be inconvenient. But less inconvenient than the reverse: having the build environment, but crap POSIX libraries (situation with all versions of MinGW). I use Cygwin for building the Windows version of the TXR language. For the run-time, I created a project which forks the Cygwin run-time. I made some key alterations in the CYGWIN1.DLL to claw back some of the ways in which the middleware emulates POSIX a little bit too far. The project is here: https://www.kylheku.com/cygnal/ Cygnal makes it as easy as "humanly possible" to port your Unix and Linux programs to Windows, and ship them to the users such that the programs exhibit native-like conventions. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-16 11:37 +0200 |
| Message-ID | <ubi5do$38ii5$1@dont-email.me> |
| In reply to | #172343 |
On 16/08/2023 02:05, Bart wrote: > On 15/08/2023 23:55, Keith Thompson wrote: >> Bart <bc@freeuk.com> writes: >>> On 15/08/2023 22:09, David Brown wrote: >>>> On 15/08/2023 19:49, Bart wrote: >>>>> You know, one thing is going 100% certain in this thread: you are >>>>> never for one minute going to admit that I'm right in there being >>>>> something wrong with those Github ZIPs. >>>>> >>>>> You didn't see the problem because you either obtained the source >>>>> bundle elsewhere, or would have used only the .tar.gz version. >>>>> >>>> >>>> Look, I have no idea if these are the same or different. I don't know, >>>> and don't care. The only reason I was at the lua website at all was >>>> because /you/ picked it as something that "proves" that make never >>>> works >>>> on Windows. I went to the lua website, followed the instructions on >>>> how >>>> to build lua on Windows, and it worked - using "make". /You/ did not >>>> not follow the instructions, >>> >>> I downloaded an open source project like I've done a hundred others: >>> from Github. It's usually expected to have everything needed to build >>> the project, except for the actual tools. >> >> And now you've learned that the "release" .tar.gz and .zip files >> provided by GitHub are just snapshots of the git repo. Official source >> releases are often generated from the git repo, with things like >> documentation and configure scripts generated by the maintainers of the >> project. Whether you can easily build something from a GitHub release >> file depends on the project. >> >> I suspect you resorted to the GitHub "release" files because lua.org >> doesn't provide a zip file. >> >> It's an understandable error -- and it gave you an excuse to complain >> and insult people. > Actually, I am not sure it is an understandable error for Bart. In one sense, Bart does not understand his error. In another sense, he is familiar with github - he most certainly should know that it is for development, and that code found there is often in flux, while released versions from the project website will be more tested and more appropriate for general use. And it is not understandable that he is scared of tarballs. > But it's not understood by David Brown, and it gave him an excuse to > insult /me/. > > In his book, it's impossible for anything to go wrong, so if I can't get > something to work, it HAS to be my fault. It can NEVER be the extra > opportunities for error that complex makefiles provide, or even simple > ones. Oh, many things can go wrong. And it is quite possible for things to go wrong that are /not/ your fault. But when you claim you're giving things a fair test, yet fail to follow the simplest and most basic instructions (despite being helped with pointers), that's not a fair test. That is a determined intention to fail. (You are far too smart and experienced to use inability or ignorance as an excuse.) > > No docs are too obscure or misleading (like lumping the 'mingw' > parameter needed for Windows under Unix-like systems) > > And if can't make something work under ordinary Windows, my mistake is > not using Linux-like layers to keep the build process happy. > > If even he has trouble pinning something on me (maybe somebody else > encountered the problem!) then of course it's because Windows is rubbish. > > So, basically, I cannot win. > You can't win until you decide to try to listen, learn, experiment, and progress as a developer. As long as your goal is to convince yourself that the entire software world, other than yourself, is wrong, and all tools other than your home-made systems are useless, unworkable and unnecessary, then no - you cannot win. No one is asking you to like C, gcc, make, Linux, or any other of your pet hates. But it would be nice if you stopped spreading shite about them. Maybe try asking "How can I do XXX in C?" rather than "I can't/won't do XXX in C, therefore it is an unusable disaster and my own language is pure genius". Wouldn't that make a nice change, and make threads a bit more friendly and useful?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-16 12:15 +0100 |
| Message-ID | <ubib54$39aqa$1@dont-email.me> |
| In reply to | #172358 |
On 16/08/2023 10:37, David Brown wrote:
> On 16/08/2023 02:05, Bart wrote:
>> But it's not understood by David Brown, and it gave him an excuse to
>> insult /me/.
>>
>> In his book, it's impossible for anything to go wrong, so if I can't
>> get something to work, it HAS to be my fault. It can NEVER be the
>> extra opportunities for error that complex makefiles provide, or even
>> simple ones.
>
> Oh, many things can go wrong. And it is quite possible for things to go
> wrong that are /not/ your fault. But when you claim you're giving
> things a fair test, yet fail to follow the simplest and most basic
> instructions (despite being helped with pointers), that's not a fair
> test.
I like how you tried desperately to make it all my fault. Oh, you should
have known this, should have known that. I bet you were surprised that
that Github repository was incomplete too!
> That is a determined intention to fail. (You are far too smart
> and experienced to use inability or ignorance as an excuse.)
You know, it really doesn't help when every makefile is called
'makefile'. Having specific names would have picked up my issue
instantly, since that particular project used two separate makefiles
both called 'makefile'.
You also know that that is a jolly good idea, but of course will never
admit it in a million years.
> You can't win until you decide to try to listen, learn, experiment, and
> progress as a developer.
You need to work a little more on being patronising.
> As long as your goal is to convince yourself
> that the entire software world, other than yourself, is wrong, and all
> tools other than your home-made systems are useless, unworkable and
> unnecessary, then no - you cannot win.
My battle is against unnecessary complex and bloat.
I like elegance and consistency in a programming language. I also like
that lessons are learned and things are improved.
I don't like elaborate solutions when simpler ones are far better.
I don't like clumsy, slow, error prone processes.
You're right that no one uses my stuff, but so what? You can think of it
as proof of concept that simpler, more elegant and more fool-proof
solutions can work.
Lua as a project is about the same size as many of mine. If written in
my language, the build process to creating lua.exe would be:
mm lua
The same on Linux if mm was ported there. (I have done that, the process
was ./mm lua). To create separate .exe and .dll, it might instead be 'mm
luac && mm -dll lualib'.
You can still use makefiles if you wish; they'd be rather short!
So my solutions are far advanced that the ones you use for C. You're
asking me, a developer, to step back a couple of decades to use obsolete
tools that people have been stuck with the same reasons that they have
to use -lm and get around a.out.
These days I'm more of a developer of languages than apps. And I
concentrate on aspects of language implementations that many ignore,
such as size, compactness, self-containment, speed, usability and
simplicity of the tool itself.
In short, I'm not a conformist.
> No one is asking you to like C, gcc, make, Linux, or any other of your
> pet hates. But it would be nice if you stopped spreading shite about
them.
>
> Maybe try asking "How can I do XXX in C?" rather than "I can't/won't do
> XXX in C, therefore it is an unusable disaster and my own language is
> pure genius". Wouldn't that make a nice change, and make threads a bit
> more friendly and useful?
You can't change the language C. But most of this discussion has been on
aspects that are peripheral to the language, like those I touched on
above. And there things could be done differently.
Of course, you are NEVER going to admit that doing:
mm lua
might be a touch sweeter than those 330 lines of makefile crap below.
You can't do that in C, so there I used a solution what was 33 lines,
exactly 1/10th the size of the combined makefiles.
So, I'm on a hiding to nothing. You will always be convinced that I'm
some deviant that needs to brainwashed into taking the correct path and
having the right subservient attitudes, a bit like the protagonist at
the end of /1984/.
In any case, I'm done. I've deleted all my C compilers and all my C
related projects.
Including mine. But I'm keeping a ZIP in case I want to maintain it as a
test program; it's one of the best I have for my own language. Although
since it is for a C subset, I may develop that aspect, change it some
more, and give that language a different name.
Thank you for making 'C' and its development methods (and the attitudes
of its adherents) so unpalatable that I'm finally able to take that break.
(I'm still available for testing build systems, since I have a knack for
finding problems that seem to slip by everyone else!)
--------------------------------------------------------
# Makefile for installing Lua
# See doc/readme.html for installation and customization instructions.
# == CHANGE THE SETTINGS BELOW TO SUIT YOUR ENVIRONMENT
=======================
# Your platform. See PLATS for possible values.
PLAT= guess
# Where to install. The installation starts in the src and doc directories,
# so take care if INSTALL_TOP is not an absolute path. See the local target.
# You may want to make INSTALL_LMOD and INSTALL_CMOD consistent with
# LUA_ROOT, LUA_LDIR, and LUA_CDIR in luaconf.h.
INSTALL_TOP= /usr/local
INSTALL_BIN= $(INSTALL_TOP)/bin
INSTALL_INC= $(INSTALL_TOP)/include
INSTALL_LIB= $(INSTALL_TOP)/lib
INSTALL_MAN= $(INSTALL_TOP)/man/man1
INSTALL_LMOD= $(INSTALL_TOP)/share/lua/$V
INSTALL_CMOD= $(INSTALL_TOP)/lib/lua/$V
# How to install. If your install program does not support "-p", then
# you may have to run ranlib on the installed liblua.a.
INSTALL= install -p
INSTALL_EXEC= $(INSTALL) -m 0755
INSTALL_DATA= $(INSTALL) -m 0644
#
# If you don't have "install" you can use "cp" instead.
# INSTALL= cp -p
# INSTALL_EXEC= $(INSTALL)
# INSTALL_DATA= $(INSTALL)
# Other utilities.
MKDIR= mkdir -p
RM= rm -f
# == END OF USER SETTINGS -- NO NEED TO CHANGE ANYTHING BELOW THIS LINE
=======
# Convenience platforms targets.
PLATS= guess aix bsd c89 freebsd generic ios linux linux-readline macosx
mingw posix solaris
# What to install.
TO_BIN= lua luac
TO_INC= lua.h luaconf.h lualib.h lauxlib.h lua.hpp
TO_LIB= liblua.a
TO_MAN= lua.1 luac.1
# Lua version and release.
V= 5.4
R= $V.6
# Targets start here.
all: $(PLAT)
$(PLATS) help test clean:
@cd src && $(MAKE) $@
install: dummy
cd src && $(MKDIR) $(INSTALL_BIN) $(INSTALL_INC) $(INSTALL_LIB)
$(INSTALL_MAN) $(INSTALL_LMOD) $(INSTALL_CMOD)
cd src && $(INSTALL_EXEC) $(TO_BIN) $(INSTALL_BIN)
cd src && $(INSTALL_DATA) $(TO_INC) $(INSTALL_INC)
cd src && $(INSTALL_DATA) $(TO_LIB) $(INSTALL_LIB)
cd doc && $(INSTALL_DATA) $(TO_MAN) $(INSTALL_MAN)
uninstall:
cd src && cd $(INSTALL_BIN) && $(RM) $(TO_BIN)
cd src && cd $(INSTALL_INC) && $(RM) $(TO_INC)
cd src && cd $(INSTALL_LIB) && $(RM) $(TO_LIB)
cd doc && cd $(INSTALL_MAN) && $(RM) $(TO_MAN)
local:
$(MAKE) install INSTALL_TOP=../install
# make may get confused with install/ if it does not support .PHONY.
dummy:
# Echo config parameters.
echo:
@cd src && $(MAKE) -s echo
@echo "PLAT= $(PLAT)"
@echo "V= $V"
@echo "R= $R"
@echo "TO_BIN= $(TO_BIN)"
@echo "TO_INC= $(TO_INC)"
@echo "TO_LIB= $(TO_LIB)"
@echo "TO_MAN= $(TO_MAN)"
@echo "INSTALL_TOP= $(INSTALL_TOP)"
@echo "INSTALL_BIN= $(INSTALL_BIN)"
@echo "INSTALL_INC= $(INSTALL_INC)"
@echo "INSTALL_LIB= $(INSTALL_LIB)"
@echo "INSTALL_MAN= $(INSTALL_MAN)"
@echo "INSTALL_LMOD= $(INSTALL_LMOD)"
@echo "INSTALL_CMOD= $(INSTALL_CMOD)"
@echo "INSTALL_EXEC= $(INSTALL_EXEC)"
@echo "INSTALL_DATA= $(INSTALL_DATA)"
# Echo pkg-config data.
pc:
@echo "version=$R"
@echo "prefix=$(INSTALL_TOP)"
@echo "libdir=$(INSTALL_LIB)"
@echo "includedir=$(INSTALL_INC)"
# Targets that do not create files (not all makes understand .PHONY).
.PHONY: all $(PLATS) help test clean install uninstall local dummy echo pc
# (end of Makefile)
# Makefile for building Lua
# See ../doc/readme.html for installation and customization instructions.
# == CHANGE THE SETTINGS BELOW TO SUIT YOUR ENVIRONMENT
=======================
# Your platform. See PLATS for possible values.
PLAT= guess
CC= gcc -std=gnu99
CFLAGS= -O2 -Wall -Wextra -DLUA_COMPAT_5_3 $(SYSCFLAGS) $(MYCFLAGS)
LDFLAGS= $(SYSLDFLAGS) $(MYLDFLAGS)
LIBS= -lm $(SYSLIBS) $(MYLIBS)
AR= ar rcu
RANLIB= ranlib
RM= rm -f
UNAME= uname
SYSCFLAGS=
SYSLDFLAGS=
SYSLIBS=
MYCFLAGS=
MYLDFLAGS=
MYLIBS=
MYOBJS=
# Special flags for compiler modules; -Os reduces code size.
CMCFLAGS=
# == END OF USER SETTINGS -- NO NEED TO CHANGE ANYTHING BELOW THIS LINE
=======
PLATS= guess aix bsd c89 freebsd generic ios linux linux-readline macosx
mingw posix solaris
LUA_A= liblua.a
CORE_O= lapi.o lcode.o lctype.o ldebug.o ldo.o ldump.o lfunc.o lgc.o
llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o
ltm.o lundump.o lvm.o lzio.o
LIB_O= lauxlib.o lbaselib.o lcorolib.o ldblib.o liolib.o lmathlib.o
loadlib.o loslib.o lstrlib.o ltablib.o lutf8lib.o linit.o
BASE_O= $(CORE_O) $(LIB_O) $(MYOBJS)
LUA_T= lua
LUA_O= lua.o
LUAC_T= luac
LUAC_O= luac.o
ALL_O= $(BASE_O) $(LUA_O) $(LUAC_O)
ALL_T= $(LUA_A) $(LUA_T) $(LUAC_T)
ALL_A= $(LUA_A)
# Targets start here.
default: $(PLAT)
all: $(ALL_T)
o: $(ALL_O)
a: $(ALL_A)
$(LUA_A): $(BASE_O)
$(AR) $@ $(BASE_O)
$(RANLIB) $@
$(LUA_T): $(LUA_O) $(LUA_A)
$(CC) -o $@ $(LDFLAGS) $(LUA_O) $(LUA_A) $(LIBS)
$(LUAC_T): $(LUAC_O) $(LUA_A)
$(CC) -o $@ $(LDFLAGS) $(LUAC_O) $(LUA_A) $(LIBS)
test:
./$(LUA_T) -v
clean:
$(RM) $(ALL_T) $(ALL_O)
depend:
@$(CC) $(CFLAGS) -MM l*.c
echo:
@echo "PLAT= $(PLAT)"
@echo "CC= $(CC)"
@echo "CFLAGS= $(CFLAGS)"
@echo "LDFLAGS= $(LDFLAGS)"
@echo "LIBS= $(LIBS)"
@echo "AR= $(AR)"
@echo "RANLIB= $(RANLIB)"
@echo "RM= $(RM)"
@echo "UNAME= $(UNAME)"
# Convenience targets for popular platforms.
ALL= all
help:
@echo "Do 'make PLATFORM' where PLATFORM is one of these:"
@echo " $(PLATS)"
@echo "See doc/readme.html for complete instructions."
guess:
@echo Guessing `$(UNAME)`
@$(MAKE) `$(UNAME)`
AIX aix:
$(MAKE) $(ALL) CC="xlc" CFLAGS="-O2 -DLUA_USE_POSIX -DLUA_USE_DLOPEN"
SYSLIBS="-ldl" SYSLDFLAGS="-brtl -bexpall"
bsd:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_POSIX -DLUA_USE_DLOPEN"
SYSLIBS="-Wl,-E"
c89:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_C89" CC="gcc -std=c89"
@echo ''
@echo '*** C89 does not guarantee 64-bit integers for Lua.'
@echo '*** Make sure to compile all external Lua libraries'
@echo '*** with LUA_USE_C89 to ensure consistency'
@echo ''
FreeBSD NetBSD OpenBSD freebsd:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_LINUX -DLUA_USE_READLINE
-I/usr/include/edit" SYSLIBS="-Wl,-E -ledit" CC="cc"
generic: $(ALL)
ios:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_IOS"
Linux linux: linux-noreadline
linux-noreadline:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_LINUX" SYSLIBS="-Wl,-E -ldl"
linux-readline:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_LINUX -DLUA_USE_READLINE"
SYSLIBS="-Wl,-E -ldl -lreadline"
Darwin macos macosx:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_MACOSX -DLUA_USE_READLINE"
SYSLIBS="-lreadline"
mingw:
$(MAKE) "LUA_A=lua54.dll" "LUA_T=lua.exe" \
"AR=$(CC) -shared -o" "RANLIB=strip --strip-unneeded" \
"SYSCFLAGS=-DLUA_BUILD_AS_DLL" "SYSLIBS=" "SYSLDFLAGS=-s" lua.exe
$(MAKE) "LUAC_T=luac.exe" luac.exe
posix:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_POSIX"
SunOS solaris:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_POSIX -DLUA_USE_DLOPEN
-D_REENTRANT" SYSLIBS="-ldl"
# Targets that do not create files (not all makes understand .PHONY).
.PHONY: all $(PLATS) help test clean default o a depend echo
# Compiler modules may use special flags.
llex.o:
$(CC) $(CFLAGS) $(CMCFLAGS) -c llex.c
lparser.o:
$(CC) $(CFLAGS) $(CMCFLAGS) -c lparser.c
lcode.o:
$(CC) $(CFLAGS) $(CMCFLAGS) -c lcode.c
# DO NOT DELETE
lapi.o: lapi.c lprefix.h lua.h luaconf.h lapi.h llimits.h lstate.h \
lobject.h ltm.h lzio.h lmem.h ldebug.h ldo.h lfunc.h lgc.h lstring.h \
ltable.h lundump.h lvm.h
lauxlib.o: lauxlib.c lprefix.h lua.h luaconf.h lauxlib.h
lbaselib.o: lbaselib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
lcode.o: lcode.c lprefix.h lua.h luaconf.h lcode.h llex.h lobject.h \
llimits.h lzio.h lmem.h lopcodes.h lparser.h ldebug.h lstate.h ltm.h \
ldo.h lgc.h lstring.h ltable.h lvm.h
lcorolib.o: lcorolib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
lctype.o: lctype.c lprefix.h lctype.h lua.h luaconf.h llimits.h
ldblib.o: ldblib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
ldebug.o: ldebug.c lprefix.h lua.h luaconf.h lapi.h llimits.h lstate.h \
lobject.h ltm.h lzio.h lmem.h lcode.h llex.h lopcodes.h lparser.h \
ldebug.h ldo.h lfunc.h lstring.h lgc.h ltable.h lvm.h
ldo.o: ldo.c lprefix.h lua.h luaconf.h lapi.h llimits.h lstate.h \
lobject.h ltm.h lzio.h lmem.h ldebug.h ldo.h lfunc.h lgc.h lopcodes.h \
lparser.h lstring.h ltable.h lundump.h lvm.h
ldump.o: ldump.c lprefix.h lua.h luaconf.h lobject.h llimits.h lstate.h \
ltm.h lzio.h lmem.h lundump.h
lfunc.o: lfunc.c lprefix.h lua.h luaconf.h ldebug.h lstate.h lobject.h \
llimits.h ltm.h lzio.h lmem.h ldo.h lfunc.h lgc.h
lgc.o: lgc.c lprefix.h lua.h luaconf.h ldebug.h lstate.h lobject.h \
llimits.h ltm.h lzio.h lmem.h ldo.h lfunc.h lgc.h lstring.h ltable.h
linit.o: linit.c lprefix.h lua.h luaconf.h lualib.h lauxlib.h
liolib.o: liolib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
llex.o: llex.c lprefix.h lua.h luaconf.h lctype.h llimits.h ldebug.h \
lstate.h lobject.h ltm.h lzio.h lmem.h ldo.h lgc.h llex.h lparser.h \
lstring.h ltable.h
lmathlib.o: lmathlib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
lmem.o: lmem.c lprefix.h lua.h luaconf.h ldebug.h lstate.h lobject.h \
llimits.h ltm.h lzio.h lmem.h ldo.h lgc.h
loadlib.o: loadlib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
lobject.o: lobject.c lprefix.h lua.h luaconf.h lctype.h llimits.h \
ldebug.h lstate.h lobject.h ltm.h lzio.h lmem.h ldo.h lstring.h lgc.h \
lvm.h
lopcodes.o: lopcodes.c lprefix.h lopcodes.h llimits.h lua.h luaconf.h
loslib.o: loslib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
lparser.o: lparser.c lprefix.h lua.h luaconf.h lcode.h llex.h lobject.h \
llimits.h lzio.h lmem.h lopcodes.h lparser.h ldebug.h lstate.h ltm.h \
ldo.h lfunc.h lstring.h lgc.h ltable.h
lstate.o: lstate.c lprefix.h lua.h luaconf.h lapi.h llimits.h lstate.h \
lobject.h ltm.h lzio.h lmem.h ldebug.h ldo.h lfunc.h lgc.h llex.h \
lstring.h ltable.h
lstring.o: lstring.c lprefix.h lua.h luaconf.h ldebug.h lstate.h \
lobject.h llimits.h ltm.h lzio.h lmem.h ldo.h lstring.h lgc.h
lstrlib.o: lstrlib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
ltable.o: ltable.c lprefix.h lua.h luaconf.h ldebug.h lstate.h lobject.h \
llimits.h ltm.h lzio.h lmem.h ldo.h lgc.h lstring.h ltable.h lvm.h
ltablib.o: ltablib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
ltm.o: ltm.c lprefix.h lua.h luaconf.h ldebug.h lstate.h lobject.h \
llimits.h ltm.h lzio.h lmem.h ldo.h lgc.h lstring.h ltable.h lvm.h
lua.o: lua.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
luac.o: luac.c lprefix.h lua.h luaconf.h lauxlib.h ldebug.h lstate.h \
lobject.h llimits.h ltm.h lzio.h lmem.h lopcodes.h lopnames.h lundump.h
lundump.o: lundump.c lprefix.h lua.h luaconf.h ldebug.h lstate.h \
lobject.h llimits.h ltm.h lzio.h lmem.h ldo.h lfunc.h lstring.h lgc.h \
lundump.h
lutf8lib.o: lutf8lib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
lvm.o: lvm.c lprefix.h lua.h luaconf.h ldebug.h lstate.h lobject.h \
llimits.h ltm.h lzio.h lmem.h ldo.h lfunc.h lgc.h lopcodes.h lstring.h \
ltable.h lvm.h ljumptab.h
lzio.o: lzio.c lprefix.h lua.h luaconf.h llimits.h lmem.h lstate.h \
lobject.h ltm.h lzio.h
# (end of Makefile)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-16 15:16 +0200 |
| Message-ID | <ubii7m$3acds$1@dont-email.me> |
| In reply to | #172367 |
On 16/08/2023 13:15, Bart wrote: > On 16/08/2023 10:37, David Brown wrote: > > On 16/08/2023 02:05, Bart wrote: > >> But it's not understood by David Brown, and it gave him an excuse to > >> insult /me/. > >> > >> In his book, it's impossible for anything to go wrong, so if I can't > >> get something to work, it HAS to be my fault. It can NEVER be the > >> extra opportunities for error that complex makefiles provide, or even > >> simple ones. > > > > Oh, many things can go wrong. And it is quite possible for things to go > > wrong that are /not/ your fault. But when you claim you're giving > > things a fair test, yet fail to follow the simplest and most basic > > instructions (despite being helped with pointers), that's not a fair > > test. > > I like how you tried desperately to make it all my fault. I am not desparate. I tried to tell you what you did wrong, so that you could try to get it right. Since you repeatedly ignore that, I condense it to saying you were wrong. > Oh, you should > have known this, should have known that. I bet you were surprised that > that Github repository was incomplete too! I wrote exactly that in a reply to Keith (which you might not have read yet). So I /do/ understand that you also found that surprising, and I don't think it is an unreasonable guess, before reading anything about a given project, to suppose that a GitHub repository connected to a project would have the same files that are provided in releases of the project. But understanding how you got this wrong does not mean you did not get it wrong. And since the GitHub page and readme contains multiple indications that you should be looking at "www.lua.org" for downloads and build and install instructions, and you were told in posts here about such instructions, it becomes your /fault/ that you remained wrong. You prefered to stay wrong, so that you could complain about problems building the project - you never had any intention of trying to get it right, and thus actively avoided doing so. That makes it your fault. > > > That is a determined intention to fail. (You are far too smart > > and experienced to use inability or ignorance as an excuse.) > > You know, it really doesn't help when every makefile is called > 'makefile'. Having specific names would have picked up my issue > instantly, since that particular project used two separate makefiles > both called 'makefile'. No, it does not. In the release tarballs, there are two separate files - "Makefile" and "src/Makefile". Directories are relevant. If you "organise" your code the way you said you do, with hundreds of different unrelated files in one directory, then I can see why you would dislike a common name like "makefile". But for people who organise their projects and code in directories, a single common name is perfect - "makefile", "README.md", etc. > > You also know that that is a jolly good idea, but of course will never > admit it in a million years. When I have multiple makefiles in a single directory (sometimes I will split a makefile into multiple parts, separating project-specific, host-specific and generic sections) I give them different names. But what would be the benefit of different names in this case? They are clearly different files when they are in different directories. Calling them "makefile" (or "Makefile") makes it immediately obvious what the files are. If they were called "install.mk" and "build.mk" instead, people would wonder what they were, and where the makefile is, and they would have to write "make -f install.mk" instead of just "make". Tell me what you see as the advantage here, and why /you/ think it would be a jolly good idea, and maybe I'll agree. But you have to say why it would be better for everyone, not just for you personally - you need good reasons to change 50 year old conventions. > > > You can't win until you decide to try to listen, learn, experiment, and > > progress as a developer. > > You need to work a little more on being patronising. > > > As long as your goal is to convince yourself > > that the entire software world, other than yourself, is wrong, and all > > tools other than your home-made systems are useless, unworkable and > > unnecessary, then no - you cannot win. > > My battle is against unnecessary complex and bloat. Why? For whom? Do you think you are achieving your goals here? I mean, it's a noble aim. Don't misunderstand me - I /agree/ that all other things being equal, it is better for software to be small, simple and fast. The trouble with your position is that all other things are /not/ equal. It is very rarely a good idea to target any particular aspect to the extreme or to the exclusion of other things. Your compiler may be much smaller and faster than gcc, but it does not have the features people need. Writing "cc *.c" may be simpler than a makefile, but it does not do the same thing. Then there is the question of why it matters. PC disks are big. PC CPUs are fast. Network speeds are high. Top quality development tools and utilities are freely available - even on Windows. Size and speed matters very little for software on PC's. (It matters a great deal on small embedded systems.) So who are you fighting for? Who are you fighting against? Do you really think you are making a difference for some greater good here, or even just for your own personal benefit? (There's nothing wrong with doing it for your own benefit - I am not suggesting you have to fight for other people.) Have you considered whether there are other battles that would make more sense or have greater impact? Have you considered forgetting it all, splashing out £300 on a new mini-PC, installing Linux Mint, and going back to having fun with computers, learning new things, and creating software without bothering about how much space gcc takes up? I really don't understand your motivation for these pointless arguments and battles - unless you simply enjoy the argument. You are not a fanatic who thinks all software is evil unless written by your personal religious cult, or that we'll all go back to C90 after the appocolypse. > > I like elegance and consistency in a programming language. I also like > that lessons are learned and things are improved. > > I don't like elaborate solutions when simpler ones are far better. > > I don't like clumsy, slow, error prone processes. > > You're right that no one uses my stuff, but so what? You can think of it > as proof of concept that simpler, more elegant and more fool-proof > solutions can work. But they /can't/ work - they don't do what people need. You /know/ this. You can write small and simple solutions for specific limited use-cases - that's nothing new. But anything that will cover a wide variety of needs of a wide variety of people is inevitably bigger and more complex. > > Lua as a project is about the same size as many of mine. If written in > my language, the build process to creating lua.exe would be: > > mm lua > > The same on Linux if mm was ported there. (I have done that, the process > was ./mm lua). To create separate .exe and .dll, it might instead be 'mm > luac && mm -dll lualib'. > > You can still use makefiles if you wish; they'd be rather short! > > So my solutions are far advanced that the ones you use for C. You're > asking me, a developer, to step back a couple of decades to use obsolete > tools that people have been stuck with the same reasons that they have > to use -lm and get around a.out. No - I am asking you to understand the world is bigger than you. You could design a television with one button - for turning it on and off. That would be beautifully simple and elegant. Why do people want the complexity of choosing channels when BBC 1 has all you need? What's the point of a volume control when the hardware can be fixed at the ideal volume level for your preferences? But would that television work for other people? Would it be better? Simple and limited are great for specific cases - and maybe that television would be better for your needs. But it won't suit others, and cannot be a wide-scale solution. > > These days I'm more of a developer of languages than apps. And I > concentrate on aspects of language implementations that many ignore, > such as size, compactness, self-containment, speed, usability and > simplicity of the tool itself. > > In short, I'm not a conformist. That's fine - be yourself, not anyone else. But don't believe it makes you better in any way, or that it makes your creations better, or that everyone else is wrong. > > > No one is asking you to like C, gcc, make, Linux, or any other of your > > pet hates. But it would be nice if you stopped spreading shite about > them. > > > > Maybe try asking "How can I do XXX in C?" rather than "I can't/won't do > > XXX in C, therefore it is an unusable disaster and my own language is > > pure genius". Wouldn't that make a nice change, and make threads a bit > > more friendly and useful? > > You can't change the language C. But most of this discussion has been on > aspects that are peripheral to the language, like those I touched on > above. And there things could be done differently. Don't you think people /would/ do things differently if they thought things could be improved? Do you believe you are alone in considering whether there might be alternative solutions or better ways to do things? Do you imagine that you alone can see flaws in common tools? Everyone who has ever used "make" seriously knows it is not perfect. Lots of people have made alternatives or companion tools. Some, such as CMake, have their fans, and others have particular niche uses and features. Excluding IDE project build systems, none have come remotely close to competing with make for market share. It turns out that for all its flaws, "make" is good enough for a huge variety of use-cases, and its ubiquity and familiarity trump its flaws. (It's like C, *nix, and many other things in that respect.) > > Of course, you are NEVER going to admit that doing: > > mm lua > > might be a touch sweeter than those 330 lines of makefile crap below. I fail to see how that's better than "make" (or "make mingw" on Windows). I /do/ see how "make" is vastly superior, because the makefile has lots more in it than just the dependencies that could be found automatically. Where does "mm lua" put all the compiler flags? The pre-defined macros used to configure lua according to needs and preferences? The alternative build targets for tests? The warning flags? The choice of compiler? The comments and documentation? Short and sweet is all well enough - /if/ it is good enough and has the features that people want. "make" may be complex, but it does what is needed. And the makefile for Lua is hardly complex or difficult to follow. > > You can't do that in C, so there I used a solution what was 33 lines, > exactly 1/10th the size of the combined makefiles. > There you go again - the unwarranted assumption that "smaller" is "better". It is not. There is more to making good software than size. > So, I'm on a hiding to nothing. You will always be convinced that I'm > some deviant that needs to brainwashed into taking the correct path and > having the right subservient attitudes, a bit like the protagonist at > the end of /1984/. > > In any case, I'm done. I've deleted all my C compilers and all my C > related projects. > What a truly silly thing to do. If someone told you your house was a horrible colour, would you burn it down? I'd make a copy of your archives while they are still functional. > Including mine. But I'm keeping a ZIP in case I want to maintain it as a > test program; it's one of the best I have for my own language. Although > since it is for a C subset, I may develop that aspect, change it some > more, and give that language a different name. > > Thank you for making 'C' and its development methods (and the attitudes > of its adherents) so unpalatable that I'm finally able to take that break. > > (I'm still available for testing build systems, since I have a knack for > finding problems that seem to slip by everyone else!) >
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-16 16:34 +0100 |
| Message-ID | <ubiqaq$3bkeq$2@dont-email.me> |
| In reply to | #172373 |
On 16/08/2023 14:16, David Brown wrote:
> On 16/08/2023 13:15, Bart wrote:
> I am not desparate. I tried to tell you what you did wrong, so that you
> could try to get it right. Since you repeatedly ignore that, I condense
> it to saying you were wrong.
And you are convinced that I must have been wrong, and that the blame
falls 100% on me.
I've spent a lot of time doing technical support with clients who were
endusers and encountered lots of different kinds of problems.
I got to have an idea of where things could be commonly or easily
misunderstood. I was also involved in writing user manuals and mine were
written with the possibility that things could go wrong and the
knowledge of which aspects could be misunderstood.
There was rarely a point where a customer was just plain stupid. If they
did something wrongly, I would see what I could change to make that less
likely and more foolproof.
Most manuals and references are written with the assumption that the
product is perfect, and so is the manual; it can never be ambiguous or
confusing.
> But understanding how you got this wrong does not mean you did not get
> it wrong.
It's not me! Building that product requires two makefiles, only one was
provided on that site.
So a bunch of .c and .h files, and a file called 'makefile'; hmmm.... Is
it not unreasonable for someone to make a wild stab and guess you built
the product using 'make'? Especially given the lack of the usual build
instructions.
The short readme does indeed say get releases from a website; but that
can be taken to mean (as I did) releases of binaries, since the Releases
section of the github page has only sources.
I take it that you wouldn't change that Readme at all just to make it a
bit clearer? After all lots of people will use 'github <appname>' to get
at the sources of projects.
But no, let's just leave it! Adding a few more lines of clarification to
a 6-line readme is too much effort.
>> might be a touch sweeter than those 330 lines of makefile crap below.
>
> I fail to see how that's better than "make" (or "make mingw" on
> Windows). I /do/ see how "make" is vastly superior, because the
> makefile has lots more in it than just the dependencies that could be
> found automatically. Where does "mm lua" put all the compiler flags?
> The pre-defined macros used to configure lua according to needs and
> preferences? The alternative build targets for tests? The warning
> flags? The choice of compiler?
'mm' /is/ the compiler, in the same way that 'cc' is the C compiler in
lots of similar examples in the rare cases that people invoke it directly.
I did say you can add a makefile if you want, or script it in any manner
you like. 'mm prog' takes care of locating the source files of a
project, which occupies most of a makefile. With that out of the way,
there is not a great deal left.
This is the script (putmm.bat) which builds a new version of mm using an
old version, then replaces that old version (backups are a separate script):
\m\mm mm -ext -opt
copy mm.exe \m\mm.exe
There are no intermediate files to clean up and no dependencies to worry
about.
'mm prog' turns a bunch of sources into one binary file. If an app is
more elaborfate than that, then some basic scripting might be needed to
invoke it more than once or copy files about etc.
Different configurations tend to have a differently named lead module.
Compiler options (there aren't many) can be added to the command line;
being options, you may not want them baked in.
The fundamental step is so simple, anyone can easily see how to apply
their own scripting for their needs.
> Short and sweet is all well enough - /if/ it is good enough and has the
> features that people want. "make" may be complex, but it does what is
> needed.
Suppose somebody wanted to know all the relevant files because they
wanted control of the whole build process? Or even, run their own
compiler that doesn't follow convention. That information is pretty much
opaque in makefiles; it's not meant to be human-readable.
(With mm, the relevant modules are listed in the lead module as part of
the module scheme. Support files, that used via 'include' or which are
embedded, are not listed in one place. But you can get a summary when
generating an amalgamated source file using -ma.)
> And the makefile for Lua is hardly complex or difficult to follow.
It's 331 lines for both of them. Can it be done better? Here's my stab
at it (based on one for Pico C as the Lua one is too abstruse):
# CC = tcc
CC = gcc
lua:
$(CC) -olua \
lua.c \
lapi.c \
lcode.c \
lctype.c \
ldebug.c \
ldo.c \
ldump.c \
lfunc.c \
lgc.c \
llex.c \
lmem.c \
lobject.c \
lopcodes.c \
lparser.c \
lstate.c \
lstring.c \
ltable.c \
ltm.c \
lundump.c \
lvm.c \
lzio.c \
lauxlib.c \
lbaselib.c \
lcorolib.c \
ldblib.c \
liolib.c \
lmathlib.c \
loadlib.c \
loslib.c \
lstrlib.c \
ltablib.c \
lutf8lib.c \
linit.c \
-lm
This had some problems with gcc, but it managed to produce executables
for both tcc and gcc. I had to run it under WSL, since my Windows at the
minute has problems running C compilers.
It is 4% the size of the two supplied makefiles: it's not just the
linecount; the latter are written horizontally. Any reason why they
can't list one file per line?
> What a truly silly thing to do. If someone told you your house was a
> horrible colour, would you burn it down?
>
> I'd make a copy of your archives while they are still functional.
It really doesn't matter. My main tools are still there, only the ones
which adversely affect my blood pressure are going.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-16 18:07 +0100 |
| Message-ID | <ubivp8$3cjsl$1@dont-email.me> |
| In reply to | #172373 |
On 16/08/2023 14:16, David Brown wrote: > Tell me what you see as the advantage here, and why /you/ think it would > be a jolly good idea, and maybe I'll agree. But you have to say why it > would be better for everyone, not just for you personally - you need > good reasons to change 50 year old conventions. [Giving names to makefiles] * You can have more than one project in the same folder * You can have different configurations of the same project * You can have different makefiles customised to different compilers (Seed7 has nearly 20 different makefiles) * You can split up a project into components with their own separately invoked makefile * You can differentiate between a makefile that is called directly, and one that is called indirectly from another * If you expected to build X according to the build instructions, but the makefile is called Y, then you know something may be wrong 'make' must be unique in being an application that takes input from a file, but the name of the file is hardcoded. A few applications will use defaults when a filename is missing (even if it's 'stdin'), but are generally used with a specific name. I would actually make a missing filename an error for an application like this. Maybe make was written by the same person who hardcoded a.out as an output filename. They missing a trick by not having a.c as the default input for a C compiler; that makes as much sense.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-08-16 17:43 +0000 |
| Message-ID | <kV7DM.428702$U3w1.254445@fx09.iad> |
| In reply to | #172388 |
Bart <bc@freeuk.com> writes:
>On 16/08/2023 14:16, David Brown wrote:
> > Tell me what you see as the advantage here, and why /you/ think it would
> > be a jolly good idea, and maybe I'll agree. But you have to say why it
> > would be better for everyone, not just for you personally - you need
> > good reasons to change 50 year old conventions.
>'make' must be unique in being an application that takes input from a
>file, but the name of the file is hardcoded.
No, it is not. If you would trouble yourself to read the make manual
page, you'll find that:
1) the -f argument allows the specification of a arbitrary name for the
makefile.
2) Absent -f, make will look for 'makefile', 'GNUmakefile', or 'Makefile'.
$ man make
SYNOPSIS
make [ -f makefile ] [ options ] ... [ targets ] ...
...
Normally you should call your makefile either makefile or Makefile.
(We recommend Makefile because it appears prominently near the begin-
ning of a directory listing, right near other important files such as
README.) The first name checked, GNUmakefile, is not recommended for
most makefiles. You should use this name if you have a makefile that
is specific to GNU make, and will not be understood by other versions
of make. If makefile is `-', the standard input is read.
...
-f file, --file=file, --makefile=FILE
Use file as a makefile.
The usenet acronym 'RTFM' is always relevent.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-16 18:51 +0100 |
| Message-ID | <ubj2ac$3cusf$1@dont-email.me> |
| In reply to | #172399 |
On 16/08/2023 18:43, Scott Lurndal wrote: > Bart <bc@freeuk.com> writes: >> On 16/08/2023 14:16, David Brown wrote: >>> Tell me what you see as the advantage here, and why /you/ think it would >>> be a jolly good idea, and maybe I'll agree. But you have to say why it >>> would be better for everyone, not just for you personally - you need >>> good reasons to change 50 year old conventions. > >> 'make' must be unique in being an application that takes input from a >> file, but the name of the file is hardcoded. > > No, it is not. If you would trouble yourself to read the make manual > page, you'll find that: > 1) the -f argument allows the specification of a arbitrary name for the > makefile. > 2) Absent -f, make will look for 'makefile', 'GNUmakefile', or 'Makefile'. I know about -f because I've seen it. But most documented uses of 'make' seem with work with the default filename 'makefile'. Most projects I've seen with a makefile, have a file called 'makefile'. In the project that has been discussed, there were two makefiles both called 'makefile'. In the erroneous set of sources, one was missing. That left a bunch of source files and a file called 'makefile'. > Normally you should call your makefile either makefile or Makefile. This is what I mean. No, you shouldn't. Suppose you accidentally copy 'makefile' from elsewhere? You wouldn't be able to tell; they're all called Bob!
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-08-16 21:26 +0100 |
| Message-ID | <87h6oyhgxk.fsf@bsb.me.uk> |
| In reply to | #172388 |
Bart <bc@freeuk.com> writes: > 'make' must be unique in being an application that takes input from a file, > but the name of the file is hardcoded. Not really. The input to make is something like a configuration file, and lots of applications (in Unix land) read a configuration file derived from the program name. bc reads .bcrc, fetchmail reads .fetchmailrc and so on. Had the authors decided have make read a file called .makerc it would look much like many others. Of course, the makefile is something more than a simple configuration file, but it's also more like one than the files make is operating on that will be specified on the command line. (I'm ignoring -f because being able to override the default does not invalidate your comment. > Maybe make was written by the same person who hardcoded a.out as an output > filename. They missing a trick by not having a.c as the default input for a > C compiler; that makes as much sense. oh dear, I typed the above before reading this, but I'll post the explanation anyway... -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-16 22:25 +0100 |
| Message-ID | <ubjerj$3eo20$1@dont-email.me> |
| In reply to | #172408 |
On 16/08/2023 21:26, Ben Bacarisse wrote: > Bart <bc@freeuk.com> writes: > >> 'make' must be unique in being an application that takes input from a file, >> but the name of the file is hardcoded. > > Not really. The input to make is something like a configuration file, > and lots of applications (in Unix land) read a configuration file > derived from the program name. bc reads .bcrc, fetchmail reads > .fetchmailrc and so on. Had the authors decided have make read a file > called .makerc it would look much like many others. No, what make does with 'makefile' is not what I'd associate with configuration data which: * May be shared by, and is constant, across different deployments of the program when applied to different inputs * Controls how the application works, and has nothing about the user's data (at best, program settings the user has made which will carry over into the next invocation) * Is separate from the real user-supplied data for the application For example, I had an application called M7.EXE, and it used (among several config files), one called M7.INI that is read automatically. But when M7 is invoked, it can be given the name of a real data file. I don't have to copy my data (in this case a 3D data model) into M7.INI! >> Maybe make was written by the same person who hardcoded a.out as an output >> filename. They missing a trick by not having a.c as the default input for a >> C compiler; that makes as much sense. > > oh dear, I typed the above before reading this, but I'll post the > explanation anyway... And I posted a civil reply anyway despite your snide remark. Yes, some of these programs do look like the early efforts of a beginning programmer. Decades later, people (even you) try to rationalise their behaviour. I just say it like it is.
[toc] | [prev] | [next] | [standalone]
| From | Richard Harnden <richard.nospam@gmail.com> |
|---|---|
| Date | 2023-08-17 00:15 +0100 |
| Message-ID | <ubjlai$3fgvr$1@dont-email.me> |
| In reply to | #172415 |
On 16/08/2023 22:25, Bart wrote: > On 16/08/2023 21:26, Ben Bacarisse wrote: > > Bart <bc@freeuk.com> writes: > > > >> 'make' must be unique in being an application that takes input from > a file, > >> but the name of the file is hardcoded. > > > > Not really. The input to make is something like a configuration file, > > and lots of applications (in Unix land) read a configuration file > > derived from the program name. bc reads .bcrc, fetchmail reads > > .fetchmailrc and so on. Had the authors decided have make read a file > > called .makerc it would look much like many others. > > No, what make does with 'makefile' is not what I'd associate with > configuration data which: > > * May be shared by, and is constant, across different deployments of the > program when applied to different inputs > > * Controls how the application works, and has nothing about the user's > data (at best, program settings the user has made which will carry over > into the next invocation) > > * Is separate from the real user-supplied data for the application > You know this is not what makefiles are for. I think you're just being wrong on purpose.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-17 01:02 +0100 |
| Message-ID | <ubjo23$3fr73$1@dont-email.me> |
| In reply to | #172422 |
On 17/08/2023 00:15, Richard Harnden wrote: > On 16/08/2023 22:25, Bart wrote: >> On 16/08/2023 21:26, Ben Bacarisse wrote: >> > Bart <bc@freeuk.com> writes: >> > >> >> 'make' must be unique in being an application that takes input >> from a file, >> >> but the name of the file is hardcoded. >> > >> > Not really. The input to make is something like a configuration file, >> > and lots of applications (in Unix land) read a configuration file >> > derived from the program name. bc reads .bcrc, fetchmail reads >> > .fetchmailrc and so on. Had the authors decided have make read a file >> > called .makerc it would look much like many others. >> >> No, what make does with 'makefile' is not what I'd associate with >> configuration data which: >> >> * May be shared by, and is constant, across different deployments of >> the program when applied to different inputs >> >> * Controls how the application works, and has nothing about the user's >> data (at best, program settings the user has made which will carry >> over into the next invocation) >> >> * Is separate from the real user-supplied data for the application >> > > You know this is not what makefiles are for. > > I think you're just being wrong on purpose. Somebody compared the 'makefile' of 'make' to a configuration file of an aplication. I'm saying no, configuration files are different; they do this. So clearly I was not saying that's what makefiles do. So maybe /you're/ wrong being wrong on purpose just to make me look bad. Please stop it.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-08-17 02:56 +0100 |
| Message-ID | <87cyzmfn4d.fsf@bsb.me.uk> |
| In reply to | #172415 |
Bart <bc@freeuk.com> writes: > On 16/08/2023 21:26, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: >> >>> 'make' must be unique in being an application that takes input from a > file, >>> but the name of the file is hardcoded. >> >> Not really. The input to make is something like a configuration file, >> and lots of applications (in Unix land) read a configuration file >> derived from the program name. bc reads .bcrc, fetchmail reads >> .fetchmailrc and so on. Had the authors decided have make read a file >> called .makerc it would look much like many others. > > No, what make does with 'makefile' is not what I'd associate with > configuration data which: > > * May be shared by, and is constant, across different deployments of the > program when applied to different inputs You mean like a makefile? > * Controls how the application works, and has nothing about the user's data > (at best, program settings the user has made which will carry over into > the next invocation) That's a curious restriction! So a makefile with only general rules and settings qualifies? But as soon as it mentions any specific file it stops being "somewhat like" a configuration file (which is all I claimed)? > * Is separate from the real user-supplied data for the application Too vague for me. What is separate? What is the unreal data? Anyway, I did not expect to convince you. I hope you enjoyed considering a perspective that differs from your own. > I just say it like it is. You say it like you see it (as do I). To consider that as "like it is" takes more self confidence than I can muster. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-17 11:21 +0100 |
| Message-ID | <ubksbq$3o738$1@dont-email.me> |
| In reply to | #172432 |
On 17/08/2023 02:56, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 16/08/2023 21:26, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>>>
>>>> 'make' must be unique in being an application that takes input from a
>> file,
>>>> but the name of the file is hardcoded.
>>>
>>> Not really. The input to make is something like a configuration file,
>>> and lots of applications (in Unix land) read a configuration file
>>> derived from the program name. bc reads .bcrc, fetchmail reads
>>> .fetchmailrc and so on. Had the authors decided have make read a file
>>> called .makerc it would look much like many others.
>>
>> No, what make does with 'makefile' is not what I'd associate with
>> configuration data which:
>>
>> * May be shared by, and is constant, across different deployments of the
>> program when applied to different inputs
>
> You mean like a makefile?
>
>> * Controls how the application works, and has nothing about the
user's data
>> (at best, program settings the user has made which will carry
over into
>> the next invocation)
>
> That's a curious restriction! So a makefile with only general rules and
> settings qualifies? But as soon as it mentions any specific file it
> stops being "somewhat like" a configuration file (which is all I
> claimed)?
>
>> * Is separate from the real user-supplied data for the application
>
> Too vague for me. What is separate? What is the unreal data?
Configuration files for me are more like this:
APPLICATION < -- > USER DATA
^
|
v
[CONFIG FILE]
Config data is more like meta-data. (Maybe, a little like cookies used
by a program within a website; say one used to format user-supplied XML
data.)
It is not the primary data of the application.
For Make, the makefile /is/ the primary data. It belongs at that top
right. And it deserves a proper name.
Any configuration files are unlikely to have variable, user-provided names.
I think you were justifying Make using mainly fixed, hardcoded names for
its primary data, by classifying that data as configuration. I don't buy
it. That would make Make even more peculiar.
(What next, build Make from source with your project files listed in the
source code?)
>
> Anyway, I did not expect to convince you. I hope you enjoyed
> considering a perspective that differs from your own.
>
>> I just say it like it is.
>
> You say it like you see it (as do I). To consider that as "like it is"
> takes more self confidence than I can muster.
Make seems to mostly use a local file called 'makefile' for its primary
data. Certainly that's what it will use if no alternate is provided.
That's like 'it is'.
I have a Python benchmark where the input file name is hardcoded in the
source code. There's a comment to adjust that name to suit (or people
can use the same name for their own data). I couldn't be bothered to
process argv parameters.
Make is pretty much at that level.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-08-17 21:26 +0100 |
| Message-ID | <871qg1fmam.fsf@bsb.me.uk> |
| In reply to | #172440 |
Bart <bc@freeuk.com> writes: > On 17/08/2023 02:56, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: >>> I just say it like it is. >> >> You say it like you see it (as do I). To consider that as "like it is" >> takes more self confidence than I can muster. > > Make seems to mostly use a local file called 'makefile' for its primary > data. Certainly that's what it will use if no alternate is provided. > > That's like 'it is'. But, as you know perfectly well, that is not the remark you were claiming to have stated as it is. The claim -- to be just saying it as it is -- was in relation to quite a rude remark about me (and others). -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-17 23:40 +0100 |
| Message-ID | <ubm7kl$3ug67$1@dont-email.me> |
| In reply to | #172476 |
On 17/08/2023 21:26, Ben Bacarisse wrote: > Bart <bc@freeuk.com> writes: > >> On 17/08/2023 02:56, Ben Bacarisse wrote: >>> Bart <bc@freeuk.com> writes: > >>>> I just say it like it is. >>> >>> You say it like you see it (as do I). To consider that as "like it is" >>> takes more self confidence than I can muster. >> >> Make seems to mostly use a local file called 'makefile' for its primary >> data. Certainly that's what it will use if no alternate is provided. >> >> That's like 'it is'. > > But, as you know perfectly well, that is not the remark you were > claiming to have stated as it is. The claim -- to be just saying it as > it is -- was in relation to quite a rude remark about me (and others). > You said this: >oh dear, I typed the above before reading this, but I'll post the explanation anyway... I called that a snide remark. Is that what you mean by 'rude'? And your own dismissive comment wasn't? OK. I try very hard to not get personal on forums, and attack only ideas and attitudes. However too many do get personal and insulting. Or incredibly patronising like David Brown. Then I /will/ make a rude response. I take it you don't have a personal opinion about 'make'? You would have written it in the same way? But you'd rather write ad hominem remarks instead. > > But, as you know perfectly well, that is not the remark you were > claiming to have stated as it is. This is a puzzle now. What the hell did I say that is the problem now> You have a habit of dissecting and analysing every chance turn of phrase I use. That seems to be more important to you, being able to attack me, than the presumably less interesting topic of where 'make' takes its input from and whether that was a good way or bad. In my view it is bad; your view, I don't actually know other than you seem to be defending it.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-08-19 00:43 +0100 |
| Message-ID | <87il9bx6fq.fsf@bsb.me.uk> |
| In reply to | #172481 |
Bart <bc@freeuk.com> writes: > On 17/08/2023 21:26, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: >> >>> On 17/08/2023 02:56, Ben Bacarisse wrote: >>>> Bart <bc@freeuk.com> writes: >> >>>>> I just say it like it is. >>>> >>>> You say it like you see it (as do I). To consider that as "like it is" >>>> takes more self confidence than I can muster. >>> >>> Make seems to mostly use a local file called 'makefile' for its primary >>> data. Certainly that's what it will use if no alternate is provided. >>> >>> That's like 'it is'. >> >> But, as you know perfectly well, that is not the remark you were >> claiming to have stated as it is. The claim -- to be just saying it as >> it is -- was in relation to quite a rude remark about me (and others). >> > > You said this: > >> oh dear, I typed the above before reading this, but I'll post the >> explanation anyway... > > I called that a snide remark. Is that what you mean by 'rude'? No. (And why is that snide? You had made a sarcastic remark that seemed to render my effort in explaining my position redundant. I was just remarking that I would not have posted if I'd seen your sarcasm first.) Anyway, can you not go up the thread and see what it was you were saying "as it is"? It was this: | Yes, some of these programs do look like the early efforts of a beginning | programmer. Decades later, people (even you) try to rationalise their | behaviour. | | I just say it like it is. People (me included) are not trying to rationalising something that looks like the efforts of a beginner. It's dismissive, to the point of rudeness, to claim that people you disagree with were merely doing that. I wouldn't post at all if you were always likely to consider my remarks as nothing but rationalising basic errors. > I take it you don't have a personal opinion about 'make'? You would have > written it in the same way? But you'd rather write ad hominem remarks > instead. Again with the spin! Where does this impulse to attack imagined positions that no one has taken come from? (I've asked before if you have some background in politics, but you never say one way or the other.) To be clear: (a) I do have a personal opinion about make, but I don't think anyone would be interested in it. (b) I would not have written it in the same way. (c) If you object to anything personal I've said I will gladly apologise. You and I see programming like chalk and cheese but I don't want to get personal about it. > You have a habit of dissecting and analysing every chance turn of phrase I > use. That seems to be more important to you, being able to attack me, than > the presumably less interesting topic of where 'make' takes its input from > and whether that was a good way or bad. I explained my position on that quite calmly until I read your sarcastic mocking of the design. That's not technical criticism, that's just PR spin. And even then, all I said is that I would have replied had I seen the sarcasm first. -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 3 of 16 — ← Prev page 1 2 [3] 4 5 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web