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 13 of 21 — ← Prev page 1 … 11 12 [13] 14 15 … 21 Next page →
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-02-08 17:22 -0800 |
| Message-ID | <8634u277o8.fsf@linuxsc.com> |
| In reply to | #381920 |
scott@slp53.sl.home (Scott Lurndal) writes: > Kaz Kylheku <433-929-6894@kylheku.com> writes: > >> On 2024-02-05, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote: >> [...] >> The Glibc shared library loading mechanism doesn't implement the nice >> strategy of finding libraries in the same directory as the executable. > > Sure it does, if you tell it to. viz. LD_LIBRARY_PATH. I would appreciate if folks posting stuff that pertains almost exclusively to comp.unix.programmer would take comp.lang.c off of those postings. Thank you.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-02-06 00:07 +0000 |
| Message-ID | <20240205160331.829@kylheku.com> |
| In reply to | #381863 |
On 2024-02-05, Lawrence D'Oliveiro <ldo@nz.invalid> wrote: > On Mon, 5 Feb 2024 13:02:52 +0100, David Brown wrote: > >> It /is/ a consumer platform, yes. And because it has no standard ways >> to build software, and no one (approximately) using it wants to build >> software on it, the norm is to distribute code in binary form for >> Windows. That works out fine for almost all Windows users. That >> includes libraries - even C programmers on Windows don't want to build >> "libjpeg" or whatever, they want a DLL. > > But without integrated package management, how do you keep it all up to > date? If two separate apps use the same library, do they each end up with > their own version, or do they share one version? Does each app have to run > its own periodic background updater task to tell you there’s a new version > available? Windows has solved this problem. Executables find .DLL libraries in their own directory. You ship a program with the exact libraries it needs which you tested with and those are the ones it will use. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-06 10:08 +0100 |
| Message-ID | <upssug$qb8m$4@dont-email.me> |
| In reply to | #381879 |
On 06/02/2024 01:07, Kaz Kylheku wrote: > On 2024-02-05, Lawrence D'Oliveiro <ldo@nz.invalid> wrote: >> On Mon, 5 Feb 2024 13:02:52 +0100, David Brown wrote: >> >>> It /is/ a consumer platform, yes. And because it has no standard ways >>> to build software, and no one (approximately) using it wants to build >>> software on it, the norm is to distribute code in binary form for >>> Windows. That works out fine for almost all Windows users. That >>> includes libraries - even C programmers on Windows don't want to build >>> "libjpeg" or whatever, they want a DLL. >> >> But without integrated package management, how do you keep it all up to >> date? If two separate apps use the same library, do they each end up with >> their own version, or do they share one version? Does each app have to run >> its own periodic background updater task to tell you there’s a new version >> available? > > Windows has solved this problem. Executables find .DLL libraries in > their own directory. > > You ship a program with the exact libraries it needs which you > tested with and those are the ones it will use. > The two methods - a repository for common libraries, and individual copies of the libraries for each program - have their advantages and disadvantages. If you have copies of the libraries for each program, that is inefficient - bigger downloads and installs (which don't bother me, but do bother some people), and extra copies in ram when running (which can sometimes slow things down). The main problem, however, is that when a serious bug is fixed, you need to wait for every individual program that uses the library to be updated and provide a new release, then you have to download them all anew. If you have a common place for common libraries, updates of that library are easy and only need to be done once when there is a fix. But now the programs that are using it are not tested with the same version that you have on your system, and there can be trouble if the API details change. And you have the "DLL hell" possibility, though careful version numbering and symbol links reduces that risk significantly. There is no single "best" solution here.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-02-09 11:44 +0000 |
| Message-ID | <uq536e$2jpss$1@dont-email.me> |
| In reply to | #381806 |
On 05/02/2024 12:02, David Brown wrote: > On 05/02/2024 01:07, Malcolm McLean wrote: >> On 04/02/2024 22:46, Lawrence D'Oliveiro wrote: >>> On Sun, 4 Feb 2024 14:01:08 +0000, bart wrote: >>> >>>> But it does seem as though Unix was a breeding ground for multitudinous >>>> developer tools. Plus there was little demarcation between user >>>> commands, C development tools, C libraries and OS. >>>> >>>> Somebody who's used to that environment is surely going to have trouble >>>> on an OS like MSDOS or Windows where they have to start from nothing. >>>> Even if most of the tools are now free. >>> >>> Yet it seems like even someone like you, who is supposed to be “used to” >>> Windows rather than *nix, still has the same trouble. So maybe it’s not >>> about being “used to” *nix at all, there really is something inherent in >>> the fundamental design of that environment that makes development work >>> easier. >> On Windows you can't assume that the end user will be interested in >> development or have any develoment tools available. Or that he'll be >> able to do anything other than the most basic installation. It's a >> consumer platform. > > It /is/ a consumer platform, yes. And because it has no standard ways > to build software, and no one (approximately) using it wants to build > software on it, the norm is to distribute code in binary form for > Windows. That works out fine for almost all Windows users. That > includes libraries - even C programmers on Windows don't want to build > "libjpeg" or whatever, they want a DLL. 20+ years ago I depended on an Intel JPEG library called IJL15.DLL, a 32-bit binary of 370KB. Then they decided to withdraw it; you couldn't find binaries anywhere, although I had copies. Its replacement was buried inside a massive 75MB developer's package (at a time when modems worked at 14.4Kbaud), and I think had to be built from source. I remember that it was totally impractical and highly inconvenient. And later on I needed a 64-bit version, which is when I started looking at libraries like LibJPEG. As it turned out, these libraries were over-the-top anyway. (The 64-bit JPEG-load libraries I use now are about 20KB, and JPEG-save about 15KB) > And thus there is much less effort put into making projects easy to > build on Windows. People on Windows fall mostly into two categories - > those that neither know nor care about building software and want > ready-to-use binaries (that's almost all of them), and people who do > development work and are willing and able to invest time and effort > reading the readmes and install.txt files, looking at the structure of > the code, running the makefiles or CMakes, importing the project into > their favourite IDE, and whatever else. I literally ran my fingers through my hair and groaned aloud just reading about makefiles and CMake. > It's not that Linux software developers go out of their way to annoy > Windows developers (well, /some/ do, but not many). But on Linux, and > widening to other modern *nix systems, there are standard ways to build > software. You know the people building it will have make, and gcc (or a > compatible compiler with many of the same extensions and flags, like > clang or icc), and development versions of countless libraries either > installed or a quick apt-get away. On Windows, however, they might have > MSVC, or cygwin, or mingw64, or TDM gcc, or lccwin, or tcc, or Borland > C++ builder. They might have a "make", but it could be MS's more > limited "nmake" version. Windows works on binaries. There is a format called 'DLL' that will work on any Windows OS and for any language that has a suitable FFI. At worst there will be 32-bit and 64-bit versions, but these days you only need one. Even if a developer wanted to make it available as C source code only, then that is easy: just write in it portable C code. Here, nano.c is such a library (to decode jpeg) with an accompanying test function in main(): c:\cx>mcc nano.c Compiling nano.c to nano.exe c:\cx>wsl ... root@XXX:/mnt/c/cx# gcc nano.c And it runs on both: root@XXX:/mnt/c/cx# ./a.out /mnt/c/jpeg/card2.jpg root@DESKTOP-11:/mnt/c/cx# ls *.ppm nanojpeg_out.ppm ... c:\cx>nano \jpeg\card2.jpg c:\cx>dir *.ppm 09/02/2024 11:31 6,220,817 nanojpeg_out.ppm So, what's the problem? This just needs ANY C compiler, and doesn't need make or anything else: c:\cx>tcc nano.c c:\cx>mcc nano.c Compiling nano.c to nano.exe c:\cx>gcc nano.c c:\cx>\dm\bin\dmc nano.c Why is everyone so intent on making this harder than necessary? Forget CYGWIN, MSYS2, WSL, mingw64, or make. Either supply one DLL (that will work on every 64-bit Windows machine in the world), or supply portable C code.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-02-09 21:03 +0000 |
| Message-ID | <uq63u4$2psod$2@dont-email.me> |
| In reply to | #382180 |
On Fri, 9 Feb 2024 11:44:13 +0000, bart wrote: > Then [Intel] decided to withdraw it; you couldn't find binaries > anywhere, although I had copies. Its replacement was buried inside a > massive 75MB developer's package (at a time when modems worked at > 14.4Kbaud), and I think had to be built from source. > > I remember that it was totally impractical and highly inconvenient. Why not extract it into its own source project and just build that? >> And thus there is much less effort put into making projects easy to >> build on Windows. Ironic that your example is from Intel, from all people. If they cannot support Windows properly, who can? > Windows works on binaries. There is a format called 'DLL' that will work > on any Windows OS and for any language that has a suitable FFI. But DLLs have no versioning mechanism, do they? Hence, “DLL Hell”.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-01 22:34 +0100 |
| Message-ID | <uph2pd$2867k$1@dont-email.me> |
| In reply to | #381501 |
On 01/02/2024 19:34, bart wrote:
> On 01/02/2024 15:11, David Brown wrote:
>
>>>> 1. It lets you split the program into separate parts - generally
>>>> separate files. This is essential for scalability for large programs.
>>>>
>>>> 2. You can compile modules independently to allow partial builds.
>>>>
>>>> 3. Modules generally have some way to specify exported symbols and
>>>> facilities that can be used by other modules.
>>>>
>>>> 4. Modules can "import" other modules, gaining access to those
>>>> modules' exported symbols.
>>>>
>>>> 5. Modules provide encapsulation of data, code and namespaces.
>>>>
>>>> 6. Modules can be used in a hierarchical system, building big
>>>> modules from smaller ones to support larger libraries with many files.
>>>>
>>>> 7. Modules provide a higher level concept that can be used by
>>>> language tools to see how the whole program fits together or
>>>> interact with package managers and librarian tools.
>>>>
>>>>
>>>> C provides 1, 2, 3, and 4 if you use a "file.c/file.h" organisation.
>>>> It provides a limited form of 5 (everything that is not exported is
>>>> "static"), but scaling to larger systems is dependent on identifier
>>>> prefixes.
>>>>
>>>> You seem to be thinking purely about item 7 above. This is, I
>>>> think, common in interpreted languages (where modules have to be
>>>> found at run-time, where the user is there but the developer is not).
>>> I've been implementing languages with language-supported modules for
>>> about 12 years.
>>>
>>> They generally provide 1, 2, 4, 5, and 7 from your list, and partial
>>> support of 6.
>>
>> Sure. Programming languages need that if they are to scale at all.
>>
>>>
>>> They don't provide 2 (compiling individual modules) because the aim
>>> is a very fast, whole-program compler.
>>
>> Okay.
>>
>>
>> But what you are talking about to add to C is item 7, nothing more.
>> That is not adding "modules" to C. Your suggestion might be useful to
>> some people for some projects, but that doesn't make it "modules" in
>> any real sense.
>
> Item 7 is my biggest stumbling to building open source C projects.
>
> While the developer (say you), knows the necessary info, and can somehow
> import into the build system, my job is trying to get it out.
>
> I can't use the intended build system because for one reason or another
> it doesn't work, or requires complex dependencies (MSYS, CMake, MSTOOLS,
> .configure), or I want to run mcc on it.
>
> That info could trivially be added to the C source code. Nobody actually
> needs to use my #pragma scheme; it could simply be a block comment on
> one of the modules.
>
> I'm sure with all your complicated tools, they could surely dump some
> text that looks like:
>
> // List of source files to build the binary cipher.c:
> // cipher.c
> // hmac.c
> // sha2.c
>
> and prepend it to one of the files. Even a README will do.
>
> That wouldn't hurt would it?
Complain to the people that made that open source software, not me. But
don't be surprised if they tell you "There's a makefile. It works for
everyone else." Or maybe they will say they can't cater for every
little problem with everyone's unusual computer setup. Maybe they will
try to be helpful, maybe they will be rude and arrogant. Maybe they
will point out that their makefile /is/ just a list of the files needed,
along with the compiler options. Usually projects of any size /do/ have
readme's and build instructions - but some won't.
No matter what, it is not the fault of anyone here, it is not the fault
of "make" or Linux or C, and there is nothing that any of us can do to
help you. (And $DEITY knows, we have tried.)
>>
>> I already have tools for determining dependencies. What can your
>> methods do that mine can't?
>>
>> (And don't bother saying that you can do it without extra tools -
>> everyone who wants "make" and "gcc" has them on hand. And those who
>> want an IDE that figures out dependencies for them have a dozen free
>> options there too. These are all standard tools available to everyone.)
>
> So, if C were to acquire modules, so that a C compiler could determine
> that all for it itself (maybe even work out for itself which need
> recompiling), would you just ignore that feature and use the same
> auxiliary methods you have always done?
That's not unlikely. Why would I change? You still haven't given any
reasons why your tools would be /better/. Even if they could do all I
needed to do for a particular project, "just as good" is not "better",
and does not encourage change.
I would still need "make" for everything else. I would, however, be
quite happy if there were some standard way to get the list of include
files needed by a C file, rather than using gcc-specific flags.
>
> You don't see that the language taking over task (1) of the things that
> makefiles do, and possibly (2) (of the list I posted; repeated below),
> can streamline makefiles to make them shorter, simpler, easier to write
> and to read, and with fewer opportunities to get stuff wrong?
>
> That was a rhetorical question. Obviously not.
I've nothing against shorter or simpler makefiles. But as far as I can
see, you are just moving the same information from a makefile into the C
files.
Indeed, you are duplicating things - now your C files have to have
"#pragma module this, #pragma module that" in addition to having
"#include this.h, #include that.h". With my makefiles, all the "this"
and "that" is found automatically - writing the includes in the C code
is sufficient.
>
>
>> Perhaps I would find your tools worked for a "Hello, world" project.
>> Maybe they were still okay as it got slightly bigger. Then I'd have
>> something that they could not handle, and I'd reach for make. What
>> would be the point of using "make" to automate - for example -
>> post-processing of a binary to add a CRC check, but using your tools
>> to handle the build? It's much easier just to use "make" for the
>> whole thing.
>
>
> Because building one binary is a process should be the job of a
> compiler, not some random external tool that knows nothing of the
> language or compiler.
No, it is the job of the linker. Compiling is the job of the compiler.
Controlling the build is the job of the build system. I don't see
monolithic applications as an advantage.
>
> Maybe you think makefiles should individually list all the 1000s of
> functions of a project too?
>
>> You are offering me a fish. I am offering to teach you to fish,
>> including where to go to catch different kinds of fish. This is
>> really a no-brainer choice.
>
> That analogy makes no sense.
>
> Let me try and explain what I do: I write whole-program compilers. That
> means that, each time you do a new build, it will reprocess each file
> from source. They use the language's module scheme to know which files
> to process.
Surely most sensibly organised projects could then be built with :
bcc *.c -o prog.exe
I mean, that's what I can do with gcc if I had something that doesn't
need other flags (which is utterly impractical for my work).
Or if I had lots of files, each with their own c file :
for f in *.c; do gcc $i -o ${f%.c}; done
>
> It works for me, and I'm sure could work for others if they didn't have
> makefiles forced down their throats and hardwired into their brains.
/Nobody/ has makefiles forced on them. People use "make" because it is
convenient, and it works. If something better comes along, and it is
better enough to overcome the familiarity momentum, people will use that.
I do a round of checking the state of the art of build tools on a
regular basis - perhaps every year or so. I look at what's popular and
what's new, to see if there's anything that would work for me and be a
step up from what I have. So far, I've not found anything that comes
very close to "make" for my needs. There's some tools that are pretty
good in many ways, but none that I can see as being a better choice for
me than "make". I am, however, considering CMake (which works at a
higher level, and outputs makefiles, ninja files or other project
files). It appears to have some disadvantages compared to my makefiles,
such as needed to be run as an extra step when files are added or
removed to a project or dependencies are changed, but that doesn't
happen too often, and it's integration with other tools and projects
might make it an overall win. I'll need some time to investigate and
study it.
So I will happily move from "make" when I find something better - enough
better to make it worth the effort. I'll happily move from gcc, or
Linux, if I find something enough better to make it worth changing. I
regularly look at alternatives and consider them - clang is the key
challenger to gcc for my purposes.
But I have no interest in changing to something vastly more limited and
which adds nothing at all.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-02-01 22:29 +0000 |
| Message-ID | <uph5vq$28mbj$1@dont-email.me> |
| In reply to | #381521 |
On 01/02/2024 21:34, David Brown wrote:
> On 01/02/2024 19:34, bart wrote:
>> You don't see that the language taking over task (1) of the things
>> that makefiles do, and possibly (2) (of the list I posted; repeated
>> below), can streamline makefiles to make them shorter, simpler, easier
>> to write and to read, and with fewer opportunities to get stuff wrong?
>>
>> That was a rhetorical question. Obviously not.
>
> I've nothing against shorter or simpler makefiles. But as far as I can
> see, you are just moving the same information from a makefile into the C
> files.
>
> Indeed, you are duplicating things - now your C files have to have
> "#pragma module this, #pragma module that" in addition to having
> "#include this.h, #include that.h". With my makefiles, all the "this"
> and "that" is found automatically - writing the includes in the C code
> is sufficient.
I don't think so. Seeing:
#include "file.h"
doesn't necessarily mean there is a matching "file.c". It might not
exist, or the header might be for some external library, or maybe it
does exist but in a different location.
Or maybe some code may use a file "fred.c", which needs to be submitted
to the compiler, but for which there is either no header used, or uses a
header file with a different name.
As I said, C's uses of .h and .c files are chaotic.
Did you have in mind using gcc's -MM option? For my 'cipher.c' demo,
that only gives a set of header names. Missing are hmac.c and sha2.c.
If I try it on lua.c, it gives me only 5 header files; the project
comprises 33 .c files and 27 .h files.
>>
>>
>>> Perhaps I would find your tools worked for a "Hello, world" project.
>>> Maybe they were still okay as it got slightly bigger. Then I'd have
>>> something that they could not handle, and I'd reach for make. What
>>> would be the point of using "make" to automate - for example -
>>> post-processing of a binary to add a CRC check, but using your tools
>>> to handle the build? It's much easier just to use "make" for the
>>> whole thing.
>>
>>
>> Because building one binary is a process should be the job of a
>> compiler, not some random external tool that knows nothing of the
>> language or compiler.
>
> No, it is the job of the linker.
There is where you're still stuck in the past.
I first got rid of a formal 'linker' about 40 years ago. I got rid of
the notion of combining independently compiled modules into an
executable a decade ago.
Linking would only come up for me if I wanted to statically combine the
outputs of several languages. Since I can't process object files, I need
to generate an object file (in my case, it represents ALL my modules),
and a traditional linker. That would be someone else's job.
> Compiling is the job of the compiler.
> Controlling the build is the job of the build system. I don't see
> monolithic applications as an advantage.
I do. You type:
cc prog
without knowing or caring whether the contains that one module, or there
are 99 more.
In any case, your linker will generate a monolithic binary whether you
like it or not.
But I suspect you don't understand what a 'whole-program compiler' does:
* It means that for each binary, all sources are recompiled at the same
time to create it
* It doesn't mean that an application can only comprise one binary
* It moves the compilation unit granularity from a module to a single
EXE or DLL file
* Interfaces (in the case of a lower level language), are moved inter-
module to inter-program. The boundaries are between one program or
library and another, not between modules.
A language which claims to have a module system, but still compiles a
module at a time, will probably still have discrete inter-module
interfaces, although they may be handled automatically.
>>
>> Maybe you think makefiles should individually list all the 1000s of
>> functions of a project too?
>>
>>> You are offering me a fish. I am offering to teach you to fish,
>>> including where to go to catch different kinds of fish. This is
>>> really a no-brainer choice.
>>
>> That analogy makes no sense.
>>
>> Let me try and explain what I do: I write whole-program compilers.
>> That means that, each time you do a new build, it will reprocess each
>> file from source. They use the language's module scheme to know which
>> files to process.
>
> Surely most sensibly organised projects could then be built with :
>
> bcc *.c -o prog.exe
>
> I mean, that's what I can do with gcc if I had something that doesn't
> need other flags (which is utterly impractical for my work).
Yes, that's one technique that can be used. But few projects are like
that one. One or two, you can try *.c and it will work.
Malcolm's resource compiler is like that, but it still benefits from a
file like this:
#pragma module "*.c"
#pragma module "freetype/*.c"
#pragma module "samplerate/*.c"
here called bbx.c. I can build it like this:
c:\bbx\src>mcc bbx
Compiling bbx.c to bbx.exe
> /Nobody/ has makefiles forced on them. People use "make" because it is
> convenient, and it works.
BUT IT DOESN'T. It fails a lot of the time on Windows, but they are too
complicated to figure out why. From a recent thread I made about trying
to build piet.c, it failed on extra programs that weren't needed (that
was on Linux; it didn't work at all on Windows).
This is a program which actually only needed:
cc piet.c
(Here cc *.c wouldn't work.) This mirrors pretty much what I see in most
C projects; needless complexity that muddies the waters and creates
failures.
ALL I WANT IS A LIST OF FILES. Why doesn't anybody get that? And why is
it so hard?
Apparently makefiles are superior because you don't even need to know
the name of the program (and will have to hunt for where it put the
executable because it won't tell you!).
> But I have no interest in changing to something vastly more limited and
> which adds nothing at all.
That's right; it adds nothing, but it takes a lot away! Like a lot of
failure points.
(Look at the Monty Hall problem, but instead of 3 doors, try it with
100, of which 98 will be opened. Then it will easy to make the right
decision because nearly all the wrong ones have been eliminated.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-02-01 15:28 -0800 |
| Message-ID | <87r0hvpxx8.fsf@nosuchdomain.example.com> |
| In reply to | #381532 |
bart <bc@freeuk.com> writes:
[...]
> As I said, C's uses of .h and .c files are chaotic.
C doesn't use .h and .c files. The C standard doesn't specify file
extensions, either for source files or for files included with #include.
It's fairly straightforward to implement something similar to "modules"
in C, using matching *.h and *.c files, include guards, and so forth,
but it requires a bit of discipline. It's a mechanism built on top of
the language, not a feature of the language itself (though of course the
language definition intentionally supports that usage).
Some projects might use .h and .c files in a chaotic manner. Most, in
my experience, do not.
--
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 | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-02-02 01:03 +0000 |
| Message-ID | <uphf0d$29ukk$2@dont-email.me> |
| In reply to | #381538 |
On Thu, 01 Feb 2024 15:28:03 -0800, Keith Thompson wrote: > The C standard doesn't specify file > extensions, either for source files or for files included with #include. It does for the standard library includes, though.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-02-01 17:42 -0800 |
| Message-ID | <87frybprp3.fsf@nosuchdomain.example.com> |
| In reply to | #381554 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Thu, 01 Feb 2024 15:28:03 -0800, Keith Thompson wrote:
>> The C standard doesn't specify file
>> extensions, either for source files or for files included with #include.
>
> It does for the standard library includes, though.
Strictly speaking, it doesn't specify that the standard library headers
are files. But yes, their names end in ".h", and that's certainly
because of the common convention to use ".h" as the extension for C
header files.
--
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 | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-02-02 02:43 +0000 |
| Message-ID | <uphkt7$2an8i$2@dont-email.me> |
| In reply to | #381559 |
On Thu, 01 Feb 2024 17:42:32 -0800, Keith Thompson wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> On Thu, 01 Feb 2024 15:28:03 -0800, Keith Thompson wrote:
>>
>>> The C standard doesn't specify file extensions, either for source
>>> files or for files included with #include.
>>
>> It does for the standard library includes, though.
>
> Strictly speaking, it doesn't specify that the standard library headers
> are files.
From the C99 spec, page 149:
6.10.2 Source file inclusion
Constraints
A #include directive shall identify a header or source file that
can be processed by the implementation.
...
3 A preprocessing directive of the form
# include "q-char-sequence" new-line
causes the replacement of that directive by the entire contents of
the source file identified by the specified sequence between the "
delimiters. The named source file is searched for in an
implementation-defined manner.
So you see, the spec very explicitly uses the term “file”.
<https://www.open-std.org/JTC1/SC22/WG14/www/docs/n869/>
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-02-01 19:03 -0800 |
| Message-ID | <87bk8zpnxx.fsf@nosuchdomain.example.com> |
| In reply to | #381568 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Thu, 01 Feb 2024 17:42:32 -0800, Keith Thompson wrote:
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>> On Thu, 01 Feb 2024 15:28:03 -0800, Keith Thompson wrote:
>>>> The C standard doesn't specify file extensions, either for source
>>>> files or for files included with #include.
>>>
>>> It does for the standard library includes, though.
>>
>> Strictly speaking, it doesn't specify that the standard library headers
>> are files.
>
> From the C99 spec, page 149:
>
> 6.10.2 Source file inclusion
> Constraints
> A #include directive shall identify a header or source file that
> can be processed by the implementation.
>
> ...
>
> 3 A preprocessing directive of the form
> # include "q-char-sequence" new-line
> causes the replacement of that directive by the entire contents of
> the source file identified by the specified sequence between the "
> delimiters. The named source file is searched for in an
> implementation-defined manner.
>
> So you see, the spec very explicitly uses the term “file”.
>
> <https://www.open-std.org/JTC1/SC22/WG14/www/docs/n869/>
Yes, but not in reference to the standard headers.
A #include directive with <> searches for a "header", which is not
stated to be a file. A #include directive with "" searches for a file
in an implementation-defined manner; if that search fails, it tries
again as if <> had been used.
References to standard headers (stdio.h et al) always use the <> syntax.
You can write `#include "stdio.h"` if you like, but it risks picking up
a file with the same name instead of the standard header (which *might*
be what you want).
BTW, the n1256.pdf draft is a close approximation to the C99 standard;
it consists of the published standard with the three Technical
Corrigenda merged into it. The n1570.pdf draft is the last publicly
release draft before C11 was published, and is close enough to C11 for
most purposes.
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-02 10:54 +0100 |
| Message-ID | <upie4d$2i275$2@dont-email.me> |
| In reply to | #381569 |
On 02/02/2024 04:03, Keith Thompson wrote: > Lawrence D'Oliveiro <ldo@nz.invalid> writes: >> On Thu, 01 Feb 2024 17:42:32 -0800, Keith Thompson wrote: >>> Lawrence D'Oliveiro <ldo@nz.invalid> writes: >>>> On Thu, 01 Feb 2024 15:28:03 -0800, Keith Thompson wrote: >>>>> The C standard doesn't specify file extensions, either for source >>>>> files or for files included with #include. >>>> >>>> It does for the standard library includes, though. >>> >>> Strictly speaking, it doesn't specify that the standard library headers >>> are files. >> >> From the C99 spec, page 149: >> >> 6.10.2 Source file inclusion >> Constraints >> A #include directive shall identify a header or source file that >> can be processed by the implementation. >> >> ... >> >> 3 A preprocessing directive of the form >> # include "q-char-sequence" new-line >> causes the replacement of that directive by the entire contents of >> the source file identified by the specified sequence between the " >> delimiters. The named source file is searched for in an >> implementation-defined manner. >> >> So you see, the spec very explicitly uses the term “file”. >> >> <https://www.open-std.org/JTC1/SC22/WG14/www/docs/n869/> > > Yes, but not in reference to the standard headers. > > A #include directive with <> searches for a "header", which is not > stated to be a file. A #include directive with "" searches for a file > in an implementation-defined manner; if that search fails, it tries > again as if <> had been used. > > References to standard headers (stdio.h et al) always use the <> syntax. > You can write `#include "stdio.h"` if you like, but it risks picking up > a file with the same name instead of the standard header (which *might* > be what you want). > > BTW, the n1256.pdf draft is a close approximation to the C99 standard; > it consists of the published standard with the three Technical > Corrigenda merged into it. The n1570.pdf draft is the last publicly > release draft before C11 was published, and is close enough to C11 for > most purposes. > In 7.1.2 "Standard headers", it says: """ Each library function is declared, with a type that includes a prototype, in a header, 188) whose contents are made available by the #include preprocessing directive. """ "Header" here is in italics, meaning it is a definition of the term. And footnote 188 has : """ header is not necessarily a source file, nor are the < and > delimited sequences in header names necessarily valid source file names. """ (I am quoting from n2346, the final C18 draft. The section numbering is generally consistent between standard versions, but footnote numbers change, in case anyone is looking this up.) I have personally used a toolchain where the standard library headers did not exist as files, but were internal to the compiler (and the implementations were internal to the linker). I think the toolchain company was a bit paranoid that others would copy their proprietary library.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-02-02 21:16 +0000 |
| Message-ID | <upjm2i$2oup9$3@dont-email.me> |
| In reply to | #381569 |
On Thu, 01 Feb 2024 19:03:38 -0800, Keith Thompson wrote: > A #include directive with <> searches for a "header", which is not > stated to be a file. A #include directive with "" searches for a file > in an implementation-defined manner; if that search fails, it tries > again as if <> had been used. The trouble with that interpretation is, it would seem to rule out the use of things like include libraries for user headers. Do you really think that was the intention?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-02-02 16:09 -0800 |
| Message-ID | <87h6iqo1cq.fsf@nosuchdomain.example.com> |
| In reply to | #381634 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Thu, 01 Feb 2024 19:03:38 -0800, Keith Thompson wrote:
>> A #include directive with <> searches for a "header", which is not
>> stated to be a file. A #include directive with "" searches for a file
>> in an implementation-defined manner; if that search fails, it tries
>> again as if <> had been used.
>
> The trouble with that interpretation is, it would seem to rule out the use
> of things like include libraries for user headers. Do you really think
> that was the intention?
I don't know. I imagine an implementation could interpret the word
"file" to include information extracted from libraries. Note that it
doesn't have to correspond to the concept of a "file" used in <stdio.h>;
that refers to files in the execution environment, not the compilation
environment.
--
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 | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-02-03 01:32 +0000 |
| Message-ID | <upk53c$2r6q8$3@dont-email.me> |
| In reply to | #381644 |
On Fri, 02 Feb 2024 16:09:09 -0800, Keith Thompson wrote: > Lawrence D'Oliveiro <ldo@nz.invalid> writes: > >> On Thu, 01 Feb 2024 19:03:38 -0800, Keith Thompson wrote: >> >>> A #include directive with <> searches for a "header", which is not >>> stated to be a file. A #include directive with "" searches for a file >>> in an implementation-defined manner; if that search fails, it tries >>> again as if <> had been used. >> >> The trouble with that interpretation is, it would seem to rule out the >> use of things like include libraries for user headers. Do you really >> think that was the intention? > > I don't know. I imagine an implementation could interpret the word > "file" to include information extracted from libraries. Then the distinction between “headers” that are “files”, versus those that are not, as so carefully worded in the standard (as you pointed out), becomes meaningless.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-02-03 02:36 +0000 |
| Message-ID | <20240202183610.892@kylheku.com> |
| In reply to | #381647 |
On 2024-02-03, Lawrence D'Oliveiro <ldo@nz.invalid> wrote: > On Fri, 02 Feb 2024 16:09:09 -0800, Keith Thompson wrote: > >> Lawrence D'Oliveiro <ldo@nz.invalid> writes: >> >>> On Thu, 01 Feb 2024 19:03:38 -0800, Keith Thompson wrote: >>> >>>> A #include directive with <> searches for a "header", which is not >>>> stated to be a file. A #include directive with "" searches for a file >>>> in an implementation-defined manner; if that search fails, it tries >>>> again as if <> had been used. >>> >>> The trouble with that interpretation is, it would seem to rule out the >>> use of things like include libraries for user headers. Do you really >>> think that was the intention? >> >> I don't know. I imagine an implementation could interpret the word >> "file" to include information extracted from libraries. > > Then the distinction between “headers” that are “files”, versus those that > are not, as so carefully worded in the standard (as you pointed out), > becomes meaningless. Not any more than the distinction between shell functions, built-in commands and external commands. -- 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 | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-02-03 00:53 -0800 |
| Message-ID | <86y1c27wum.fsf@linuxsc.com> |
| In reply to | #381644 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Lawrence D'Oliveiro <ldo@nz.invalid> writes: > >> On Thu, 01 Feb 2024 19:03:38 -0800, Keith Thompson wrote: >> >>> A #include directive with <> searches for a "header", which is not >>> stated to be a file. A #include directive with "" searches for a file >>> in an implementation-defined manner; if that search fails, it tries >>> again as if <> had been used. >> >> The trouble with that interpretation is, it would seem to rule out the use >> of things like include libraries for user headers. Do you really think >> that was the intention? > > I don't know. I imagine an implementation could interpret the word > "file" to include information extracted from libraries. Note that it > doesn't have to correspond to the concept of a "file" used in <stdio.h>; > that refers to files in the execution environment, not the compilation > environment. To me what the C standard says is clear. A #include "whatever.h" gets its stuff from a file (assuming of course the appropriate file can be found, and not revert to the #include <whatever.h> form). A #include <whatever.h> gets its stuff from a header, said header perhaps being stored in a file or perhaps not, and if file-stored then it could be a 1-1 relationship, or a 1-many relationship, or a many-1 relationship. Since the C standard doesn't define the term 'header', an implementation is allowed to actualize it however the implementation chooses (including the possibility of storing information inside the compiler itself).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-02-03 13:51 -0800 |
| Message-ID | <87v875md2s.fsf@nosuchdomain.example.com> |
| In reply to | #381663 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>> On Thu, 01 Feb 2024 19:03:38 -0800, Keith Thompson wrote:
>>>> A #include directive with <> searches for a "header", which is not
>>>> stated to be a file. A #include directive with "" searches for a file
>>>> in an implementation-defined manner; if that search fails, it tries
>>>> again as if <> had been used.
>>>
>>> The trouble with that interpretation is, it would seem to rule out the use
>>> of things like include libraries for user headers. Do you really think
>>> that was the intention?
>>
>> I don't know. I imagine an implementation could interpret the word
>> "file" to include information extracted from libraries. Note that it
>> doesn't have to correspond to the concept of a "file" used in <stdio.h>;
>> that refers to files in the execution environment, not the compilation
>> environment.
>
> To me what the C standard says is clear. A #include "whatever.h"
> gets its stuff from a file (assuming of course the appropriate
> file can be found, and not revert to the #include <whatever.h>
> form). A #include <whatever.h> gets its stuff from a header,
> said header perhaps being stored in a file or perhaps not, and if
> file-stored then it could be a 1-1 relationship, or a 1-many
> relationship, or a many-1 relationship. Since the C standard
> doesn't define the term 'header', an implementation is allowed to
> actualize it however the implementation chooses (including the
> possibility of storing information inside the compiler itself).
On further thought, I tend to agree.
I was thinking that an implementation could usefully provide some of its
own headers as something other than files, as it's clearly allowed to do
for the C standard headers. But the obvious way to do that would be to
require such headers to be included with <>, not "". POSIX-specific
headers like unistd.h are already conventionally included with <>.
An implementation probably *could* bend the meaning of "file" enough to
support having `#include "whatever.h"` load something other than a file
in the host filesystem, but it's not as useful as I first thought it
might be -- and it could interfere with user-provided header files that
happen to have the same name.
--
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 | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-02-03 17:56 -0500 |
| Message-ID | <upmgap$1g3ud$3@i2pn2.org> |
| In reply to | #381708 |
On 2/3/24 4:51 PM, Keith Thompson wrote: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >>> Lawrence D'Oliveiro <ldo@nz.invalid> writes: >>>> On Thu, 01 Feb 2024 19:03:38 -0800, Keith Thompson wrote: >>>>> A #include directive with <> searches for a "header", which is not >>>>> stated to be a file. A #include directive with "" searches for a file >>>>> in an implementation-defined manner; if that search fails, it tries >>>>> again as if <> had been used. >>>> >>>> The trouble with that interpretation is, it would seem to rule out the use >>>> of things like include libraries for user headers. Do you really think >>>> that was the intention? >>> >>> I don't know. I imagine an implementation could interpret the word >>> "file" to include information extracted from libraries. Note that it >>> doesn't have to correspond to the concept of a "file" used in <stdio.h>; >>> that refers to files in the execution environment, not the compilation >>> environment. >> >> To me what the C standard says is clear. A #include "whatever.h" >> gets its stuff from a file (assuming of course the appropriate >> file can be found, and not revert to the #include <whatever.h> >> form). A #include <whatever.h> gets its stuff from a header, >> said header perhaps being stored in a file or perhaps not, and if >> file-stored then it could be a 1-1 relationship, or a 1-many >> relationship, or a many-1 relationship. Since the C standard >> doesn't define the term 'header', an implementation is allowed to >> actualize it however the implementation chooses (including the >> possibility of storing information inside the compiler itself). > > On further thought, I tend to agree. > > I was thinking that an implementation could usefully provide some of its > own headers as something other than files, as it's clearly allowed to do > for the C standard headers. But the obvious way to do that would be to > require such headers to be included with <>, not "". POSIX-specific > headers like unistd.h are already conventionally included with <>. > > An implementation probably *could* bend the meaning of "file" enough to > support having `#include "whatever.h"` load something other than a file > in the host filesystem, but it's not as useful as I first thought it > might be -- and it could interfere with user-provided header files that > happen to have the same name. > I beleive an implementation doesn't need to provide a way to provide replacements for the standard defined headers. The include search method is fully implementation defined, with only the provision that if you use " " and don't find the file, it needs to use the < > method, but that doesn't say that the standard headers might not be first in the " " search order. Als 7.1.2p4 says: If a file with the same name as one of the above < and > delimited sequences, not provided as part of the implementation, is placed in any of the standard places that are searched for included source files, the behavior is undefined. So overridding a Standard defined header is explicitly Undefined Behaivor. (Not sure if POSIX extends that to its headers).
[toc] | [prev] | [next] | [standalone]
Page 13 of 21 — ← Prev page 1 … 11 12 [13] 14 15 … 21 Next page →
Back to top | Article view | comp.lang.c
csiph-web