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 1 of 21 [1] 2 3 … 21 Next page →
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-01-29 16:03 +0000 |
| Subject | Experimental C Build System |
| Message-ID | <up8i91$h6iu$1@dont-email.me> |
By 'Build System', I mean a convenient or automatic way to tell a
compiler which source and library files comprise a project, one that
doesn't involve extra dependencies.
This proposal comes under 'convenient' rather than 'automatic'. (I did
try an automatic scheme in the past, but that only worked for specially
written projects.)
Here, the method is straightforward: the necessary info is simply listed
in the designated lead module, within a set of #pragma lines.
For my go-to small project demo, which comprises the three source files
cipher.c, hmac.c, sha2.c, there are two ways to do it:
(1) Add the info to top of the lead module cipher.c:
#pragma module "hmac.c"
#pragma module "sha2.c"
....
I wasn't intending to actually implement it, but it didn't take long,
and it seems to work:
c:\cx>mcc cipher
Compiling cipher.c to cipher.exe
Adding module hmac.c
Adding module sha2.c
(2) Create an extra lead module and add it to the project.
This allows the scheme to be superimposed on an existing codebase
without having to modify it. If I try that on the above cipher project
in a new module demo.c, it will contain:
#pragma module "cipher.c"
#pragma module "hmac.c"
#pragma module "sha2.c"
It works like this (in the real version those "Adding" lines will be
silent):
c:\cx>mcc demo
Compiling demo.c to demo.exe
Adding module cipher.c
Adding module hmac.c
Adding module sha2.c
To get the original cipher.exe output needs an override option, but see
below.
Method (2) is attractive as it provides a means to easily set up
different configurations of an applications, but mix-and-matching modules.
Pragma Directives
-----------------
These are the ones I had in mind:
module "file.c" As used above. Possibly, wildcards can work here
import "file.c Incorporate a separate project which has its own
set of pragma directives
link "file.dll" Any binary libraries
header "file.h" Specify a program-wide shared header
Possibly the 'import' one can be dispensed with; it is simple enough to
manually copy and past the necessary info. However that means it is
listed in more than one place, and the original can change.
The idea of 'header' is to specify big headers (windows.h, sdl2.h, etc)
which are independent of anything else, which are then processed just
once in the compiler, rather than once for each module that includes
them. The usual '#include's are still needed.
(The intention is not to create a whole-program compiler, or to
introduce a module scheme, although this provides some of the benefits.
The C language is unchanged.)
Possibly, there can be a directive called 'name' to specify an
executable file name.
Working with Other Compilers
----------------------------
Clearly, my scheme will only work with a suitable modified compiler.
Without that, then I considered doing something like this, adding this
block to my example from (2):
#pragma module "cipher.c"
#pragma module "hmac.c"
#pragma module "sha2.c"
#ifndef __MCC__
#include "runcc.c"
int main(void) {
runcc(__FILE__);
}
#endif
When run a compiler that is not MCC, this builds a small program (here
still called demo.exe), which calls a function to read from this file,
process the relevant #pragma lines, and use that info to invoke a
conventional compiler.
I haven't tested it, but it would mean a two-step process that looks
something like this (possibly, it can pick up the name of the compiler
that /is/ used, and invoke that on the actual program):
c:\cx\tcc demo.c
c:\cx\demo
... invoke tcc to build cipher.c hmac.c sha2.c ...
(Tcc of course also has the -run option to save that second line)
For this to work, the pragma stuff must be cleanly written: the runcc()
function will only do basic string processing, it is not a C compiler.
Using a Makefile
----------------
One use-case for this would be if /I/ supplied a multi-module C program,
or packaged someone else's.
But people are mad about makefiles so, sure, I can also supply a 2-line
makefile to do the above.
Dependencies and Incremental Compilation
----------------------------------------
This project is not about that, and is for cases where compiling all
sources in one go is viable, or where a one-off build time is not relevant.
That can mean when using fast a compiler and/or the scale of the project
allows.
Although the 'header' directive will also help, in cases where the
application itself is small, but has dependencies on large complex
headers. (I haven't quite figured out how it might work though.)
[toc] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-01-30 00:57 +0000 |
| Message-ID | <up9hh3$m75n$3@dont-email.me> |
| In reply to | #381174 |
On Mon, 29 Jan 2024 16:03:45 +0000, bart wrote: > By 'Build System', I mean a convenient or automatic way to tell a > compiler which source and library files comprise a project, one that > doesn't involve extra dependencies. If it only works for C code, then that is going to limit its usefulness in today’s multilingual world.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-01-29 17:38 -0800 |
| Message-ID | <up9jvh$mjpg$1@dont-email.me> |
| In reply to | #381208 |
On 1/29/2024 4:57 PM, Lawrence D'Oliveiro wrote: > On Mon, 29 Jan 2024 16:03:45 +0000, bart wrote: > >> By 'Build System', I mean a convenient or automatic way to tell a >> compiler which source and library files comprise a project, one that >> doesn't involve extra dependencies. > > If it only works for C code, then that is going to limit its usefulness in > today’s multilingual world. Huh?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-30 09:06 +0100 |
| Message-ID | <upaamj$teb5$1@dont-email.me> |
| In reply to | #381215 |
On 30/01/2024 02:38, Chris M. Thomasson wrote: > On 1/29/2024 4:57 PM, Lawrence D'Oliveiro wrote: >> On Mon, 29 Jan 2024 16:03:45 +0000, bart wrote: >> >>> By 'Build System', I mean a convenient or automatic way to tell a >>> compiler which source and library files comprise a project, one that >>> doesn't involve extra dependencies. >> >> If it only works for C code, then that is going to limit its >> usefulness in >> today’s multilingual world. > > Huh? I assume he means it's common to use multiple programming languages, rather than multiple human languages. (The later may also be true, but it's the former that is relevant.) For my own use at least, he's right. His system is aimed at being simpler than make for C-only projects with limited and straightforward build requirements. That's fine for such projects, and if that suits his needs or the needs of others, great. But it would not cover more than a tiny proportion of my projects over the decades - at least not without extra help (extra commands, bash/bat files, etc.)
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-01-30 15:23 -0800 |
| Message-ID | <upc0db$16gik$2@dont-email.me> |
| In reply to | #381228 |
On 1/30/2024 12:06 AM, David Brown wrote: > On 30/01/2024 02:38, Chris M. Thomasson wrote: >> On 1/29/2024 4:57 PM, Lawrence D'Oliveiro wrote: >>> On Mon, 29 Jan 2024 16:03:45 +0000, bart wrote: >>> >>>> By 'Build System', I mean a convenient or automatic way to tell a >>>> compiler which source and library files comprise a project, one that >>>> doesn't involve extra dependencies. >>> >>> If it only works for C code, then that is going to limit its >>> usefulness in >>> today’s multilingual world. >> >> Huh? > > I assume he means it's common to use multiple programming languages, > rather than multiple human languages. (The later may also be true, but > it's the former that is relevant.) > > For my own use at least, he's right. His system is aimed at being > simpler than make for C-only projects with limited and straightforward > build requirements. When you say his, you mean, Bart's system, right? > That's fine for such projects, and if that suits > his needs or the needs of others, great. But it would not cover more > than a tiny proportion of my projects over the decades - at least not > without extra help (extra commands, bash/bat files, etc.) >
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-31 08:36 +0100 |
| Message-ID | <upcta5$1e58u$1@dont-email.me> |
| In reply to | #381294 |
On 31/01/2024 00:23, Chris M. Thomasson wrote: > On 1/30/2024 12:06 AM, David Brown wrote: >> On 30/01/2024 02:38, Chris M. Thomasson wrote: >>> On 1/29/2024 4:57 PM, Lawrence D'Oliveiro wrote: >>>> On Mon, 29 Jan 2024 16:03:45 +0000, bart wrote: >>>> >>>>> By 'Build System', I mean a convenient or automatic way to tell a >>>>> compiler which source and library files comprise a project, one that >>>>> doesn't involve extra dependencies. >>>> >>>> If it only works for C code, then that is going to limit its >>>> usefulness in >>>> today’s multilingual world. >>> >>> Huh? >> >> I assume he means it's common to use multiple programming languages, >> rather than multiple human languages. (The later may also be true, >> but it's the former that is relevant.) >> >> For my own use at least, he's right. His system is aimed at being >> simpler than make for C-only projects with limited and straightforward >> build requirements. > > When you say his, you mean, Bart's system, right? > Yes. > >> That's fine for such projects, and if that suits his needs or the >> needs of others, great. But it would not cover more than a tiny >> proportion of my projects over the decades - at least not without >> extra help (extra commands, bash/bat files, etc.) >> >
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-01-31 19:12 -0800 |
| Message-ID | <upf268$1tea9$1@dont-email.me> |
| In reply to | #381313 |
On 1/30/2024 11:36 PM, David Brown wrote: > On 31/01/2024 00:23, Chris M. Thomasson wrote: >> On 1/30/2024 12:06 AM, David Brown wrote: >>> On 30/01/2024 02:38, Chris M. Thomasson wrote: >>>> On 1/29/2024 4:57 PM, Lawrence D'Oliveiro wrote: >>>>> On Mon, 29 Jan 2024 16:03:45 +0000, bart wrote: >>>>> >>>>>> By 'Build System', I mean a convenient or automatic way to tell a >>>>>> compiler which source and library files comprise a project, one that >>>>>> doesn't involve extra dependencies. >>>>> >>>>> If it only works for C code, then that is going to limit its >>>>> usefulness in >>>>> today’s multilingual world. >>>> >>>> Huh? >>> >>> I assume he means it's common to use multiple programming languages, >>> rather than multiple human languages. (The later may also be true, >>> but it's the former that is relevant.) >>> >>> For my own use at least, he's right. His system is aimed at being >>> simpler than make for C-only projects with limited and >>> straightforward build requirements. >> >> When you say his, you mean, Bart's system, right? >> > > Yes. [...] Ahhh, thanks David.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-01-31 00:44 +0000 |
| Message-ID | <upc56a$178be$1@dont-email.me> |
| In reply to | #381228 |
On 30/01/2024 08:06, David Brown wrote:
> On 30/01/2024 02:38, Chris M. Thomasson wrote:
>> On 1/29/2024 4:57 PM, Lawrence D'Oliveiro wrote:
>>> On Mon, 29 Jan 2024 16:03:45 +0000, bart wrote:
>>>
>>>> By 'Build System', I mean a convenient or automatic way to tell a
>>>> compiler which source and library files comprise a project, one that
>>>> doesn't involve extra dependencies.
>>>
>>> If it only works for C code, then that is going to limit its
>>> usefulness in
>>> today’s multilingual world.
>>
>> Huh?
>
> I assume he means it's common to use multiple programming languages,
> rather than multiple human languages. (The later may also be true, but
> it's the former that is relevant.)
>
> For my own use at least, he's right. His system is aimed at being
> simpler than make for C-only projects with limited and straightforward
> build requirements. That's fine for such projects, and if that suits
> his needs or the needs of others, great. But it would not cover more
> than a tiny proportion of my projects over the decades - at least not
> without extra help (extra commands, bash/bat files, etc.)
It would cover most open source C projects that I have tried to build.
All the following examples came down to a list of C files to be
submitted to a compiler:
Lua
Seed7* (a version from 5 years ago)
Tcc*
PicoC
LibJPEG*
'BBX' (Malcolm's resource compiler)
A68G (An older version; current one is Linux-only)
The ones marked * I believe required some process first to synthesised
some essential header, eg. config.h, often only a few lines long. But
once out of the way, then yes it was just N C files to plough through.
Tcc also had other things going on (once tcc.exe was built, it was used
to prepare some libraries).
LibJPEG had more than one executable, which shared a lot of common
modules. The makefile put those into one .a file, which was then
included in all programs. But since it was statically linked, it did not
save space.
Once I knew what was going on, I just put the common modules in the list
for each program. Or /I/ could choose to put those into a shared library.
It's a question of extracting the easy parts of a project. Once I know
that, I can work my way around anything else and devise my own solutions.
--------------------
In terms of my own real applications, they involved compiled modules;
interpreted modules (that needed compiling to bytecode); processing
source files to derive/update message files for internationalisation;
packaging the numerous files into tidy containers; uploading to
distribution disks, or via FTP; scripts to generate the new index.html
for downloads...
I understand all that part of it. The necessary scripting is utterly
trivial. The above was a process to go through for each release. It
wasn't time-critical, and there were no dependencies to deal with. It
wasn't makefile territory.
The build system described in my OP is that needed to build one binary
file in one language, which is 95% of what I had trouble with in that
list above, /because/ the supplied build process revolved around
makefiles and configure scripts.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-01-30 01:45 +0000 |
| Message-ID | <up9kc7$mkt1$2@dont-email.me> |
| In reply to | #381208 |
On 30/01/2024 00:57, Lawrence D'Oliveiro wrote:
> On Mon, 29 Jan 2024 16:03:45 +0000, bart wrote:
>
>> By 'Build System', I mean a convenient or automatic way to tell a
>> compiler which source and library files comprise a project, one that
>> doesn't involve extra dependencies.
>
> If it only works for C code, then that is going to limit its usefulness in
> today’s multilingual world.
Languages these days tend to have module schemes and built-in means of
compiling assemblies of modules.
C doesn't.
The proposal would allow a project to be built using:
cc file.c
instead of cc file.c file2.c .... lib1.dll lib2.dll ...,
or instead of having to provide a makefile or an @ filelist.
That is significant advance on what C compilers typically do.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-01-30 04:46 +0000 |
| Message-ID | <up9uuj$rmmf$2@dont-email.me> |
| In reply to | #381217 |
On 30/01/2024 01:45, bart wrote: > On 30/01/2024 00:57, Lawrence D'Oliveiro wrote: >> On Mon, 29 Jan 2024 16:03:45 +0000, bart wrote: >> >>> By 'Build System', I mean a convenient or automatic way to tell a >>> compiler which source and library files comprise a project, one that >>> doesn't involve extra dependencies. >> >> If it only works for C code, then that is going to limit its >> usefulness in >> today’s multilingual world. > > Languages these days tend to have module schemes and built-in means of > compiling assemblies of modules. > > C doesn't. > > The proposal would allow a project to be built using: > > cc file.c > > instead of cc file.c file2.c .... lib1.dll lib2.dll ..., > > or instead of having to provide a makefile or an @ filelist. > > That is significant advance on what C compilers typically do. > There's a desperate need for hierarchy. A library like ChatGTP only needs to expose one function, "answer_question". Maybe a few extra to give context. But of course that one function calls masses and masses of subroutines. Which should be private to the module, but not to the source file for the "answer_question" function. -- 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-01-30 11:52 +0000 |
| Message-ID | <upanta$vkgm$1@dont-email.me> |
| In reply to | #381220 |
On 30/01/2024 04:46, Malcolm McLean wrote:
> On 30/01/2024 01:45, bart wrote:
>> On 30/01/2024 00:57, Lawrence D'Oliveiro wrote:
>>> On Mon, 29 Jan 2024 16:03:45 +0000, bart wrote:
>>>
>>>> By 'Build System', I mean a convenient or automatic way to tell a
>>>> compiler which source and library files comprise a project, one that
>>>> doesn't involve extra dependencies.
>>>
>>> If it only works for C code, then that is going to limit its
>>> usefulness in
>>> today’s multilingual world.
>>
>> Languages these days tend to have module schemes and built-in means of
>> compiling assemblies of modules.
>>
>> C doesn't.
>>
>> The proposal would allow a project to be built using:
>>
>> cc file.c
>>
>> instead of cc file.c file2.c .... lib1.dll lib2.dll ...,
>>
>> or instead of having to provide a makefile or an @ filelist.
>>
>> That is significant advance on what C compilers typically do.
> >
> There's a desperate need for hierarchy.
> A library like ChatGTP only needs to expose one function,
> "answer_question". Maybe a few extra to give context. But of course that
> one function calls masses and masses of subroutines. Which should be
> private to the module, but not to the source file for the
> "answer_question" function.
I'm not sure what that has to do with my proposal (which is not to add a
module scheme as I said).
I've now added wildcards to my test implementation. If I go to your
resource compiler project (which I call 'BBX') and add one small C file
called bbx.c containing:
#pragma module "*.c"
#pragma module "freetype/*.c"
#pragma module "samplerate/*.c"
then I can build it like this:
c:\bbx\src>mcc bbx
Compiling bbx.c to bbx.exe
The file provides also the name of the executable:
c:\bbx\src>bbx
The Baby X resource compiler v1.1
by Malcolm Mclean
....
Without this feature, building wasn't exactly onerous; I used an @ file
called 'bbx' which contained:
*.c freetype/*.c samplerate/*.c
and built using:
c:\bbx\src>mcc @bbx -out:bbx
Compiling 44 files to bbx.exe
But this requires an extra, non-C file (effectively a script), and a
special invocation (the @). The EXE name can be put in there was well,
but the option for that depends on compiler. (gcc can''t use this @ file
as it contains wildcards.)
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-01-30 16:50 +0000 |
| Message-ID | <upb9ca$12je5$1@dont-email.me> |
| In reply to | #381237 |
On 30/01/2024 11:52, bart wrote: > On 30/01/2024 04:46, Malcolm McLean wrote: >> On 30/01/2024 01:45, bart wrote: >>> On 30/01/2024 00:57, Lawrence D'Oliveiro wrote: >>>> On Mon, 29 Jan 2024 16:03:45 +0000, bart wrote: >>>> >>>>> By 'Build System', I mean a convenient or automatic way to tell a >>>>> compiler which source and library files comprise a project, one that >>>>> doesn't involve extra dependencies. >>>> >>>> If it only works for C code, then that is going to limit its >>>> usefulness in >>>> today’s multilingual world. >>> >>> Languages these days tend to have module schemes and built-in means >>> of compiling assemblies of modules. >>> >>> C doesn't. >>> >>> The proposal would allow a project to be built using: >>> >>> cc file.c >>> >>> instead of cc file.c file2.c .... lib1.dll lib2.dll ..., >>> >>> or instead of having to provide a makefile or an @ filelist. >>> >>> That is significant advance on what C compilers typically do. >> > >> There's a desperate need for hierarchy. >> A library like ChatGTP only needs to expose one function, >> "answer_question". Maybe a few extra to give context. But of course >> that one function calls masses and masses of subroutines. Which should >> be private to the module, but not to the source file for the >> "answer_question" function. > > > I'm not sure what that has to do with my proposal (which is not to add a > module scheme as I said). > Oh you are not adding modules > I've now added wildcards to my test implementation. If I go to your > resource compiler project (which I call 'BBX') and add one small C file > called bbx.c containing: > > #pragma module "*.c" > #pragma module "freetype/*.c" > #pragma module "samplerate/*.c" > > then I can build it like this: > > c:\bbx\src>mcc bbx > Compiling bbx.c to bbx.exe > > The file provides also the name of the executable: > > c:\bbx\src>bbx > The Baby X resource compiler v1.1 > by Malcolm Mclean > .... > > Without this feature, building wasn't exactly onerous; I used an @ file > called 'bbx' which contained: > > *.c freetype/*.c samplerate/*.c > > and built using: > > c:\bbx\src>mcc @bbx -out:bbx > Compiling 44 files to bbx.exe > > But this requires an extra, non-C file (effectively a script), and a > special invocation (the @). The EXE name can be put in there was well, > but the option for that depends on compiler. (gcc can''t use this @ file > as it contains wildcards.) > So essentially we have path listing and description language. Which ironically is what the resource compiler basically does. You put a list of paths into an XML file, and it uses that to find the resources, and merge them together on standard output (as text, of course :-) ). You're doing the same, except that of course you have to compile and link rather than decode and lightly pre-process. But I'm wondering about one file which contains all the sources for the program. Like an IDE project file but lighter weight. -- 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-01-30 17:57 +0000 |
| Message-ID | <upbda8$139gn$1@dont-email.me> |
| In reply to | #381257 |
On 30/01/2024 16:50, Malcolm McLean wrote: > On 30/01/2024 11:52, bart wrote: >> On 30/01/2024 04:46, Malcolm McLean wrote: >>> There's a desperate need for hierarchy. >>> A library like ChatGTP only needs to expose one function, >>> "answer_question". Maybe a few extra to give context. But of course >>> that one function calls masses and masses of subroutines. Which >>> should be private to the module, but not to the source file for the >>> "answer_question" function. >> >> >> I'm not sure what that has to do with my proposal (which is not to add >> a module scheme as I said). >> > Oh you are not adding modules In my other language with modules, it specifically does not have a hierarchy of modules. It causes all sorts of problems, since it's hard to get away from cycles. And sometimes you just want to split one module M into modules A and B; there is no dominant one. But it also means it doesn't do anything clever to determine the set of modules comprising a project, starting from one module. Some languages traverse a tree of import statements. In mine, I don't have import statements at all littered across the program. There is just a shopping list of modules started at the start the lead module. That is the model I used for this C experiment. >> I've now added wildcards to my test implementation. If I go to your >> resource compiler project (which I call 'BBX') and add one small C >> file called bbx.c containing: >> >> #pragma module "*.c" >> #pragma module "freetype/*.c" >> #pragma module "samplerate/*.c" >> >> then I can build it like this: >> >> c:\bbx\src>mcc bbx >> Compiling bbx.c to bbx.exe > So essentially we have path listing and description language. > Which ironically is what the resource compiler basically does. You put a > list of paths into an XML file, and it uses that to find the resources, > and merge them together on standard output (as text, of course :-) ). > > You're doing the same, except that of course you have to compile and > link rather than decode and lightly pre-process. Yes, the requirement are very simple: it's a list of files! The same list is usually encoded cryptically inside a make file, or that you need to submit to CMake, or that you put inside an @ file, or submit to the compiler on one long command line, or in multiple invocations. Here it's tidily contained within the C source code. > But I'm wondering about one file which contains all the sources for the > program. Like an IDE project file but lighter weight. That occurred to me too. I gave an outline to invoke a special C module to scan those #pragma entries in cases where my compiler was not used. Such an approach could also be used to unpack a set of source files concatenated into one big source file. This is tidier than having a sprawling set of files perhaps split across directories. It means you can just supply one text file. But there are other ways that people do the same job of turning multi-module C into a single file.
[toc] | [prev] | [next] | [standalone]
| From | Richard Harnden <richard.nospam@gmail.invalid> |
|---|---|
| Date | 2024-01-30 19:22 +0000 |
| Message-ID | <upbi8o$14443$1@dont-email.me> |
| In reply to | #381257 |
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
[toc] | [prev] | [next] | [standalone]
| From | vallor <vallor@cultnix.org> |
|---|---|
| Date | 2024-01-31 16:41 +0000 |
| Message-ID | <updt7h$1jc8a$1@dont-email.me> |
| In reply to | #381271 |
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.
$ make -j # how does Bart's new build manager handle this case?
("-j" engages parallel compilation.)
ObC:
$ cat try.c
#include <stdlib.h>
int main(void) {
return(system("make -j 16"));
}
_ _ _ _ _ _ _
$ cat Makefile
CFLAGS=-g -O2 -std=c90 -pedantic
_ _ _ _ _ _ _
$ make try
cc -g -O2 -std=c90 -pedantic try.c -o try
$ ./try
make: 'try' is up to date.
--
-v
[toc] | [prev] | [next] | [standalone]
| From | vallor <vallor@cultnix.org> |
|---|---|
| Date | 2024-01-31 19:01 +0000 |
| Message-ID | <upe5dd$1jc8a$2@dont-email.me> |
| In reply to | #381375 |
On Wed, 31 Jan 2024 16:41:21 -0000 (UTC), vallor <vallor@cultnix.org>
wrote in <updt7h$1jc8a$1@dont-email.me>:
> 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.
>
> $ make -j # how does Bart's new build manager handle this case?
>
> ("-j" engages parallel compilation.)
>
> ObC:
> $ cat try.c
> #include <stdlib.h>
> int main(void) {
> return(system("make -j 16"));
> }
> _ _ _ _ _ _ _
>
> $ cat Makefile
> CFLAGS=-g -O2 -std=c90 -pedantic
> _ _ _ _ _ _ _
>
> $ make try
> cc -g -O2 -std=c90 -pedantic try.c -o try
>
> $ ./try
> make: 'try' is up to date.
I also had "try:" in my Makefile.
_ _ _ _ _ _ _
CFLAGS=-g -O2 -std=c90 -pedantic
try:
_ _ _ _ _ _ _
But I changed the source to make it
explicitely:
$ cat try.c
#include <stdlib.h>
int main(void) {
return(system("make -j 16 try"));
}
$ ./try
cc -g -O2 -std=c90 -pedantic try.c -o try
$ ./try
make: 'try' is up to date.
(Beats trying to learn COBOL to keep up with
comp.lang.c... ;)
--
-v
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-01-31 20:25 +0000 |
| Message-ID | <upeab3$1m2f4$1@dont-email.me> |
| In reply to | #381375 |
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.
> $ make -j # how does Bart's new build manager handle this case?
>
> ("-j" engages parallel compilation.)
>
> ObC:
> $ cat try.c
> #include <stdlib.h>
> int main(void) {
> return(system("make -j 16"));
> }
> _ _ _ _ _ _ _
>
> $ cat Makefile
> CFLAGS=-g -O2 -std=c90 -pedantic
> _ _ _ _ _ _ _
>
> $ make try
> cc -g -O2 -std=c90 -pedantic try.c -o try
>
> $ ./try
> make: 'try' is up to date.
>
This on the other hand looks EXACTLY like a solution looking a problem.
BTW that 'make' only works on my machine because it happens to be part
of mingw; none of my other C compilers have make.
And as written, it only works for 'cc' which comes with 'gcc'. If I use
CC to set another compiler, then the -o option is wrong for tcc. The
other options are not recognised with two other compilers.
Look at the follow-up to my OP that I will shortly post.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-01 09:39 +0100 |
| Message-ID | <upflbj$202rb$1@dont-email.me> |
| In reply to | #381403 |
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). Compiled languages don't usually have such a thing, because developers (as distinct from users) have build tools available that do a better job.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-02-01 11:31 +0000 |
| Message-ID | <upfve3$21uv7$1@dont-email.me> |
| In reply to | #381443 |
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. They don't provide 2 (compiling individual modules) because the aim is a very fast, whole-program compler. 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. 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. My view is that that tool only needs to be the compiler (a program that does the 'full stack' from source files to executable binary) working purely from the source code. Yours is to have compilers, assemblers, linkers and make programs, working with auxiliary data in makefiles, that itself have to be generated by extra tools or special options, or built by hand. I see that as old-fashioned and error-prone. Also complex and limited (eg. they will not support my compiler.) The experiment in my OP is intended to bring part of my module scheme to C. However, that will of course be poorly received. Why? Because when a language doesn't provide a certain feature (eg. module management), then people are free to do all sorts of wild and whacky things to achieve some result. Approaches that don't fit in to the disciplined requirements of a language-stipulated module scheme. A good example is the header-based module scheme of my BCC compiler; this required modules to be implemented as tidy .h/.c pairs of files. Of course, real C code is totally chaotic in its use of headers. In other words, you can're retro-fit a real module-scheme to C, not one that will work with existing code. But for all my projects and all the ones /I/ want to build, they do come down to just knowing what source files need to be submitted to the compiler. It really can be that simple. That CAN be trivially retro-fitted to existing projects.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-01 16:11 +0100 |
| Message-ID | <upgcbm$246u1$1@dont-email.me> |
| In reply to | #381448 |
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. > > 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.) > > My view is that that tool only needs to be the compiler (a program that > does the 'full stack' from source files to executable binary) working > purely from the source code. > > Yours is to have compilers, assemblers, linkers and make programs, > working with auxiliary data in makefiles, that itself have to be > generated by extra tools or special options, or built by hand. > You want a limited little built-in tool. I want a toolbox that I can use in all sorts of ways - for things you have never imagined. I can see how your personal tools can be useful for you, as a single developer on your own - if you want something else you can add it to those tools. For others, they are useless. 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. 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. > > In other words, you can're retro-fit a real module-scheme to C, not one > that will work with existing code. > We know that. Otherwise it would have happened, long ago.
[toc] | [prev] | [next] | [standalone]
Page 1 of 21 [1] 2 3 … 21 Next page →
Back to top | Article view | comp.lang.c
csiph-web