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 9 of 16 — ← Prev page 1 … 7 8 [9] 10 11 … 16 Next page →
| From | Rainer Weikusat <rweikusat@talktalk.net> |
|---|---|
| Date | 2023-08-25 17:22 +0100 |
| Message-ID | <87edjrhz1d.fsf@doppelsaurus.mobileactivedefense.com> |
| In reply to | #172728 |
Kaz Kylheku <864-117-4973@kylheku.com> writes: [...] > If you're unfortunate enough to work with AutoTools, then for pete's > sake, generate the configure script, and the Makefile.in and whatnot, > and check them into the repository. Do that every time they change. I routinely remove these from any source tree I seriously need to work with because sooner or later, changes to all the autosomething files will become necessary and intermediate autosomething files generated from the others tend to get in the way then.
[toc] | [prev] | [next] | [standalone]
| From | Spiros Bousbouras <spibou@gmail.com> |
|---|---|
| Date | 2023-08-25 16:39 +0000 |
| Message-ID | <55ZtEPESLDecorlDj@bongo-ra.co> |
| In reply to | #172767 |
On Fri, 25 Aug 2023 17:22:54 +0100 Rainer Weikusat <rweikusat@talktalk.net> wrote: > Kaz Kylheku <864-117-4973@kylheku.com> writes: > > [...] > > > If you're unfortunate enough to work with AutoTools, then for pete's > > sake, generate the configure script, and the Makefile.in and whatnot, > > and check them into the repository. Do that every time they change. > > I routinely remove these from any source tree I seriously need to work > with because sooner or later, changes to all the autosomething files > will become necessary and intermediate autosomething files generated > from the others tend to get in the way then. git supports the gitignore file to cover such situations : https://git-scm.com/docs/gitignore .So you can add all the automatically generated files to a gitgnore file.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-25 16:54 +0000 |
| Message-ID | <20230825095132.571@kylheku.com> |
| In reply to | #172768 |
On 2023-08-25, Spiros Bousbouras <spibou@gmail.com> wrote: > On Fri, 25 Aug 2023 17:22:54 +0100 > Rainer Weikusat <rweikusat@talktalk.net> wrote: >> Kaz Kylheku <864-117-4973@kylheku.com> writes: >> >> [...] >> >> > If you're unfortunate enough to work with AutoTools, then for pete's >> > sake, generate the configure script, and the Makefile.in and whatnot, >> > and check them into the repository. Do that every time they change. >> >> I routinely remove these from any source tree I seriously need to work >> with because sooner or later, changes to all the autosomething files >> will become necessary and intermediate autosomething files generated >> from the others tend to get in the way then. > > git supports the gitignore file to cover such situations : > https://git-scm.com/docs/gitignore .So you can add all the automatically > generated files to a gitgnore file. I think, gitignore doesn't cover the situation when some of those files are tracked in git, but you disagree. -- 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 | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-25 17:02 +0000 |
| Message-ID | <20230825095521.754@kylheku.com> |
| In reply to | #172767 |
On 2023-08-25, Rainer Weikusat <rweikusat@talktalk.net> wrote: > Kaz Kylheku <864-117-4973@kylheku.com> writes: > > [...] > >> If you're unfortunate enough to work with AutoTools, then for pete's >> sake, generate the configure script, and the Makefile.in and whatnot, >> and check them into the repository. Do that every time they change. > > I routinely remove these from any source tree I seriously need to work > with because sooner or later, changes to all the autosomething files > will become necessary and intermediate autosomething files generated > from the others tend to get in the way then. If you have to change the configuration, you have to make a commit for that and check in the updated files. That maintains the repository in a configurable, buildable state for a downstream user who deosn't have AutoTools installed. If you use the same version of the tools as what was previously used, then the diffs in those files will be minimized. -- 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 | Rainer Weikusat <rweikusat@talktalk.net> |
|---|---|
| Date | 2023-08-25 19:21 +0100 |
| Message-ID | <87a5ufhtk5.fsf@doppelsaurus.mobileactivedefense.com> |
| In reply to | #172770 |
Kaz Kylheku <864-117-4973@kylheku.com> writes: > On 2023-08-25, Rainer Weikusat <rweikusat@talktalk.net> wrote: >> Kaz Kylheku <864-117-4973@kylheku.com> writes: >> >> [...] >> >>> If you're unfortunate enough to work with AutoTools, then for pete's >>> sake, generate the configure script, and the Makefile.in and whatnot, >>> and check them into the repository. Do that every time they change. >> >> I routinely remove these from any source tree I seriously need to work >> with because sooner or later, changes to all the autosomething files >> will become necessary and intermediate autosomething files generated >> from the others tend to get in the way then. > > If you have to change the configuration, you have to make a commit for > that and check in the updated files. > > That maintains the repository in a configurable, buildable state > for a downstream user who deosn't have AutoTools installed. Downstream users are a problem I don't have. Nevertheless, I think a repository is something supposed to be used for development, ie, it should be expected that users of it will make changes to .ac and .am files. If the files generated from these are also in the repository, nuisance git dances will have to be performed to deal with them and this will also cause nuisance merge conflicts for updates.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-25 18:56 +0000 |
| Message-ID | <20230825113441.899@kylheku.com> |
| In reply to | #172775 |
On 2023-08-25, Rainer Weikusat <rweikusat@talktalk.net> wrote: > Kaz Kylheku <864-117-4973@kylheku.com> writes: >> That maintains the repository in a configurable, buildable state >> for a downstream user who deosn't have AutoTools installed. > > Downstream users are a problem I don't have. > > Nevertheless, I think a > repository is something supposed to be used for development, ie, it > should be expected that users of it will make changes to .ac and .am > files. A repository should easily support all parties. Someone who wants to build the program for their own use, package it for a distro, or work on it. Downstream users are a problem that open source projects have. > If the files generated from these are also in the repository, > nuisance git dances will have to be performed to deal with them and this > will also cause nuisance merge conflicts for updates. If you merge parallel changes to a primary file from which a secondary file is generated, you must regenerate the secondary file. The seconary file should not be merged. (That would be editing, and generated files are "generated, do not edit", right?) The problem is not that you get a conflict in the secondary file. The problem is that you might *not* get a conflict in it, but (1) it's a bad merge (even though the merge of the primary file is good) and (2) it happens that the badly merged secondary has a newer timestamp than the primary, so the build system doesn't notice that it needs to be regenerated. So, in fact, it's probably a good idea for a generated file to include some boilerplate header with the time and date (or hash of the primary file), so that it will cause a merge conflict on puprpose, preventing a silent bad merge! E.g.: // // foo.c: generated from foo.x: do not edit! // // If you get a merge conflict in the following line, do not try // to resolve it (see "do not edit!) above; regenerate the file using // "make foo.c": // // 0828aa34e7d8bf5c8007e897ce12459912e7ee491e1c17377432c8bf204704be -- 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 | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-24 11:44 -0700 |
| Message-ID | <87sf88fffe.fsf@nosuchdomain.example.com> |
| In reply to | #172720 |
Bart <bc@freeuk.com> writes:
> On 24/08/2023 16:51, Kaz Kylheku wrote:
[...]
>> Unix already had make as far back as 1979.
>> Here is the source tree for the utilities:
>> https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd
[...]
>> There are some single file .c utilities and some subdirectories.
>> There is a "makeall" shell script which invokes something amusingly
>> called "cmake" on the top level files, individually.
>> This cmake is a script in the cmake/ subdirectory. A silly thing it
>> has
>> a big case statement that switches on the program name and branches to a
>> customized compile command. Many of them are identical except for names;
>> it's obviously copy-paste.
>> Most of the subdirectories have makefiles (lower case "makefile";
>> they hadn't yet thought of supporting "Makefile" so that it would
>> appear above lower-cased source file names; modern make still looks
>> for a "makefile" too).
>> The makefiles are tidy; they look better than an equivalent script.
>> By equivalent I mean a script that handles the dependencies for
>> incremental rebuilds.
>> Here is adb/makefile from V7 Unix, dated January 11, 1979:
>> CFLAGS = -i -O
>> all: adb
>> cmp: adb
>> cmp adb /bin/adb
>> rm adb *.o
>> cp: adb
>> cp adb /bin/adb
>> rm adb *.o
>> adb: access.o command.o expr.o findfn.o
>> adb: format.o input.o opset.o main.o
>> adb: message.o output.o pcs.o print.o
>> adb: runpcs.o setup.o sym.o
>> adb:; cc -o adb -i *.o
>>
>> access.o: defs.h
>> command.o: defs.h
>> expr.o: defs.h
>> findrtn.o: defs.h
>> format.o: defs.h
>> input.o: defs.h
>> main.o: defs.h
>> message.o: mac.h mode.h
>> output.o: defs.h
>> pcs.o: defs.h
>> print.o: defs.h
>> runpcs.o: defs.h
>> setup.o: defs.h
>> sym.o: defs.h
>> This is very tidy and more or less how make should be used today.
>> We can see that in 1979, make already had built-in rules for
>> compiling. We
>> don't see the compile command anywhere, or how CFLAGS is pulled into the build.
>> It must have been beneficial to those coders to only have to
>> recompile output.c to output.o when output.c was touched.
>
> Some observations:
>
> * This is a C project? If so there is a remarkable lack of .c files!
Make has a number of implicit rules, one of which is that foo.o depends
on foo.c and is generated by something like "$(CC) $(CFLAGS) -c foo.c".
It wasn't necessary to list the *.c files in the Makefile.
> * opset.o has no dependencies?
It implicitly depends on opset.c. If opset.o doesn't exist when you run
make, it will compile opset.c to generateit.
> * There is a lot of repetition of defs.h
>
> * All the modules (except opset.o) are named twice
Because they all depend on defs.h.
> * How are the dependencies derived? I guess either manually, which
> can be error prone, or an extra tool is needed that understands
> C code
Yes, either manually or with an extra tool.
> * The project seems simple enough that you will know:
>
> * No .c file depends on any other. Any edit to a .c
> file only requires compiling that one file
>
> * With any changes to defs.h, you might as well compile the lot
>
> * At best, the makefile lists the modules that are submitted to the
> linker
>
> In this case, you can easily do without 'make'.
If you're building the whole thing from scratch, probably.
Suppose you're doing development on the project. Since the last time
you built it, you've modified 3 of the 16 *.c files. Maybe you don't
remember which ones. Maybe you used a script to do a global
search-and-replace, so you don't even know which files you changed
unless you look at their timestamps. Without make, you can either
rebuild everything (which on a project of this size on 1979 hardware, or
on a larger project on modern hardware, might be unreasonably slow), or
you can figure out which files you need to recompile. The latter is
error-prone. (I've certainly re-run a program after making a source
file change and forgetting to recompile.)
Or you can type "make" and it will rebuild only what needs to be
rebuilt. Type "make" again, and it does nothing, because there's
nothing to do.
Sure, you could provide a script that just compiles everything
unconditionally. That could be useful for users who want to build the
project from source but don't need to modify anything. (And you could
construct such a script from the output of make.)
But if you can make some reasonable assumptions about the tools your
users will have on their systems, there's no need for such a script.
Anyone who would even consider building Unix V7 adb command from source
in 1979 would have had make already, and the presence of a makefile in
the directory would have been more than enough of a clue that that's how
to build it. (More modern software distributions would likely have a
README and/or INSTALL file, and the makefile would have a "clean"
target.)
For a typical user who wants to do a clean build, running "make" just
works. There's a lot of stuff going on behind the scenes, but the
typical user doesn't need to care about that, as long as the maekefile
is written correctly.
[...]
--
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 | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-24 18:47 +0000 |
| Message-ID | <20230824112048.435@kylheku.com> |
| In reply to | #172720 |
On 2023-08-24, Bart <bc@freeuk.com> wrote:
> On 24/08/2023 16:51, Kaz Kylheku wrote:
>> Here is adb/makefile from V7 Unix, dated January 11, 1979:
>>
>> CFLAGS = -i -O
>>
>> all: adb
>>
>> cmp: adb
>> cmp adb /bin/adb
>> rm adb *.o
>>
>> cp: adb
>> cp adb /bin/adb
>> rm adb *.o
>>
>> adb: access.o command.o expr.o findfn.o
>> adb: format.o input.o opset.o main.o
>> adb: message.o output.o pcs.o print.o
>> adb: runpcs.o setup.o sym.o
>> adb:; cc -o adb -i *.o
>>
>>
>> access.o: defs.h
>> command.o: defs.h
>> expr.o: defs.h
>> findrtn.o: defs.h
>> format.o: defs.h
>> input.o: defs.h
>> main.o: defs.h
>> message.o: mac.h mode.h
>> output.o: defs.h
>> pcs.o: defs.h
>> print.o: defs.h
>> runpcs.o: defs.h
>> setup.o: defs.h
>> sym.o: defs.h
>>
>> This is very tidy and more or less how make should be used today.
>>
>> We can see that in 1979, make already had built-in rules for compiling. We
>> don't see the compile command anywhere, or how CFLAGS is pulled into the build.
>>
>> It must have been beneficial to those coders to only have to
>> recompile output.c to output.o when output.c was touched.
>
> Some observations:
>
> * This is a C project? If so there is a remarkable lack of .c files!
This is how makefiles are still written today.
here is a section from the Makefile of the TXR language I work on
OBJS := txr.o lex.yy.o y.tab.o match.o lib.o regex.o gc.o unwind.o stream.o
OBJS += arith.o hash.o utf8.o filter.o eval.o parser.o rand.o combi.o sysif.o
OBJS += args.o autoload.o cadr.o struct.o itypes.o buf.o jmp.o protsym.o ffi.o
OBJS += strudel.o vm.o tree.o time.o psquare.o
OBJS += chksum.o chksums/sha1.o chksums/sha256.o chksums/crc32.o chksums/md5.o
OBJS += linenoise/linenoise.o
OBJS-$(debug_support) += debug.o
OBJS-$(have_syslog) += syslog.o
OBJS-$(have_glob) += glob.o
OBJS-$(have_ftw) += ftw.o
OBJS-$(have_posix_sigs) += signal.o
OBJS-$(have_sockets) += socket.o
OBJS-$(have_termios) += termios.o
OBJS-$(have_zlib) += gzio.o
EXTRA_OBJS-$(add_win_res) += win/txr.res
You will not find the .c files mentioned.
The program is an executable made by loading and linking .o files.
Given a progran name like "adb", make cannot figure out what .o files
it is made out of, so that has to be spelled out somehow.
Given a .o file like output.o, make *can* implicitly figure out that
there is an output.c, which might be newer.
Looks like that by 1979, they had all this in make already. Built
in rules, and automatic inference of prerequisites based on suffix
rules.
> * opset.o has no dependencies?
Not exactly true; there is an opset.c file, so it has that dependency.
If opset.c includes header files that are not mentioned here, then
that's a bug in the makefile.
(And why we like to obtain dependency makefile fragments from the
compiler.)
> * There is a lot of repetition of defs.h
Perhaps they didn't yet have multiple left-hand-side targets yet?
In modern (or even not-so-modern) make, we woiuld do:
OBJS = access.o command.o expr.o findfn.o \
format.o input.o opset.o main.o \
message.o output.o pcs.o print.o \
runpcs.o setup.o sym.o
adb: $(OBJS)
$(OBJS): defs.h # a few don't include defs.h: no huge deal.
In GNU Make:
OBJS_no_defs = opsyms.o message.o
$(filter-out $(OBJS_no_defs), $(OBJS)): defs.h
> * All the modules (except opset.o) are named twice
In spite of that, the linker line
adb:; cc -o adb -i *.o
neglects to refer to the makefile's list of objects,
reaching for a shell wildcard.
Clearly, this looks like good practices around makefiles had
far from gelled yet.
> * How are the dependencies derived? I guess either manually, which
> can be error prone, or an extra tool is needed that understands
> C code
>
> * The project seems simple enough that you will know:
>
> * No .c file depends on any other. Any edit to a .c
> file only requires compiling that one file
Correct and make has that covered already.
> * With any changes to defs.h, you might as well compile the lot
Exactly: using "make clean" or "rm *.o" and then make.
> In this case, you can easily do without 'make'.
You can, but even automating the recompiling of just the
changed .c file will be a fairly ugly script.
Without dependencies and without the "cp" and "cmp"
targets, the makefile gets short:
CFLAGS = -i -O
OBJS = access.o command.o expr.o findfn.o \
format.o input.o opset.o main.o \
message.o output.o pcs.o print.o \
runpcs.o setup.o sym.o
adb:; cc -o adb -i $(OBJS)
We can drop the "all" target because adb is the first
and only target.
If the files use a comon header, with just one more
line we handle that:
$(OBJS): defs.h
message.o: mac.c mode.h
So it's a no-brainer.
Don't discount make because of bad makefiles, including ones
from the birthplace of make.
--
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 | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-24 21:20 +0100 |
| Message-ID | <uc8e2b$3k7gq$1@dont-email.me> |
| In reply to | #172724 |
On 24/08/2023 19:47, Kaz Kylheku wrote: > On 2023-08-24, Bart <bc@freeuk.com> wrote: > (And why we like to obtain dependency makefile fragments from the > compiler.) That sounds like an incremental process. How does the compiler know which files to look at? It looks at the makefile. Presumably dependencies (conditional compilation) have to be turned off to ensure all files are visited. > Without dependencies and without the "cp" and "cmp" > targets, the makefile gets short: > > CFLAGS = -i -O > > OBJS = access.o command.o expr.o findfn.o \ > format.o input.o opset.o main.o \ > message.o output.o pcs.o print.o \ > runpcs.o setup.o sym.o > > adb:; cc -o adb -i $(OBJS) This reminds me of another point: * The makefile exposes intermediate .o files I think this is undesirable. That's an internal compiler detail. Some compilers may use different extensions. Some may even dispense with intermediate files (I was thinking of doing that), or don't have a linking stage. The same .o file extension may also be used by multiple languages. Another matter, which applies to your original example, is that adding or removing modules requires updating multiple sites in the makefile. > We can drop the "all" target because adb is the first > and only target. > > If the files use a comon header, with just one more > line we handle that: > > $(OBJS): defs.h > > message.o: mac.c mode.h > > So it's a no-brainer. > > Don't discount make because of bad makefiles, including ones > from the birthplace of make. I'm discounting it for my own purposes because (1) I have a module system so half of it is redundant; (2) for C, I only need simple lists of C files; (3) I use very fast compilers so the other half, dependencies, is also redundant. There's not much left! (I also consider development, remote one-off builds, and app installation as separate tasks that shouldn't be lumped together) I wonder if the existence of makefiles stopped C getting modules? Because it fills part of that role, but is a separate thing outside of the language.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-24 22:59 +0000 |
| Message-ID | <20230824153204.791@kylheku.com> |
| In reply to | #172725 |
On 2023-08-24, Bart <bc@freeuk.com> wrote: > On 24/08/2023 19:47, Kaz Kylheku wrote: >> On 2023-08-24, Bart <bc@freeuk.com> wrote: > >> (And why we like to obtain dependency makefile fragments from the >> compiler.) > > That sounds like an incremental process. How does the compiler know > which files to look at? It looks at the makefile. Presumably > dependencies (conditional compilation) have to be turned off to ensure > all files are visited. When nothing is built at all, then the dependencies don't matter. Every object file must be built. In the course of building it, the dependencies are visited by the compiler. GCC can dump them in the form of a makefile fragment. Those fragments can be included into the Makefile (using -include (dash include) which doesn't fail when the included file is missing). >> Without dependencies and without the "cp" and "cmp" >> targets, the makefile gets short: >> >> CFLAGS = -i -O >> >> OBJS = access.o command.o expr.o findfn.o \ >> format.o input.o opset.o main.o \ >> message.o output.o pcs.o print.o \ >> runpcs.o setup.o sym.o >> >> adb:; cc -o adb -i $(OBJS) > > This reminds me of another point: > > * The makefile exposes intermediate .o files > > I think this is undesirable. That's an internal compiler detail. Some > compilers may use different extensions. Some may even dispense with > intermediate files (I was thinking of doing that), or don't have a > linking stage. Looks like it has stood the test of time: here we are in 2023, and still there are .o files made from .c files. > The same .o file extension may also be used by multiple languages. That is so, E.g. C++ will use .o, assembly language files will use .o. The part of the name before the .o has to be different in such a mixed project. You just don't have have an input.s and input.c assembling and compiling to input.o, or not in the same directory. > Another matter, which applies to your original example, is that adding > or removing modules requires updating multiple sites in the makefile. j > >> We can drop the "all" target because adb is the first >> and only target. >> >> If the files use a comon header, with just one more >> line we handle that: >> >> $(OBJS): defs.h >> >> message.o: mac.c mode.h >> >> So it's a no-brainer. >> >> Don't discount make because of bad makefiles, including ones >> from the birthplace of make. > > I'm discounting it for my own purposes because (1) I have a module > system so half of it is redundant; (2) for C, I only need simple lists > of C files; (3) I use very fast compilers so the other half, > dependencies, is also redundant. > > There's not much left! > > (I also consider development, remote one-off builds, and app > installation as separate tasks that shouldn't be lumped together) > > I wonder if the existence of makefiles stopped C getting modules? > Because it fills part of that role, but is a separate thing outside of > the language. I'd say it's mostly because modules are academic. I worked with Modula-2, and Pascal variants with modules, so I understand what modules do. They are a kind of toy idea that works fine for certain kinds of programs. The "module agnostic" C model proves to be flexible in various situations like producing firmware image such as bootloaders, shared libraries, kernel drivers and whatnot. Module system are opinionated about initialization. They generate the startup code to initialize modules in the correct order. This can be inflexible. A firmware build for the bare metal may require custom linking with flexible use of sections to assign initialization functions to different initialization phases. Being "module agnostic" means C is mixed with other languages easily. If a C object file needs a function to be called to initialize it, that will be an ordinary, named function. From what I remember of Modula-2, it doesn't offer any solution for program shutdown. The top-level initialization blocks in modules were called in the correct order: used modules initialized before using modules. But there was nothing for orderly shutdown. Circular references were a problem. In real-world programs, modules have circular dependencies: A depends on B, while B also depends on A. Firstly, you need some way to support that on a syntactic level. In C we can do it, e.g. using incomplete types. The header file "B.h" can refer to a "struct A" without having to include "A.h". Initialization may be broken into multiple stages like b_early_init() is called before a_early_init(), where b_early_init does those B initializations that don't depend on anything in A. Then later b_late_init() is called that performs initializations that now assume a_early_init() has been. I think that a module system that doesn't handle flexible multi-phase initialization, orderly shutdown and circular dependencies, and relies on "magic" unnamed code being generated by the compiler is too broken for most real world use. C dodged a bullet by not going for anything like that. It's better to leave some problems unsolved than to commit to a bad solution. -- 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 | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-25 02:18 +0100 |
| Message-ID | <uc8vi3$3qrit$1@dont-email.me> |
| In reply to | #172727 |
On 24/08/2023 23:59, Kaz Kylheku wrote: > On 2023-08-24, Bart <bc@freeuk.com> wrote: >> I think this is undesirable. That's an internal compiler detail. Some >> compilers may use different extensions. Some may even dispense with >> intermediate files (I was thinking of doing that), or don't have a >> linking stage. > > Looks like it has stood the test of time: here we are in 2023, and > still there are .o files made from .c files. > >> The same .o file extension may also be used by multiple languages. For actual object files, I've also used .obj. Or my C compiler used only .asm, no binary object files (and even .asm was usually internal; no discrete file). Elsewhere I don't use intermediate files at all. Or for interpreted languages I've sometimes use bytecode files, which do not need linking. It can be quite diverse and that's just for what I do! >> I wonder if the existence of makefiles stopped C getting modules? >> Because it fills part of that role, but is a separate thing outside of >> the language. > > I'd say it's mostly because modules are academic. > > I worked with Modula-2, and Pascal variants with modules, so I > understand what modules do. > > They are a kind of toy idea that works fine for certain kinds of > programs. > > The "module agnostic" C model proves to be flexible in various > situations like producing firmware image such as bootloaders, > shared libraries, kernel drivers and whatnot. > > Module system are opinionated about initialization. They generate the > startup code to initialize modules in the correct order. This can be > inflexible. A firmware build for the bare metal may require custom > linking with flexible use of sections to assign initialization functions > to different initialization phases. > > Being "module agnostic" means C is mixed with other languages easily. > If a C object file needs a function to be called to initialize it, > that will be an ordinary, named function. > > From what I remember of Modula-2, it doesn't offer any solution for > program shutdown. The top-level initialization blocks in modules were > called in the correct order: used modules initialized before using > modules. But there was nothing for orderly shutdown. > > Circular references were a problem. In real-world programs, modules have > circular dependencies: A depends on B, while B also depends on A. Each language has its own ideas about what modules even mean. I've tried to keep mine simple and practical. My first attempt had a hierarchical module structure with no circular imports. It was a nuisance (but there were underhand methods to get around that). Then I eventually had circular references (I may have moved to whole-program compilation at the same time), but there was a problem in determining load-order: If A imports B and vice-versa, and they each have an automatically called init section, which gets loaded first? My current scheme solves that. And for my stuff, it works extremely well. Although it also just moves some of the interface problems away from boundaries between modules, and into the boundaries between programs and libraries: my program/library structure is still hierarchical. > Firstly, you need some way to support that on a syntactic level. > In C we can do it, e.g. using incomplete types. The header > file "B.h" can refer to a "struct A" without having to include "A.h". I partly did it by allowing out-of-order definitions for everything. But that is quite hard to do. My latest project steps back from that. > Initialization may be broken into multiple stages like b_early_init() > is called before a_early_init(), where b_early_init does those B > initializations that don't depend on anything in A. Then later > b_late_init() is called that performs initializations that now assume > a_early_init() has been. > > I think that a module system that doesn't handle flexible multi-phase > initialization, orderly shutdown and circular dependencies, and > relies on "magic" unnamed code being generated by the compiler is > too broken for most real world use. C dodged a bullet by not going for > anything like that. > It's better to leave some problems unsolved than to commit to a bad > solution. I've mentioned a simple module scheme that could be used for C, but requiring compiler support. It requires that all modules use tidy .c/.h pairs. Circular references aren't a problem, because in C, modules still use separate interface (.h) files, and the latter are written manually. It was automatic interface/export files combined with independent module compilation that was the obstacle with my early module attempts.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-24 20:17 -0700 |
| Message-ID | <87o7ivg69r.fsf@nosuchdomain.example.com> |
| In reply to | #172732 |
Bart <bc@freeuk.com> writes:
> On 24/08/2023 23:59, Kaz Kylheku wrote:
>> On 2023-08-24, Bart <bc@freeuk.com> wrote:
>>> I think this is undesirable. That's an internal compiler detail. Some
>>> compilers may use different extensions. Some may even dispense with
>>> intermediate files (I was thinking of doing that), or don't have a
>>> linking stage.
>> Looks like it has stood the test of time: here we are in 2023, and
>> still there are .o files made from .c files.
>>
>>> The same .o file extension may also be used by multiple languages.
>
> For actual object files, I've also used .obj. Or my C compiler used
> only .asm, no binary object files (and even .asm was usually internal;
> no discrete file).
The authors of a makefile written to build the UNIX V7 adb command in
1979 didn't worry about the compiler using a suffix other than ".o", or
about the compiler driver having a name other than "cc". There's no
reason they should have. It probably never occurred to them that it
would be built on a non-UNIX system. Neither MS Windows nor MS-DOS even
existed yet.
And if there had been a possibility of the compiler generating ".obj"
files, the suffix could easily have been parameterized in the makefile.
If you're wondering why the makefile referred to the object files at all
rather than the source files, it's so that the object files could be
kept around and not rebuilt unnecessarily during development.
> Elsewhere I don't use intermediate files at all. Or for interpreted
> languages I've sometimes use bytecode files, which do not need
> linking.
That's nice. Seriously, it is. But we're discussing the makefile for a
UNIX-only tool written in C. Why mention irrelevancies (unless you're
suggesting that adb should have been written in an interpreted language
in 1979)?
> It can be quite diverse and that's just for what I do!
The makefile we're discussing wasn't written for diverse environments.
--
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 | Anton Shepelev <anton.txt@g{oogle}mail.com> |
|---|---|
| Date | 2023-08-24 16:30 +0300 |
| Message-ID | <20230824163053.7bd1ec8295f40b3dad1582bc@g{oogle}mail.com> |
| In reply to | #172703 |
David Brown to Anton Shepelev:
> > Borland and Free Pascal compilers do not require a
> > separate build system (nor a project file, or solution)
> > to build a large modular program. The modern reliance on
> > super compicated tools for simple tasks is horrifying.
> > It makes the programmer feel as a servant rathern than a
> > demiurge.
>
> The version of "make" that I used with DOS and Windows for
> about a decade came with Borland Pascal. (It might even
> have been Turbo Pascal, before the renaming.)
Yes, the Borland Pascal distribution on vetusware.com
includes a make utility, but I am not at all certain it is
required to build a modular program. I think the compiler
will figure out the dependency hierarcy between the various
source files itself, reserving `make' for especially complex
cases.
> Mostly I used the IDE for building Pascal projects, rather
> than a makefile.
So did I, but the FreePascal command-line compiler is
perfectly usable without make, because the language supports
real modules and spares the programmer specifying the
dependency hierarchy by hand. Libraries and paths are
specified in configuration file fpc.cfg.
FreePascal's make uses makefiles written in Pascal:
https://wiki.freepascal.org/FPMake
--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-08-23 17:43 +0000 |
| Message-ID | <UyrFM.102486$O8ab.3406@fx40.iad> |
| In reply to | #172701 |
Anton Shepelev <anton.txt@g{oogle}mail.com> writes:
>Bart quoth:
>
>> Build systems will get more complex and impenetrable, not
>> simpler and more transparent.
>
>Bart's law.
Sure, whatever you say. I'd call it an effect
of the second law of thermodynamics, myself.
>
>Borland and Free Pascal compilers do not require a separate
>build system (nor a project file, or solution) to build a
>large modular program.
Have any "large modular" programs ever been built in the modern
era using either of those compilers? What is your definition
of both large and modular?
I challenge Bart to try to build qemu without a makefile, or
the linux kernel, or vmware, or the cert stack for Verisign
enterprise certificate generation.
The application I'm working on has an executable driver or
can be dynamically linked with python or other applications and consists
of a very small executable, a large shared object and a
few dozen run-time loadable shared objects that are optionally
loaded depending on run-time configuration of the application.
It consists of about 9 million source lines of code across a few
hundred source files. Stored, of course in a set of hierarchical
directories.
Yet for all that build complexity, the actual makefiles are
small, readable and maintainable.
I challenge Bart to build it using 'bcc *.cpp' or even 'bcc *.cpp */*.cpp */*/*.cpp'
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-23 20:15 +0100 |
| Message-ID | <uc5lsi$32bjk$1@dont-email.me> |
| In reply to | #172704 |
On 23/08/2023 18:43, Scott Lurndal wrote:
> Anton Shepelev <anton.txt@g{oogle}mail.com> writes:
>> Bart quoth:
>>
>>> Build systems will get more complex and impenetrable, not
>>> simpler and more transparent.
>>
>> Bart's law.
>
> Sure, whatever you say. I'd call it an effect
> of the second law of thermodynamics, myself.
>
>>
>> Borland and Free Pascal compilers do not require a separate
>> build system (nor a project file, or solution) to build a
>> large modular program.
>
> Have any "large modular" programs ever been built in the modern
> era using either of those compilers? What is your definition
> of both large and modular?
>
> I challenge Bart to try to build qemu without a makefile, or
> the linux kernel, or vmware, or the cert stack for Verisign
> enterprise certificate generation.
That's like challenging me to travel to the moon using my car.
I think that is a 'strawman' argument. You create an extreme version of
the tasks for which I believe makefiles are unnecessarily used, then
claim that /my/ simpler approach to those tasks won't work.
Yet, my car is perfectly adequate for a school run; I don't need a Saturn V.
> The application I'm working on has an executable driver or
> can be dynamically linked with python or other applications and consists
> of a very small executable, a large shared object and a
> few dozen run-time loadable shared objects that are optionally
> loaded depending on run-time configuration of the application.
>
> It consists of about 9 million source lines of code across a few
> hundred source files. Stored, of course in a set of hierarchical
> directories.
>
> Yet for all that build complexity, the actual makefiles are
> small, readable and maintainable.
> I challenge Bart to build it using 'bcc *.cpp' or even 'bcc *.cpp */*.cpp */*/*.cpp'
Compilers like my 'mm.exe' product accomplish only one task: producing a
single .EXE binary file. To that end, they are given the name of the
lead source module, and from that point everything is automatic.
So building an app presented as multiple components will need a simple
script.
However, C is different: compilers need to be told the files that
comprise each binary. That in itself does not cause complexity; that's
just a simple list.
But makefiles take that simple list and expand it into a graph of
inter-dependencies. (Which information also has to be imparted by
external means; make isn't that clever.)
They further expose intermediate representations such as .o files, which
should be the business of the compiler.
The whole is then further polluted with matters of installation and
maintenance. And then all buried under impenetrable syntax.
Now I don't know the details of your project, or what you consider
'small' and 'readable'. But if it is that small, you can probably use a
simple script.
You might also consider what an emergency build process might look like,
where you've lost all binaries and want to quickly compile everything
without effing about with dependency graphs. The sort of thing that I've
been claiming should accompany packaged sources of working applications.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.moc> |
|---|---|
| Date | 2023-08-26 18:19 +0300 |
| Message-ID | <20230826181917.2c486bc60d07dc5eea471ede@gmail.moc> |
| In reply to | #172704 |
Scott Lurndal to Anton Shepelev > > Borland and Free Pascal compilers do not require a > > separate build system (nor a project file, or solution) > > to build a large modular program. > > Have any "large modular" programs ever been built in the > modern era using either of those compilers? What do you ask specifically about the modern era, limiting the entire history of computing to the tiny slice of its current state? FreePascal is a modern language and compiler, for that matter, and the majority of programs written in that require no dedicated build system. > What is your definition of both large and modular? A modular program is one comprising two or more moules, such as introduced in Modula and supported by the Borlad dialect of Pascal (as "units"), and now present in the majority of modern languages, such as Python, Julia, and C#. You know what they are. C's source files are not modules, although I wish there were, see: Date: Thu, 1 Nov 2018 01:11:42 +0300 From: Anton Shepelev <anton.txt@gmail.com> Newsgroups: comp.lang.c Message-Id: <20181101011142.368f7c22ba2b54779b99f69a@gmail.com> `large' is not a technical term and needs no personal definition from me. Do you ask for quantitive criteria? But I don't think they matter in our case because it is not the size of a project that makes it need a dedicated build tool. The FreePascal compiler does the basic job of buidling the dependency tree and recompiling only the changed files, whereas the compiler settings and library pathds are stored in a simple config file. > [...] > Yet for all that build complexity, the actual makefiles > are small, readable and maintainable. Great, but the majority of popular open-source software has horrible makefiles. > I challenge Bart to build it using 'bcc *.cpp' or even > 'bcc *.cpp */*.cpp */*/*.cpp' I fear participation in such a challenge will take an unreasonable amount of effort. Is it not easier to discuss the specific tasks that your makefiles peform and what Bart proposes instead? I, for one, had the impression that Bart objects to (ab)using complicated build systems with relatively small and simple programs, rather than the Linux kernel... -- () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-08-26 21:47 -0700 |
| Message-ID | <86r0npxf9y.fsf@linuxsc.com> |
| In reply to | #172816 |
Anton Shepelev <anton.txt@gmail.moc> writes: > Scott Lurndal to Anton Shepelev >> What is your definition of [...] modular? > > A modular program is one comprising two or more moules, such > as introduced in Modula [...] Modules appeared earlier in the programming language Mesa. Modula copied them from Mesa.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@g{oogle}mail.com> |
|---|---|
| Date | 2023-08-28 11:31 +0300 |
| Message-ID | <20230828113117.1141aca74003695959b17a29@g{oogle}mail.com> |
| In reply to | #172859 |
Tim Rentsch to Anton Shepelev: > > A modular program is one comprising two or more moules, > > such as introduced in Modula [...] > > Modules appeared earlier in the programming language Mesa. > Modula copied them from Mesa. Bad word choice on my part. I quoted Modula as an example of a language with modules, not as the first programming language on Earth to support them. Modula introduced its own kind of module. Now that I have looked up Mesa in Wikipedia, I see that Mesa's modules are similar to C's header-source pairs in that they consist of at least two files. Not so in Modula, where a module is a single self-contained source file. Furthermore, Wikipedia lists Modula as predating Mesa by a year. -- () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-08-28 06:48 -0700 |
| Message-ID | <86il8zxopd.fsf@linuxsc.com> |
| In reply to | #172956 |
Anton Shepelev <anton.txt@g{oogle}mail.com> writes:
> Tim Rentsch to Anton Shepelev:
>
>>> A modular program is one comprising two or more moules,
>>> such as introduced in Modula [...]
>>
>> Modules appeared earlier in the programming language Mesa.
>> Modula copied them from Mesa.
>
> Bad word choice on my part. I quoted Modula as an example of
> a language with modules, not as the first programming
> language on Earth to support them. Modula introduced its own
> kind of module.
Okay.
> Now that I have looked up Mesa in Wikipedia, I see that
> Mesa's modules are similar to C's header-source pairs in
> that they consist of at least two files. Not so in Modula,
> where a module is a single self-contained source file.
Okay.
> Furthermore, Wikipedia lists Modula as predating Mesa by a
> year.
Niklaus Wirth was at Xerox PARC while Mesa was being developed.
It was after that experience that he started working on Modula.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-08-25 02:11 +0100 |
| Message-ID | <87fs48q62b.fsf@bsb.me.uk> |
| In reply to | #172695 |
Bart <bc@freeuk.com> writes: > On 23/08/2023 03:18, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: >> >>> On 22/08/2023 01:31, Ben Bacarisse wrote: >>> >>>>> If there's anything extra, then that can be explained. This can be put into >>>>> a Readme or Install or Build text file. >>>> Sounds simple. What does this simple solution look like for a68g? I'll >>>> send it to the authors if you don't want to do that yourself. >>>> >>> >>> Have a look at the post I made 21-08-23 14:12 BST, and follow-on ones, >>> where I explore what happens when a build process provides such >>> information. >> I'll look if you provide the message ID. That's how Usenet posts are >> cited. >> >>> In that case, 1000s of lines of 'configure' scripts and numerous makefiles >>> could be reduced to a 6-line build script, even if the lines are somewhat >>> long. >>> >>> That is unusual, but note that this was version 9 of that project; that >>> info was not present on version 6. >> That's not an Algol 68G version number. You have switched horses yet >> again. >> >>> (I'm not replying to your other points as you are not receptive to what I >>> am trying to do. You are just shrugging your shoulders at Windows. So is >>> nearly everyone. You are part of the problem. >> What should I do "at Windows". You seem to think I should care about >> how easily Unix/Linux software builds on it. Why should I? > > At least you appear to believe me when I say that makefiles on Windows are > very often troublesome. Since some here are trying to say that it's purely > due to my incompetence. Will you answer any questions? > But you also say that I should put on my cape and single-handedly fix all > the myriad projects where it could be handled better. No I did not say that. In fact I said something very different > So you acknowledge that some apps build poorly on Windows, but are not > surprised, and also don't appear to care since you don't use Windows. > > Then I'm not quite sure why you're taking part in this thread. It seems to > be one giant <shrug>. I participated because you didn't know what make is, how it is used or the benefits it brings to the people who use it. I hope you are, at least, a little better informed on these topics. > It's my turn then not to be surprised that Linux is so highly favoured in > build systems Linux is favoured by the build systems because all the examples you picked were for Linux software. Is there no similar healthy ecosystem of Windows software? If so, I image very little of it would build on Linux without some work. > if your attitude is typical but Windows gets the second or > third class treatment: For years, Linux was (so the story went) the poor relation. All the good end-user software was developed for Windows. Surely that has not changed to such an extent that the only software you care about is now Linux-specific. > ... But you seem to think I should > personally take charge of every such project on the planet, Spin! Seriously, every time I ask if you have a background in politics you duck the question. Do you? -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 9 of 16 — ← Prev page 1 … 7 8 [9] 10 11 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web