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 20 of 21 — ← Prev page 1 … 18 19 [20] 21 Next page →
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-01-30 16:46 -0800 |
| Message-ID | <86eddyba7z.fsf@linuxsc.com> |
| In reply to | #381174 |
bart <bc@freeuk.com> writes:
> [description of a rudimentary C build system]
What was described is what I might call the easiest and
least important part of a build system.
Looking over one of my current projects (modest in size,
a few thousand lines of C source, plus some auxiliary
files adding perhaps another thousand or two), here are
some characteristics essential for my workflow (given
in no particular order):
* have multiple outputs (some outputs the result of
C compiles, others the result of other tools)
* use different flag settings for different translation
units
* be able to express dependency information
* produece generated source files, sometimes based
on other source files
* be able to invoke arbitrary commands, including
user-written scripts or other programs
* build or rebuild some outputs only when necessary
* condition some processing steps on successful
completion of other processing steps
* deliver partially built as well as fully built
program units
* automate regression testing and project archival
(in both cases depending on completion status)
* produce sets of review locations for things like
program errors or TBD items
* express different ways of combining compiler
outputs (such as .o files) depending on what
is being combined and what output is being
produced (sometimes a particular set of inputs
will be combined in several different ways to
produce several different outputs)
Indeed it is the case that producing a complete program is one
part of my overall build process. But it is only one step out
of many, and it is easy to express without needing any special
considerations from the build system.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-01-31 03:13 +0000 |
| Message-ID | <upcdsg$1c5c0$2@dont-email.me> |
| In reply to | #381297 |
On Tue, 30 Jan 2024 16:46:56 -0800, Tim Rentsch wrote: > * have multiple outputs (some outputs the result of > C compiles, others the result of other tools) Just as an example, the man page for Blender is generated by a Python script that runs the built executable with the “--help” option and wraps that output in some troff markup.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-01-31 03:23 +0000 |
| Message-ID | <20240130192236.711@kylheku.com> |
| In reply to | #381299 |
On 2024-01-31, Lawrence D'Oliveiro <ldo@nz.invalid> wrote: > On Tue, 30 Jan 2024 16:46:56 -0800, Tim Rentsch wrote: > >> * have multiple outputs (some outputs the result of >> C compiles, others the result of other tools) > > Just as an example, the man page for Blender is generated by a Python > script that runs the built executable with the “--help” option and wraps > that output in some troff markup. That's the sort of stunt why distros have given up on clean cross compiling, and resorted to Qemu. -- 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-01-31 08:47 +0100 |
| Message-ID | <upctu8$1e58u$2@dont-email.me> |
| In reply to | #381301 |
On 31/01/2024 04:23, Kaz Kylheku wrote: > On 2024-01-31, Lawrence D'Oliveiro <ldo@nz.invalid> wrote: >> On Tue, 30 Jan 2024 16:46:56 -0800, Tim Rentsch wrote: >> >>> * have multiple outputs (some outputs the result of >>> C compiles, others the result of other tools) >> >> Just as an example, the man page for Blender is generated by a Python >> script that runs the built executable with the “--help” option and wraps >> that output in some troff markup. > > That's the sort of stunt why distros have given up on clean cross > compiling, and resorted to Qemu. > It is also the sort of stunt that reduces development effort and ensures that you minimise the risk of documentation being out of sync with the program. I have never tried to build Blender, so I can't comment on this particular project, but if it is done right then I don't see a big problem. (If it is done wrong, requiring multiple "make" invocations or something like that, then it can be annoying.) For distros trying to make good meta-build systems, something like that is minor compared to C source files using __DATE__ and __TIME__ (or even worse, $Id$) to generate version numbers.
[toc] | [prev] | [next] | [standalone]
| From | Spiros Bousbouras <spibou@gmail.com> |
|---|---|
| Date | 2024-01-31 11:02 +0000 |
| Message-ID | <uDlPmlhCATufTD4Jk@bongo-ra.co> |
| In reply to | #381314 |
On Wed, 31 Jan 2024 08:47:20 +0100 David Brown <david.brown@hesbynett.no> wrote: > On 31/01/2024 04:23, Kaz Kylheku wrote: > > On 2024-01-31, Lawrence D'Oliveiro <ldo@nz.invalid> wrote: > >> On Tue, 30 Jan 2024 16:46:56 -0800, Tim Rentsch wrote: > >> > >>> * have multiple outputs (some outputs the result of > >>> C compiles, others the result of other tools) > >> > >> Just as an example, the man page for Blender is generated by a Python > >> script that runs the built executable with the “--help” option and wraps > >> that output in some troff markup. > > > > That's the sort of stunt why distros have given up on clean cross > > compiling, and resorted to Qemu. > > > > It is also the sort of stunt that reduces development effort and ensures > that you minimise the risk of documentation being out of sync with the > program. I don't see how it achieves such tasks. For preventing loss of agreement between behaviour and documentation , the developers must have the necessary self-discipline to modify the documentation when they make changes in the behaviour. If they have such self-discipline then it's no harder to modify a separate documentation file than it is to modify the part of the source code which prints the --help output. Personally , I have the file(s) with the documentation as additional tabs in the same vim session where other tabs have the source code. Regarding development effort , it's actually more development effort to have the documentation as source code which prints a message. If it is source code then you have the usual requirements for good documentation *plus* the requirement that it is embedded within legal source code in the language you are writing. If for example the text of the documentation has somewhere a double quote then you have to take into account whether a double quote has a special meaning in the programming language you are using (and likely it will have). If the documentation is a separate file then you don't have this additional requirement. Also , the output of --help should be a short reminder whereas documentation should be longer , possibly much longer , possibly containing a tutorial , depending on how complex the application is. > I have never tried to build Blender, so I can't comment on > this particular project, but if it is done right then I don't see a big > problem. (If it is done wrong, requiring multiple "make" invocations or > something like that, then it can be annoying.) -- vlaho.ninja/menu
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-31 15:31 +0100 |
| Message-ID | <updlk1$1i2he$4@dont-email.me> |
| In reply to | #381321 |
On 31/01/2024 12:02, Spiros Bousbouras wrote: > On Wed, 31 Jan 2024 08:47:20 +0100 > David Brown <david.brown@hesbynett.no> wrote: >> On 31/01/2024 04:23, Kaz Kylheku wrote: >>> On 2024-01-31, Lawrence D'Oliveiro <ldo@nz.invalid> wrote: >>>> On Tue, 30 Jan 2024 16:46:56 -0800, Tim Rentsch wrote: >>>> >>>>> * have multiple outputs (some outputs the result of >>>>> C compiles, others the result of other tools) >>>> >>>> Just as an example, the man page for Blender is generated by a Python >>>> script that runs the built executable with the “--help” option and wraps >>>> that output in some troff markup. >>> >>> That's the sort of stunt why distros have given up on clean cross >>> compiling, and resorted to Qemu. >>> >> >> It is also the sort of stunt that reduces development effort and ensures >> that you minimise the risk of documentation being out of sync with the >> program. > > I don't see how it achieves such tasks. For preventing loss of agreement > between behaviour and documentation , the developers must have the necessary > self-discipline to modify the documentation when they make changes in the > behaviour. If they have such self-discipline then it's no harder to modify a > separate documentation file than it is to modify the part of the source code > which prints the --help output. Personally , I have the file(s) with the > documentation as additional tabs in the same vim session where other tabs > have the source code. They must document the user-visible features in (at least) two places - the "man" page, and the "--help" output. By using automation to generate one of these from the other, they reduce the duplicated effort. > > Also , the output of --help should be a short reminder whereas > documentation should be longer , possibly much longer , possibly containing a > tutorial , depending on how complex the application is. The same applies to "man" pages. Sometimes it makes sense to have short "--help" outputs and longer "man" pages, but if the documentation is longer than perhaps a dozen pages/screenfuls, "man" is unsuitable. And I imagine that the documentation for blender, along with its tutorials (as you say), is many orders of magnitude more than that. Keeping the "man" page and "--help" output the same seems sensible here.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-01-31 15:13 +0000 |
| Message-ID | <kstuN.273506$Wp_8.117681@fx17.iad> |
| In reply to | #381342 |
David Brown <david.brown@hesbynett.no> writes:
>On 31/01/2024 12:02, Spiros Bousbouras wrote:
>> On Wed, 31 Jan 2024 08:47:20 +0100
>> David Brown <david.brown@hesbynett.no> wrote:
>>> On 31/01/2024 04:23, Kaz Kylheku wrote:
>>>> On 2024-01-31, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>>> On Tue, 30 Jan 2024 16:46:56 -0800, Tim Rentsch wrote:
>>>>>
>>>>>> * have multiple outputs (some outputs the result of
>>>>>> C compiles, others the result of other tools)
>>>>>
>>>>> Just as an example, the man page for Blender is generated by a Python
>>>>> script that runs the built executable with the “--help” option and wraps
>>>>> that output in some troff markup.
>>>>
>>>> That's the sort of stunt why distros have given up on clean cross
>>>> compiling, and resorted to Qemu.
>>>>
>>>
>>> It is also the sort of stunt that reduces development effort and ensures
>>> that you minimise the risk of documentation being out of sync with the
>>> program.
>>
>> I don't see how it achieves such tasks. For preventing loss of agreement
>> between behaviour and documentation , the developers must have the necessary
>> self-discipline to modify the documentation when they make changes in the
>> behaviour. If they have such self-discipline then it's no harder to modify a
>> separate documentation file than it is to modify the part of the source code
>> which prints the --help output. Personally , I have the file(s) with the
>> documentation as additional tabs in the same vim session where other tabs
>> have the source code.
>
>They must document the user-visible features in (at least) two places -
>the "man" page, and the "--help" output. By using automation to
>generate one of these from the other, they reduce the duplicated effort.
Indeed. In our case, we generate the manpages using nroff and
the simulator 'help' command will call system("man ${INSTALL_LOC}/man/topic.man")
to display the help text. We also process the manpage source files with troff
to generate pages appended to the end of the users guide (troff MOM
macro set) PDF.
Only one place (the manpage source file) need be updated.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-01-31 23:00 +0000 |
| Message-ID | <upejfa$1nil8$1@dont-email.me> |
| In reply to | #381346 |
On Wed, 31 Jan 2024 15:13:20 GMT, Scott Lurndal wrote:
> ... and the simulator 'help' command will call system("man
> ${INSTALL_LOC}/man/topic.man")
Agh! Why do people feel the need to go through a shell where a shell is
not needed?
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-02-01 00:29 +0000 |
| Message-ID | <DBBuN.86397$m4d.3472@fx43.iad> |
| In reply to | #381413 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Wed, 31 Jan 2024 15:13:20 GMT, Scott Lurndal wrote:
>
>> ... and the simulator 'help' command will call system("man
>> ${INSTALL_LOC}/man/topic.man")
>
>Agh! Why do people feel the need to go through a shell where a shell is
>not needed?
Because 'system()' works and it a lot less code than
fork and exec?
How would you display an manpage using nroff markup
from an application?
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-02-01 03:07 +0000 |
| Message-ID | <upf1sn$1t7cn$5@dont-email.me> |
| In reply to | #381420 |
On Thu, 01 Feb 2024 00:29:23 GMT, Scott Lurndal wrote:
> How would you display an manpage using nroff markup from an application?
Much safer:
subprocess.run \
(
args = ("man", os.path.expandvars("${INSTALL_LOC}/man/topic.man"))
)
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-02-01 15:00 +0000 |
| Message-ID | <TlOuN.411739$83n7.368997@fx18.iad> |
| In reply to | #381435 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Thu, 01 Feb 2024 00:29:23 GMT, Scott Lurndal wrote:
>
>> How would you display an manpage using nroff markup from an application?
>
>Much safer:
>
>subprocess.run \
> (
> args = ("man", os.path.expandvars("${INSTALL_LOC}/man/topic.man"))
> )
WTF?
You are aware you are posting to comp.lang.c, right?
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-02-01 23:40 +0000 |
| Message-ID | <upha55$2916e$6@dont-email.me> |
| In reply to | #381475 |
On Thu, 01 Feb 2024 15:00:03 GMT, Scott Lurndal wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>>On Thu, 01 Feb 2024 00:29:23 GMT, Scott Lurndal wrote:
>>
>>> How would you display an manpage using nroff markup from an
>>> application?
>>
>>Much safer:
>>
>>subprocess.run \
>> (
>> args = ("man", os.path.expandvars("${INSTALL_LOC}/man/topic.man"))
>> )
>
> You are aware you are posting to comp.lang.c, right?
Yes. Nevertheless, this is the clearest and most concise (read: least work
involved for me) way of explaining what I mean; I will leave it to the C
experts to translate it into their preferred lower-level way of doing
things.
[toc] | [prev] | [next] | [standalone]
| From | vallor <vallor@cultnix.org> |
|---|---|
| Date | 2024-02-01 08:15 +0000 |
| Subject | system(3) (was: Re: Experimental C Build System) |
| Message-ID | <upfjvo$1tvq1$3@dont-email.me> |
| In reply to | #381413 |
On Wed, 31 Jan 2024 23:00:58 -0000 (UTC), Lawrence D'Oliveiro
<ldo@nz.invalid> wrote in <upejfa$1nil8$1@dont-email.me>:
> On Wed, 31 Jan 2024 15:13:20 GMT, Scott Lurndal wrote:
>
>> ... and the simulator 'help' command will call system("man
>> ${INSTALL_LOC}/man/topic.man")
>
> Agh! Why do people feel the need to go through a shell where a shell is
> not needed?
In my case: it wasn't so much of a "need" -- more of a "want". :)
Generally, I'd agree with you; but let's say Programmer Joe decides to
change his path to run his own special version of make(1). (Maybe he's on
an ancient SunOS system with gnu make in (say) /opt/gnu/bin. You know --
weird Unix stuff.)
So who are we to decide "no gnus allowed"?
Okay, maybe that's a weak example -- but
yes, I wouldn't use system(3) in any program
that needs to be very specific about what it passes
on to its children. (I wouldn't -- but someone else might.)
--
-v
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-01-31 23:02 +0000 |
| Message-ID | <upeji8$1nil8$2@dont-email.me> |
| In reply to | #381342 |
On Wed, 31 Jan 2024 15:31:29 +0100, David Brown wrote:
> ... but if the documentation is
> longer than perhaps a dozen pages/screenfuls, "man" is unsuitable.
So it is your considered opinion, then, that the bash man page is
“unsuitable”?
ldo@theon:~> man bash | wc -l
5276
Actually I refer to it quite a lot. Being able to use search functions
helps.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-02-01 00:33 +0000 |
| Message-ID | <QFBuN.86398$m4d.38518@fx43.iad> |
| In reply to | #381414 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Wed, 31 Jan 2024 15:31:29 +0100, David Brown wrote:
>
>> ... but if the documentation is
>> longer than perhaps a dozen pages/screenfuls, "man" is unsuitable.
>
>So it is your considered opinion, then, that the bash man page is
>“unsuitable”?
>
> ldo@theon:~> man bash | wc -l
> 5276
>
>Actually I refer to it quite a lot. Being able to use search functions
>helps.
When working with the ksh man page, I use vim.
function viman
{
a=$(mktemp absXXXXXXX)
man "$1" | col -b > ${a}
vim ${a}
rm ${a}
}
$ viman ksh
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-02-01 15:11 +0100 |
| Message-ID | <upg8r5$23jdt$1@dont-email.me> |
| In reply to | #381421 |
On 01.02.2024 01:33, Scott Lurndal wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>> On Wed, 31 Jan 2024 15:31:29 +0100, David Brown wrote:
>>
>>> ... but if the documentation is
>>> longer than perhaps a dozen pages/screenfuls, "man" is unsuitable.
>>
>> So it is your considered opinion, then, that the bash man page is
>> “unsuitable�
>>
>> ldo@theon:~> man bash | wc -l
>> 5276
>>
>> Actually I refer to it quite a lot. Being able to use search functions
>> helps.
>
> When working with the ksh man page, I use vim.
>
> function viman
> {
> a=$(mktemp absXXXXXXX)
> man "$1" | col -b > ${a}
> vim ${a}
> rm ${a}
> }
>
>
> $ viman ksh
>
In some modern shells (ksh, bash, zsh) you may use process substitution
and avoid creating a temporary file (it simplifies things)...
vim <(man "$1" | col -b)
Janis
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-02-01 14:55 +0100 |
| Message-ID | <upg7s9$23e60$1@dont-email.me> |
| In reply to | #381342 |
On 31.01.2024 15:31, David Brown wrote: > On 31/01/2024 12:02, Spiros Bousbouras wrote: > They must document the user-visible features in (at least) two places - > the "man" page, and the "--help" output. By using automation to > generate one of these from the other, they reduce the duplicated effort. > >> Also , the output of --help should be a short reminder whereas >> documentation should be longer , possibly much longer , possibly >> containing a >> tutorial , depending on how complex the application is. > > The same applies to "man" pages. Sometimes it makes sense to have short > "--help" outputs and longer "man" pages, but if the documentation is > longer than perhaps a dozen pages/screenfuls, "man" is unsuitable. And > I imagine that the documentation for blender, along with its tutorials > (as you say), is many orders of magnitude more than that. Keeping the > "man" page and "--help" output the same seems sensible here. Ksh93 has chosen an interesting path here; they have a powerful getopts command (to parse the command line options), and have extended the well known simple option-string format to allow to specify with actually an own language all about options (type, defaults, forms, purpose, etc.). This allows an automated generation of output in some forms (HTML, man, etc.) with every command that uses ksh93 getopts to parse the options (try 'getopts --man' [in ksh93] for details). There are a couple approaches (Eiffel extracts some properties inherent to the language from the source, Javs extracts user defined doxygen entries, etc.). Janis
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-02-01 14:42 +0100 |
| Message-ID | <upg73m$23aac$1@dont-email.me> |
| In reply to | #381321 |
On 31.01.2024 12:02, Spiros Bousbouras wrote: > On Wed, 31 Jan 2024 08:47:20 +0100 > David Brown <david.brown@hesbynett.no> wrote: >> >> It is also the sort of stunt that reduces development effort and ensures >> that you minimise the risk of documentation being out of sync with the >> program. This statement was also to me an initiator of some neurons firing and make me recall the development processes we used (in some large projects, not in one-man-shows)... > > I don't see how it achieves such tasks. For preventing loss of agreement > between behaviour and documentation , the developers must have the necessary > self-discipline to modify the documentation when they make changes in the > behaviour. This self-discipline can be supported by tools. If we had to change things (due to feature request or bug) we opened a 'feature or bug request', established a 'track' and associated some 'fix-records' to the track. The 'request' contained the description, requirements, or specification, the individual 'fix-records' were, e.g., for code, or documentation, or dependent parts, and separately assigned. A (typical?) method to organize things and not forget an important step or product part. (Note: The used 'keywords' are approximations and may not actually match the tool's literals.) > If they have such self-discipline then it's no harder to modify a > separate documentation file than it is to modify the part of the source code > which prints the --help output. Personally , I have the file(s) with the > documentation as additional tabs in the same vim session where other tabs > have the source code. > > [...] Janis
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-01-31 12:19 +0000 |
| Message-ID | <upddrt$1gllv$1@dont-email.me> |
| In reply to | #381299 |
On 31/01/2024 03:13, Lawrence D'Oliveiro wrote:
> On Tue, 30 Jan 2024 16:46:56 -0800, Tim Rentsch wrote:
>
>> * have multiple outputs (some outputs the result of
>> C compiles, others the result of other tools)
>
> Just as an example, the man page for Blender is generated by a Python
> script that runs the built executable with the “--help” option and wraps
> that output in some troff markup.
I do things a bit more simply. The '-help' text for my MCC program is
implemented with this line in the original source:
println strinclude("help.txt")
The help text is just a regular text file. So often you see reams of
printf statements containing strings full of escape codes...
But I can do complex too, if this is what we're trying to show off.
I needed to produce (some time ago...) a printed manual for my
application (CAD software), which contained a mix of text, tables,
images and vector diagrams:
- The text was created with an ordinary text editor
- It incorporated runoff-like commands that I'd devised
- It was processed by a program I'd written in a scripting language.
- That program ran under the application in question
- It rendered it a page at a time, which was then processed by the app's
PostScript driver, then sent it to an actual PostScript printer
- I also wrote the manual
- I also wrote the whole CAD application
- I created both the language used for the app, and the scripting language
- I /implemented/ both languages, one of them in itself
- Oh, and I wrote the text editor!
- I believe this was done pre-Windows, which meant also writing various
drivers for graphics adaptors, all the libraries needed to draw stuff
including GUI, providing bitmap and vector fonts, writing printer and
plotter drivers (of which the PS/EPS driver was one), etc etc
So this was not just orchestrating various bits of pre-existing
software, which makes Unix people feel so superior because they can do:
x | a | b | c > y
instead of (using default file extensions):
a x
b x
c x
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-02-01 14:29 +0000 |
| Message-ID | <upg9rk$23ocu$1@dont-email.me> |
| In reply to | #381297 |
On 31/01/2024 00:46, Tim Rentsch wrote:
> bart <bc@freeuk.com> writes:
>
>> [description of a rudimentary C build system]
>
> What was described is what I might call the easiest and
> least important part of a build system.
>
> Looking over one of my current projects (modest in size,
> a few thousand lines of C source, plus some auxiliary
> files adding perhaps another thousand or two), here are
> some characteristics essential for my workflow (given
> in no particular order):
>
> * have multiple outputs (some outputs the result of
> C compiles, others the result of other tools)
>
> * use different flag settings for different translation
> units
>
> * be able to express dependency information
>
> * produece generated source files, sometimes based
> on other source files
>
> * be able to invoke arbitrary commands, including
> user-written scripts or other programs
>
> * build or rebuild some outputs only when necessary
>
> * condition some processing steps on successful
> completion of other processing steps
>
> * deliver partially built as well as fully built
> program units
>
> * automate regression testing and project archival
> (in both cases depending on completion status)
>
> * produce sets of review locations for things like
> program errors or TBD items
>
> * express different ways of combining compiler
> outputs (such as .o files) depending on what
> is being combined and what output is being
> produced (sometimes a particular set of inputs
> will be combined in several different ways to
> produce several different outputs)
>
> Indeed it is the case that producing a complete program is one
> part of my overall build process. But it is only one step out
> of many, and it is easy to express without needing any special
> considerations from the build system.
> Looking over one of my current projects (modest in size,
> a few thousand lines of C source, plus some auxiliary
> files adding perhaps another thousand or two),
So, will a specific build of such a project produce a single EXE/DLL//SO
file? (The // includes the typical file extension of Linux executables.)
This is all I want for a build.
I guess if you wrote your program in a language XXX that provided this
build process for example:
xxxc -build leadmodule.xxx
you would find it equally unusable because it doesn't provide the
flexibility you're accustomed to from the chaotic, DIY nature of your
current methods.
The idea is that you have a a tool that provides the basic build process
as illustrated with the xxxc example, and you superimpose any custom
requirements on top of that, making use of whatever customisation
abilities it does provide.
An analogy would be switching to a language that doesn't have C's
preprocessor. If your coding style depends on macros that yield random
bits of syntax, or to use conditional blocks to arbitrarily choose which
lines to process, then you can also dismiss it as unusable.
[toc] | [prev] | [next] | [standalone]
Page 20 of 21 — ← Prev page 1 … 18 19 [20] 21 Next page →
Back to top | Article view | comp.lang.c
csiph-web