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 14 of 21 — ← Prev page 1 … 12 13 [14] 15 16 … 21 Next page →
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-02-04 07:52 -0800 |
| Message-ID | <86wmrk6xc9.fsf@linuxsc.com> |
| In reply to | #381713 |
Richard Damon <richard@damon-family.org> writes: > On 2/3/24 4:51 PM, Keith Thompson wrote: > >> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >> >>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >>> >>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes: >>>> >>>>> On Thu, 01 Feb 2024 19:03:38 -0800, Keith Thompson wrote: >>>>> >>>>>> A #include directive with <> searches for a "header", which is >>>>>> not stated to be a file. A #include directive with "" searches >>>>>> for a file in an implementation-defined manner; if that search >>>>>> fails, it tries again as if <> had been used. >>>>> >>>>> The trouble with that interpretation is, it would seem to rule >>>>> out the use of things like include libraries for user headers. >>>>> Do you really think that was the intention? >>>> >>>> I don't know. I imagine an implementation could interpret the >>>> word "file" to include information extracted from libraries. >>>> Note that it doesn't have to correspond to the concept of a >>>> "file" used in <stdio.h>; that refers to files in the execution >>>> environment, not the compilation environment. >>> >>> To me what the C standard says is clear. A #include "whatever.h" >>> gets its stuff from a file (assuming of course the appropriate >>> file can be found, and not revert to the #include <whatever.h> >>> form). A #include <whatever.h> gets its stuff from a header, >>> said header perhaps being stored in a file or perhaps not, and if >>> file-stored then it could be a 1-1 relationship, or a 1-many >>> relationship, or a many-1 relationship. Since the C standard >>> doesn't define the term 'header', an implementation is allowed to >>> actualize it however the implementation chooses (including the >>> possibility of storing information inside the compiler itself). >> >> On further thought, I tend to agree. >> >> I was thinking that an implementation could usefully provide some >> of its own headers as something other than files, as it's clearly >> allowed to do for the C standard headers. But the obvious way to >> do that would be to require such headers to be included with <>, >> not "". POSIX-specific headers like unistd.h are already >> conventionally included with <>. >> >> An implementation probably *could* bend the meaning of "file" >> enough to support having `#include "whatever.h"` load something >> other than a file in the host filesystem, but it's not as useful as >> I first thought it might be -- and it could interfere with >> user-provided header files that happen to have the same name. > > I beleive an implementation doesn't need to provide a way to provide > replacements for the standard defined headers. > > The include search method is fully implementation defined, Not exactly. The <> form of #include searches "a sequence of implementation-defined places" for a header, whereas the "" form of #include searches "in an implementation-defined manner" for "the named source file". The sequence of places (for headers) is fixed for each implementation, but where a "" form of #include searches (for a file) is not fixed but may vary from, for example, compilation to compilation. Of course there is nothing stopping an implementation from defining those two searches so that there is some overlap, but surely that possibility is not expected to be realized in any normal configuration (except perhaps by accident), either by the C standard's authors or by developers. > with only > the provision that if you use " " and don't find the file, it > needs to use the < > method, but that doesn't say that the > standard headers might not be first in the " " search order. The "" form of #include doesn't have a "search order", only a statement that a search is done "in an implementation-defined manner". Normally the set of places searched for "" files is not fixed, and typically can be changed by the developer using compilation options such as -I. > Als 7.1.2p4 says: > > If a file with the same name as one of the above < and > delimited > sequences, not provided as part of the implementation, is placed in > any of the standard places that are searched for included source > files, the behavior is undefined. > > So overridding a Standard defined header is explicitly Undefined > Behaivor. (Not sure if POSIX extends that to its headers). I believe this conclusion is a misreading. The C standard uses the word "places" only in connection with the <> form of #include, and not with the "" form of #include. There is nothing wrong with, for example, #include "stdio.h", and having a local stdio.h file (which may do a #include <stdio.h> internally). Indeed it appears that part of the point of the rule that the <> form is used if the "" form fails is so that a #include "stdio.h" may be used and simply fall back to the <stdio.h> header if the file stdio.h is not present. There is no undefined behavior for having a file named "stdio.h" (or any other standard header name), as long as such files are not in one of the fixed set of places defined by the implementation for where headers (as opposed to regular #include source files) might reside.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-02-04 06:18 -0800 |
| Message-ID | <861q9s8g9r.fsf@linuxsc.com> |
| In reply to | #381708 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >> >>> Lawrence D'Oliveiro <ldo@nz.invalid> writes: >>> >>>> On Thu, 01 Feb 2024 19:03:38 -0800, Keith Thompson wrote: >>>> >>>>> A #include directive with <> searches for a "header", which is >>>>> not stated to be a file. A #include directive with "" searches >>>>> for a file in an implementation-defined manner; if that search >>>>> fails, it tries again as if <> had been used. >>>> >>>> The trouble with that interpretation is, it would seem to rule >>>> out the use of things like include libraries for user headers. >>>> Do you really think that was the intention? >>> >>> I don't know. I imagine an implementation could interpret the >>> word "file" to include information extracted from libraries. Note >>> that it doesn't have to correspond to the concept of a "file" used >>> in <stdio.h>; that refers to files in the execution environment, >>> not the compilation environment. >> >> To me what the C standard says is clear. A #include "whatever.h" >> gets its stuff from a file (assuming of course the appropriate >> file can be found, and not revert to the #include <whatever.h> >> form). A #include <whatever.h> gets its stuff from a header, >> said header perhaps being stored in a file or perhaps not, and if >> file-stored then it could be a 1-1 relationship, or a 1-many >> relationship, or a many-1 relationship. Since the C standard >> doesn't define the term 'header', an implementation is allowed to >> actualize it however the implementation chooses (including the >> possibility of storing information inside the compiler itself). > > On further thought, I tend to agree. > > I was thinking that an implementation could usefully provide some of > its own headers as something other than files, as it's clearly > allowed to do for the C standard headers. But the obvious way to do > that would be to require such headers to be included with <>, not > "". POSIX-specific headers like unistd.h are already conventionally > included with <>. > > An implementation probably *could* bend the meaning of "file" enough > to support having `#include "whatever.h"` load something other than > a file in the host filesystem, but it's not as useful as I first > thought it might be -- and it could interfere with user-provided > header files that happen to have the same name. A correction of my earlier statement: actually the C standard does define the word header, via the convention of using italics, in the first sentence of section 7.1.2, paragraph 1 (and it is "defined" in a way that IMO is singularly useless as a definition). It seems clear that any implementation-provided "include units" are meant to be supplied as 'headers', so that they may be accessed by using a #include <name.h> form of inclusion. Similarly it seems clear that any compilation-specific or project-specific "include units" are meant to be supplied as files, so that they may be accessed by using a #include "foo.h" form of inclusion. I don't see any place in the C standard that expresses this distinction, but surely it is meant to reflect the normal use pattern. Also I don't see anything in the C standard that would preclude having system-wide (but not tied to the implementation) "include units" be available as headers, and so accessible using the <> form of inclusion. Third-party libraries are often made available in this way.
[toc] | [prev] | [next] | [standalone]
| From | tTh <tth@none.invalid> |
|---|---|
| Date | 2024-02-02 03:22 +0100 |
| Message-ID | <uphjlm$2rqp$1@news.gegeweb.eu> |
| In reply to | #381532 |
On 2/1/24 23:29, bart wrote:
> I do. You type:
>
> cc prog
>
> without knowing or caring whether the contains that one module, or there
> are 99 more.
>
I also do. You type:
make prog
without knowing or caring whether the contains that one module, or
there are 51 more.
--
+---------------------------------------------------------------------+
| https://tube.interhacker.space/a/tth/video-channels |
+---------------------------------------------------------------------+
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-02-02 11:13 +0000 |
| Message-ID | <upiio9$2itjs$1@dont-email.me> |
| In reply to | #381565 |
On 02/02/2024 02:22, tTh wrote:
> On 2/1/24 23:29, bart wrote:
>> I do. You type:
>>
>> cc prog
>>
>> without knowing or caring whether the contains that one module, or
>> there are 99 more.
>>
>
> I also do. You type:
>
> make prog
>
> without knowing or caring whether the contains that one module, or
> there are 51 more.
Really? OK, let's try it:
c:\c>make cipher
cc cipher.c -o cipher
C:\tdm\bin\ld.exe:
C:\Users\44775\AppData\Local\Temp\ccRvFIdY.o:cipher.c:(.text+0x55a):
undefined reference to `hmac_sha256_final'
It seems I do need to care after all!
Oh, you mean I don't need to care AFTER I've created a complicated
makefile containing all those details that you claim I don't need to
bother with?
Let's try with a real solution:
c:\c>mcc cipher
Compiling cipher.c to cipher.exe
Or here's one where I don't need to add anything to the C code:
c:\c>bcc -auto cipher
1 Compiling cipher.c to cipher.asm (Pass 1)
* 2 Compiling hmac.c to hmac.asm (Pass 2)
* 3 Compiling sha2.c to sha2.asm (Pass 2)
Assembling to cipher.exe
I'm the one who's trying innovative approaches to minimise the extra
gumph you need to provide to build programs.
You're the one who needs to first write a pile of garbage within a
makefile in order for you to do:
make prog
Below is the makefile needed to build lua 5.4, which is a project of
only 35 C modules. Simple, isn't it?
---------------------------------
# Makefile for building Lua
# See ../doc/readme.html for installation and customization instructions.
# == CHANGE THE SETTINGS BELOW TO SUIT YOUR ENVIRONMENT
=======================
# Your platform. See PLATS for possible values.
PLAT= guess
CC= gcc -std=gnu99
CFLAGS= -O2 -Wall -Wextra -DLUA_COMPAT_5_3 $(SYSCFLAGS) $(MYCFLAGS)
LDFLAGS= $(SYSLDFLAGS) $(MYLDFLAGS)
LIBS= -lm $(SYSLIBS) $(MYLIBS)
AR= ar rcu
RANLIB= ranlib
RM= rm -f
UNAME= uname
SYSCFLAGS=
SYSLDFLAGS=
SYSLIBS=
MYCFLAGS=
MYLDFLAGS=
MYLIBS=
MYOBJS=
# Special flags for compiler modules; -Os reduces code size.
CMCFLAGS=
# == END OF USER SETTINGS -- NO NEED TO CHANGE ANYTHING BELOW THIS LINE
=======
PLATS= guess aix bsd c89 freebsd generic ios linux linux-readline macosx
mingw posix solaris
LUA_A= liblua.a
CORE_O= lapi.o lcode.o lctype.o ldebug.o ldo.o ldump.o lfunc.o lgc.o
llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o
ltm.o lundump.o lvm.o lzio.o
LIB_O= lauxlib.o lbaselib.o lcorolib.o ldblib.o liolib.o lmathlib.o
loadlib.o loslib.o lstrlib.o ltablib.o lutf8lib.o linit.o
BASE_O= $(CORE_O) $(LIB_O) $(MYOBJS)
LUA_T= lua
LUA_O= lua.o
LUAC_T= luac
LUAC_O= luac.o
ALL_O= $(BASE_O) $(LUA_O) $(LUAC_O)
ALL_T= $(LUA_A) $(LUA_T) $(LUAC_T)
ALL_A= $(LUA_A)
# Targets start here.
default: $(PLAT)
all: $(ALL_T)
o: $(ALL_O)
a: $(ALL_A)
$(LUA_A): $(BASE_O)
$(AR) $@ $(BASE_O)
$(RANLIB) $@
$(LUA_T): $(LUA_O) $(LUA_A)
$(CC) -o $@ $(LDFLAGS) $(LUA_O) $(LUA_A) $(LIBS)
$(LUAC_T): $(LUAC_O) $(LUA_A)
$(CC) -o $@ $(LDFLAGS) $(LUAC_O) $(LUA_A) $(LIBS)
test:
./$(LUA_T) -v
clean:
$(RM) $(ALL_T) $(ALL_O)
depend:
@$(CC) $(CFLAGS) -MM l*.c
echo:
@echo "PLAT= $(PLAT)"
@echo "CC= $(CC)"
@echo "CFLAGS= $(CFLAGS)"
@echo "LDFLAGS= $(LDFLAGS)"
@echo "LIBS= $(LIBS)"
@echo "AR= $(AR)"
@echo "RANLIB= $(RANLIB)"
@echo "RM= $(RM)"
@echo "UNAME= $(UNAME)"
# Convenience targets for popular platforms.
ALL= all
help:
@echo "Do 'make PLATFORM' where PLATFORM is one of these:"
@echo " $(PLATS)"
@echo "See doc/readme.html for complete instructions."
guess:
@echo Guessing `$(UNAME)`
@$(MAKE) `$(UNAME)`
AIX aix:
$(MAKE) $(ALL) CC="xlc" CFLAGS="-O2 -DLUA_USE_POSIX -DLUA_USE_DLOPEN"
SYSLIBS="-ldl" SYSLDFLAGS="-brtl -bexpall"
bsd:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_POSIX -DLUA_USE_DLOPEN"
SYSLIBS="-Wl,-E"
c89:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_C89" CC="gcc -std=c89"
@echo ''
@echo '*** C89 does not guarantee 64-bit integers for Lua.'
@echo '*** Make sure to compile all external Lua libraries'
@echo '*** with LUA_USE_C89 to ensure consistency'
@echo ''
FreeBSD NetBSD OpenBSD freebsd:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_LINUX -DLUA_USE_READLINE
-I/usr/include/edit" SYSLIBS="-Wl,-E -ledit" CC="cc"
generic: $(ALL)
ios:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_IOS"
Linux linux: linux-noreadline
linux-noreadline:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_LINUX" SYSLIBS="-Wl,-E -ldl"
linux-readline:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_LINUX -DLUA_USE_READLINE"
SYSLIBS="-Wl,-E -ldl -lreadline"
Darwin macos macosx:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_MACOSX -DLUA_USE_READLINE"
SYSLIBS="-lreadline"
mingw:
$(MAKE) "LUA_A=lua54.dll" "LUA_T=lua.exe" \
"AR=$(CC) -shared -o" "RANLIB=strip --strip-unneeded" \
"SYSCFLAGS=-DLUA_BUILD_AS_DLL" "SYSLIBS=" "SYSLDFLAGS=-s" lua.exe
$(MAKE) "LUAC_T=luac.exe" luac.exe
posix:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_POSIX"
SunOS solaris:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_POSIX -DLUA_USE_DLOPEN
-D_REENTRANT" SYSLIBS="-ldl"
# Targets that do not create files (not all makes understand .PHONY).
.PHONY: all $(PLATS) help test clean default o a depend echo
# Compiler modules may use special flags.
llex.o:
$(CC) $(CFLAGS) $(CMCFLAGS) -c llex.c
lparser.o:
$(CC) $(CFLAGS) $(CMCFLAGS) -c lparser.c
lcode.o:
$(CC) $(CFLAGS) $(CMCFLAGS) -c lcode.c
# DO NOT DELETE
lapi.o: lapi.c lprefix.h lua.h luaconf.h lapi.h llimits.h lstate.h \
lobject.h ltm.h lzio.h lmem.h ldebug.h ldo.h lfunc.h lgc.h lstring.h \
ltable.h lundump.h lvm.h
lauxlib.o: lauxlib.c lprefix.h lua.h luaconf.h lauxlib.h
lbaselib.o: lbaselib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
lcode.o: lcode.c lprefix.h lua.h luaconf.h lcode.h llex.h lobject.h \
llimits.h lzio.h lmem.h lopcodes.h lparser.h ldebug.h lstate.h ltm.h \
ldo.h lgc.h lstring.h ltable.h lvm.h
lcorolib.o: lcorolib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
lctype.o: lctype.c lprefix.h lctype.h lua.h luaconf.h llimits.h
ldblib.o: ldblib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
ldebug.o: ldebug.c lprefix.h lua.h luaconf.h lapi.h llimits.h lstate.h \
lobject.h ltm.h lzio.h lmem.h lcode.h llex.h lopcodes.h lparser.h \
ldebug.h ldo.h lfunc.h lstring.h lgc.h ltable.h lvm.h
ldo.o: ldo.c lprefix.h lua.h luaconf.h lapi.h llimits.h lstate.h \
lobject.h ltm.h lzio.h lmem.h ldebug.h ldo.h lfunc.h lgc.h lopcodes.h \
lparser.h lstring.h ltable.h lundump.h lvm.h
ldump.o: ldump.c lprefix.h lua.h luaconf.h lobject.h llimits.h lstate.h \
ltm.h lzio.h lmem.h lundump.h
lfunc.o: lfunc.c lprefix.h lua.h luaconf.h ldebug.h lstate.h lobject.h \
llimits.h ltm.h lzio.h lmem.h ldo.h lfunc.h lgc.h
lgc.o: lgc.c lprefix.h lua.h luaconf.h ldebug.h lstate.h lobject.h \
llimits.h ltm.h lzio.h lmem.h ldo.h lfunc.h lgc.h lstring.h ltable.h
linit.o: linit.c lprefix.h lua.h luaconf.h lualib.h lauxlib.h
liolib.o: liolib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
llex.o: llex.c lprefix.h lua.h luaconf.h lctype.h llimits.h ldebug.h \
lstate.h lobject.h ltm.h lzio.h lmem.h ldo.h lgc.h llex.h lparser.h \
lstring.h ltable.h
lmathlib.o: lmathlib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
lmem.o: lmem.c lprefix.h lua.h luaconf.h ldebug.h lstate.h lobject.h \
llimits.h ltm.h lzio.h lmem.h ldo.h lgc.h
loadlib.o: loadlib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
lobject.o: lobject.c lprefix.h lua.h luaconf.h lctype.h llimits.h \
ldebug.h lstate.h lobject.h ltm.h lzio.h lmem.h ldo.h lstring.h lgc.h \
lvm.h
lopcodes.o: lopcodes.c lprefix.h lopcodes.h llimits.h lua.h luaconf.h
loslib.o: loslib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
lparser.o: lparser.c lprefix.h lua.h luaconf.h lcode.h llex.h lobject.h \
llimits.h lzio.h lmem.h lopcodes.h lparser.h ldebug.h lstate.h ltm.h \
ldo.h lfunc.h lstring.h lgc.h ltable.h
lstate.o: lstate.c lprefix.h lua.h luaconf.h lapi.h llimits.h lstate.h \
lobject.h ltm.h lzio.h lmem.h ldebug.h ldo.h lfunc.h lgc.h llex.h \
lstring.h ltable.h
lstring.o: lstring.c lprefix.h lua.h luaconf.h ldebug.h lstate.h \
lobject.h llimits.h ltm.h lzio.h lmem.h ldo.h lstring.h lgc.h
lstrlib.o: lstrlib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
ltable.o: ltable.c lprefix.h lua.h luaconf.h ldebug.h lstate.h lobject.h \
llimits.h ltm.h lzio.h lmem.h ldo.h lgc.h lstring.h ltable.h lvm.h
ltablib.o: ltablib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
ltm.o: ltm.c lprefix.h lua.h luaconf.h ldebug.h lstate.h lobject.h \
llimits.h ltm.h lzio.h lmem.h ldo.h lgc.h lstring.h ltable.h lvm.h
lua.o: lua.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
luac.o: luac.c lprefix.h lua.h luaconf.h lauxlib.h ldebug.h lstate.h \
lobject.h llimits.h ltm.h lzio.h lmem.h lopcodes.h lopnames.h lundump.h
lundump.o: lundump.c lprefix.h lua.h luaconf.h ldebug.h lstate.h \
lobject.h llimits.h ltm.h lzio.h lmem.h ldo.h lfunc.h lstring.h lgc.h \
lundump.h
lutf8lib.o: lutf8lib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
lvm.o: lvm.c lprefix.h lua.h luaconf.h ldebug.h lstate.h lobject.h \
llimits.h ltm.h lzio.h lmem.h ldo.h lfunc.h lgc.h lopcodes.h lstring.h \
ltable.h lvm.h ljumptab.h
lzio.o: lzio.c lprefix.h lua.h luaconf.h llimits.h lmem.h lstate.h \
lobject.h ltm.h lzio.h
# (end of Makefile)
[toc] | [prev] | [next] | [standalone]
| From | "Gary R. Schmidt" <grschmidt@acm.org> |
|---|---|
| Date | 2024-02-03 00:25 +1100 |
| Message-ID | <337v8k-s4h.ln1@paranoia.mcleod-schmidt.id.au> |
| In reply to | #381591 |
On 02/02/2024 22:13, bart wrote: [Bitching about "make" snipped] Try "cake", Zoltan wrote it many decades ago, when we were at $GOSHWHATAUNIVERSITY, because he thought "make" was too prolix. Cheers, Gary B-)
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-02-02 13:29 +0000 |
| Message-ID | <upiqog$2k717$1@dont-email.me> |
| In reply to | #381591 |
On 02/02/2024 11:13, bart wrote:
> You're the one who needs to first write a pile of garbage within a
makefile in order for you to do:
>
> make prog
>
> Below is the makefile needed to build lua 5.4, which is a project of
only 35 C modules. Simple, isn't it?
> ---------------------------------
> # Makefile for building Lua
> # See ../doc/readme.html for installation and customization instructions.
>
> # == CHANGE THE SETTINGS BELOW TO SUIT YOUR ENVIRONMENT
Now this is an interesting comment. The makefile is set up for gcc. For
another compiler it won't work.
If I try to switch to 'tcc', there are a number of problems. First,
unless you do 'make clean', the .o files lying about (I guess a
consequence of being to do incremental builds), are incompatible.
At this point I discovered a bug in the makefile for Lua (you might say
it's not bug, it's one of the settings that need changing, but I've no
idea how or where):
Although this makefile works with gcc on Windows, it thinks the
executable is called 'lua', not 'lua.exe'. It will produce 'lua.exe'
with gcc, but it checks for the existence of 'lua'.
That is never present, so it always links; it never says 'is up-to-date'.
With tcc however, there's another issue: tcc requires the .exe extension
in the -o option, otherwise it writes the executable as 'lua'. Now, at
last, make sees 'lua' and deems it up-to-date. Unfortunately that won't
run under Windows.
Either not at all, or it will use the lua.exe left over from gcc. I can
bodge this by using '-o $@.exe', producing lua.exe from tcc, but make is
still checking 'lua'.
There are some minor things: tcc doesn't like the -lm option for example.
But what it comes down to is that it seems I need a separate makefile
for each compiler. As supplied, it didn't even work 100% for gcc on Windows.
That means duplicating all that file info.
This is a solution I used before, using this @ file:
------------------------------
-O2 -s -o lua.exe
lua.c lapi.c lcode.c lctype.c ldebug.c ldo.c ldump.c lfunc.c lgc.c
llex.c lmem.c lobject.c lopcodes.c lparser.c lstate.c lstring.c
ltable.c ltm.c lundump.c lvm.c lzio.c lauxlib.c lbaselib.c lcorolib.c
ldblib.c liolib.c lmathlib.c loadlib.c loslib.c lstrlib.c ltablib.c
lutf8lib.c linit.c
------------------------------
If I run it like this:
gcc @luafiles
it produces a 260KB executable. Which is another interesting thing:
using 'make lua' set up for gcc produces a 360KB executable.
But I can also run it like this:
tcc @luafiles
The same file works for both gcc and tcc.
It won't work for mcc unless I split it into two, as that first line of
options doesn't work there. However with mcc I can now just do this:
mcc lua
So two solutions for this project that (1) don't involve a makefile; (2)
work better than the makefile.
It's true that it involved recompiling every module. But tcc still
builds this project in 0.3 seconds.
This project contains 34 C files, or which 33 are needed (not 35 as I
said). That means that using *.c is not possible, unless that extra file
(I believe used when building a shared library) is renamed.
If that is done, then all compilers just need "*.c" plus whatever other
options are needed.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-02 10:47 +0100 |
| Message-ID | <upidn1$2i275$1@dont-email.me> |
| In reply to | #381532 |
On 01/02/2024 23:29, bart wrote: > On 01/02/2024 21:34, David Brown wrote: >> On 01/02/2024 19:34, bart wrote: > >>> You don't see that the language taking over task (1) of the things >>> that makefiles do, and possibly (2) (of the list I posted; repeated >>> below), can streamline makefiles to make them shorter, simpler, >>> easier to write and to read, and with fewer opportunities to get >>> stuff wrong? >>> >>> That was a rhetorical question. Obviously not. >> >> I've nothing against shorter or simpler makefiles. But as far as I >> can see, you are just moving the same information from a makefile into >> the C files. >> >> Indeed, you are duplicating things - now your C files have to have >> "#pragma module this, #pragma module that" in addition to having >> "#include this.h, #include that.h". With my makefiles, all the "this" >> and "that" is found automatically - writing the includes in the C code >> is sufficient. > > I don't think so. Seeing: > > #include "file.h" > > doesn't necessarily mean there is a matching "file.c". It might not > exist, or the header might be for some external library, or maybe it > does exist but in a different location. As I said, you are duplicating things. For my builds, I do not have anywhere that I need to specify "file.c". > > Or maybe some code may use a file "fred.c", which needs to be submitted > to the compiler, but for which there is either no header used, or uses a > header file with a different name. > > As I said, C's uses of .h and .c files are chaotic. My uses of .h and .c files are not chaotic. Maybe you can't write well-structured C programs. Certainly not everyone can. (And /please/ do not give another list of open source programs that you don't like. I didn't write them. I can tell you how and why /I/ organise my projects and makefiles - I don't speak for others.) > > Did you have in mind using gcc's -MM option? For my 'cipher.c' demo, > that only gives a set of header names. Missing are hmac.c and sha2.c. > I use makefiles where gcc's "-M" options are part of the solution - not the whole solution. > If I try it on lua.c, it gives me only 5 header files; the project > comprises 33 .c files and 27 .h files. > I don't care. I did not write lua. But I /have/ integrated lua with one of my projects, long ago. It fit into my makefile format without trouble - I added the lua directory as a subdirectory of my source directory, and that was all that was needed. >>> >>> >>>> Perhaps I would find your tools worked for a "Hello, world" project. >>>> Maybe they were still okay as it got slightly bigger. Then I'd have >>>> something that they could not handle, and I'd reach for make. What >>>> would be the point of using "make" to automate - for example - >>>> post-processing of a binary to add a CRC check, but using your tools >>>> to handle the build? It's much easier just to use "make" for the >>>> whole thing. >>> >>> >>> Because building one binary is a process should be the job of a >>> compiler, not some random external tool that knows nothing of the >>> language or compiler. >> >> No, it is the job of the linker. > > There is where you're still stuck in the past. > > I first got rid of a formal 'linker' about 40 years ago. I got rid of > the notion of combining independently compiled modules into an > executable a decade ago. No, you built a monolithic tool that /included/ the linker. That's fine for niche tools that are not intended to work with anything else. Most people work with many tools - that's why we have standards, defined file formats, and flexible tools with wide support. Other people got rid of monolithic tools forty years ago when they realised it was a terrible way to organise things. > > But I suspect you don't understand what a 'whole-program compiler' does: > I know exactly what it does. I am entirely without doubt that I know the point and advantages of them better than you do - the /real/ points and advantages, not some pathetic "it means I don't have to use that horrible nasty make program" reason. > * It means that for each binary, all sources are recompiled at the same > time to create it No, it does not. > > * It doesn't mean that an application can only comprise one binary Correct. > > * It moves the compilation unit granularity from a module to a single > EXE or DLL file No, it does not. > > * Interfaces (in the case of a lower level language), are moved inter- > module to inter-program. The boundaries are between one program or > library and another, not between modules. Correct. > > A language which claims to have a module system, but still compiles a > module at a time, will probably still have discrete inter-module > interfaces, although they may be handled automatically. > Correct. In real-world whole program compilation systems, the focus is on inter-module optimisations. Total build times are expected to go /up/. Build complexity can be much higher, especially for large programs. It is more often used for C++ than C. The main point of a lot of whole-program compilation is to allow cross-module optimisation. It means you can have "access" functions hidden away in implementation files so that you avoid global variables or inter-dependencies between modules, but now they can be inline across modules so that you have no overhead or costs for this. It means you can write code that is more structured and modular, with different teams handling different parts, and with layers of abstractions, but when you pull it all together into one whole-program build, the run-time costs and overhead for this all disappear. And it means lots of checks and static analysis can be done across the whole program. For such programs, each translation unit is still compiled separately, but the "object" files contain internal data structures and analysis information, rather than generated code. Lots of the work is done by this point, with inter-procedural optimisations done within the unit. These compilations will be done as needed, in parallel, under the control of a build system. Then they are combined for the linking and link-time optimisation which fits the parts together. Doing this in a scalable way is hard, and the subject of a lot of research, as you need to partition it into chunks that can be handled in parallel on multiple cpu cores (or even distributed amongst servers). Once you have parts of code that are ready, they are handed on to backend compilers that do more optimisation and generate the object code, and this in turn is linked (sometimes incrementally in parts, again aiming at improving parallel building and scalability. You go to all this effort because you are building software that is used by millions of people, and your build effort is minor compared to the total improvements for all users combined. Or you do it because you are building speed-critical software. Or you want the best static analysis you can get, and want that done across modules. Or you are building embedded systems that need to be as efficient as possible. You don't do it because you find "make" ugly. It is also very useful on old-fashioned microcontrollers with multiple banks for data ram and code memory, and no good data stack access - the compiler can do large-scale lifetime analysis and optimise placement and the re-use of the very limited ram. > >> /Nobody/ has makefiles forced on them. People use "make" because it >> is convenient, and it works. > > BUT IT DOESN'T. IT DOES WORK. People use it all the time. > It fails a lot of the time on Windows, but they are too > complicated to figure out why. People use it all the time on Windows. Even Microsoft ships its own version of make, "nmake.exe", and has done for decades. /You/ can't work it, but you excel at failing to get things working. You have a special gift - you just have to look at a computer with tools that you didn't write yourself, and it collapses. > >> But I have no interest in changing to something vastly more limited >> and which adds nothing at all. > > That's right; it adds nothing, but it takes a lot away! Like a lot of > failure points. Like pretty much everything I need.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-02-02 15:45 +0200 |
| Message-ID | <20240202154531.00006289@yahoo.com> |
| In reply to | #381585 |
On Fri, 2 Feb 2024 10:47:12 +0100 David Brown <david.brown@hesbynett.no> wrote: > On 01/02/2024 23:29, bart wrote: > > On 01/02/2024 21:34, David Brown wrote: > >> On 01/02/2024 19:34, bart wrote: > > > >>> You don't see that the language taking over task (1) of the > >>> things that makefiles do, and possibly (2) (of the list I posted; > >>> repeated below), can streamline makefiles to make them shorter, > >>> simpler, easier to write and to read, and with fewer > >>> opportunities to get stuff wrong? > >>> > >>> That was a rhetorical question. Obviously not. > >> > >> I've nothing against shorter or simpler makefiles. But as far as > >> I can see, you are just moving the same information from a > >> makefile into the C files. > >> > >> Indeed, you are duplicating things - now your C files have to have > >> "#pragma module this, #pragma module that" in addition to having > >> "#include this.h, #include that.h". With my makefiles, all the > >> "this" and "that" is found automatically - writing the includes in > >> the C code is sufficient. > > > > I don't think so. Seeing: > > > > #include "file.h" > > > > doesn't necessarily mean there is a matching "file.c". It might not > > exist, or the header might be for some external library, or maybe > > it does exist but in a different location. > > As I said, you are duplicating things. > > For my builds, I do not have anywhere that I need to specify "file.c". > > > > > Or maybe some code may use a file "fred.c", which needs to be > > submitted to the compiler, but for which there is either no header > > used, or uses a header file with a different name. > > > > As I said, C's uses of .h and .c files are chaotic. > > My uses of .h and .c files are not chaotic. > > Maybe you can't write well-structured C programs. Certainly not > everyone can. (And /please/ do not give another list of open source > programs that you don't like. I didn't write them. I can tell you > how and why /I/ organise my projects and makefiles - I don't speak > for others.) > > > > > Did you have in mind using gcc's -MM option? For my 'cipher.c' > > demo, that only gives a set of header names. Missing are hmac.c > > and sha2.c. > > I use makefiles where gcc's "-M" options are part of the solution - > not the whole solution. > > > If I try it on lua.c, it gives me only 5 header files; the project > > comprises 33 .c files and 27 .h files. > > > > I don't care. I did not write lua. > > But I /have/ integrated lua with one of my projects, long ago. It > fit into my makefile format without trouble - I added the lua > directory as a subdirectory of my source directory, and that was all > that was needed. > > >>> > >>> > >>>> Perhaps I would find your tools worked for a "Hello, world" > >>>> project. Maybe they were still okay as it got slightly bigger. > >>>> Then I'd have something that they could not handle, and I'd > >>>> reach for make. What would be the point of using "make" to > >>>> automate - for example - post-processing of a binary to add a > >>>> CRC check, but using your tools to handle the build? It's much > >>>> easier just to use "make" for the whole thing. > >>> > >>> > >>> Because building one binary is a process should be the job of a > >>> compiler, not some random external tool that knows nothing of the > >>> language or compiler. > >> > >> No, it is the job of the linker. > > > > There is where you're still stuck in the past. > > > > I first got rid of a formal 'linker' about 40 years ago. I got rid > > of the notion of combining independently compiled modules into an > > executable a decade ago. > > No, you built a monolithic tool that /included/ the linker. That's > fine for niche tools that are not intended to work with anything > else. Most people work with many tools - that's why we have > standards, defined file formats, and flexible tools with wide support. > > Other people got rid of monolithic tools forty years ago when they > realised it was a terrible way to organise things. > Actually, nowadays monolithic tools are solid majority in programming. I mean, programming in general, not C/C++/Fortran programming which by itself is a [sizable] minority. Even in C++, a majority uses non-monolithic tools well-hidden behind front end (IDE) that makes them indistinguishable from monolithic. > > > > > But I suspect you don't understand what a 'whole-program compiler' > > does: > > I know exactly what it does. I am entirely without doubt that I know > the point and advantages of them better than you do - the /real/ > points and advantages, not some pathetic "it means I don't have to > use that horrible nasty make program" reason. > > > * It means that for each binary, all sources are recompiled at the > > same time to create it > > No, it does not. > > > > > * It doesn't mean that an application can only comprise one binary > > Correct. > > > > > * It moves the compilation unit granularity from a module to a > > single EXE or DLL file > > No, it does not. > > > > > * Interfaces (in the case of a lower level language), are moved > > inter- module to inter-program. The boundaries are between one > > program or library and another, not between modules. > > Correct. > > > > > A language which claims to have a module system, but still compiles > > a module at a time, will probably still have discrete inter-module > > interfaces, although they may be handled automatically. > > > > Correct. > > > In real-world whole program compilation systems, the focus is on > inter-module optimisations. Total build times are expected to go > /up/. Build complexity can be much higher, especially for large > programs. It is more often used for C++ than C. > > The main point of a lot of whole-program compilation is to allow > cross-module optimisation. It means you can have "access" functions > hidden away in implementation files so that you avoid global > variables or inter-dependencies between modules, but now they can be > inline across modules so that you have no overhead or costs for this. > It means you can write code that is more structured and modular, > with different teams handling different parts, and with layers of > abstractions, but when you pull it all together into one > whole-program build, the run-time costs and overhead for this all > disappear. And it means lots of checks and static analysis can be > done across the whole program. > > > For such programs, each translation unit is still compiled > separately, but the "object" files contain internal data structures > and analysis information, rather than generated code. Lots of the > work is done by this point, with inter-procedural optimisations done > within the unit. These compilations will be done as needed, in > parallel, under the control of a build system. Then they are > combined for the linking and link-time optimisation which fits the > parts together. Doing this in a scalable way is hard, and the > subject of a lot of research, as you need to partition it into chunks > that can be handled in parallel on multiple cpu cores (or even > distributed amongst servers). Once you have parts of code that are > ready, they are handed on to backend compilers that do more > optimisation and generate the object code, and this in turn is linked > (sometimes incrementally in parts, again aiming at improving parallel > building and scalability. > > > You go to all this effort because you are building software that is > used by millions of people, and your build effort is minor compared > to the total improvements for all users combined. Or you do it > because you are building speed-critical software. Or you want the > best static analysis you can get, and want that done across modules. > Or you are building embedded systems that need to be as efficient as > possible. > > You don't do it because you find "make" ugly. > > > It is also very useful on old-fashioned microcontrollers with > multiple banks for data ram and code memory, and no good data stack > access - the compiler can do large-scale lifetime analysis and > optimise placement and the re-use of the very limited ram. > > > > > >> /Nobody/ has makefiles forced on them. People use "make" because > >> it is convenient, and it works. > > > > BUT IT DOESN'T. > > IT DOES WORK. > > People use it all the time. > > > It fails a lot of the time on Windows, but they are too > > complicated to figure out why. > > People use it all the time on Windows. > > Even Microsoft ships its own version of make, "nmake.exe", and has > done for decades. > > /You/ can't work it, but you excel at failing to get things working. > You have a special gift - you just have to look at a computer with > tools that you didn't write yourself, and it collapses. > > > > >> But I have no interest in changing to something vastly more > >> limited and which adds nothing at all. > > > > That's right; it adds nothing, but it takes a lot away! Like a lot > > of failure points. > > Like pretty much everything I need. > >
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-02 16:26 +0100 |
| Message-ID | <upj1ik$2ldkd$1@dont-email.me> |
| In reply to | #381600 |
On 02/02/2024 14:45, Michael S wrote: > > Actually, nowadays monolithic tools are solid majority in programming. > I mean, programming in general, not C/C++/Fortran programming which by > itself is a [sizable] minority. > Even in C++, a majority uses non-monolithic tools well-hidden behind > front end (IDE) that makes them indistinguishable from monolithic. > It can often be helpful to have a single point of interaction - a front-end that combines tools. But usually these are made of parts. For many of the microcontrollers I work with, the manufacturer's standard development toolset is based around Eclipse and gcc. From the user point of view, it looks a lot like one monolithic IDE that lets you write your code, compile and link it, and download and debug it on the microcontroller. Under the hood, it is far from a monolithic application. Different bits come from many different places. This means the microcontroller manufacturer is only making the bits that are specific to /their/ needs - such as special views while debugging, or "wizards" for configuring chip pins. The Eclipse folk are experts at making an editor and IDE, the gcc folks are experts at the compiler, the openocd folks know about jtag debugging, and so on. And to a fair extent, advanced users can use the bits they want and leave out other bits. I sometimes use other editors, but might still use the toolchain provided with the manufacturer's tools. I might swap out the debugger connection. I might use the IDE for something completely different. I might install additional features in the IDE. I might use different toolchains. Manufacturers, when putting things together, might change where they get their toolchains, or what debugging connectors they use. It's even been known for them to swap out the base IDE while keeping most of the rest the same (VS Code has become a popular choice now, and a few use NetBeans rather than Eclipse). (Oh, and for those that don't believe "make" and "gcc" work on Windows, these development tools invariably have "make" and almost invariably use gcc as their toolchain, all working in almost exactly the same way on Linux and Windows. The only difference is builds are faster on Linux.) This is getting the best (or at least, trying to) from all worlds. It gives people the ease-of-use advantages of monolithic tools without the key disadvantages of real monolithic tools - half-arse editors, half-arsed project managers, half-arsed compilers, and poor extensibility because the suppliers are trying to do far too much themselves. I don't think it is common now to have /real/ monolithic development tools. But it is common to have front-ends aimed at making the underlying tools easier and more efficient to use, and to provide all-in-one base packages.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-02-03 14:39 +0100 |
| Message-ID | <uplfm1$352ce$1@dont-email.me> |
| In reply to | #381611 |
On 02.02.2024 16:26, David Brown wrote: > > [...] The Eclipse folk are experts at making an editor and IDE, [...] I have to disagree with this bit. At the time I used it[*] they were even incapable of integrating an existing Vim editor (even a standard Vi would have been okay for me, but no). - Instead they supported/embedded an own trashy vi clone with a small subset of the vi feature (not to speak about the vim features). Janis [*] Disclaimer: my Eclipse/Java episode was around 2005 and I don't know the current state, whether that has changed meanwhile, or got better.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-03 16:26 +0100 |
| Message-ID | <uplluv$3650b$1@dont-email.me> |
| In reply to | #381672 |
On 03/02/2024 14:39, Janis Papanagnou wrote: > On 02.02.2024 16:26, David Brown wrote: >> >> [...] The Eclipse folk are experts at making an editor and IDE, [...] > > I have to disagree with this bit. > My point is independent of whether or not you like Eclipse (people are split on that), or what editor you think is best (people break out in fights over that). The point is that the editor and IDE people make the editor and IDE, the compiler people make the compiler, the debugger people make the debugger, and so on - while to the user, the package looks more or less like a complete "do everything" development tool.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-02-03 17:11 +0100 |
| Message-ID | <uploke$36kkr$1@dont-email.me> |
| In reply to | #381682 |
On 03.02.2024 16:26, David Brown wrote: > On 03/02/2024 14:39, Janis Papanagnou wrote: >> On 02.02.2024 16:26, David Brown wrote: >>> >>> [...] The Eclipse folk are experts at making an editor and IDE, [...] >> >> I have to disagree with this bit. >> > > My point is independent of whether or not you like Eclipse (people are > split on that), or what editor you think is best (people break out in > fights over that). > > The point is that the editor and IDE people make the editor and IDE, Yes, and my point was that they had no integration concept for that. (Thus it wouldn't occur to me to call that "experts". But they likely had just another agenda.) And this is of course completely independent of anyones opinion on Eclipse or on any specific editor. > the > compiler people make the compiler, the debugger people make the > debugger, and so on - while to the user, the package looks more or less > like a complete "do everything" development tool. Right. (Only they ignored the modularization on the "editor and IDE" component.) Janis
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-02-06 13:59 +0200 |
| Message-ID | <20240206135950.00001f20@yahoo.com> |
| In reply to | #381611 |
On Fri, 2 Feb 2024 16:26:12 +0100 David Brown <david.brown@hesbynett.no> wrote: > On 02/02/2024 14:45, Michael S wrote: > > > > Actually, nowadays monolithic tools are solid majority in > > programming. I mean, programming in general, not C/C++/Fortran > > programming which by itself is a [sizable] minority. > > Even in C++, a majority uses non-monolithic tools well-hidden behind > > front end (IDE) that makes them indistinguishable from monolithic. > > > > It can often be helpful to have a single point of interaction - a > front-end that combines tools. But usually these are made of parts. > > For many of the microcontrollers I work with, the manufacturer's > standard development toolset is based around Eclipse and gcc. From > the user point of view, it looks a lot like one monolithic IDE that > lets you write your code, compile and link it, and download and debug > it on the microcontroller. Under the hood, it is far from a > monolithic application. Different bits come from many different > places. This means the microcontroller manufacturer is only making > the bits that are specific to /their/ needs - such as special views > while debugging, or "wizards" for configuring chip pins. The Eclipse > folk are experts at making an editor and IDE, the gcc folks are > experts at the compiler, the openocd folks know about jtag debugging, > and so on. And to a fair extent, advanced users can use the bits > they want and leave out other bits. I sometimes use other editors, > but might still use the toolchain provided with the manufacturer's > tools. I might swap out the debugger connection. I might use the > IDE for something completely different. I might install additional > features in the IDE. I might use different toolchains. > Manufacturers, when putting things together, might change where they > get their toolchains, or what debugging connectors they use. It's > even been known for them to swap out the base IDE while keeping most > of the rest the same (VS Code has become a popular choice now, and a > few use NetBeans rather than Eclipse). > > (Oh, and for those that don't believe "make" and "gcc" work on > Windows, these development tools invariably have "make" and almost > invariably use gcc as their toolchain, all working in almost exactly > the same way on Linux and Windows. The only difference is builds are > faster on Linux.) > > This is getting the best (or at least, trying to) from all worlds. > It gives people the ease-of-use advantages of monolithic tools > without the key disadvantages of real monolithic tools - half-arse > editors, half-arsed project managers, half-arsed compilers, and poor > extensibility because the suppliers are trying to do far too much > themselves. > > I don't think it is common now to have /real/ monolithic development > tools. But it is common to have front-ends aimed at making the > underlying tools easier and more efficient to use, and to provide > all-in-one base packages. > > > First, you moved a goal post from monolithic compiler to monolithic IDE. Second, you are still talking about C/C++/Fortran. That's not where majority of software development goes this days. The first most used language is JavaScript. Where exactly JavaScript dev sees separate compiler and linker? The second most used language is python. The same question here. Even in more traditional compiled/jitted and mostly statically typed programming environments like Java/Cotlin, .net, Swift, go, Rust, even if they use separate tools for compiling, assembling, linking and build management, it's all integrated in a way that even die-hard command-line user does not know about separation.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-06 13:14 +0100 |
| Message-ID | <upt7qm$s5ov$4@dont-email.me> |
| In reply to | #381914 |
On 06/02/2024 12:59, Michael S wrote: > On Fri, 2 Feb 2024 16:26:12 +0100 > David Brown <david.brown@hesbynett.no> wrote: > >> On 02/02/2024 14:45, Michael S wrote: >>> >>> Actually, nowadays monolithic tools are solid majority in >>> programming. I mean, programming in general, not C/C++/Fortran >>> programming which by itself is a [sizable] minority. >>> Even in C++, a majority uses non-monolithic tools well-hidden behind >>> front end (IDE) that makes them indistinguishable from monolithic. >>> >> >> It can often be helpful to have a single point of interaction - a >> front-end that combines tools. But usually these are made of parts. >> >> For many of the microcontrollers I work with, the manufacturer's >> standard development toolset is based around Eclipse and gcc. From >> the user point of view, it looks a lot like one monolithic IDE that >> lets you write your code, compile and link it, and download and debug >> it on the microcontroller. Under the hood, it is far from a >> monolithic application. Different bits come from many different >> places. This means the microcontroller manufacturer is only making >> the bits that are specific to /their/ needs - such as special views >> while debugging, or "wizards" for configuring chip pins. The Eclipse >> folk are experts at making an editor and IDE, the gcc folks are >> experts at the compiler, the openocd folks know about jtag debugging, >> and so on. And to a fair extent, advanced users can use the bits >> they want and leave out other bits. I sometimes use other editors, >> but might still use the toolchain provided with the manufacturer's >> tools. I might swap out the debugger connection. I might use the >> IDE for something completely different. I might install additional >> features in the IDE. I might use different toolchains. >> Manufacturers, when putting things together, might change where they >> get their toolchains, or what debugging connectors they use. It's >> even been known for them to swap out the base IDE while keeping most >> of the rest the same (VS Code has become a popular choice now, and a >> few use NetBeans rather than Eclipse). >> >> (Oh, and for those that don't believe "make" and "gcc" work on >> Windows, these development tools invariably have "make" and almost >> invariably use gcc as their toolchain, all working in almost exactly >> the same way on Linux and Windows. The only difference is builds are >> faster on Linux.) >> >> This is getting the best (or at least, trying to) from all worlds. >> It gives people the ease-of-use advantages of monolithic tools >> without the key disadvantages of real monolithic tools - half-arse >> editors, half-arsed project managers, half-arsed compilers, and poor >> extensibility because the suppliers are trying to do far too much >> themselves. >> >> I don't think it is common now to have /real/ monolithic development >> tools. But it is common to have front-ends aimed at making the >> underlying tools easier and more efficient to use, and to provide >> all-in-one base packages. >> >> >> > > First, you moved a goal post from monolithic compiler to monolithic IDE. > Second, you are still talking about C/C++/Fortran. I was thinking of compiled languages, yes. > That's not where majority of software development goes this days. Agreed. > > The first most used language is JavaScript. Where exactly JavaScript dev > sees separate compiler and linker? > The second most used language is python. The same question here. Interpreted, byte-code compiled or JIT languages have a different model entirely. But again, you have a front-end that appears monolithic, hiding back-ends that are very far from monolithic. The language front-end can come from one place, libraries from somewhere else, the VM may be totally independent, and the JIT could be separate again. And if you are using an IDE for it, as many do (regardless of the language), you've got all the editors, revision control system, gui designer, HTML previewer, and whatever else from another dozen independent sources and all acting as one. It is not monolithic by any means - but it /looks/ that way for user convenience. > Even in more traditional compiled/jitted and mostly statically typed > programming environments like Java/Cotlin, .net, Swift, go, Rust, even > if they use separate tools for compiling, assembling, linking and build > management, it's all integrated in a way that even die-hard command-line > user does not know about separation. >
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-02-06 14:32 +0200 |
| Message-ID | <20240206143229.00004a75@yahoo.com> |
| In reply to | #381916 |
On Tue, 6 Feb 2024 13:14:14 +0100 David Brown <david.brown@hesbynett.no> wrote: > > It is not monolithic by any means - but it /looks/ that way for user > convenience. > And Bart wants the same for slightly extended variant of C, that's all. According to my understanding, he does not care deeply about distinction between "true monolithic" and integrated compiler + linker + build system as long as it looks like monolithic. Or may be I should say that he will certainly express his unhappiness about size and speed of looks-monolithic tool and about the fact that they have to be installed, if they have to be installed, at least 20 times per week, but at least he will be reasonably satisfied with functionality.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-02-06 14:16 +0000 |
| Message-ID | <uptf0r$tq8i$1@dont-email.me> |
| In reply to | #381917 |
On 06/02/2024 12:32, Michael S wrote: > On Tue, 6 Feb 2024 13:14:14 +0100 > David Brown <david.brown@hesbynett.no> wrote: >> >> It is not monolithic by any means - but it /looks/ that way for user >> convenience. >> > > And Bart wants the same for slightly extended variant of C, that's all. > According to my understanding, he does not care deeply about > distinction between "true monolithic" and integrated compiler + linker > + build system as long as it looks like monolithic. > Or may be I should say that he will certainly express his unhappiness > about size and speed of looks-monolithic tool and about the fact that > they have to be installed, if they have to be installed, at least 20 > times per week, but at least he will be reasonably satisfied with > functionality. > > The packaging of language installations is certainly one aspect that I'm interested in. And my preference is to have as few files involved as possible. There is a trend now for newer languages to come as one giant executable, although in practice they need a few more bits. My own language projects do each come in one self-contained executable, and are from 0.1MB to 0.6MB. My original C compiler was also a single file, about 1MB. My current one, because it is now private, is in 2-3 parts (mcc.exe, aa.exe, about 360KB, and a discrete windows.h which was what took up most of that 1MB). It behaves as though it is monolithic. Regarding Tiny C, as it seems to be distributed, it requires a minimum of 3 binaries (tcc.exe, libtcc.dll, libtcc1-64.a, about 220KB) in order to build any of my generated-C applications. But for general use, it needs a bunch of C header files too. There are also products like Pico C, an interpreter, about 130KB self-contained in one file, although it has limitations and is very slow even for an interpreter. It could be adequate though for scripting builds. I know David Brown doesn't like 'toy' implementations of C, but if you need to bundle something for example, then the smaller and more self-contained the better. (FWIW, if I apply UPX compression to those examples, then Pico C reduces to 32KB; my mcc/aa combo to 123KB, and tcc exe/lib/a combo to 141KB. But the latter still needs discrete std header files.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-06 17:02 +0100 |
| Message-ID | <uptl64$ur6f$1@dont-email.me> |
| In reply to | #381919 |
On 06/02/2024 15:16, bart wrote: > There are also products like Pico C, an interpreter, about 130KB > self-contained in one file, although it has limitations and is very slow > even for an interpreter. It could be adequate though for scripting builds. > > I know David Brown doesn't like 'toy' implementations of C, but if you > need to bundle something for example, then the smaller and more > self-contained the better. > Just to be clear - you can have as many "toy" implementations of C as you like. And sometimes small, fast, limited tools are useful - such as if you want to have a C "interpreter". (I can't see the point myself - there are better languages for scripting, and they are not difficult to learn to the level you need for scripting. Even your own scripting languages are a better choice than interpreted C for pretty much any use.) What I don't agree with is the idea that such small C implementations are a viable replace for, or even better than, serious tools like gcc, clang, icc, MSVC, Green Hills, Metrowerks, and other major compilers. I am quite happy to accept that "small and fast" is a good thing - I just don't give it anything like the weighting you do, at least for normal compiler use.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-02-06 20:31 +0000 |
| Message-ID | <upu4uq$11f6i$5@dont-email.me> |
| In reply to | #381919 |
On Tue, 6 Feb 2024 14:16:59 +0000, bart wrote:
> There is a trend now for newer languages to come as one giant
> executable ...
I don’t know where you get that idea:
ldo@theon:~> dpkg-query -L python3.11
/.
/usr
/usr/bin
/usr/bin/pydoc3.11
/usr/bin/pygettext3.11
/usr/lib
/usr/lib/python3
/usr/lib/python3/dist-packages
/usr/lib/python3.11
/usr/lib/python3.11/lib-dynload
/usr/share
/usr/share/applications
/usr/share/applications/python3.11.desktop
/usr/share/doc
/usr/share/doc/python3.11
/usr/share/doc/python3.11/ACKS.gz
/usr/share/doc/python3.11/NEWS.gz
/usr/share/doc/python3.11/README.Debian
/usr/share/doc/python3.11/README.rst.gz
/usr/share/doc/python3.11/README.venv
/usr/share/doc/python3.11/changelog.Debian.gz
/usr/share/doc/python3.11/copyright
/usr/share/lintian
/usr/share/lintian/overrides
/usr/share/lintian/overrides/python3.11
/usr/share/man
/usr/share/man/man1
/usr/share/man/man1/pdb3.11.1.gz
/usr/share/man/man1/pydoc3.11.1.gz
/usr/share/man/man1/pygettext3.11.1.gz
/usr/share/man/man1/pysetup3.11.1.gz
/usr/share/pixmaps
/usr/share/pixmaps/python3.11.xpm
/usr/bin/pdb3.11
/usr/share/doc/python3.11/changelog.gz
Of course, that isn’t all of it:
ldo@theon:~> apt-cache depends python3.11
python3.11
Depends: python3.11-minimal
Depends: libpython3.11-stdlib
|Depends: media-types
Depends: mime-support
Breaks: python3-all
Breaks: python3-dev
Breaks: python3-venv
Recommends: ca-certificates
Suggests: python3.11-venv
Suggests: python3.11-doc
Suggests: binutils
The actual “python3” executable is in here:
ldo@theon:~> dpkg-query -L python3.11-minimal
/.
/usr
/usr/bin
/usr/bin/python3.11
/usr/lib
/usr/lib/binfmt.d
/usr/lib/binfmt.d/python3.11.conf
/usr/share
/usr/share/binfmts
/usr/share/binfmts/python3.11
/usr/share/doc
/usr/share/doc/python3.11-minimal
/usr/share/doc/python3.11-minimal/README.Debian.gz
/usr/share/doc/python3.11-minimal/changelog.Debian.gz
/usr/share/doc/python3.11-minimal/copyright
/usr/share/lintian
/usr/share/lintian/overrides
/usr/share/lintian/overrides/python3.11-minimal
/usr/share/man
/usr/share/man/man1
/usr/share/man/man1/python3.11.1.gz
Is this your idea of a “giant” executable?
ldo@theon:~> ls -lL /usr/bin/python3
-rwxr-xr-x 1 root root 6784920 Dec 9 03:22 /usr/bin/python3
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-02-02 14:14 +0000 |
| Message-ID | <upitc7$2kmuj$1@dont-email.me> |
| In reply to | #381585 |
On 02/02/2024 09:47, David Brown wrote: > On 01/02/2024 23:29, bart wrote: >> As I said, C's uses of .h and .c files are chaotic. > > My uses of .h and .c files are not chaotic. We can't write tools that only work for careful users. Any open-source project I want to build WILL be chaotic. We can however write languages where you are forced to be more disciplined. Mine doesn't have the equivalent of .h files for example. However this is about C. >> I first got rid of a formal 'linker' about 40 years ago. I got rid of >> the notion of combining independently compiled modules into an >> executable a decade ago. > > No, you built a monolithic tool that /included/ the linker. No, I ELIMINATED the linker. And in the past, I wrote a program called a Loader, much simpler than a linker, and very fast (it had to be as I worked with floppies). > That's fine > for niche tools that are not intended to work with anything else. Most > people work with many tools - that's why we have standards, defined file > formats, and flexible tools with wide support. > > Other people got rid of monolithic tools forty years ago when they > realised it was a terrible way to organise things. > >> >> But I suspect you don't understand what a 'whole-program compiler' does: >> > > I know exactly what it does. I am entirely without doubt that I know > the point and advantages of them better than you do You can't create a language devised for whole-program compilation, and implement a full-stack compiler for it, without learning a lot about the ins and outs. So I suspect I know a bit more about it than you do. Probably you're mixing this up with whole-program optimisation. - the /real/ points > and advantages, not some pathetic "it means I don't have to use that > horrible nasty make program" reason. > >> * It means that for each binary, all sources are recompiled at the same >> time to create it > > No, it does not. That's not a whole-program compiler then. Not if half the modules were compiled last week! >> >> * It doesn't mean that an application can only comprise one binary > > Correct. > >> >> * It moves the compilation unit granularity from a module to a single >> EXE or DLL file > > No, it does not. Again, it can't be a whole-program compiler if it can compile modules independently. > In real-world whole program compilation systems, the focus is on > inter-module optimisations. Total build times are expected to go /up/. > Build complexity can be much higher, especially for large programs. It > is more often used for C++ than C. > > The main point of a lot of whole-program compilation is to allow > cross-module optimisation. It means you can have "access" functions > hidden away in implementation files so that you avoid global variables > or inter-dependencies between modules, but now they can be inline across > modules so that you have no overhead or costs for this. It means you > can write code that is more structured and modular, with different teams > handling different parts, and with layers of abstractions, but when you > pull it all together into one whole-program build, the run-time costs > and overhead for this all disappear. And it means lots of checks and > static analysis can be done across the whole program. > > > For such programs, each translation unit is still compiled separately, > but the "object" files contain internal data structures and analysis > information, rather than generated code. Lots of the work is done by > this point, with inter-procedural optimisations done within the unit. > These compilations will be done as needed, in parallel, under the > control of a build system. Then they are combined for the linking and > link-time optimisation which fits the parts together. Doing this in a > scalable way is hard, and the subject of a lot of research, as you need > to partition it into chunks that can be handled in parallel on multiple > cpu cores (or even distributed amongst servers). Once you have parts of > code that are ready, they are handed on to backend compilers that do > more optimisation and generate the object code, and this in turn is > linked (sometimes incrementally in parts, again aiming at improving > parallel building and scalability. You've just described a tremendously complex way to do whole-program analysis. There are easier ways. The C transpiler I use takes a project of dozens of modules in my language, and produces a single C source file which will form one EXE or one DLL file. Now any ordinary optimising C compiler has a view of the entire program and can do wider optimisations (but that view does not span multiple EXE/DLL files.) > /You/ can't work it, but you excel at failing to get things working. You > have a special gift - you just have to look at a computer with tools > that you didn't write yourself, and it collapses. Yes, I do. I'm like that kid poking fun at the emperor's new clothes; I'm just stating what I see. But in one way it is hilarious seeing you lot defend programs like 'as' to the death. Why not just admit that it is a POS that you've had to learn to live with, instead of trying to make out it is somehow superior?
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-02-02 16:43 +0200 |
| Message-ID | <20240202164351.00000d33@yahoo.com> |
| In reply to | #381602 |
On Fri, 2 Feb 2024 14:14:31 +0000 bart <bc@freeuk.com> wrote: > On 02/02/2024 09:47, David Brown wrote: > > On 01/02/2024 23:29, bart wrote: > > >> As I said, C's uses of .h and .c files are chaotic. > > > > My uses of .h and .c files are not chaotic. > > We can't write tools that only work for careful users. Any > open-source project I want to build WILL be chaotic. > > We can however write languages where you are forced to be more > disciplined. Mine doesn't have the equivalent of .h files for example. > > However this is about C. > > > >> I first got rid of a formal 'linker' about 40 years ago. I got rid > >> of the notion of combining independently compiled modules into an > >> executable a decade ago. > > > > No, you built a monolithic tool that /included/ the linker. > > No, I ELIMINATED the linker. > > And in the past, I wrote a program called a Loader, much simpler than > a linker, and very fast (it had to be as I worked with floppies). > > > That's fine > > for niche tools that are not intended to work with anything else. > > Most people work with many tools - that's why we have standards, > > defined file formats, and flexible tools with wide support. > > > > Other people got rid of monolithic tools forty years ago when they > > realised it was a terrible way to organise things. > > > > > > >> > >> But I suspect you don't understand what a 'whole-program compiler' > >> does: > > > > I know exactly what it does. I am entirely without doubt that I > > know the point and advantages of them better than you do > > You can't create a language devised for whole-program compilation, > and implement a full-stack compiler for it, without learning a lot > about the ins and outs. > > So I suspect I know a bit more about it than you do. > > Probably you're mixing this up with whole-program optimisation. > > - the /real/ points > > and advantages, not some pathetic "it means I don't have to use > > that horrible nasty make program" reason. > > > >> * It means that for each binary, all sources are recompiled at the > >> same time to create it > > > > No, it does not. > > That's not a whole-program compiler then. Not if half the modules > were compiled last week! > > >> > >> * It doesn't mean that an application can only comprise one binary > >> > > > > Correct. > > > >> > >> * It moves the compilation unit granularity from a module to a > >> single EXE or DLL file > > > > No, it does not. > > Again, it can't be a whole-program compiler if it can compile modules > independently. > > > In real-world whole program compilation systems, the focus is on > > inter-module optimisations. Total build times are expected to go > > /up/. Build complexity can be much higher, especially for large > > programs. It is more often used for C++ than C. > > > > The main point of a lot of whole-program compilation is to allow > > cross-module optimisation. It means you can have "access" > > functions hidden away in implementation files so that you avoid > > global variables or inter-dependencies between modules, but now > > they can be inline across modules so that you have no overhead or > > costs for this. It means you can write code that is more > > structured and modular, with different teams handling different > > parts, and with layers of abstractions, but when you pull it all > > together into one whole-program build, the run-time costs and > > overhead for this all disappear. And it means lots of checks and > > static analysis can be done across the whole program. > > > > > > For such programs, each translation unit is still compiled > > separately, but the "object" files contain internal data structures > > and analysis information, rather than generated code. Lots of the > > work is done by this point, with inter-procedural optimisations > > done within the unit. These compilations will be done as needed, in > > parallel, under the control of a build system. Then they are > > combined for the linking and link-time optimisation which fits the > > parts together. Doing this in a scalable way is hard, and the > > subject of a lot of research, as you need to partition it into > > chunks that can be handled in parallel on multiple cpu cores (or > > even distributed amongst servers). Once you have parts of code > > that are ready, they are handed on to backend compilers that do > > more optimisation and generate the object code, and this in turn is > > linked (sometimes incrementally in parts, again aiming at improving > > parallel building and scalability. > > You've just described a tremendously complex way to do whole-program > analysis. > But it proves that your statement above (it can't be a whole-program compiler if it can compile modules independently) is false. > There are easier ways. The C transpiler I use takes a project of > dozens of modules in my language, and produces a single C source file > which will form one EXE or one DLL file. > > Now any ordinary optimising C compiler has a view of the entire > program and can do wider optimisations (but that view does not span > multiple EXE/DLL files.) > If the program in question is really big then there is a good chance that your method will expose internal limits of the back-end compiler. I think, that's one of the reason (not the only one) why Mozilla didn't re-write the whole Firefox in Rust. According to my understanding, Rust does something similar to your approach, except that it outputs LLVM IR instead of C and there are real concern that LLVM back end would have troubles with input as big as the whole FF. > > /You/ can't work it, but you excel at failing to get things > > working. You have a special gift - you just have to look at a > > computer with tools that you didn't write yourself, and it > > collapses. > > Yes, I do. I'm like that kid poking fun at the emperor's new clothes; > I'm just stating what I see. But in one way it is hilarious seeing > you lot defend programs like 'as' to the death. > > Why not just admit that it is a POS that you've had to learn to live > with, instead of trying to make out it is somehow superior? > > I never run gnu as directly. Running it by means of driver program (personally I prefer clang for that task, but gcc will do the job as well) isolates me from all peculiarities.
[toc] | [prev] | [next] | [standalone]
Page 14 of 21 — ← Prev page 1 … 12 13 [14] 15 16 … 21 Next page →
Back to top | Article view | comp.lang.c
csiph-web