Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #381174 > unrolled thread
| Started by | bart <bc@freeuk.com> |
|---|---|
| First post | 2024-01-29 16:03 +0000 |
| Last post | 2024-02-12 02:18 +0000 |
| Articles | 20 on this page of 415 — 26 participants |
Back to article view | Back to comp.lang.c
Experimental C Build System bart <bc@freeuk.com> - 2024-01-29 16:03 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-30 00:57 +0000
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-29 17:38 -0800
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-01-30 09:06 +0100
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-30 15:23 -0800
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-01-31 08:36 +0100
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-31 19:12 -0800
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-01-31 00:44 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-01-30 01:45 +0000
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-30 04:46 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-01-30 11:52 +0000
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-30 16:50 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-01-30 17:57 +0000
Re: Experimental C Build System Richard Harnden <richard.nospam@gmail.invalid> - 2024-01-30 19:22 +0000
Re: Experimental C Build System vallor <vallor@cultnix.org> - 2024-01-31 16:41 +0000
Re: Experimental C Build System vallor <vallor@cultnix.org> - 2024-01-31 19:01 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-01-31 20:25 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-01 09:39 +0100
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-01 11:31 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-01 16:11 +0100
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-01 17:33 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-01 18:34 +0000
Re: Experimental C Build System Michael S <already5chosen@yahoo.com> - 2024-02-01 22:23 +0200
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 20:55 +0000
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-01 13:10 -0800
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-01 22:38 +0100
Re: Experimental C Build System Michael S <already5chosen@yahoo.com> - 2024-02-02 00:55 +0200
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-01 23:31 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-02 02:08 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-02 09:02 +0100
Re: Experimental C Build System Michael S <already5chosen@yahoo.com> - 2024-02-02 15:28 +0200
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-02 15:49 +0100
Re: Experimental C Build System Michael S <already5chosen@yahoo.com> - 2024-02-02 16:53 +0200
Stu Feldman (Was: Experimental C Build System) gazelle@shell.xmission.com (Kenny McCormack) - 2024-02-02 16:29 +0000
Re: Stu Feldman (Was: Experimental C Build System) Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-02 17:29 +0000
Re: Stu Feldman (Was: Experimental C Build System) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-04 05:44 +0100
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-02 13:47 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-02 15:57 +0100
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-02 15:18 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-02 17:44 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-02 18:26 +0000
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-03 05:45 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-03 21:24 +0000
Re: Experimental C Build System Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-03 13:19 +0100
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-02 21:42 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-02 22:12 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-03 01:29 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-03 12:02 +0000
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-03 12:25 -0800
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-04 06:47 +0000
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-04 19:52 -0800
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-04 19:58 -0800
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-03 05:52 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-03 14:52 +0100
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-03 14:59 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-04 06:51 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-04 11:08 +0000
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-03 15:44 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-03 16:03 +0000
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-03 17:02 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-04 13:29 +0100
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-03 12:31 -0800
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-03 22:11 +0000
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-03 16:24 -0800
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-04 01:19 +0000
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-03 17:51 -0800
Re: Experimental C Build System "Gary R. Schmidt" <grschmidt@acm.org> - 2024-02-04 14:07 +1100
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-04 20:01 -0800
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-04 04:56 +0000
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-03 21:36 -0800
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-03 21:41 -0800
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-04 13:44 +0100
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-04 15:50 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-04 18:27 +0100
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-04 14:52 -0800
Re: Experimental C Build System Kees Nuyt <k.nuyt@nospam.demon.nl> - 2024-02-05 17:57 +0100
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-05 09:17 -0800
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-05 19:11 +0000
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-03 12:29 -0800
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-04 06:43 +0000
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-04 14:51 -0800
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-03 21:15 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-03 21:39 +0000
Re: Experimental C Build System Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-03 14:23 +0100
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-03 13:48 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-03 14:16 +0000
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-03 18:17 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-03 20:12 +0000
Re: Experimental C Build System Jim Jackson <jj@franjam.org.uk> - 2024-02-04 16:13 +0000
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-04 14:08 -0800
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-04 18:22 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-04 13:53 +0100
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-04 14:01 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-04 18:36 +0100
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-04 22:46 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-04 23:29 +0000
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-04 15:32 -0800
Re: Experimental C Build System Jim Jackson <jj@franjam.org.uk> - 2024-02-05 17:37 +0000
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-05 18:03 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-05 18:42 +0000
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-05 13:25 -0800
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-05 21:31 +0000
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-05 13:40 -0800
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-05 22:29 +0000
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-05 14:39 -0800
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-05 22:47 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-06 00:03 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-05 19:16 +0000
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-05 00:07 +0000
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-04 16:10 -0800
Re: Experimental C Build System candycanearter07 <no@thanks.net> - 2024-02-05 10:41 -0600
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-05 18:13 +0000
Re: Experimental C Build System candycanearter07 <no@thanks.net> - 2024-02-06 23:41 -0600
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-07 09:56 +0000
Re: Experimental C Build System Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-07 11:10 +0000
Re: Experimental C Build System Dan Purgert <dan@djph.net> - 2024-02-07 11:13 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-07 20:50 +0000
Re: Experimental C Build System Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-08 11:05 +0000
Re: Experimental C Build System "Gary R. Schmidt" <grschmidt@acm.org> - 2024-02-07 23:46 +1100
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-07 15:09 +0100
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-07 14:21 +0000
Re: Experimental C Build System candycanearter07 <no@thanks.net> - 2024-02-07 10:11 -0600
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-07 20:46 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-07 21:53 +0100
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-07 14:54 +0000
Re: Experimental C Build System Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-07 16:15 +0000
Re: Experimental C Build System Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-07 17:34 +0000
Re: Experimental C Build System [Ben] olcott <polcott2@gmail.com> - 2024-02-07 22:50 -0600
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-08 09:40 +0000
Re: Experimental C Build System Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-08 11:55 +0000
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-08 12:32 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-08 16:35 +0100
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-08 16:31 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-08 21:24 +0100
Re: Experimental C Build System Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-08 16:50 +0000
Re: Experimental C Build System Dan Purgert <dan@djph.net> - 2024-02-08 17:04 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-08 17:10 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-08 17:25 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-08 23:30 +0000
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-08 17:38 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-08 21:30 +0100
Re: Experimental C Build System Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-09 00:58 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-09 01:14 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-09 01:18 +0000
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-09 01:27 +0000
Re: Experimental C Build System Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-09 01:30 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-09 10:32 +0000
Re: Experimental C Build System Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-09 13:16 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-09 02:07 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-09 15:49 +0000
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-09 17:13 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-09 18:24 +0000
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-09 10:34 -0800
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-09 18:42 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-09 20:41 +0000
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-09 21:56 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-09 22:43 +0000
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-09 23:12 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-09 23:47 +0000
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-10 00:28 +0000
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-09 15:41 -0800
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-09 23:53 +0000
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-10 00:16 +0000
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-09 16:33 -0800
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-10 02:26 +0000
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-10 02:47 +0000
Re: Experimental C Build System Michael S <already5chosen@yahoo.com> - 2024-02-10 20:17 +0200
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-10 21:02 +0000
Re: Experimental C Build System Michael S <already5chosen@yahoo.com> - 2024-02-10 20:09 +0200
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-09 22:43 +0000
Re: Experimental C Build System Michael S <already5chosen@yahoo.com> - 2024-02-10 19:51 +0200
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-09 18:25 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-09 20:55 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-09 21:06 +0000
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-09 13:15 -0800
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-09 22:09 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-10 15:24 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-09 21:04 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-09 09:21 +0100
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-08 17:15 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-08 23:29 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-07 15:31 +0000
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-07 19:24 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-07 20:44 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-07 15:30 +0000
Re: Experimental C Build System candycanearter07 <no@thanks.net> - 2024-02-07 10:12 -0600
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-07 08:40 -0800
Re: Experimental C Build System candycanearter07 <no@thanks.net> - 2024-02-07 12:24 -0600
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-05 01:45 +0000
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-04 20:17 -0800
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-04 20:41 -0800
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-04 20:46 -0800
Re: Experimental C Build System Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-05 06:48 -0800
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-05 11:20 -0800
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-05 13:33 -0800
Re: Experimental C Build System gazelle@shell.xmission.com (Kenny McCormack) - 2024-02-05 21:57 +0000
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-05 23:20 +0000
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-05 15:41 -0800
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-06 01:48 +0000
Re: Experimental C Build System gazelle@shell.xmission.com (Kenny McCormack) - 2024-02-06 00:18 +0000
Re: Experimental C Build System gazelle@shell.xmission.com (Kenny McCormack) - 2024-02-05 06:00 +0000
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-04 22:46 -0800
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-05 15:57 -0800
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-05 13:02 +0100
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-05 14:50 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-05 22:51 +0000
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-05 23:18 +0000
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-06 00:16 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-06 14:32 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-06 14:40 +0000
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-06 16:59 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-06 19:20 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-06 20:32 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-06 20:34 +0000
Re: Experimental C Build System Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-02-06 20:49 +0000
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-06 13:07 -0800
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-06 21:39 +0000
Re: Experimental C Build System Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-02-07 15:02 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-07 20:36 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-07 20:48 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-07 21:15 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-07 23:15 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-07 23:58 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-08 01:33 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-08 01:34 +0000
Re: Experimental C Build System vallor <vallor@cultnix.org> - 2024-02-08 01:50 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-08 02:17 +0000
Re: Experimental C Build System Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-07 22:48 +0100
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-07 23:44 +0000
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-06 21:09 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-06 21:43 +0000
Re: Experimental C Build System Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-08 17:23 -0800
Re: Experimental C Build System Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-07 00:51 +0100
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-07 02:18 +0000
Re: Experimental C Build System Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-07 04:21 +0100
Re: Experimental C Build System Richard Harnden <richard.nospam@gmail.invalid> - 2024-02-07 07:17 +0000
Re: Experimental C Build System Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-07 12:59 +0100
Re: Experimental C Build System "Gary R. Schmidt" <grschmidt@acm.org> - 2024-02-07 23:53 +1100
Re: Experimental C Build System Michael S <already5chosen@yahoo.com> - 2024-02-07 15:45 +0200
Re: Experimental C Build System "Gary R. Schmidt" <grschmidt@acm.org> - 2024-02-08 12:56 +1100
Re: Experimental C Build System Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-08 17:22 -0800
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-06 00:07 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-06 10:08 +0100
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-09 11:44 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-09 21:03 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-01 22:34 +0100
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-01 22:29 +0000
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-01 15:28 -0800
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-02 01:03 +0000
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-01 17:42 -0800
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-02 02:43 +0000
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-01 19:03 -0800
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-02 10:54 +0100
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-02 21:16 +0000
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-02 16:09 -0800
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-03 01:32 +0000
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-03 02:36 +0000
Re: Experimental C Build System Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-03 00:53 -0800
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-03 13:51 -0800
Re: Experimental C Build System Richard Damon <richard@damon-family.org> - 2024-02-03 17:56 -0500
Re: Experimental C Build System Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-04 07:52 -0800
Re: Experimental C Build System Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-04 06:18 -0800
Re: Experimental C Build System tTh <tth@none.invalid> - 2024-02-02 03:22 +0100
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-02 11:13 +0000
Re: Experimental C Build System "Gary R. Schmidt" <grschmidt@acm.org> - 2024-02-03 00:25 +1100
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-02 13:29 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-02 10:47 +0100
Re: Experimental C Build System Michael S <already5chosen@yahoo.com> - 2024-02-02 15:45 +0200
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-02 16:26 +0100
Re: Experimental C Build System Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-03 14:39 +0100
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-03 16:26 +0100
Re: Experimental C Build System Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-03 17:11 +0100
Re: Experimental C Build System Michael S <already5chosen@yahoo.com> - 2024-02-06 13:59 +0200
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-06 13:14 +0100
Re: Experimental C Build System Michael S <already5chosen@yahoo.com> - 2024-02-06 14:32 +0200
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-06 14:16 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-06 17:02 +0100
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-06 20:31 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-02 14:14 +0000
Re: Experimental C Build System Michael S <already5chosen@yahoo.com> - 2024-02-02 16:43 +0200
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-02 15:18 +0000
Re: Experimental C Build System tTh <tth@none.invalid> - 2024-02-02 20:43 +0100
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-02 20:16 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-02 16:31 +0100
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-02 17:00 +0000
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-02 17:31 +0000
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-02 10:36 -0800
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-02 19:52 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-02 20:21 +0000
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-02 21:09 +0000
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-02 13:15 -0800
Re: Experimental C Build System Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-03 15:13 +0100
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-02 21:23 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-02 21:51 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-03 01:31 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-03 12:16 +0000
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-03 17:59 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-03 19:35 +0000
Re: Experimental C Build System tTh <tth@none.invalid> - 2024-02-03 21:57 +0100
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-04 18:48 +0100
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-04 20:18 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-04 20:55 +0000
Re: Experimental C Build System vallor <vallor@cultnix.org> - 2024-02-07 02:57 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-07 03:18 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-07 15:27 +0000
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-07 15:48 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-07 16:30 +0000
Re: Experimental C Build System vallor <vallor@cultnix.org> - 2024-02-08 00:39 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-07 21:59 +0100
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-07 09:42 +0100
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-07 10:40 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-07 15:37 +0100
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-04 22:51 +0100
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-04 23:11 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-05 13:42 +0100
Re: Experimental C Build System Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-05 14:59 +0100
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-05 15:45 +0000
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-05 11:25 -0800
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-05 22:46 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-05 14:43 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-04 22:42 +0000
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-04 14:53 -0800
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-04 14:02 -0800
Re: Experimental C Build System candycanearter07 <no@thanks.net> - 2024-02-05 10:48 -0600
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-05 17:29 +0000
Re: Experimental C Build System candycanearter07 <no@thanks.net> - 2024-02-05 11:36 -0600
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-03 14:04 -0800
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-02 18:54 +0000
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-03 06:04 +0000
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-02 22:13 -0800
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-03 06:43 +0000
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-03 00:02 -0800
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-03 08:47 +0000
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-03 06:30 +0000
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-03 11:17 +0000
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-03 14:02 -0800
[meta] Re: Experimental C Build System Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-03 15:04 +0100
Re: [meta] Re: Experimental C Build System Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-03 07:19 -0800
Re: [meta] Re: Experimental C Build System Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-04 05:29 +0100
Re: [meta] Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-04 05:37 +0000
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-02 16:26 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-01 23:30 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-02 11:05 +0100
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-02 21:18 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-04 15:50 +0000
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-02 00:26 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-02 00:35 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-02 11:13 +0100
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-02 10:54 +0000
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-02 14:15 +0000
Re: Experimental C Build System Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-02 01:46 +0100
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-01 16:20 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-01 21:34 +0000
Re: Experimental C Build System Richard Harnden <richard.nospam@gmail.invalid> - 2024-02-01 16:09 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-01 17:32 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 19:25 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-01 19:51 +0000
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-01 12:12 -0800
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-01 12:43 -0800
Re: Experimental C Build System Michael S <already5chosen@yahoo.com> - 2024-02-01 22:36 +0200
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-01 23:09 +0100
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-01 23:32 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-31 21:17 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-01 09:48 +0100
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-01 11:49 -0800
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-01 21:39 +0000
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-01 15:24 -0800
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-01 23:38 +0000
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-01 23:53 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-01 23:14 +0100
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-01-30 09:17 +0100
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-01-30 12:09 +0000
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-30 15:25 -0800
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-30 17:50 -0800
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-31 03:14 +0000
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-31 20:38 -0800
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-05 13:46 +0000
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-05 14:06 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-05 14:48 +0000
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-05 15:23 +0000
Re: Experimental C Build System Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-30 16:46 -0800
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-31 03:13 +0000
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-31 03:23 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-01-31 08:47 +0100
Re: Experimental C Build System Spiros Bousbouras <spibou@gmail.com> - 2024-01-31 11:02 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-01-31 15:31 +0100
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 15:13 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-31 23:00 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 00:29 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-01 03:07 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 15:00 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-01 23:40 +0000
system(3) (was: Re: Experimental C Build System) vallor <vallor@cultnix.org> - 2024-02-01 08:15 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-31 23:02 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 00:33 +0000
Re: Experimental C Build System Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-01 15:11 +0100
Re: Experimental C Build System Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-01 14:55 +0100
Re: Experimental C Build System Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-01 14:42 +0100
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-01-31 12:19 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-01 14:29 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-01 16:43 +0100
Re: Experimental C Build System Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-03 01:05 -0800
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-03 11:54 +0000
Re: Experimental C Build System Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-03 07:17 -0800
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-03 15:54 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-03 16:05 +0000
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-03 12:39 -0800
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-03 22:19 +0000
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-04 20:56 -0800
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-04 20:57 -0800
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-01-31 20:36 +0000
Re: Experimental C Build System thiago <thiago.adams@gmail.com> - 2024-02-07 20:36 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-08 13:50 +0000
Re: Experimental C Build System thiago <thiago.adams@gmail.com> - 2024-02-07 20:42 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-12 02:18 +0000
Page 15 of 21 — ← Prev page 1 … 13 14 [15] 16 17 … 21 Next page →
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-02-02 15:18 +0000 |
| Message-ID | <upj14r$2lb9l$1@dont-email.me> |
| In reply to | #381604 |
On 02/02/2024 14:43, Michael S wrote: > On Fri, 2 Feb 2024 14:14:31 +0000 > bart <bc@freeuk.com> wrote: >> You've just described a tremendously complex way to do whole-program >> analysis. >> > > But it proves that your statement above (it can't be a whole-program > compiler if it can compile modules independently) is false. Then /every/ compiler can be regarded as a whole-program one, since the end result, even if the modules were randomly compiled over the last month, will always be a whole program. So it comes down to what is meant by a whole-program compiler. My definition is where you build one program (eg. one EXE or DLL file on Windows) with ONE invocaton of the compiler, which processes ALL source and support files from scratch. The output (from my compiler) is a single file, usually an EXE or DLL, that may use external shared libraries. Or, rarely, it may generate a single OBJ file for more exotic requirements, but it will need external tools. Then it may end up as a component of a larger program. Or sometimes the output is fixed up in memory and run immediately. That describes the compiler I use for my systems language. My C compiler is not a whole-program one. Although you can submit all modules and it can produce one EXE/DLL file, so that the behaviour can appear similar, internally they are compiled independently. I have thought about using real whole-program techniques (so that all modules share a global symbol table for example, and common headers are processed only once), but I don't use C enough to make that interesting to attempt. >> There are easier ways. The C transpiler I use takes a project of >> dozens of modules in my language, and produces a single C source file >> which will form one EXE or one DLL file. >> >> Now any ordinary optimising C compiler has a view of the entire >> program and can do wider optimisations (but that view does not span >> multiple EXE/DLL files.) >> > > If the program in question is really big then there is a good chance > that your method will expose internal limits of the back-end compiler. My personal whole-program projects impose some limitations. One is the scale of the application being compiled. However they are designed for use with a fast compiler. That puts an upper limit of about 0.5M lines per project, if you want to keep build time below, say, 1 second. (Figures pertain to my slowish PC, running an unoptimised compiler, so are conservative. An optimised compiler might be 40% faster.) 0.5M lines of code means about a 5MB executable, which is a pretty hefty project. The vast majority of executables and libraries on my PC are smaller than that. Another is that whole-program compilation is harder to parallelise (the above figures are for a single core). But you can of course compile multiple programs at the same time. The killer is that most professional compilers are hugely complex: they are big, and they take considerable machine resources. These are ones like gcc or any using LLVM. So to get around that in order to do whole-program stuff, things get very, very complicated. I can't help that. But I can't remember how we got here. The thread subject is the far-simpler-to-realise topic of discovering the modules for a non-whole-program C compiler, which seems to give the big boys a lot more trouble!
[toc] | [prev] | [next] | [standalone]
| From | tTh <tth@none.invalid> |
|---|---|
| Date | 2024-02-02 20:43 +0100 |
| Message-ID | <upjgm0$rh7$1@news.gegeweb.eu> |
| In reply to | #381610 |
On 2/2/24 16:18, bart wrote:
>
> My definition is where you build one program (eg. one EXE or DLL file on
> Windows) with ONE invocaton of the compiler, which processes ALL source
> and support files from scratch.
>
And can you disclose the magic trick who let your magic
compiler know exactly the list of "ALL source and support
files" needed for a scratchy build ?
--
+---------------------------------------------------------------------+
| https://tube.interhacker.space/a/tth/video-channels |
+---------------------------------------------------------------------+
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-02-02 20:16 +0000 |
| Message-ID | <upjiir$2odvr$1@dont-email.me> |
| In reply to | #381628 |
On 02/02/2024 19:43, tTh wrote:
> On 2/2/24 16:18, bart wrote:
>>
>> My definition is where you build one program (eg. one EXE or DLL file
>> on Windows) with ONE invocaton of the compiler, which processes ALL
>> source and support files from scratch.
>>
> And can you disclose the magic trick who let your magic
> compiler know exactly the list of "ALL source and support
> files" needed for a scratchy build ?
If talking about the language used by my whole-program compiler, the
info comes from the module scheme. And /that/ involves simply listing
the modules the project comprises, in one place.
Other languages with module schemes tend to have ragged collections of
'import' statements at the top of every module.
Below is the lead module of my C compiler (cc.m) which is not C code,
but in my language. This module only contains project info. This allows
a choice of module for different configurations, but I sometimes just
comment lines in and out.
No other project info, import statements etc appear anywhere else.
5 modules are not shown in that list, which belong to the language's
standard library. Those are included automatically.
-------------------------------
cc.m
-------------------------------
!CLI
module cc_cli
!Global Data and Tables
module cc_decls
module cc_tables
!Lexing and Parsing
module cc_lex
module cc_parse
!General
module cc_lib
module cc_support
!PCL handling
module cc_blockPCL
module cc_genPCL
module cc_libPCL
module cc_pcl
!MCL handling
module cc_mcldecls
module cc_genmcl
module cc_libmcl
module cc_optim
module cc_stackmcl
!Bundled headers
module cc_headers
! module cc_headersx
module cc_export
!Diagnostics
module cc_show
! module cc_showdummy
!x64 and exe backend
! module mc_genss
! module mc_objdecls
! module mc_writeexe
! module mc_writess
! module mc_disasm
-------------------------------
! lines are comments. PCL is the IL. MCL is native code. The mc_ files
provide direct EXE generation, rather than ASM (as normally built it
invokes my external assembly 'as'. I'm joking, it is called 'aa'.). But
I haven't bothered with that backend.
This is in in action:
c:\cx>mm cc Build the above app
Compiling cc.m---------- to cc.exe
c:\cx>cc sql Test cc on sql.c
Compiling sql.c to sql.exe
c:\cx>sql See if it works
SQLite version 3.25.3 2018-11-05 20:37:38
...
Building the compiler with 'mm cc' takes 80ms; that's why I have no need
of dependency graphs or incremental compilation.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-02 16:31 +0100 |
| Message-ID | <upj1t2$2ldkd$2@dont-email.me> |
| In reply to | #381602 |
On 02/02/2024 15:14, bart wrote: > Yes, I do. I'm like that kid poking fun at the emperor's new clothes; > I'm just stating what I see. But in one way it is hilarious seeing you > lot defend programs like 'as' to the death. > No, /you/ are the emperor in this analogy. Well, you are actually the kid - except you are the kid with no clothes who /thinks/ he's an emperor. > Why not just admit that it is a POS that you've had to learn to live > with, instead of trying to make out it is somehow superior? > The whole world is out of step, except Bart. Has it never occurred to you that when you are in disagreement with everyone, /you/ might be the one that is wrong? I think you suffer from the "misunderstood genius" myth. It's surprisingly common amongst people who have invested heavily in going their own way, against common knowledge or common practice. It's a sort of psychological defence mechanism against realising you've been wrong all this time.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-02-02 17:00 +0000 |
| Message-ID | <upj72s$2md0u$1@dont-email.me> |
| In reply to | #381613 |
On 02/02/2024 15:31, David Brown wrote: > On 02/02/2024 15:14, bart wrote: > >> Yes, I do. I'm like that kid poking fun at the emperor's new clothes; >> I'm just stating what I see. But in one way it is hilarious seeing you >> lot defend programs like 'as' to the death. >> > > No, /you/ are the emperor in this analogy. Well, you are actually the > kid - except you are the kid with no clothes who /thinks/ he's an emperor. > >> Why not just admit that it is a POS that you've had to learn to live >> with, instead of trying to make out it is somehow superior? >> > > The whole world is out of step, except Bart. Has it ever occurred to YOU that the world is more than Unix and make and massive compilers like gcc and clang? > Has it never occurred to you that when you are in disagreement with > everyone, /you/ might be the one that is wrong? I think you suffer from > the "misunderstood genius" myth. It's surprisingly common amongst > people who have invested heavily in going their own way, against common > knowledge or common practice. It's a sort of psychological defence > mechanism against realising you've been wrong all this time. This is a newsgroup about C. That is a language that can be fairly adequately implemented with a 180KB program, the size of Tiny C. Tiny C itself can turn C source into binary at about 10MB per second. So, a toy language, really, and a toy implementation that nevertheless does the job: in most cases, a user of the resulting program will not be able to tell how it was compiled. And yet there is this massive collection of of huge, complex tools built around a toy language, dwarfing it by 1000:1, that you insist is what it's really all about, and you want to put down anyone who disagrees. It's like saying that the only businesses worth having are huge corporations, or the only form of transport must be a jetliner. The way 'as' works IS rubbish. It is fascinating how you keep trying to turn it round and make it about me. There can't possibly be anything wrong with it, whoever says so must be deluded!
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-02-02 17:31 +0000 |
| Message-ID | <20240202092942.722@kylheku.com> |
| In reply to | #381621 |
On 2024-02-02, bart <bc@freeuk.com> wrote: > Has it ever occurred to YOU that the world is more than Unix and make > and massive compilers like gcc and clang? There is more, but from your perspective, it's just more stuff to shake your fist at and avoid learning about. -- 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 | 2024-02-02 10:36 -0800 |
| Message-ID | <87ttmqogrk.fsf@nosuchdomain.example.com> |
| In reply to | #381621 |
bart <bc@freeuk.com> writes:
[...]
> The way 'as' works IS rubbish. It is fascinating how you keep trying
> to turn it round and make it about me. There can't possibly be
> anything wrong with it, whoever says so must be deluded!
"as" works. It's not perfect, but it's good enough. Its job is to
translate assembly code to object code. It does that. There's is
nothing you could do with your preferred user interface (whatever that
might be) that can't be done with the existing one. "as" is rarely
invoked directly, so any slight clumsiness in its well defined user
interface hardly matters. Any changes to its interface could break
existing scripts.
Nobody is claiming that "there can't possibly be anything wrong with
it". You made that up.
Why does the way "as" works offend you?
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-02-02 19:52 +0000 |
| Message-ID | <upjh6e$2o5vo$1@dont-email.me> |
| In reply to | #381626 |
On 02/02/2024 18:36, Keith Thompson wrote:
> bart <bc@freeuk.com> writes:
> [...]
>> The way 'as' works IS rubbish. It is fascinating how you keep trying
>> to turn it round and make it about me. There can't possibly be
>> anything wrong with it, whoever says so must be deluded!
>
> "as" works. It's not perfect, but it's good enough. Its job is to
> translate assembly code to object code. It does that. There's is
> nothing you could do with your preferred user interface (whatever that
> might be) that can't be done with the existing one. "as" is rarely
> invoked directly, so any slight clumsiness in its well defined user
> interface hardly matters. Any changes to its interface could break
> existing scripts.
That always seems to be the excuse. Some half-finished test version is
produced, with no proper file interface, and an output that temporarily
gets sent to a.out until it can be sorted out properly.
But it never is finished, and the same raw half-finished product works
the same way decades later, surprising every new generation who have to
relearn its quirks.
I saw an example today in tutorial:
as -o filename.o filename.as
having to type the name twice again.
> Nobody is claiming that "there can't possibly be anything wrong with
> it". You made that up.
>
> Why does the way "as" works offend you?
It just does. I've used a few assemblers, this one is downright weird:
* The output is odd: it ALWAYS goes to a.out. Hmm, that's the executable
file produced by gcc, so is it performing linking? No, this a.out
is an object file; gcc's a.out is an executable! (And if you and link
a.out with gcc, it will go wrong unless you use -o)
* You have to specify the output file name and extension, so writing
the input file twice
* If you start it with no params, instead of a usage message, it sits
silently waiting for you to type assembly code live at the terminal
* It accepts multiple input files. OK, presumably it will write each to
a corresponding .o file? No it writes all the code to one output.
* So, it is combining multiple, distinct assembler files to one single
object? That's actually quite neat. Except no, the input files are
effectively just concatenated into one big ASM file. Any symbol L3
in one, will clash with an L3 in another.
* All these behaviours are quite different to that of gcc. Pass
a.s, a.s, a.s to gcc, and will produce a.o, b.o, c.o. 'as' will
concatenate and produce one object file called a.out.
This is apparently the flagship assembler provided with Unix systems.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-02-02 20:21 +0000 |
| Message-ID | <y9cvN.322280$c3Ea.233788@fx10.iad> |
| In reply to | #381629 |
bart <bc@freeuk.com> writes: >On 02/02/2024 18:36, Keith Thompson wrote: >> bart <bc@freeuk.com> writes: >I saw an example today in tutorial: > > as -o filename.o filename.as > >having to type the name twice again. As has been pointed out numerous times, you don't need to type both names twice. All I have to type to build my entire project is 'mr'. I very seldom every need to use 'cc' or 'as' directly except for one-off examples to post here.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-02-02 21:09 +0000 |
| Message-ID | <20240202130117.231@kylheku.com> |
| In reply to | #381629 |
On 2024-02-02, bart <bc@freeuk.com> wrote: > That always seems to be the excuse. Some half-finished test version is > produced, with no proper file interface, and an output that temporarily > gets sent to a.out until it can be sorted out properly. Historically, GCC had to work with proprietary "as" programs; it couldn't redefine the API. > But it never is finished, and the same raw half-finished product works > the same way decades later, surprising every new generation who have to > relearn its quirks. Most people using GCC do not learn anything about as. Even those programming in assembler, because the gcc driver recognizes .s and .S suffixes. But we've been through this? > I saw an example today in tutorial: > > as -o filename.o filename.as > > having to type the name twice again. You want: gcc -c filename.S The .S file is preprocessed for you so you can use #define macros and #include, and handed off to an assembler, somehow resulting in filename.o. There are lots of tutorials out there written by people who are "writing to learn". > It just does. I've used a few assemblers, this one is downright weird: I've used lots of electric stove elements and room heaters! But this ceramic resistor is weird. It has no on/off switch or temperature control, and just bare wires?! No plug. Sure, if I pass current through it, it warms up, so I guess what these electrical engineers call "working" in their little world. "as" is not an application designed for programming; it's an internal toolchain component. Why can't you understand that? -- 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 | 2024-02-02 13:15 -0800 |
| Message-ID | <87plxeo9ed.fsf@nosuchdomain.example.com> |
| In reply to | #381629 |
bart <bc@freeuk.com> writes:
> On 02/02/2024 18:36, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
[...]
> That always seems to be the excuse. Some half-finished test version is
> produced, with no proper file interface, and an output that
> temporarily gets sent to a.out until it can be sorted out properly.
It's not an "excuse", it's an explanation.
But OK, let me drop everything and fix it for you. I can submit a patch
for "as" so it behaves the way you want. I'll also submit patches for
gcc so it invokes "as" with the new interface. It will still have to
handle the old interface at least temporarily, so there will have to be
a way to ask "as" which interface it uses. Nothing will ever generate a
file named "a.out" unless it's explicitly told to do so. I'll also send
the word out so everyone knows not to rely on the name "a.out" anymore.
And I'll convince everyone that they've been doing it wrong for the last
several decades.
I'll let you know when that's done. Because nothing short of that would
satisfy you.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-02-03 15:13 +0100 |
| Message-ID | <uplhlq$35d9r$1@dont-email.me> |
| In reply to | #381633 |
On 02.02.2024 22:15, Keith Thompson wrote: > bart <bc@freeuk.com> writes: >> [...] > [...] > > But OK, let me drop everything and fix it for you. I can submit a patch > for "as" so it behaves the way you want. I'll also submit patches for > gcc so it invokes "as" with the new interface. It will still have to > handle the old interface at least temporarily, so there will have to be > a way to ask "as" which interface it uses. Nothing will ever generate a > file named "a.out" unless it's explicitly told to do so. I'll also send > the word out so everyone knows not to rely on the name "a.out" anymore. > And I'll convince everyone that they've been doing it wrong for the last > several decades. > > I'll let you know when that's done. Because nothing short of that would > satisfy you. He would still find something that is different from his tool so that he anyway won't accept it. Janis
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-02-02 21:23 +0000 |
| Message-ID | <upjmhf$2oup9$5@dont-email.me> |
| In reply to | #381629 |
On Fri, 2 Feb 2024 19:52:45 +0000, bart wrote:
> as -o filename.o filename.as
On *nix systems, we can use “cc” as kind of a “universal” compile command,
not just for C code but for assembler as well, e.g.
cc -c filename.o filename.s
(without preprocessor)
cc -c filename.o filename.S
(with preprocessor)
cc -o filename filename.S
(with preprocessor and linking stages as well).
Can your system offer these options?
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-02-02 21:51 +0000 |
| Message-ID | <upjo5f$2pc52$1@dont-email.me> |
| In reply to | #381636 |
On 02/02/2024 21:23, Lawrence D'Oliveiro wrote:
> On Fri, 2 Feb 2024 19:52:45 +0000, bart wrote:
>
>> as -o filename.o filename.as
>
> On *nix systems, we can use “cc” as kind of a “universal” compile command,
> not just for C code but for assembler as well, e.g.
>
> cc -c filename.o filename.s
>
> (without preprocessor)
>
> cc -c filename.o filename.S
>
> (with preprocessor)
>
> cc -o filename filename.S
>
> (with preprocessor and linking stages as well).
>
> Can your system offer these options?
What option is that, to have one command 'cc' that can deal with N
different languages?
No. But I can offer a system where you have a choice of N different
compilers or assemblers for the same language:
lc64 filename.c
tcc filename.c
gcc filename.c -ofilename.exe
mcc filename
nasm -fwin64 filename.asm
yasm -fwin64 filename.asm
aa filename -obj
as filename.s -ofilename.o
How do you choose different compilers or assemblers with 'cc'?
I also offer a scheme with my tools where the tool magically knows what
language it is dealing with:
mm filename (filename.m => filename.exe)
mcc filename (filename.c => filename.exe)
aa filename (filename.asm => filename.exe)
qq filename (run filename.q)
pci filename (run filename.pcl)
ms filename (run filename.m)
.m and .q files are lead modules of an application.
.c files are standalone modules
One .asm file normally represents a whole program unless generated from mcc
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-02-03 01:31 +0000 |
| Message-ID | <upk516$2r6q8$2@dont-email.me> |
| In reply to | #381639 |
On Fri, 2 Feb 2024 21:51:43 +0000, bart wrote: > What option is that, to have one command 'cc' that can deal with N > different languages? Hint: it uses the filename extension to determine which language, and which flavour of the language even, it is dealing with. > No. But I can offer a system where you have a choice of N different > compilers or assemblers for the same language: Are their ABIs compatible?
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-02-03 12:16 +0000 |
| Message-ID | <uplaqh$3494t$1@dont-email.me> |
| In reply to | #381646 |
On 03/02/2024 01:31, Lawrence D'Oliveiro wrote:
> On Fri, 2 Feb 2024 21:51:43 +0000, bart wrote:
>
>> What option is that, to have one command 'cc' that can deal with N
>> different languages?
>
> Hint: it uses the filename extension to determine which language, and
> which flavour of the language even, it is dealing with.
This is the filename extension which Linux famously ignores, because you
can use any extension you like?
Hint: my tools KNOW which language they are dealing with:
c:\c>copy hello.c hello.x
c:\c>mcc hello.x
Compiling hello.x to hello.exe
c:\c>copy hello.c hello.s
c:\c>mcc hello.s
Compiling hello.s to hello.exe
Now let's see what the famous gcc does:
root@XXX:/mnt/c/c# cp hello.c hello.x
root@XXX:/mnt/c/c# gcc hello.x
hello.x: file not recognized: file format not recognized
root@XXX:/mnt/c/c# cp hello.c hello.s
root@XXX:/mnt/c/c# gcc hello.s
hello.s: Assembler messages:
hello.s:2: Error: unknown vector operation: `{'
...
>> No. But I can offer a system where you have a choice of N different
>> compilers or assemblers for the same language:
>
> Are their ABIs compatible?
Huh? They will all use the platform ABI.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-02-03 17:59 +0000 |
| Message-ID | <20240203082517.687@kylheku.com> |
| In reply to | #381669 |
On 2024-02-03, bart <bc@freeuk.com> wrote: > On 03/02/2024 01:31, Lawrence D'Oliveiro wrote: >> On Fri, 2 Feb 2024 21:51:43 +0000, bart wrote: >> >>> What option is that, to have one command 'cc' that can deal with N >>> different languages? >> >> Hint: it uses the filename extension to determine which language, and >> which flavour of the language even, it is dealing with. > > This is the filename extension which Linux famously ignores, because you > can use any extension you like? > > Hint: my tools KNOW which language they are dealing with: You're arguing for a user-unfriendly system where you have to memorize a separate command for processing each language. Recognizing files by suffix is obviously superior. > root@XXX:/mnt/c/c# cp hello.c hello.x > root@XXX:/mnt/c/c# gcc hello.x > hello.x: file not recognized: file format not recognized This is good; it's one more little piece of resistance against people using the wrong suffix. It's not the only one. Editors won't bring up the correct syntax formatting and coloring if the file suffix is wrong. Tools for cross-referencing identifiers in source code may also get things wrong due to the wrong suffix, or ignore the file entirely. Your argument of "I can rename my C to any suffix and my compiler still recognizes it" is completely childish. -- 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 | 2024-02-03 19:35 +0000 |
| Message-ID | <upm4i9$38qq7$1@dont-email.me> |
| In reply to | #381690 |
On 03/02/2024 17:59, Kaz Kylheku wrote: > On 2024-02-03, bart <bc@freeuk.com> wrote: >> On 03/02/2024 01:31, Lawrence D'Oliveiro wrote: >>> On Fri, 2 Feb 2024 21:51:43 +0000, bart wrote: >>> >>>> What option is that, to have one command 'cc' that can deal with N >>>> different languages? >>> >>> Hint: it uses the filename extension to determine which language, and >>> which flavour of the language even, it is dealing with. >> >> This is the filename extension which Linux famously ignores, because you >> can use any extension you like? >> >> Hint: my tools KNOW which language they are dealing with: > > You're arguing for a user-unfriendly system where you have to memorize > a separate command for processing each language. You have to impart that information to the tool in any case. It can either be by file extension, or the name of the command. So, 'cc' is some tool that looks at a file extension and selects a suitable program based on that extension; well done. But what is the point? Do you routinely invoke cc with multiple files of mixed languages? Suppose you wanted a different C compiler on each .c file? Oh, you then invoke it separately for each file. So you do that anyway in that rare event. > Recognizing files by suffix is obviously superior. > >> root@XXX:/mnt/c/c# cp hello.c hello.x >> root@XXX:/mnt/c/c# gcc hello.x >> hello.x: file not recognized: file format not recognized > > This is good; it's one more little piece of resistance > against people using the wrong suffix. > It's not the only one. Editors won't bring up the correct syntax > formatting and coloring if the file suffix is wrong. > > Tools for cross-referencing identifiers in source code may also get > things wrong due to the wrong suffix, or ignore the file entirely. This completely contradicts what people have been saying about Linux where file extensions are optional and only serve as a convenience. For example, executables can have no extension, or .exe, or even .c. It is Windows that places more store by file extensions, which Linux people say is a bad thing. But above you say that is the advantage of Linux. > Your argument of "I can rename my C to any suffix and my compiler > still recognizes it" is completely childish. It only seems to be childish when one of my programs handles this better than one of yours! There is only thing my mcc program can't do, which is to compile a C file named 'filename.'; that is, 'filename' followed by an actual '.', not 'filename' with no extension. And that's only when I run it under Linux. That's because under Linux, 'filename' and 'filename.' are distinct files; the "." is part of the file name, not a notional separator. So here's a summary of what I've recently learnt about Linux in the form of an FAQ: Q Why do Linux executables usually not have extensions? A Because if they had an extension like .exe or .elf, you'd have to invoke them as prog.exe or ./prog.elf, which would rapidly get tedious Q Why do filenames specified in shell command lines tend to not have default extensions? A Because 'abc.' and 'abc' are distinct files, it can't tell whether 'abc' means a 'abc.x' (the default extension) or 'abc'. You can't use 'abc.' to indicate no extension, because that is an actual file name Q Why do a lot of programs on Linux that default to stdin and stdout for i/o, never display helpful prompts or messages? A Because that output would screw up any data output that is sent to stdout. So they are silent. (Imagine if Bash displayed no prompt!)
[toc] | [prev] | [next] | [standalone]
| From | tTh <tth@none.invalid> |
|---|---|
| Date | 2024-02-03 21:57 +0100 |
| Message-ID | <upm9bb$2n2m$1@news.gegeweb.eu> |
| In reply to | #381696 |
On 2/3/24 20:35, bart wrote:
> But what is the point? Do you routinely invoke cc with multiple files of
> mixed languages? Suppose you wanted a different C compiler on each .c
> file? Oh, you then invoke it separately for each file. So you do that
> anyway in that rare event.
And this is better done with a short Maakefile.
--
+---------------------------------------------------------------------+
| https://tube.interhacker.space/a/tth/video-channels |
+---------------------------------------------------------------------+
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-04 18:48 +0100 |
| Message-ID | <upoiks$3o7ig$4@dont-email.me> |
| In reply to | #381696 |
On 03/02/2024 20:35, bart wrote: > On 03/02/2024 17:59, Kaz Kylheku wrote: >> On 2024-02-03, bart <bc@freeuk.com> wrote: >>> On 03/02/2024 01:31, Lawrence D'Oliveiro wrote: >>>> On Fri, 2 Feb 2024 21:51:43 +0000, bart wrote: >>>> >>>>> What option is that, to have one command 'cc' that can deal with N >>>>> different languages? >>>> >>>> Hint: it uses the filename extension to determine which language, and >>>> which flavour of the language even, it is dealing with. >>> >>> This is the filename extension which Linux famously ignores, because you >>> can use any extension you like? >>> >>> Hint: my tools KNOW which language they are dealing with: >> >> You're arguing for a user-unfriendly system where you have to memorize >> a separate command for processing each language. > > You have to impart that information to the tool in any case. It can > either be by file extension, or the name of the command. > > So, 'cc' is some tool that looks at a file extension and selects a > suitable program based on that extension; well done. > "cc" is not a tool in itself - it's just a standard name for the system's C compiler. It might be a pure C compiler. On most Linux systems, it is a symbolic link to a version of gcc. And the "gcc" binary is a front-end, and will handle C, C++, assembly, linking, and - if you have installed the compilers - FORTRAN, Ada, and possibly other languages. > But what is the point? Do you routinely invoke cc with multiple files of > mixed languages? I certainly invoke it with C, C++ and the occasional assembly file. (Though I do so explicitly as gcc rather than cc.) > Suppose you wanted a different C compiler on each .c > file? Oh, you then invoke it separately for each file. So you do that > anyway in that rare event. Yes. > > > >> Recognizing files by suffix is obviously superior. >> >>> root@XXX:/mnt/c/c# cp hello.c hello.x >>> root@XXX:/mnt/c/c# gcc hello.x >>> hello.x: file not recognized: file format not recognized >> >> This is good; it's one more little piece of resistance >> against people using the wrong suffix. > >> It's not the only one. Editors won't bring up the correct syntax >> formatting and coloring if the file suffix is wrong. Usually the suffix is used for the initial language type selection, and you can override it if you want. >> >> Tools for cross-referencing identifiers in source code may also get >> things wrong due to the wrong suffix, or ignore the file entirely. > > This completely contradicts what people have been saying about Linux > where file extensions are optional and only serve as a convenience. > No, it fits it perfectly. File extensions are a convenience. You can override them if you want. > For example, executables can have no extension, or .exe, or even .c. Yes. It is common, for example, to have ".py" as the extension for Python source files - /and/ for executable Python files. But sometimes it is also convenient to have no extension for executable Python files intended to be used as convenient command-line programs. > > It is Windows that places more store by file extensions, which Linux > people say is a bad thing. > Windows is too dependent on them, and too trusting. > But above you say that is the advantage of Linux. Yes, it's a hands-down win for Linux (and other *nix) in this aspect. > >> Your argument of "I can rename my C to any suffix and my compiler >> still recognizes it" is completely childish. > > It only seems to be childish when one of my programs handles this better > than one of yours! But it /doesn't/ handle it better. It does worse. gcc acts the way users expect, based on sensible choices of file extensions. Yours can't cope with any other kind of file and instead acts contrary to user expectation. > > There is only thing my mcc program can't do, which is to compile a C > file named 'filename.'; that is, 'filename' followed by an actual '.', > not 'filename' with no extension. > > And that's only when I run it under Linux. That's because under Linux, > 'filename' and 'filename.' are distinct files; the "." is part of the > file name, not a notional separator. > Of course it is. It's simple and consistent. In Windows, it is sometimes part of a file name (when it is not the last period in the name), sometimes a magical character that appears or disappears (when the file ends in a period), and sometimes it delimits a file extension.
[toc] | [prev] | [next] | [standalone]
Page 15 of 21 — ← Prev page 1 … 13 14 [15] 16 17 … 21 Next page →
Back to top | Article view | comp.lang.c
csiph-web