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 10 of 16 — ← Prev page 1 … 8 9 [10] 11 12 … 16 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-25 11:27 +0100 |
| Message-ID | <uc9vmu$3vvmi$1@dont-email.me> |
| In reply to | #172729 |
On 25/08/2023 02:11, Ben Bacarisse wrote: > 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? What sort of answers are you looking for? >> 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 I understand now that people use it to solve certain types of problems where there are no commonly used alternatives. I disagree about some of the problems, and have generally used alternatives. Those alternatives also tend to be simpler and shorter. I understand that given the choice of one tool, and typical patterns of use (pack /everything/ into one hard-to-understand file), people will get into the habit of using it for everything, even when simple alternatives will work just as well. There could easily be an option in a makefile (if not, than redirecting the output will do most of it) where the commands needed to do a clean build, with certain defaults, can be captured into a shell script. Then just supply that script with a source bundle (as well as the makefile). That could be a more foolproof backup. >> 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. I don't actively seek out Windows software. But most attempts to use libraries seem to end up in some rabbit-hole which always leads back to Linux. While open-source projects I might want to build tend to be Linux-centric, even ones you'd think cannot possible depend on which OS they run on, since they only read and write files. Some that are Windows-only tend to use big tools like Visual Studio, which is not for me either. Even a library with ready-made binaries, like GTK, has a humungous set of headers. Even the instructions to install on Windows start off with advice to MSYS2 which 'provides a UNIX-like environment for Windows'. Um, it's bunch of headers! The first GTK example I saw used this command line: gcc $(pkg-config --cflags gtk4) -o hello-world-gtk hello-world-gtk.c $(pkg-config --libs gtk4) Presumably pkg-config is something I have to install, that picks up some config info that is part of GTK and imparts it to the compiler? See, another rabbit-hole! I went into GTK in some detail when I tried to use it from bcc. There, pkg-config is meaningless. (I have my own ideas on how libraries like this should be presented, but that is another tangential subject.) (BTW I was just about able to run a GTK hello-world using bcc, using a workaround. That workaround was necessary because GTK2 exposed bitfields within its public interface. Bitfields are implementation-dependent (?). The issue here was that it affected the size of an important struct. My bcc doesn't do bitfields, they are treated as regular ints so struct sizes can be different.)
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-08-25 13:52 +0000 |
| Message-ID | <Mm2GM.463337$U3w1.33730@fx09.iad> |
| In reply to | #172748 |
Bart <bc@freeuk.com> writes: >On 25/08/2023 02:11, Ben Bacarisse wrote: >> 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? > >What sort of answers are you looking for? Start with the question you evaded "Why should he care how easily unix/linux software is built on windows".
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-25 15:40 +0100 |
| Message-ID | <ucaegi$2p2r$1@dont-email.me> |
| In reply to | #172761 |
On 25/08/2023 14:52, Scott Lurndal wrote: > Bart <bc@freeuk.com> writes: >> What sort of answers are you looking for? > > Start with the question you evaded "Why should he care how easily unix/linux > software is built on windows". Where did I say that BB personally should care? I /have/ remarked on why, if he doesn't care because it doesn't affect him, why be so antagonistic, and why participate at all? My posts are about easily ANY software is built on Windows, where either it is supposed to do so, or there is no reason why it shouldn't. You people wonder why /I/ am so antagonistic towards C. And it is those possessive attitudes as much as anything else. C is /your/ language; it was designed for and on /your/ beloved Unixes; it mainly uses /your/ compilers (where MSVC is seen as the enemy, and Mingw as some watered-down imitation of gcc and friends); and of course it makes full use of all the toys Unix provides (as much as possible, just out of spite!) You also make no secret of how much you despise Windows. Why would anyone even want to run C on Windows? It's only for Unix! Who cares whether any programs work on such a 'shitty' operating system? One that you actually have to ... buy? So your attitude is, Just use C at your own risk, but we're not going to make it easy for you. To compile code, just install half of Linux because we're not going to lift a finger otherwise to make it simpler. That's what I get from this thread, and from you and BB in particular. Is that about right! Windows users are third class citizens that no body ought to care about? If so, that is despical. I'm glad I don't use your fucking 'make'.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-25 20:04 +0200 |
| Message-ID | <ucaqf7$4q0l$2@dont-email.me> |
| In reply to | #172765 |
On 25/08/2023 16:40, Bart wrote: > On 25/08/2023 14:52, Scott Lurndal wrote: >> Bart <bc@freeuk.com> writes: > >>> What sort of answers are you looking for? >> >> Start with the question you evaded "Why should he care how easily >> unix/linux >> software is built on windows". > > Where did I say that BB personally should care? > > I /have/ remarked on why, if he doesn't care because it doesn't affect > him, why be so antagonistic, and why participate at all? > > My posts are about easily ANY software is built on Windows, where either > it is supposed to do so, or there is no reason why it shouldn't. > > You people wonder why /I/ am so antagonistic towards C. And it is those > possessive attitudes as much as anything else. > > C is /your/ language; it was designed for and on /your/ beloved Unixes; > it mainly uses /your/ compilers (where MSVC is seen as the enemy, and > Mingw as some watered-down imitation of gcc and friends); and of course > it makes full use of all the toys Unix provides (as much as possible, > just out of spite!) > > You also make no secret of how much you despise Windows. Why would > anyone even want to run C on Windows? It's only for Unix! Who cares > whether any programs work on such a 'shitty' operating system? One that > you actually have to ... buy? > > So your attitude is, Just use C at your own risk, but we're not going to > make it easy for you. To compile code, just install half of Linux > because we're not going to lift a finger otherwise to make it simpler. > > That's what I get from this thread, and from you and BB in particular. > > Is that about right! Windows users are third class citizens that no body > ought to care about? > > If so, that is despical. I'm glad I don't use your fucking 'make'. > You might want to cut down on the hallucinogenics - they are making you paranoid. There is pretty much nothing in that rant that has a foundation in reality or in posts in this thread. You seem to be reading what you want to read, or expect to read - not what is actually written.
[toc] | [prev] | [next] | [standalone]
| From | candycane@f172.n1.z21.fsxnet (candycane) |
|---|---|
| Date | 2023-08-26 00:47 +1300 |
| Message-ID | <2903500388@f172.n1.z21.fsxnet> |
| In reply to | #172761 |
SL> Start with the question you evaded "Why should he care how easily SL> unix/linux software is built on windows". I'd think it would be because most people use windows unfortunately. You're bound to deal with this if you want any kind of cross platformness. ----------------------------------- user is generated from /dev/urandom
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-08-25 21:26 +0100 |
| Message-ID | <87edjqq36m.fsf@bsb.me.uk> |
| In reply to | #172748 |
Bart <bc@freeuk.com> writes: > On 25/08/2023 02:11, Ben Bacarisse wrote: >> 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? > > What sort of answers are you looking for? Clearly, that's a "no". You didn't answer the question nine lines up, nor the one asking if would answer any. For the record: I don't care what sort of answer, provided that the words used constitute what as reasonable reader would call an answer. >>> 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 > > I understand now that people use it to solve certain types of problems > where there are no commonly used alternatives. > > I disagree about some of the problems, and have generally used > alternatives. Those alternatives also tend to be simpler and shorter. > > I understand that given the choice of one tool, and typical patterns of use > (pack /everything/ into one hard-to-understand file), people will get into > the habit of using it for everything, even when simple alternatives will > work just as well. I get the impression that you still don't know why people use make. You have certainly offered no alternative. > There could easily be an option in a makefile (if not, than redirecting the > output will do most of it) where the commands needed to do a clean build, > with certain defaults, can be captured into a shell script. > > Then just supply that script with a source bundle (as well as the > makefile). That could be a more foolproof backup. What problem do you think this will solve? On a typical system targeted by the authors, just typing make will probably just work. If you think it will help with an unsupported build like Algol 68G on Windows, I can capture the commands and send them to you to try. >>> 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. > > I don't actively seek out Windows software. But most attempts to use > libraries seem to end up in some rabbit-hole which always leads back to > Linux. If it is not just you, but a much more widely help opinion that most "attempts to use libraries" eventually depend on Linux software, then Linux (or maybe GNU) has won. I can't say I'm not pleased to hear this, but I appreciate it must be awkward for people developing on Windows. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-26 01:42 +0100 |
| Message-ID | <ucbhpd$8s7o$1@dont-email.me> |
| In reply to | #172786 |
On 25/08/2023 21:26, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>>>>> 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?
> Clearly, that's a "no". You didn't answer the question nine lines up,
> nor the one asking if would answer any.
You want me to tell you why should care? In what capacity of yours would
that be?
Obviously I care, and it's not just because of my personal needs. I see
the current solutions as poor.
You obviously don't care when a solution involves an autocong-generated
script of nearly forty thousand lines that does countless largely
pointless tests.
If you can't see anything Wrong with that then there's nothing much
further I can say to you.
(BTW that 38Kloc configure file was for gzip. That one failed on 'make'
with a missing aclocal-1.16. After online searching I was able to get
around that using:
apt install autoconf
followed by:
autoreconf -f -i
Now make (using a generated 2.5Kloc makefile) proceeds, apparently doing
many of the same tests that ./configure has done, for example:
checking how to run the C preprocessor... gcc -E
Then it fails with being unable to makeinfo or MAKEINFO. Installing
either didn't work. Again, an online search suggested the real package
needed is texinfo:
apt-get install texinfo
Now make eventually completes. What it has created is unclear, I have to
do a directory listing to find it has produced a 440KB executable, a
640KB archive (which seems to include its own versions of functions like
'fopen' and 'printf'), and a number of small bash scripts.
My trick of trying to capture the actual gcc commands doesn't work here;
it is just too deviant. All I can tell you is that libgzip.a probably
comprises 56 .c files, and gzip about another dozen files.)
>> I understand that given the choice of one tool, and typical patterns of use
>> (pack /everything/ into one hard-to-understand file), people will get into
>> the habit of using it for everything, even when simple alternatives will
>> work just as well.
>
> I get the impression that you still don't know why people use make. You
> have certainly offered no alternative.
I've concentrated on one type of task: doing a remote build from source
of a working resource by someone who will be a user, not developer or
maintainer.
And for that, I have mentioned many approaches I have used. Plus of
course I have been building programs of my own for a very long time
without problems and without resorting to such elaborate build methods.
I Keep Things Simple.
>> There could easily be an option in a makefile (if not, than redirecting the
>> output will do most of it) where the commands needed to do a clean build,
>> with certain defaults, can be captured into a shell script.
>>
>> Then just supply that script with a source bundle (as well as the
>> makefile). That could be a more foolproof backup.
>
> What problem do you think this will solve?
Probably nothing. Spending 30 minutes dealing with that Gzip thing has
drained me completely.
Is this the the state-of-the-art in building software? Labyrinthine
scripts in multiple layers which are intent on hiding their tracks.
I really despair. The binaries produced are about 1MB. I can build a 1MB
executable from source in a fraction of second with no fuss at all - I
must be doing something wrong!
If you and others think this gzip business: 38,000 lines of Bash, 2,500
lines of obscure makefile, a million things going on, requiring multiple
extensions to the remote Ubuntu system, is THE way to /distribute/
software from source, then I'm wasting my time.
> If it is not just you, but a much more widely help opinion that most
> "attempts to use libraries" eventually depend on Linux software, then
> Linux (or maybe GNU) has won. I can't say I'm not pleased to hear this,
> but I appreciate it must be awkward for people developing on Windows.
It only affects me when building other people's software, then it is
just frustrating in how complex and, yes, backward some of this stuff it.
Especially how few understand the difference between a developer's
build, and the streamlined one needed by a user:
level 1 lib.dll
level 2 lib.c needs gcc -shared -olib.dll lib.c
level 3 *.c in one linear folder
level 4 *.c in multiple nested folders
level 5 ???? configure scripts, obscure makefiles,
synthesised makefiles, synthesised source
files, needs additional tools, ...
Ideally the user wants just the binary. Sometimes (for example gmail
doesn't like sending .dll attachments), one step back from that is
better, so still one file, but of C source code.
I used to provide level 1 and 2 (either for Windows, level 2 for Linux).
But not everyone has the means to produce an amalgamated file, so level
3 is acceptable. This is a simple list of C files in the same place.
Most open source software however is made available as level 4, and I
seem also to come across lots of level 5 where anything goes.
On Windows I usually work with libraries that exist as DLL binaries.
Then it is enough work creating bindings for those (for my languages'
FFIs) when the APIs are presented as C header files.
Ones that need building from source, I stay clear of.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-08-27 01:16 +0100 |
| Message-ID | <87r0npnxv5.fsf@bsb.me.uk> |
| In reply to | #172790 |
Bart <bc@freeuk.com> writes: > On 25/08/2023 21:26, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: > >>>>>> 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? > >> Clearly, that's a "no". You didn't answer the question nine lines up, >> nor the one asking if would answer any. > > You want me to tell you why should care? In what capacity of yours would > that be? I don't know. I'm not sure what you mean. I'm just someone who trains dogs a couple of days a week and writes code for fun every now and then. > Obviously I care, and it's not just because of my personal needs. I see the > current solutions as poor. I see them as failed -- at least I take your word for it that the examples you tried failed. Maybe we misunderstand "caring"? In some very abstract sense I care. I'd like everything in the world to work perfectly for everyone. But, to me, caring is active. Should I do something about the fact that a lot of Unix/Linux software does not build easily on Windows? And, if so, why? > You obviously don't care when a solution involves an autocong-generated > script of nearly forty thousand lines that does countless largely pointless > tests. I never said that. >>> I understand that given the choice of one tool, and typical patterns of use >>> (pack /everything/ into one hard-to-understand file), people will get into >>> the habit of using it for everything, even when simple alternatives will >>> work just as well. >> I get the impression that you still don't know why people use make. You >> have certainly offered no alternative. > > I've concentrated on one type of task: doing a remote build from source of > a working resource by someone who will be a user, not developer or > maintainer. Yes. That will, inevitably, lead to some deep misunderstanding of why people use make. I don't think there's much point in examining this in detail though. >>> There could easily be an option in a makefile (if not, than redirecting the >>> output will do most of it) where the commands needed to do a clean build, >>> with certain defaults, can be captured into a shell script. >>> >>> Then just supply that script with a source bundle (as well as the >>> makefile). That could be a more foolproof backup. >> What problem do you think this will solve? > > Probably nothing. That makes it a very odd suggestion. But thank you for giving a direct answer. > If you and others think this gzip business: 38,000 lines of Bash, 2,500 > lines of obscure makefile, a million things going on, requiring multiple > extensions to the remote Ubuntu system, is THE way to /distribute/ software > from source, then I'm wasting my time. Spin. There are obviously other ways with different costs and benefits. >> If it is not just you, but a much more widely help opinion that most >> "attempts to use libraries" eventually depend on Linux software, then >> Linux (or maybe GNU) has won. I can't say I'm not pleased to hear this, >> but I appreciate it must be awkward for people developing on Windows. > > It only affects me when building other people's software, then it is just > frustrating in how complex and, yes, backward some of this stuff it. It's been weirdly successful. Like C itself. A good critique would include some examination of the reasons for that success. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-25 05:51 +0000 |
| Message-ID | <20230824224817.54@kylheku.com> |
| In reply to | #172695 |
On 2023-08-23, Bart <bc@freeuk.com> wrote: > At least you appear to believe me when I say that makefiles on Windows > are very often troublesome. By the same (preprocessor?) token, Visual C or C++ programs are troublesome on Unix. Nothing is more siloed than Windows development tools connected with Microsoft. -- 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 | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-24 23:17 -0700 |
| Message-ID | <9091fc13-35c7-4543-bd34-5b7739ebf4a3n@googlegroups.com> |
| In reply to | #172736 |
On Friday, 25 August 2023 at 06:52:04 UTC+1, Kaz Kylheku wrote: > On 2023-08-23, Bart <b...@freeuk.com> wrote: > > At least you appear to believe me when I say that makefiles on Windows > > are very often troublesome. > By the same (preprocessor?) token, Visual C or C++ programs > are troublesome on Unix. > > Nothing is more siloed than Windows development tools connected > with Microsoft. > Yes. The big companies like Microsoft and Apple don't really like portable software, because they want programs to run on their system and their system alone. But Baby X programs run on both Windows and Linux. The CMake script works for both, with just a small amount of platform-specific twiddling.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-21 02:52 +0000 |
| Message-ID | <20230820191756.541@kylheku.com> |
| In reply to | #172605 |
On 2023-08-21, Bart <bc@freeuk.com> wrote:
> On 21/08/2023 00:51, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 20/08/2023 20:48, Ben Bacarisse wrote:
>>>> bart c <bart4858@gmail.com> writes:
>>>
>>>> But for some reason not quite attractive enough. Why? That's not
>>>> rhetorical. I really would like to know why you spend this amount of
>>>> time on something you don't like and don't want to use. It's really
>>>> odd.
>>>
>>> I'd replied at length to some of your other points, until I came to
>>> this.
>>
>> That's a good idea. Often there is only one key point in contention.
>>
>>> So why is it hard to move on? Because it means you have all won.
>>
>> Ah, I see. What does winning look like to you? Stopping me from using
>> make? Making me use your software? Are you prepared to document it and
>> support it? Or is winning to you just getting people to say they agree
>> with you? Do you want me to say that make is crap and gcc shouldn't
>> assemble and compile C on the same command line?
>
> How about admitting that the solutions based around makefiles can end up
> more elaborate than necessary, and more fragile.
>
>>
>>> You've championed what I consider to be a poor tool for building open
>>> source software. You're championing complexity.
>>
>> I am not championing anything. I use it. I like it. It has always
>> worked to build the software I've needed it to build. You found open
>> source software that does not build on Windows using make.
>
> But why SHOULDN'T it build on Windows? What's the difference between a C
> compiler on Windows and on Linux? Isn't C supposed to be portable?
C supports portable programming. Building C programs is not required to
be portable according to the language standard. Right at the outset,
in section "1 Scope", that stuff is declared out of scope and so
not part of the language:
it is written (I'm quoting the C99 version of the text):
This International Standard does not specify
— the mechanism by which C programs are transformed for use by a
data-processing system;
— the mechanism by which C programs are invoked for use by a
data-processing system;
— the mechanism by which input data are transformed for use by a C program;
— the mechanism by which output data are transformed after being
produced by a C program;
— the size or complexity of a program and its data that will exceed the
capacity of any specific data-processing system or the capacity of a
particular processor;
— all minimal requirements of a data-processing system that is capable
of supporting a conforming implementation.
C came from Unix. On Unix, people were using makefiles and a program
called "cc" with -c and -o options, and an "a.out" default.
Those things were not specified as part of C. People took C into other
systems, and had a different take on the "para-programming" aspect;
what the C compiler looks like, how it is called, and what to do about
incremental builds.
When C standardization came along, that was not considered part of the
language. There were two working groups: one standardizing the language,
and one working on a Unix standard. The people working on the Unix
standard *did* consider that build stuff to be in their domain.
C and Unix were born together. Both are standardized, but in
standardization, they forked. We have ISO C 9899 for C, and IEEE 1003
"POSIX" for Unix.
Some programs take advantage of both standards. They use the C langauge
with the POSIX library and are built by POSIX tools like make.
> But what is it about compiling these 72 .c files under non-Unix, that
> makes it so hard? I can't just compile them as some .h files need to be
> created.
What's hard about non-Unix is that Unix is standard environment.
It has a standard: IEEE 1003 "POSIX".
Non-unix is nonstandard, and nonstandard is harder due to proliferating
the ways of doing things, and having inadequate/missing tooling.
POSIX is a language: it has the shell and utilities. Utilities like
sed, awk, and Make.
Systems which conform to POSIX can be targeted by programs in
that language, like makefiles containing shells script fragments that
use the utilities.
Then for all the systems that don't conform to POSIX, we have to use
their arbitrary languages for all the "para-programming".
> Anyway this can be chalked up under a project that I can't build despite
> all those makefiles. Why are these 15 C compilers all so different
> anyway, and how do they differ from Unix compilers? It's the same language!
C is the same language, but non-Unix is not the same language as Unix.
Isn't it obvious?
> Gzlib. A compression utility.
>
> This only had makefile.am/.in, and ./configure. Another project which
> you'd think, as it reads and writes files, would hardly be OS-specific.
Gzip comes from the GNU project.
The boss of the GNU project was/is a keen Lisp programmer. His ideal
system would have been some kind of Lisp machine. This preference
is well documented in his own writings.
However, more than that, he wanted the world to be liberated from
proprietary software. He saw that Unix systems were more popular than
Lisp machines, and so he decided that his GNU project would replace the
proprietary software in Unix. That would be the target. (And there
would be Lisp, as an application, rather than as the foundational basis
for the entire system.)
Thus, programs like Gzip, GNU Bash, GNU Make and GNU C were explicitly
geared toward the Unix world. They exactly copied Unix conventions,
where applicable, albeit with their own extensions.
They built using the Unix ways, because that suited the GNU project; all
the utilities used for building a GNU program on a proprietary Unix like
SunOS were being replaced by the GNU project itself: a system loaded
with GNU utilities instead of proprietary Unix utilities could also
build the GNU programs.
Users were able to choose how much GNU stuff to use; it was designed to
blend in. You could choose to use GNU Bash instead of the shell that
came with your Unix, but otherwise use its utilities. Or you could
choose just to have GNU grep, and nothing else. Or just the GNU
compiler, but nothing else from GNU.
GNU stands for "GNU is not Unix" but of course it's a clone of Unix.
GNU set the tone for subsequent FOSS. Linus Torvalds started a project
which gave GNU a practical kernel to run over to form a complete
system and the rest is recent history.
That sytem spawned a hotbed of FOSS activity, and most of that
activity has been Unix-flavored.
Non-Unix systems are just annoying outliers. For various reasons, people
are required to work with them, and want to bring some of that FOSS, so
they get up to their knees and elbows in shit and make it work.
--
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 | vallor <vallor@cultnix.org> |
|---|---|
| Date | 2023-08-21 03:02 +0000 |
| Message-ID | <ubuk47$1j6dq$2@dont-email.me> |
| In reply to | #172611 |
On Mon, 21 Aug 2023 02:52:44 -0000 (UTC), Kaz Kylheku <864-117-4973@kylheku.com> wrote in <20230820191756.541@kylheku.com>: > On 2023-08-21, Bart <bc@freeuk.com> wrote: >> On 21/08/2023 00:51, Ben Bacarisse wrote: >>> Bart <bc@freeuk.com> writes: >>> >>>> On 20/08/2023 20:48, Ben Bacarisse wrote: >>>>> bart c <bart4858@gmail.com> writes: >>>> >>>>> But for some reason not quite attractive enough. Why? That's not >>>>> rhetorical. I really would like to know why you spend this amount >>>>> of time on something you don't like and don't want to use. It's >>>>> really odd. >>>> >>>> I'd replied at length to some of your other points, until I came to >>>> this. >>> >>> That's a good idea. Often there is only one key point in contention. >>> >>>> So why is it hard to move on? Because it means you have all won. >>> >>> Ah, I see. What does winning look like to you? Stopping me from >>> using make? Making me use your software? Are you prepared to >>> document it and support it? Or is winning to you just getting people >>> to say they agree with you? Do you want me to say that make is crap >>> and gcc shouldn't assemble and compile C on the same command line? >> >> How about admitting that the solutions based around makefiles can end >> up more elaborate than necessary, and more fragile. >> >> >>>> You've championed what I consider to be a poor tool for building open >>>> source software. You're championing complexity. >>> >>> I am not championing anything. I use it. I like it. It has always >>> worked to build the software I've needed it to build. You found open >>> source software that does not build on Windows using make. >> >> But why SHOULDN'T it build on Windows? What's the difference between a >> C compiler on Windows and on Linux? Isn't C supposed to be portable? > > C supports portable programming. Building C programs is not required to > be portable according to the language standard. Right at the outset, > in section "1 Scope", that stuff is declared out of scope and so not > part of the language: > > it is written (I'm quoting the C99 version of the text): > > This International Standard does not specify > > — the mechanism by which C programs are transformed for use by a > data-processing system; > — the mechanism by which C programs are invoked for use by a > data-processing system; > — the mechanism by which input data are transformed for use by a C > program; > — the mechanism by which output data are transformed after being > produced by a C program; > — the size or complexity of a program and its data that will exceed > the > capacity of any specific data-processing system or the capacity of a > particular processor; > — all minimal requirements of a data-processing system that is capable > of supporting a conforming implementation. > > C came from Unix. On Unix, people were using makefiles and a program > called "cc" with -c and -o options, and an "a.out" default. > > Those things were not specified as part of C. People took C into other > systems, and had a different take on the "para-programming" aspect; what > the C compiler looks like, how it is called, and what to do about > incremental builds. > > When C standardization came along, that was not considered part of the > language. There were two working groups: one standardizing the language, > and one working on a Unix standard. The people working on the Unix > standard *did* consider that build stuff to be in their domain. > > C and Unix were born together. Both are standardized, but in > standardization, they forked. We have ISO C 9899 for C, and IEEE 1003 > "POSIX" for Unix. > > Some programs take advantage of both standards. They use the C langauge > with the POSIX library and are built by POSIX tools like make. > >> But what is it about compiling these 72 .c files under non-Unix, that >> makes it so hard? I can't just compile them as some .h files need to be >> created. > > What's hard about non-Unix is that Unix is standard environment. > It has a standard: IEEE 1003 "POSIX". > > Non-unix is nonstandard, and nonstandard is harder due to proliferating > the ways of doing things, and having inadequate/missing tooling. > > POSIX is a language: it has the shell and utilities. Utilities like sed, > awk, and Make. > > Systems which conform to POSIX can be targeted by programs in that > language, like makefiles containing shells script fragments that use the > utilities. > > Then for all the systems that don't conform to POSIX, we have to use > their arbitrary languages for all the "para-programming". > >> Anyway this can be chalked up under a project that I can't build >> despite all those makefiles. Why are these 15 C compilers all so >> different anyway, and how do they differ from Unix compilers? It's the >> same language! > > C is the same language, but non-Unix is not the same language as Unix. > > Isn't it obvious? > >> Gzlib. A compression utility. >> >> This only had makefile.am/.in, and ./configure. Another project which >> you'd think, as it reads and writes files, would hardly be OS-specific. > > Gzip comes from the GNU project. > > The boss of the GNU project was/is a keen Lisp programmer. His ideal > system would have been some kind of Lisp machine. This preference is > well documented in his own writings. > > However, more than that, he wanted the world to be liberated from > proprietary software. He saw that Unix systems were more popular than > Lisp machines, and so he decided that his GNU project would replace the > proprietary software in Unix. That would be the target. (And there > would be Lisp, as an application, rather than as the foundational basis > for the entire system.) > > Thus, programs like Gzip, GNU Bash, GNU Make and GNU C were explicitly > geared toward the Unix world. They exactly copied Unix conventions, > where applicable, albeit with their own extensions. > > They built using the Unix ways, because that suited the GNU project; all > the utilities used for building a GNU program on a proprietary Unix like > SunOS were being replaced by the GNU project itself: a system loaded > with GNU utilities instead of proprietary Unix utilities could also > build the GNU programs. > > Users were able to choose how much GNU stuff to use; it was designed to > blend in. You could choose to use GNU Bash instead of the shell that > came with your Unix, but otherwise use its utilities. Or you could > choose just to have GNU grep, and nothing else. Or just the GNU > compiler, but nothing else from GNU. > > GNU stands for "GNU is not Unix" but of course it's a clone of Unix. > > GNU set the tone for subsequent FOSS. Linus Torvalds started a project > which gave GNU a practical kernel to run over to form a complete system > and the rest is recent history. > > That sytem spawned a hotbed of FOSS activity, and most of that activity > has been Unix-flavored. > > Non-Unix systems are just annoying outliers. For various reasons, people > are required to work with them, and want to bring some of that FOSS, so > they get up to their knees and elbows in shit and make it work. Thank you for this excellent post, and thank you for the time it took you to write it. -- -v
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-21 06:05 +0000 |
| Message-ID | <20230820205419.975@kylheku.com> |
| In reply to | #172613 |
On 2023-08-21, vallor <vallor@cultnix.org> wrote: > On Mon, 21 Aug 2023 02:52:44 -0000 (UTC), Kaz Kylheku > > Thank you for this excellent post, and thank you for the time it took > you to write it. You're welcome. I glossed over some important things: one of which being how hard it had been to write programs that only work on multiple Unixes and nothing else. In the 1980s, Unix was a zoo due to everyone licensing the code and rolling their own. They couldn't agree on how to copy memory around: BSD had bcopy (which some goofballs still use today in new program) AT&T introduced memcpy. Differences in TTY handling, job control, shared memory, file locking, yadda yadda, you name it. Different hader files. Then the environment: broken shells and whatnot, so you resort to crap like if test foo$x = $x ; ... then The GNU project had its hands full just with the chosen mission: to make replacement equivalents of Unix programs, and get them to build everywhere. GNU programs went with the approach of using scripts to detect features of the environment and then to focus on making up for differences or lack of individual features. They did some things that are not so great in hindsight, like a monstrous configuraton system based on using M4 as a compiler that generates a shell script, which then detects features and generates makefile fragments and header files. That continues to be used even though there is a lot less of a reason for it. Today, the situation is a lot better, with much improved consistency among systems due to standardization (and also market forces that wiped out "weird" systems leaving fewer players). Still, even today, if you write some nontrivial program and get it working on a few Linux distros, Cygwin, and MacOS, that's no guarantee it will build on, say, Solaris, and getting it to build there is no guarantee it will work on AIX, and so on. There are still little problems you run into. Even just minor things. Like that one one system, if you include a certain POSIX header file, it also includes another one that you happen to need (but didn't include). On antoher system, that other one is not included for you by the first header, so the program breaks. -- 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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-08-21 11:32 +0100 |
| Message-ID | <87lee4sn1q.fsf@bsb.me.uk> |
| In reply to | #172615 |
Kaz Kylheku <864-117-4973@kylheku.com> writes: > On 2023-08-21, vallor <vallor@cultnix.org> wrote: >> On Mon, 21 Aug 2023 02:52:44 -0000 (UTC), Kaz Kylheku >> >> Thank you for this excellent post, and thank you for the time it took >> you to write it. > > You're welcome. > > I glossed over some important things: one of which being how hard it had > been to write programs that only work on multiple Unixes and nothing > else. > > In the 1980s, Unix was a zoo due to everyone licensing the code and > rolling their own. To make matters worse, C was a zoo then too. Some compilers had void and some did not. Most had unsigned and long but not all had structure assignment and parameter passing. Some had function prototype syntax and some did not. And then there were extensions galore. For a long time you could not write any significant Windows software without near and far pointers. > They couldn't agree on how to copy memory around: BSD > had bcopy Yes. In K&R1 "the C library" was essentially the I/O function, character testing, a couple of string functions and calloc (no malloc). The only standard include file was stdio.h because, with implicit int and without prototypes, what's point in declaring "strlen();"? So when that changed a few years latter there was the fun of finding out whether to include "strings.h" or "string.h"; "malloc.h", "memory.h" or "stdlib.h". This was the legacy that spawned autoconf and all that malarkey. As you say, much of it is redundant now, but if it still works (and I find dozens of configure scripts work correctly to this day) there is little incentive to revise the code and get rid of them. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-08-19 14:42 +0000 |
| Message-ID | <Hx4EM.686038$TPw2.217661@fx17.iad> |
| In reply to | #172516 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >bart c <bart4858@gmail.com> writes: > >> >> on those other programs is anathema. > >Well (if you are talking about having to say gcc prog.c rather than gcc >prog) there are advantages, and none of them have anything to do with >how much one has to type. After all, command completion means I rarely >type a file name explcitly anyway. > It's worth repeating that 'gcc' is a driver program, not a compiler. So: $ gcc -c -o a.o a.s is a perfectly legal and viable way to invoke the assembler. $ gcc -o a a.o is a perfectly legal and viable way to invoke the linker.
[toc] | [prev] | [next] | [standalone]
| From | bart c <bart4858@gmail.com> |
|---|---|
| Date | 2023-08-19 08:09 -0700 |
| Message-ID | <db175a13-352a-461b-88e4-d37e14d1a6e2n@googlegroups.com> |
| In reply to | #172535 |
On Saturday, 19 August 2023 at 15:43:02 UTC+1, Scott Lurndal wrote: > Ben Bacarisse <ben.u...@bsb.me.uk> writes: > >bart c <bart...@gmail.com> writes: > > > > >> > >> on those other programs is anathema. > > > >Well (if you are talking about having to say gcc prog.c rather than gcc > >prog) there are advantages, and none of them have anything to do with > >how much one has to type. After all, command completion means I rarely > >type a file name explcitly anyway. > > > It's worth repeating that 'gcc' is a driver program, not a compiler. > > So: > > $ gcc -c -o a.o a.s > > is a perfectly legal and viable way to invoke the assembler. > > $ gcc -o a a.o > > is a perfectly legal and viable way to invoke the linker. You can run the assembler directly using 'as', and the linker using 'ld'. So how do you directly invoke the actual C compiler?
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-19 15:59 +0000 |
| Message-ID | <20230819085418.391@kylheku.com> |
| In reply to | #172541 |
On 2023-08-19, bart c <bart4858@gmail.com> wrote: > On Saturday, 19 August 2023 at 15:43:02 UTC+1, Scott Lurndal wrote: >> Ben Bacarisse <ben.u...@bsb.me.uk> writes: >> >bart c <bart...@gmail.com> writes: >> > >> >> >> >> >> on those other programs is anathema. >> > >> >Well (if you are talking about having to say gcc prog.c rather than gcc >> >prog) there are advantages, and none of them have anything to do with >> >how much one has to type. After all, command completion means I rarely >> >type a file name explcitly anyway. >> > >> It's worth repeating that 'gcc' is a driver program, not a compiler. >> >> So: >> >> $ gcc -c -o a.o a.s >> >> is a perfectly legal and viable way to invoke the assembler. >> >> $ gcc -o a a.o >> >> is a perfectly legal and viable way to invoke the linker. > > You can run the assembler directly using 'as', and the linker using 'ld'. Not reliably. The gcc driver is configured to use a particular assembler, not necessarily the one found in you PATH under the name "as". You might have an "as" that came from your Unix vendor, but gcc was built with the GNU assembler. You could have different installations of gcc with different versions of an assembler. > So how do you directly invoke the actual C compiler? That's an executable usually called cc1. You have to know where that is. Even if gcc is in your PATH, cc1 won't be. -- 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 c <bart4858@gmail.com> |
|---|---|
| Date | 2023-08-19 09:38 -0700 |
| Message-ID | <45028397-a7aa-4243-afa3-2751a6d5ef8en@googlegroups.com> |
| In reply to | #172543 |
On Saturday, 19 August 2023 at 16:59:16 UTC+1, Kaz Kylheku wrote:
> On 2023-08-19, bart c <bart...@gmail.com> wrote:
> > On Saturday, 19 August 2023 at 15:43:02 UTC+1, Scott Lurndal wrote:
> >> Ben Bacarisse <ben.u...@bsb.me.uk> writes:
> >> >bart c <bart...@gmail.com> writes:
> >> >
> >>
> >> >>
> >> >> on those other programs is anathema.
> >> >
> >> >Well (if you are talking about having to say gcc prog.c rather than gcc
> >> >prog) there are advantages, and none of them have anything to do with
> >> >how much one has to type. After all, command completion means I rarely
> >> >type a file name explcitly anyway.
> >> >
> >> It's worth repeating that 'gcc' is a driver program, not a compiler.
> >>
> >> So:
> >>
> >> $ gcc -c -o a.o a.s
> >>
> >> is a perfectly legal and viable way to invoke the assembler.
> >>
> >> $ gcc -o a a.o
> >>
> >> is a perfectly legal and viable way to invoke the linker.
> >
> > You can run the assembler directly using 'as', and the linker using 'ld'.
> Not reliably. The gcc driver is configured to use a particular
> assembler, not necessarily the one found in you PATH under the
> name "as".
>
> You might have an "as" that came from your Unix vendor, but gcc
> was built with the GNU assembler.
>
> You could have different installations of gcc with different
> versions of an assembler.
> > So how do you directly invoke the actual C compiler?
> That's an executable usually called cc1. You have to know where
> that is. Even if gcc is in your PATH, cc1 won't be.
I found cc1, but how do you use it? There's no conventional CLI. You can do:
cc1 <hello.c
but it needs a bunch of options. 'cci --help' produces a list of 1700 options, which is as helpful as saying that this week's winning lottery numbers are in the set 1 to 49.
I get the feeling it is not meant to be used from the command line like 'as' and 'ld'.
So, there /is/ no proper C-specific compiler with a normal interface; we're stuck with that driver.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-19 18:16 +0000 |
| Message-ID | <20230819110026.903@kylheku.com> |
| In reply to | #172547 |
On 2023-08-19, bart c <bart4858@gmail.com> wrote:
> On Saturday, 19 August 2023 at 16:59:16 UTC+1, Kaz Kylheku wrote:
>> On 2023-08-19, bart c <bart...@gmail.com> wrote:
>> > On Saturday, 19 August 2023 at 15:43:02 UTC+1, Scott Lurndal wrote:
>> >> Ben Bacarisse <ben.u...@bsb.me.uk> writes:
>> >> >bart c <bart...@gmail.com> writes:
>> >> >
>> >>
>> >> >>
>> >> >> on those other programs is anathema.
>> >> >
>> >> >Well (if you are talking about having to say gcc prog.c rather than gcc
>> >> >prog) there are advantages, and none of them have anything to do with
>> >> >how much one has to type. After all, command completion means I rarely
>> >> >type a file name explcitly anyway.
>> >> >
>> >> It's worth repeating that 'gcc' is a driver program, not a compiler.
>> >>
>> >> So:
>> >>
>> >> $ gcc -c -o a.o a.s
>> >>
>> >> is a perfectly legal and viable way to invoke the assembler.
>> >>
>> >> $ gcc -o a a.o
>> >>
>> >> is a perfectly legal and viable way to invoke the linker.
>> >
>> > You can run the assembler directly using 'as', and the linker using 'ld'.
>> Not reliably. The gcc driver is configured to use a particular
>> assembler, not necessarily the one found in you PATH under the
>> name "as".
>>
>> You might have an "as" that came from your Unix vendor, but gcc
>> was built with the GNU assembler.
>>
>> You could have different installations of gcc with different
>> versions of an assembler.
>> > So how do you directly invoke the actual C compiler?
>> That's an executable usually called cc1. You have to know where
>> that is. Even if gcc is in your PATH, cc1 won't be.
>
> I found cc1, but how do you use it? There's no conventional CLI. You can do:
>
> cc1 <hello.c
I don't think it's documented for use.
If you want to see what arguments are being passed to cc1, you can
use the "strace" utility on Linux or similar syscall tracers elsewhere.
> I get the feeling it is not meant to be used from the command line like 'as' and 'ld'.
>
> So, there /is/ no proper C-specific compiler with a normal interface; we're stuck with that driver.
That's correct.
Let's try:
$ strace -s 4096 -o gcc.log -f gcc foo.c -o foo
$ grep cc1 gcc.log
25364 stat64("/usr/lib/gcc/i686-linux-gnu/7/cc1", {st_mode=S_IFREG|0755, st_size=22895720, ...}) = 0
25364 access("/usr/lib/gcc/i686-linux-gnu/7/cc1", X_OK) = 0
25365 execve("/usr/lib/gcc/i686-linux-gnu/7/cc1", ["/usr/lib/gcc/i686-linux-gnu/7/cc1", "-quiet", "-imultiarch", "i386-linux-gnu", "foo.c", "-quiet", "-dumpbase", "foo.c", "-mtune=generic", "-march=i686", "-auxbase", "foo", "-fstack-protector-strong", "-Wformat", "-Wformat-security", "-o", "/tmp/ccKrG8uQ.s"], 0x8cad030 /* 62 vars */ <unfinished ...>
Looks like cc1 isn't being given a huge number of many options.
cc1 must be doing the preprocessing since it's getting foo.c as
input. I don't see any arguments which would tell it where the header
files are, so it must be getting that configuration in some
other ways. (I looked into the environment with strace -v too;
didn't see it.)
There is also another intermediary program called "collect2" which I
think handles the details of linking. In the above trace, there is an
invocation of collect2 after cc1.
--
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 | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-08-19 21:02 +0000 |
| Message-ID | <B5aEM.562365$SuUf.252005@fx14.iad> |
| In reply to | #172549 |
Kaz Kylheku <864-117-4973@kylheku.com> writes:
>On 2023-08-19, bart c <bart4858@gmail.com> wrote:
>> On Saturday, 19 August 2023 at 16:59:16 UTC+1, Kaz Kylheku wrote:
>>> On 2023-08-19, bart c <bart...@gmail.com> wrote:
>>> > On Saturday, 19 August 2023 at 15:43:02 UTC+1, Scott Lurndal wrote:
>>> >> Ben Bacarisse <ben.u...@bsb.me.uk> writes:
>>> >> >bart c <bart...@gmail.com> writes:
>>> >> >
>>> >>
>>> >> >>
>>> >> >> on those other programs is anathema.
>>> >> >
>>> >> >Well (if you are talking about having to say gcc prog.c rather than gcc
>>> >> >prog) there are advantages, and none of them have anything to do with
>>> >> >how much one has to type. After all, command completion means I rarely
>>> >> >type a file name explcitly anyway.
>>> >> >
>>> >> It's worth repeating that 'gcc' is a driver program, not a compiler.
>>> >>
>>> >> So:
>>> >>
>>> >> $ gcc -c -o a.o a.s
>>> >>
>>> >> is a perfectly legal and viable way to invoke the assembler.
>>> >>
>>> >> $ gcc -o a a.o
>>> >>
>>> >> is a perfectly legal and viable way to invoke the linker.
>>> >
>>> > You can run the assembler directly using 'as', and the linker using 'ld'.
>>> Not reliably. The gcc driver is configured to use a particular
>>> assembler, not necessarily the one found in you PATH under the
>>> name "as".
>>>
>>> You might have an "as" that came from your Unix vendor, but gcc
>>> was built with the GNU assembler.
>>>
>>> You could have different installations of gcc with different
>>> versions of an assembler.
>>> > So how do you directly invoke the actual C compiler?
>>> That's an executable usually called cc1. You have to know where
>>> that is. Even if gcc is in your PATH, cc1 won't be.
>>
>> I found cc1, but how do you use it? There's no conventional CLI. You can do:
>>
>> cc1 <hello.c
>
>I don't think it's documented for use.
>
>If you want to see what arguments are being passed to cc1, you can
>use the "strace" utility on Linux or similar syscall tracers elsewhere.
>
>> I get the feeling it is not meant to be used from the command line like 'as' and 'ld'.
>>
>> So, there /is/ no proper C-specific compiler with a normal interface; we're stuck with that driver.
>
>That's correct.
>
>Let's try:
>
>$ strace -s 4096 -o gcc.log -f gcc foo.c -o foo
>$ grep cc1 gcc.log
>25364 stat64("/usr/lib/gcc/i686-linux-gnu/7/cc1", {st_mode=S_IFREG|0755, st_size=22895720, ...}) = 0
>25364 access("/usr/lib/gcc/i686-linux-gnu/7/cc1", X_OK) = 0
>25365 execve("/usr/lib/gcc/i686-linux-gnu/7/cc1", ["/usr/lib/gcc/i686-linux-gnu/7/cc1", "-quiet", "-imultiarch", "i386-linux-gnu", "foo.c", "-quiet", "-dumpbase", "foo.c", "-mtune=generic", "-march=i686", "-auxbase", "foo", "-fstack-protector-strong", "-Wformat", "-Wformat-security", "-o", "/tmp/ccKrG8uQ.s"], 0x8cad030 /* 62 vars */ <unfinished ...>
>
>Looks like cc1 isn't being given a huge number of many options.
>
>cc1 must be doing the preprocessing since it's getting foo.c as
>input. I don't see any arguments which would tell it where the header
>files are, so it must be getting that configuration in some
>other ways. (I looked into the environment with strace -v too;
>didn't see it.)
>
>There is also another intermediary program called "collect2" which I
>think handles the details of linking. In the above trace, there is an
>invocation of collect2 after cc1.
IIRC collect is the optimization pass.
[toc] | [prev] | [next] | [standalone]
Page 10 of 16 — ← Prev page 1 … 8 9 [10] 11 12 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web