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 2 of 21 — ← Prev page 1 [2] 3 4 … 21 Next page →
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-02-01 17:33 +0000 |
| Message-ID | <upgklr$25mca$1@dont-email.me> |
| In reply to | #381479 |
On 01/02/2024 15:11, David Brown wrote: > On 01/02/2024 12:31, bart wrote: >> On 01/02/2024 08:39, David Brown wrote: >>> On 31/01/2024 21:25, bart wrote: >>>> On 31/01/2024 16:41, vallor wrote: >>>>> On Tue, 30 Jan 2024 19:22:00 +0000, Richard Harnden >>>>> <richard.nospam@gmail.invalid> wrote in >>>>> <upbi8o$14443$1@dont-email.me>: >>>>> >>>>>> On 30/01/2024 16:50, Malcolm McLean wrote: >>>>>>> >>>>>>> But I'm wondering about one file which contains all the sources >>>>>>> for the >>>>>>> program. Like an IDE project file but lighter weight. >>>>>>> >>>>>>> >>>>>> In other words: a Makefile >>>>> >>>>> Agreed; it's a solution looking for a problem. >>>> >>>> Why do you think languages come with modules? That allows them to >>>> discover their own modules, rather than rely on external apps where >>>> the details are buried under appalling syntax and mixed up with a >>>> hundred other matters. >>>> >>> >>> No, that is not at all the purpose of modules in programming. Note >>> that there is no specific meaning of "module", and different >>> languages use different for similar concepts. There are many >>> features that a language's "module" system might have - some have >>> all, some have few: >>> >>> 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. > > >> >> While for 6, there is only a hierarchy between groups of modules, each >> forming an independent sub-program or library. I tried a strict full >> per-module hierarchy early on, mixed up with independent compilation; >> it worked poorly. >> >> The two levels allow you to assemble one binary out of groups of >> modules that each represent an independent component or library. >> >> > Compiled >> > languages don't usually have such a thing, because developers (as >> > distinct from users) have build tools available that do a better job. >> >> Given a module scheme, the tool needed to build a whole program should >> not need to be told about the names and location of every constituent >> module; it should be able to determine that from what's already in the >> source code, given only a start point. > > Why? > > You can't just take some idea that you like, and that is suitable for > the projects you use, and assume it applies to everyone else. > > I have no problem telling my build system, or compilers, where the files > are. In fact, I'd have a lot of problems if I couldn't do that. It is > not normal development practice to have the source files in the same > directory that you use for building the object code and binaries. > Our system is that we've got two types of source generated by us, the libraries which are used by all the programs, and the code specific to each program. The library source code is placed on a central server and then downloaded by conan (a package manager) which keeps it in a private directory in the local machine not intended for viewing. The source specific to the program is placed in a git project and synchronised with git's remote repository facilities. Then IDE project files are built with CMake. These with various other derived bits and bobs are placed in a build folder, which is always under the git repository, but placed in the ignore file and so not under git source control. The IDE is then invoked on the project file in the build directory, and the executables also go into the build directory. They then need to be moved to a different location to be run. CMake is set up so that it recursively crawls the source directories and places every single source file into the IDE project file. This isn't really recommended but it means you don't have to maintain CMakeLists files. So it's an out of tree build. But we can't just place source in some random location on the local machine and tell the system to pull it in. Technically you could modify the CMake script to do that. But it would break the whole system. -- Check out Basic Algorithms and my other books: https://www.lulu.com/spotlight/bgy1mm
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-02-01 18:34 +0000 |
| Message-ID | <upgo72$26abt$1@dont-email.me> |
| In reply to | #381479 |
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?
>> Given a module scheme, the tool needed to build a whole program should
>> not need to be told about the names and location of every constituent
>> module; it should be able to determine that from what's already in the
>> source code, given only a start point.
>
> Why?
>
> You can't just take some idea that you like, and that is suitable for
> the projects you use, and assume it applies to everyone else.
>
> I have no problem telling my build system, or compilers, where the files
> are. In fact, I'd have a lot of problems if I couldn't do that. It is
> not normal development practice to have the source files in the same
> directory that you use for building the object code and binaries.
>
>>
>> Even with independent compilation, you might be able to use that info
>> to determine dependencies, but you will need that module hierarchy if
>> you want to compile individual modules.
>
> 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?
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.
> 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.
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.
I tend to build C programs by recompiling all modules too. So I want to
introduce the same convenience I have elsewhere.
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.
----------------------------
(Repost)
I've already covered this in many posts on the subject. But 'make' deals
with three kinds of requirements:
(1) Specifying what the modules are to be compiled and combined into one
binary file
(2) Specifying dependences between all files to allow rebuilding of that
one file with minimal recompilation
(3) Everything else needed in a complex project: running processes to
generate files file config.h, creating multiple binaries, specifying
dependencies between binaries, installation etc
My proposal tackles only (1), which is something that many languages now
have the means to deal with themselves. I already stated that (2) is not
covered.
But you may still need makefiles to deal with (3).
If your main requirement /is/ only (1), then my idea is to move the
necessary info into the source code, and tackle it with the C compiler.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-02-01 22:23 +0200 |
| Message-ID | <20240201222328.00006859@yahoo.com> |
| In reply to | #381501 |
On Thu, 1 Feb 2024 18:34:08 +0000 bart <bc@freeuk.com> 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? > > >> Given a module scheme, the tool needed to build a whole program > >> should not need to be told about the names and location of every > >> constituent module; it should be able to determine that from > >> what's already in the source code, given only a start point. > > > > Why? > > > > You can't just take some idea that you like, and that is suitable > > for the projects you use, and assume it applies to everyone else. > > > > I have no problem telling my build system, or compilers, where the > > files are. In fact, I'd have a lot of problems if I couldn't do > > that. It is not normal development practice to have the source > > files in the same directory that you use for building the object > > code and binaries. > >> > >> Even with independent compilation, you might be able to use that > >> info to determine dependencies, but you will need that module > >> hierarchy if you want to compile individual modules. > > > > 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? > > 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. > > > > 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. > > 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. > > I tend to build C programs by recompiling all modules too. So I want > to introduce the same convenience I have elsewhere. > > 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. > > ---------------------------- > (Repost) > > I've already covered this in many posts on the subject. But 'make' > deals with three kinds of requirements: > > (1) Specifying what the modules are to be compiled and combined into > one binary file > > (2) Specifying dependences between all files to allow rebuilding of > that one file with minimal recompilation > > (3) Everything else needed in a complex project: running processes to > generate files file config.h, creating multiple binaries, > specifying dependencies between binaries, installation etc > > My proposal tackles only (1), which is something that many languages > now have the means to deal with themselves. I already stated that (2) > is not covered. > > But you may still need makefiles to deal with (3). > > If your main requirement /is/ only (1), then my idea is to move the > necessary info into the source code, and tackle it with the C > compiler. > You proposal and needs of David Brown are not necessarily contradictory. All you need to do to satisfy him is to add to your compiler an option for export of dependencies in make-compatible format, i.e. something very similar to -MD option of gcc. Then David could write in his makefile: out/foo.elf : main_foo.c mcc -MD $< -o $@ -include out/foo.d And then to proceed with automatiion of his pre and post-processing needs.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-02-01 20:55 +0000 |
| Message-ID | <tzTuN.104491$JLvf.66783@fx44.iad> |
| In reply to | #381512 |
Michael S <already5chosen@yahoo.com> writes: >On Thu, 1 Feb 2024 18:34:08 +0000 >bart <bc@freeuk.com> wrote: > >> On 01/02/2024 15:11, David Brown wrote: >> But you may still need makefiles to deal with (3). >>=20 >> If your main requirement /is/ only (1), then my idea is to move the=20 >> necessary info into the source code, and tackle it with the C >> compiler. >>=20 > > >You proposal and needs of David Brown are not necessarily >contradictory.=20 Although David (and I) aren't particularly interested in changing something that already works quite well. >All you need to do to satisfy him is to add to your compiler an option >for export of dependencies in make-compatible format, i.e. something >very similar to -MD option of gcc. I suspect he may be much more difficult to satisfy on this topic. Nobody is going to switch production software to a one-off unsupported compiler.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-02-01 13:10 -0800 |
| Message-ID | <uph1bl$27tkp$1@dont-email.me> |
| In reply to | #381515 |
On 2/1/2024 12:55 PM, Scott Lurndal wrote: > Michael S <already5chosen@yahoo.com> writes: >> On Thu, 1 Feb 2024 18:34:08 +0000 >> bart <bc@freeuk.com> wrote: >> >>> On 01/02/2024 15:11, David Brown wrote: > >>> But you may still need makefiles to deal with (3). >>> =20 >>> If your main requirement /is/ only (1), then my idea is to move the=20 >>> necessary info into the source code, and tackle it with the C >>> compiler. >>> =20 >> >> >> You proposal and needs of David Brown are not necessarily >> contradictory.=20 > > Although David (and I) aren't particularly interested in > changing something that already works quite well. > >> All you need to do to satisfy him is to add to your compiler an option >> for export of dependencies in make-compatible format, i.e. something >> very similar to -MD option of gcc. > > I suspect he may be much more difficult to satisfy on this topic. > > Nobody is going to switch production software to a one-off > unsupported compiler. > No shit. Even then, he would have to test drive it, make sure it passes all unit tests, ect... How fun... ;^)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-01 22:38 +0100 |
| Message-ID | <uph305$2867k$2@dont-email.me> |
| In reply to | #381512 |
On 01/02/2024 21:23, Michael S wrote: > On Thu, 1 Feb 2024 18:34:08 +0000 >> I've already covered this in many posts on the subject. But 'make' >> deals with three kinds of requirements: >> >> (1) Specifying what the modules are to be compiled and combined into >> one binary file >> >> (2) Specifying dependences between all files to allow rebuilding of >> that one file with minimal recompilation >> >> (3) Everything else needed in a complex project: running processes to >> generate files file config.h, creating multiple binaries, >> specifying dependencies between binaries, installation etc >> >> My proposal tackles only (1), which is something that many languages >> now have the means to deal with themselves. I already stated that (2) >> is not covered. >> >> But you may still need makefiles to deal with (3). >> >> If your main requirement /is/ only (1), then my idea is to move the >> necessary info into the source code, and tackle it with the C >> compiler. >> > > > You proposal and needs of David Brown are not necessarily > contradictory. > All you need to do to satisfy him is to add to your compiler an option > for export of dependencies in make-compatible format, i.e. something > very similar to -MD option of gcc. > > Then David could write in his makefile: > > out/foo.elf : main_foo.c > mcc -MD $< -o $@ > > -include out/foo.d > > And then to proceed with automatiion of his pre and post-processing needs. > But then I'd still be using "make", and Bart would not be happy. And "gcc -MD" does not need any extra #pragmas, so presumably neither would an implementation of that feature in bcc (or mcc or whatever). So Bart's new system would disappear entirely.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-02-02 00:55 +0200 |
| Message-ID | <20240202005538.000054ff@yahoo.com> |
| In reply to | #381522 |
On Thu, 1 Feb 2024 22:38:13 +0100 David Brown <david.brown@hesbynett.no> wrote: > On 01/02/2024 21:23, Michael S wrote: > > On Thu, 1 Feb 2024 18:34:08 +0000 > > >> I've already covered this in many posts on the subject. But 'make' > >> deals with three kinds of requirements: > >> > >> (1) Specifying what the modules are to be compiled and combined > >> into one binary file > >> > >> (2) Specifying dependences between all files to allow rebuilding of > >> that one file with minimal recompilation > >> > >> (3) Everything else needed in a complex project: running processes > >> to generate files file config.h, creating multiple binaries, > >> specifying dependencies between binaries, installation etc > >> > >> My proposal tackles only (1), which is something that many > >> languages now have the means to deal with themselves. I already > >> stated that (2) is not covered. > >> > >> But you may still need makefiles to deal with (3). > >> > >> If your main requirement /is/ only (1), then my idea is to move the > >> necessary info into the source code, and tackle it with the C > >> compiler. > >> > > > > > > You proposal and needs of David Brown are not necessarily > > contradictory. > > All you need to do to satisfy him is to add to your compiler an > > option for export of dependencies in make-compatible format, i.e. > > something very similar to -MD option of gcc. > > > > Then David could write in his makefile: > > > > out/foo.elf : main_foo.c > > mcc -MD $< -o $@ > > > > -include out/foo.d > > > > And then to proceed with automatiion of his pre and post-processing > > needs. > > But then I'd still be using "make", and Bart would not be happy. > > And "gcc -MD" does not need any extra #pragmas, so presumably neither > would an implementation of that feature in bcc (or mcc or whatever). > So Bart's new system would disappear entirely. > > > Bart spares you from managing list(s) of objects in your makefile and from writing arcan helper macros. Yes, I know, you copy&past arcan macros from project to project, but you had to write them n years ago and that surely was not easy.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-02-01 23:31 +0000 |
| Message-ID | <uph9ko$2916e$3@dont-email.me> |
| In reply to | #381535 |
On Fri, 2 Feb 2024 00:55:38 +0200, Michael S wrote: > Yes, I know, you copy&past arcan macros from project to project, but you > had to write them n years ago and that surely was not easy. And maybe you discover bugs in them in certain situations, and have to track down all the places you copied/pasted them and fix them. My code-reuse OCD reflex is twitching at this point.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-02-02 02:08 +0000 |
| Message-ID | <i8YuN.420682$83n7.16386@fx18.iad> |
| In reply to | #381535 |
Michael S <already5chosen@yahoo.com> writes: >On Thu, 1 Feb 2024 22:38:13 +0100 >David Brown <david.brown@hesbynett.no> wrote: > >> > And then to proceed with automatiion of his pre and post-processing >> > needs. >> >> But then I'd still be using "make", and Bart would not be happy. >> >> And "gcc -MD" does not need any extra #pragmas, so presumably neither >> would an implementation of that feature in bcc (or mcc or whatever). >> So Bart's new system would disappear entirely. >> >> >> > >Bart spares you from managing list(s) of objects in your makefile and >from writing arcan helper macros. >Yes, I know, you copy&past arcan macros from project to project, but >you had to write them n years ago and that surely was not easy. "Not easy for you" doesn't automatically translate to "not easy for everyone else". Difficult is the configuration file for sendmail processed by m4. Make is easy.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-02 09:02 +0100 |
| Message-ID | <upi7i8$2h3eq$1@dont-email.me> |
| In reply to | #381535 |
On 01/02/2024 23:55, Michael S wrote: > On Thu, 1 Feb 2024 22:38:13 +0100 > David Brown <david.brown@hesbynett.no> wrote: > >> On 01/02/2024 21:23, Michael S wrote: >>> On Thu, 1 Feb 2024 18:34:08 +0000 >> >>> >>> You proposal and needs of David Brown are not necessarily >>> contradictory. >>> All you need to do to satisfy him is to add to your compiler an >>> option for export of dependencies in make-compatible format, i.e. >>> something very similar to -MD option of gcc. >>> >>> Then David could write in his makefile: >>> >>> out/foo.elf : main_foo.c >>> mcc -MD $< -o $@ >>> >>> -include out/foo.d >>> >>> And then to proceed with automatiion of his pre and post-processing >>> needs. >> >> But then I'd still be using "make", and Bart would not be happy. >> >> And "gcc -MD" does not need any extra #pragmas, so presumably neither >> would an implementation of that feature in bcc (or mcc or whatever). >> So Bart's new system would disappear entirely. >> >> >> > > Bart spares you from managing list(s) of objects in your makefile and > from writing arcan helper macros. > Yes, I know, you copy&past arcan macros from project to project, but > you had to write them n years ago and that surely was not easy. > Google "makefile automatic dependencies", then adapt to suit your own needs. Re-use the same makefile time and again. Yes, some of the functions I have in my makefiles are a bit hairy, and some of the command line options for gcc are a bit complicated. They are done now. If there had been an easier way than this, which still let me do what I need (Bart's system does not), which is popular enough that you can easily google for examples, blogs, and tutorials, then I'd have been happy to use that at the time. I won't change to something else unless it gives me significant additional benefits. People smarter and more experienced than Bart have been trying to invent better replacements for "make" for many decades. None have succeeded. Some build systems are better in some ways, but nothing has come close to covering the wide range of features and uses of make, or gaining hold outside a particular niche. Everyone who has ever made serious use of "make" knows it has many flaws, unnecessarily complications, limitations and inefficiencies. Despite that, it is the best we have. With Bart's limited knowledge and experience, and deeply ingrained prejudices and misunderstandings, the best we can hope for is something that works well enough for some simple cases of C programs. More realistically, it will work for Bart's use alone. And that, of course, is absolutely fine. No one is paying Bart to write a generic build system, or something of use to anyone else. He is free to write exactly what he wants, in the way he wants, and if ends up with a tool that he finds useful himself, that is great. If he ends up with something that at least some other people find useful, that is even better, and I wish him luck with his work. But don't hold your breath waiting for something that will replace make, or attract users of any other build system.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-02-02 15:28 +0200 |
| Message-ID | <20240202152849.0000218e@yahoo.com> |
| In reply to | #381580 |
On Fri, 2 Feb 2024 09:02:15 +0100 David Brown <david.brown@hesbynett.no> wrote: > > But don't hold your breath waiting for something that will replace > make, or attract users of any other build system. > > It seems, you already forgot the context of my post that started this short sub-thread. BTW, I would imagine that Stu Feldman, if he is still in good health, would fine talking with Bart more entertaining that talking with you. I think, you, English speakers, call it birds of feather.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-02 15:49 +0100 |
| Message-ID | <upivdg$2ku97$2@dont-email.me> |
| In reply to | #381597 |
On 02/02/2024 14:28, Michael S wrote: > On Fri, 2 Feb 2024 09:02:15 +0100 > David Brown <david.brown@hesbynett.no> wrote: >> >> But don't hold your breath waiting for something that will replace >> make, or attract users of any other build system. >> >> > > It seems, you already forgot the context of my post that started this > short sub-thread. > That is absolutely possible. It was not intentional, but the number of posts in recent times has been overwhelming. I apologise if I have misinterpreted what you wrote. > BTW, I would imagine that Stu Feldman, if he is still in good health, > would fine talking with Bart more entertaining that talking with you. I have no idea who that is, so I'll take your word for it. > I think, you, English speakers, call it birds of feather. >
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-02-02 16:53 +0200 |
| Message-ID | <20240202165335.0000384a@yahoo.com> |
| In reply to | #381606 |
On Fri, 2 Feb 2024 15:49:20 +0100 David Brown <david.brown@hesbynett.no> wrote: > On 02/02/2024 14:28, Michael S wrote: > > On Fri, 2 Feb 2024 09:02:15 +0100 > > David Brown <david.brown@hesbynett.no> wrote: > >> > >> But don't hold your breath waiting for something that will replace > >> make, or attract users of any other build system. > >> > >> > > > > It seems, you already forgot the context of my post that started > > this short sub-thread. > > > > That is absolutely possible. It was not intentional, but the number > of posts in recent times has been overwhelming. I apologise if I > have misinterpreted what you wrote. > > > BTW, I would imagine that Stu Feldman, if he is still in good > > health, would fine talking with Bart more entertaining that talking > > with you. > > I have no idea who that is, so I'll take your word for it. > Inventor of make > > I think, you, English speakers, call it birds of feather. > > >
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2024-02-02 16:29 +0000 |
| Subject | Stu Feldman (Was: Experimental C Build System) |
| Message-ID | <upj590$qsat$1@news.xmission.com> |
| In reply to | #381607 |
In article <20240202165335.0000384a@yahoo.com>, Michael S <already5chosen@yahoo.com> wrote: ... >> I have no idea who that is, so I'll take your word for it. >> > >Inventor of make At Bell Labs, in 1976. Currently, like quite a few ex-Bell Labs people, a big wheel at Google. -- Marshall: 10/22/51 Jessica: 4/4/79
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-02-02 17:29 +0000 |
| Subject | Re: Stu Feldman (Was: Experimental C Build System) |
| Message-ID | <20240202092850.835@kylheku.com> |
| In reply to | #381618 |
On 2024-02-02, Kenny McCormack <gazelle@shell.xmission.com> wrote: > In article <20240202165335.0000384a@yahoo.com>, > Michael S <already5chosen@yahoo.com> wrote: > ... >>> I have no idea who that is, so I'll take your word for it. >>> >> >>Inventor of make > > At Bell Labs, in 1976. > > Currently, like quite a few ex-Bell Labs people, a big wheel at Google. It's like a cargo cult. If we hire old Unix geezers and prop them up in chairs, be they dead or alive, magic will happen. -- 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 | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-02-04 05:44 +0100 |
| Subject | Re: Stu Feldman (Was: Experimental C Build System) |
| Message-ID | <upn4mn$3h7rh$1@dont-email.me> |
| In reply to | #381622 |
On 02.02.2024 18:29, Kaz Kylheku wrote: > On 2024-02-02, Kenny McCormack <gazelle@shell.xmission.com> wrote: >> In article <20240202165335.0000384a@yahoo.com>, >> Michael S <already5chosen@yahoo.com> wrote: >> ... >>>> I have no idea who that is, so I'll take your word for it. >>>> >>> >>> Inventor of make >> >> At Bell Labs, in 1976. >> >> Currently, like quite a few ex-Bell Labs people, a big wheel at Google. Also fired from AT&T/Bell Labs like the/some other Unix pioneers? > > It's like a cargo cult. If we hire old Unix geezers and prop them up in > chairs, be they dead or alive, magic will happen. Certainly no magic. But I'd also not disdain their experience. It has its price, and management typically considers that most. Google might have more money to afford the expenses. Janis
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-02-02 13:47 +0000 |
| Message-ID | <upirpd$2kdoe$1@dont-email.me> |
| In reply to | #381580 |
On 02/02/2024 08:02, David Brown wrote: > On 01/02/2024 23:55, Michael S wrote: >> On Thu, 1 Feb 2024 22:38:13 +0100 >> David Brown <david.brown@hesbynett.no> wrote: >> >>> On 01/02/2024 21:23, Michael S wrote: >>>> On Thu, 1 Feb 2024 18:34:08 +0000 >>> > >>>> >>>> You proposal and needs of David Brown are not necessarily >>>> contradictory. >>>> All you need to do to satisfy him is to add to your compiler an >>>> option for export of dependencies in make-compatible format, i.e. >>>> something very similar to -MD option of gcc. >>>> >>>> Then David could write in his makefile: >>>> >>>> out/foo.elf : main_foo.c >>>> mcc -MD $< -o $@ >>>> >>>> -include out/foo.d >>>> >>>> And then to proceed with automatiion of his pre and post-processing >>>> needs. >>> >>> But then I'd still be using "make", and Bart would not be happy. >>> >>> And "gcc -MD" does not need any extra #pragmas, so presumably neither >>> would an implementation of that feature in bcc (or mcc or whatever). >>> So Bart's new system would disappear entirely. >>> >>> >>> >> >> Bart spares you from managing list(s) of objects in your makefile and >> from writing arcan helper macros. >> Yes, I know, you copy&past arcan macros from project to project, but >> you had to write them n years ago and that surely was not easy. >> > > Google "makefile automatic dependencies", then adapt to suit your own > needs. Re-use the same makefile time and again. > > Yes, some of the functions I have in my makefiles are a bit hairy, and > some of the command line options for gcc are a bit complicated. They > are done now. > > If there had been an easier way than this, which still let me do what I > need (Bart's system does not), which is popular enough that you can > easily google for examples, blogs, and tutorials, then I'd have been > happy to use that at the time. I won't change to something else unless > it gives me significant additional benefits. > > People smarter and more experienced than Bart have been trying to invent > better replacements for "make" for many decades. None have succeeded. > Some build systems are better in some ways, but nothing has come close > to covering the wide range of features and uses of make, or gaining hold > outside a particular niche. Everyone who has ever made serious use of > "make" knows it has many flaws, unnecessarily complications, limitations > and inefficiencies. Despite that, it is the best we have. > > With Bart's limited knowledge and experience, That's true: only 47 years in computing, and 42 years of evolving, implementing and running my systems language. What can I possibly know about compiling sources files of a lower-level language into binaries? How many assemblers, compilers, linkers, and interpreters have /you/ written? > and deeply ingrained > prejudices and misunderstandings, the best we can hope for is something > that works well enough for some simple cases of C programs. With the proposal outlined in my OP, any of MY C programs, if I was to write or port multi-module projects in that language, could be trivially built by giving only the name of the compiler, and the name of one module. > More > realistically, it will work for Bart's use alone. It certainly won't for your stuff, or SL's, or JP's, or TR's, as you all seem to delight in wheeling out the most complex scenarios you can find. That is another aspect you might do well to learn how to do: KISS. (Yes I can be a patronising fuck too.) > And that, of course, is absolutely fine. No one is paying Bart to write > a generic build system, or something of use to anyone else. He is free > to write exactly what he wants, in the way he wants, and if ends up with > a tool that he finds useful himself, that is great. If he ends up with > something that at least some other people find useful, that is even > better, and I wish him luck with his work. > > But don't hold your breath waiting for something that will replace make, > or attract users of any other build system. Jesus. And you seem to determined to ignore everything I write, or have a short memory. I'm not suggesting replacing make, only to reduce its involvement. Twice I posted a list of 3 things that make takes care of; I'm looking at replacing just 1 of those things, the I which for me is more critical.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-02 15:57 +0100 |
| Message-ID | <upivso$2ku97$3@dont-email.me> |
| In reply to | #381601 |
On 02/02/2024 14:47, bart wrote: > On 02/02/2024 08:02, David Brown wrote: >> On 01/02/2024 23:55, Michael S wrote: >>> On Thu, 1 Feb 2024 22:38:13 +0100 >>> David Brown <david.brown@hesbynett.no> wrote: >>> >>>> On 01/02/2024 21:23, Michael S wrote: >>>>> On Thu, 1 Feb 2024 18:34:08 +0000 >>>> >> >>>>> >>>>> You proposal and needs of David Brown are not necessarily >>>>> contradictory. >>>>> All you need to do to satisfy him is to add to your compiler an >>>>> option for export of dependencies in make-compatible format, i.e. >>>>> something very similar to -MD option of gcc. >>>>> >>>>> Then David could write in his makefile: >>>>> >>>>> out/foo.elf : main_foo.c >>>>> mcc -MD $< -o $@ >>>>> >>>>> -include out/foo.d >>>>> >>>>> And then to proceed with automatiion of his pre and post-processing >>>>> needs. >>>> >>>> But then I'd still be using "make", and Bart would not be happy. >>>> >>>> And "gcc -MD" does not need any extra #pragmas, so presumably neither >>>> would an implementation of that feature in bcc (or mcc or whatever). >>>> So Bart's new system would disappear entirely. >>>> >>>> >>>> >>> >>> Bart spares you from managing list(s) of objects in your makefile and >>> from writing arcan helper macros. >>> Yes, I know, you copy&past arcan macros from project to project, but >>> you had to write them n years ago and that surely was not easy. >>> >> >> Google "makefile automatic dependencies", then adapt to suit your own >> needs. Re-use the same makefile time and again. >> >> Yes, some of the functions I have in my makefiles are a bit hairy, and >> some of the command line options for gcc are a bit complicated. They >> are done now. >> >> If there had been an easier way than this, which still let me do what >> I need (Bart's system does not), which is popular enough that you can >> easily google for examples, blogs, and tutorials, then I'd have been >> happy to use that at the time. I won't change to something else >> unless it gives me significant additional benefits. >> >> People smarter and more experienced than Bart have been trying to >> invent better replacements for "make" for many decades. None have >> succeeded. Some build systems are better in some ways, but nothing has >> come close to covering the wide range of features and uses of make, or >> gaining hold outside a particular niche. Everyone who has ever made >> serious use of "make" knows it has many flaws, unnecessarily >> complications, limitations and inefficiencies. Despite that, it is >> the best we have. >> >> With Bart's limited knowledge and experience, > > That's true: only 47 years in computing, and 42 years of evolving, > implementing and running my systems language. Yes. Most of it using your languages, your tools, your programs, and determinedly refusing to learn or use anything else more than the barest minimum, and so completely convinced of your own superiority and the failings of everyone else and all other languages and software that you are unable to learn things properly or consider anything from a viewpoint other than your own. You have experience - but it is limited by the walls you put up around yourself. > > What can I possibly know about compiling sources files of a lower-level > language into binaries? You know how /you/ do it, and how /you/ want to do it. You know sod all about anyone else. > > That is another aspect you might do well to learn how to do: KISS. (Yes > I can be a patronising fuck too.) > KISS is great. It's what encourages people to use existing standard tools like "make" and "C", instead of trying to re-invent their own personal wheels all the time. /Sometimes/ it is useful to re-invent something from scratch. Most of the time, it is not. > >> And that, of course, is absolutely fine. No one is paying Bart to >> write a generic build system, or something of use to anyone else. He >> is free to write exactly what he wants, in the way he wants, and if >> ends up with a tool that he finds useful himself, that is great. If >> he ends up with something that at least some other people find useful, >> that is even better, and I wish him luck with his work. >> >> But don't hold your breath waiting for something that will replace >> make, or attract users of any other build system. > > Jesus. And you seem to determined to ignore everything I write, or have > a short memory. > > I'm not suggesting replacing make, only to reduce its involvement. I didn't say you were trying to replace make, or even thought you were. I said you were not replacing make. There's a difference. > > Twice I posted a list of 3 things that make takes care of; I'm looking > at replacing just 1 of those things, the I which for me is more critical. > And I have repeatedly said that if you are making a tool that is useful for you, then great - make your tool and use it.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-02-02 15:18 +0000 |
| Message-ID | <TI7vN.377812$p%Mb.157491@fx15.iad> |
| In reply to | #381601 |
bart <bc@freeuk.com> writes: >On 02/02/2024 08:02, David Brown wrote: >> With Bart's limited knowledge and experience, > >That's true: only 47 years in computing, and 42 years of evolving, >implementing and running my systems language. It's pretty clear that you have very limited knowledge and experience with unix, make and and pretty much anything that isn't your soi disant compiler. > >What can I possibly know about compiling sources files of a lower-level >language into binaries? Very little, it appears, outside of your toy projects. > >How many assemblers, compilers, linkers, and interpreters have /you/ >written? Can't speak for David, but in my case, at least one of each, and you can add operating systems and hypervisors to that list. >It certainly won't for your stuff, or SL's, or JP's, or TR's, as you >all seem to delight in wheeling out the most complex scenarios you can find. The "stuff" I write is for customers. Any so-called-bart-complexity is based on customer requirements. The customers are quite happy with the solutions they get. > >That is another aspect you might do well to learn how to do: KISS. (Yes >I can be a patronising fuck too.) KISS is a good principle to follow, and while I cannot again speak for David, it's a principle followed by most programmers I've worked with. That doesn't mean throwing away perfectly usable tools (one can easily make KISS-compliant makefiles, for example). >I'm not suggesting replacing make, only to reduce its involvement. And to reduce it's involvement, something must replace make. ipso facto.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-02-02 17:44 +0000 |
| Message-ID | <upj9lq$2mrl8$1@dont-email.me> |
| In reply to | #381609 |
On 02/02/2024 15:18, Scott Lurndal wrote: > bart <bc@freeuk.com> writes: >> On 02/02/2024 08:02, David Brown wrote: > >>> With Bart's limited knowledge and experience, >> >> That's true: only 47 years in computing, and 42 years of evolving, >> implementing and running my systems language. > > It's pretty clear that you have very limited knowledge > and experience with unix, make and and pretty much > anything that isn't your soi disant compiler. Yes. And? > >> >> What can I possibly know about compiling sources files of a lower-level >> language into binaries? > > Very little, it appears, outside of your toy projects. That's right, I only have experience of the stuff I've done. And? Most stuff I want to build is on a similar scale, so you'd probably consider all that as toys too. You're saying that anyone not using Unix, not building 10Mloc projects, and not a fan of make, should FOAD? > >> >> How many assemblers, compilers, linkers, and interpreters have /you/ >> written? OK. How do I know these aren't just toys, or is it only you who is allowed to judge? BTW what exactly is a toy project? > Can't speak for David, but in my case, at least one of each, and > you can add operating systems and hypervisors to that list. I don't do OSes. If I did, you probably have a good idea of what mine would look like! >> It certainly won't for your stuff, or SL's, or JP's, or TR's, as you >> all seem to delight in wheeling out the most complex scenarios you can find. > > The "stuff" I write is for customers. Any so-called-bart-complexity is based on > customer requirements. The customers are quite happy with the solutions > they get. > >> >> That is another aspect you might do well to learn how to do: KISS. (Yes >> I can be a patronising fuck too.) > > KISS is a good principle to follow, and while I cannot again speak > for David, it's a principle followed by most programmers I've worked > with. That doesn't mean throwing away perfectly usable tools > (one can easily make KISS-compliant makefiles, for example). > > >> I'm not suggesting replacing make, only to reduce its involvement. > > And to reduce it's involvement, something must replace make. ipso facto. No. I'm saying make should be less involved in specifying which files to be submitted to a compiler-toolchain. Especially for a makefile specifying a production or distribution build, such as one done at a remote site by someone is not the developer, but just wants a working binary.
[toc] | [prev] | [next] | [standalone]
Page 2 of 21 — ← Prev page 1 [2] 3 4 … 21 Next page →
Back to top | Article view | comp.lang.c
csiph-web