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 | 15 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 21 of 21 — ← Prev page 1 … 19 20 [21]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-01 16:43 +0100 |
| Message-ID | <upge7u$24hfl$1@dont-email.me> |
| In reply to | #381465 |
On 01/02/2024 15:29, bart wrote: > On 31/01/2024 00:46, Tim Rentsch wrote: > > > Looking over one of my current projects (modest in size, > > a few thousand lines of C source, plus some auxiliary > > files adding perhaps another thousand or two), > > So, will a specific build of such a project produce a single EXE/DLL//SO > file? (The // includes the typical file extension of Linux executables.) > > This is all I want for a build. I my current project, when I run "make" it builds 5 different executables, each in three formats with different post-processing by other programs (not the compiler or linker). Most of my projects have fewer, but four or five outputs is not at all uncommon. It is also common that a few of the source files are generated by other programs as part of the build. So if I have an embedded web server in the program, I can change an html file and "make" will result in that being in the encrypted download image ready for deployment. Your tools can't do what I need for a lot of my work. Maybe they could be useable for some projects or programs. But why would I bother with them when I already need more serious and flexible tools for other things, already have these better tools, and those better tools work simply and easily for the simple and easy projects that your ones could handle?
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-02-03 01:05 -0800 |
| Message-ID | <86ttmp9aus.fsf@linuxsc.com> |
| In reply to | #381465 |
bart <bc@freeuk.com> writes: > On 31/01/2024 00:46, Tim Rentsch wrote: > >> Looking over one of my current projects (modest in size, >> a few thousand lines of C source, plus some auxiliary >> files adding perhaps another thousand or two), here are >> some characteristics essential for my workflow (given >> in no particular order): >> >> * have multiple outputs (some outputs the result of >> C compiles, others the result of other tools) >> >> * use different flag settings for different translation >> units >> >> * be able to express dependency information >> >> * produece generated source files, sometimes based >> on other source files >> >> * be able to invoke arbitrary commands, including >> user-written scripts or other programs >> >> * build or rebuild some outputs only when necessary >> >> * condition some processing steps on successful >> completion of other processing steps >> >> * deliver partially built as well as fully built >> program units >> >> * automate regression testing and project archival >> (in both cases depending on completion status) >> >> * produce sets of review locations for things like >> program errors or TBD items >> >> * express different ways of combining compiler >> outputs (such as .o files) depending on what >> is being combined and what output is being >> produced (sometimes a particular set of inputs >> will be combined in several different ways to >> produce several different outputs) >> >> Indeed it is the case that producing a complete program is one >> part of my overall build process. But it is only one step out >> of many, and it is easy to express without needing any special >> considerations from the build system. > > So, will a specific build of such a project produce a single > EXE/DLL//SO file? (The // includes the typical file extension of > Linux executables.) No, there are several outputs of this kind, including object files, static libraries, and dynamic libraries, and all for a C environment. (There are also other outputs but of a different kind than what you are asking about.) I have no expectation that you will incorporate these ideas or capabilities into a tool you are building for yourself. I gave the list in case other readers might have an interest.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-02-03 11:54 +0000 |
| Message-ID | <upl9i2$342ho$1@dont-email.me> |
| In reply to | #381664 |
On 03/02/2024 09:05, Tim Rentsch wrote:
> bart <bc@freeuk.com> writes:
>>> Indeed it is the case that producing a complete program is one
>>> part of my overall build process. But it is only one step out
>>> of many, and it is easy to express without needing any special
>>> considerations from the build system.
>>
>> So, will a specific build of such a project produce a single
>> EXE/DLL//SO file? (The // includes the typical file extension of
>> Linux executables.)
>
> No, there are several outputs of this kind, including object
> files, static libraries, and dynamic libraries, and all for a C
> environment. (There are also other outputs but of a different
> kind than what you are asking about.)
>
> I have no expectation that you will incorporate these ideas or
> capabilities into a tool you are building for yourself. I gave
> the list in case other readers might have an interest.
OK. You seem fairly level-headed and calm, so I'll try this explanation.
Let's say that 'ccc' (not 'cc') is a C compiler; it only processes C
source files.
All that I am attempting is that for a full build for this 3-file project:
ccc one two three
which takes one.c, two.c and three.c and produces (on Windows say)
one.exe, that you can instead do:
ccc one
for the same job. That would take that particular task (together with
endless dependency lists that you have to determine with extra tools)
out of makefiles.
Here I'm not interested in incremental compilation; this is typically
for a remote build (away from the developer's setup) of a finished,
working program.
It doesn't mean doing away with 'make'; that might still be needed to
orchestrate everything else that might be needed.
Although I'd prefer that those needs were also listed separately, in
comments or readme files, so that people can devise their own solutions
if needed (see, that is now one extra level of flexibility above just
supplying a complex, busy makefile which you just have to blindly trust
will work).
But in simple cases then yes, you just need 'ccc' and a bunch of C
source files.
With my experimental compiler using my #pragma method, I can do exactly
that:
mcc lua 33 files prepended to lua.c
mcc pico 23 files created pico.c
mcc bbx 45 files created bbx.c
mcc cjpeg 54 files prepended to each
mcc djpeg 54 files
In the last example, the two programs shared 46 common .c files. I put
those #pragma lines in a common file that was then #included.
(This makes processing those lines via a script harder, but I've given
up on that idea. In the original makefile, those 46 were compiled into a
.a archive file)
I created a special lead module when there wasn't a clear candidate to
take that role. That module provides the name of the EXE.
OK, the idea works. I will leave it in my compiler, and use it as secret
weapon for my personal use.
Nobody else cares, so everyone please pretend this thread was never
posted, and sorry for wasting your time.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-02-03 07:17 -0800 |
| Message-ID | <86plxd8tmq.fsf@linuxsc.com> |
| In reply to | #381667 |
bart <bc@freeuk.com> writes: > On 03/02/2024 09:05, Tim Rentsch wrote: > >> bart <bc@freeuk.com> writes: >> >>>> Indeed it is the case that producing a complete program is one >>>> part of my overall build process. But it is only one step out >>>> of many, and it is easy to express without needing any special >>>> considerations from the build system. >>> >>> So, will a specific build of such a project produce a single >>> EXE/DLL//SO file? (The // includes the typical file extension of >>> Linux executables.) >> >> No, there are several outputs of this kind, including object >> files, static libraries, and dynamic libraries, and all for a C >> environment. (There are also other outputs but of a different >> kind than what you are asking about.) >> >> I have no expectation that you will incorporate these ideas or >> capabilities into a tool you are building for yourself. I gave >> the list in case other readers might have an interest. > > OK. You seem fairly level-headed and calm, so I'll try this > explanation. [...] You have no interest in what's important to me in a build system. I have no interest in what's important to you in a build system. And in any case the recent discussion of build systems has gone beyond the bounds of comp.lang.c and should be conducted in some other newsgroup, or perhaps some other venue.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-02-03 15:54 +0000 |
| Message-ID | <uplnje$36b4p$2@dont-email.me> |
| In reply to | #381680 |
On 03/02/2024 15:17, Tim Rentsch wrote: > bart <bc@freeuk.com> writes: > >> On 03/02/2024 09:05, Tim Rentsch wrote: >> >>> bart <bc@freeuk.com> writes: >>> >>>>> Indeed it is the case that producing a complete program is one >>>>> part of my overall build process. But it is only one step out >>>>> of many, and it is easy to express without needing any special >>>>> considerations from the build system. >>>> >>>> So, will a specific build of such a project produce a single >>>> EXE/DLL//SO file? (The // includes the typical file extension of >>>> Linux executables.) >>> >>> No, there are several outputs of this kind, including object >>> files, static libraries, and dynamic libraries, and all for a C >>> environment. (There are also other outputs but of a different >>> kind than what you are asking about.) >>> >>> I have no expectation that you will incorporate these ideas or >>> capabilities into a tool you are building for yourself. I gave >>> the list in case other readers might have an interest. >> >> OK. You seem fairly level-headed and calm, so I'll try this >> explanation. [...] > > You have no interest in what's important to me in a build system. > > I have no interest in what's important to you in a build system. > > And in any case the recent discussion of build systems has gone > beyond the bounds of comp.lang.c and should be conducted in some > other newsgroup, or perhaps some other venue. At what point does a discussion about C programming turn into a discussion about general programming? But one of the criticisms of Bart was that he was talking about a build system designed to produce executables from flat C source, and ignoring the other functions of a build system. -- Check out Basic Algorithms and my other books: https://www.lulu.com/spotlight/bgy1mm
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-02-03 16:05 +0000 |
| Message-ID | <uplo8k$36hig$2@dont-email.me> |
| In reply to | #381680 |
On 03/02/2024 15:17, Tim Rentsch wrote: > bart <bc@freeuk.com> writes: > >> On 03/02/2024 09:05, Tim Rentsch wrote: >> >>> bart <bc@freeuk.com> writes: >>> >>>>> Indeed it is the case that producing a complete program is one >>>>> part of my overall build process. But it is only one step out >>>>> of many, and it is easy to express without needing any special >>>>> considerations from the build system. >>>> >>>> So, will a specific build of such a project produce a single >>>> EXE/DLL//SO file? (The // includes the typical file extension of >>>> Linux executables.) >>> >>> No, there are several outputs of this kind, including object >>> files, static libraries, and dynamic libraries, and all for a C >>> environment. (There are also other outputs but of a different >>> kind than what you are asking about.) >>> >>> I have no expectation that you will incorporate these ideas or >>> capabilities into a tool you are building for yourself. I gave >>> the list in case other readers might have an interest. >> >> OK. You seem fairly level-headed and calm, so I'll try this >> explanation. [...] > > You have no interest in what's imprtant to me in a build system. Determining which files to submit to a compiler is not important to you? OK... (I think the compiler will say otherwise!). But whether that is actually the case, that's the only thing I was addressing.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-02-03 12:39 -0800 |
| Message-ID | <upm89k$39d9n$1@dont-email.me> |
| In reply to | #381667 |
On 2/3/2024 3:54 AM, bart wrote: [...] Say I want to use your C compiler. How do I use it when I need to assemble and link external asm code? Say, I assembled something into an .o file, how can I make your C compiler use it, link it in, ect... Using the C ABI, I would create declarations for its functions. masm version, intel syntax: http://web.archive.org/web/20060214112539/http://appcore.home.comcast.net/appcore/src/cpu/i686/ac_i686_masm_asm.html So, this creates some functions. How would I use your compiler to call these functions from my C code in your system?
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-02-03 22:19 +0000 |
| Message-ID | <upme5c$3a9gd$2@dont-email.me> |
| In reply to | #381701 |
On 03/02/2024 20:39, Chris M. Thomasson wrote:
> On 2/3/2024 3:54 AM, bart wrote:
> [...]
>
> Say I want to use your C compiler. How do I use it when I need to
> assemble and link external asm code? Say, I assembled something into an
> .o file, how can I make your C compiler use it, link it in, ect...
>
> Using the C ABI, I would create declarations for its functions.
>
>
> masm version, intel syntax:
>
> http://web.archive.org/web/20060214112539/http://appcore.home.comcast.net/appcore/src/cpu/i686/ac_i686_masm_asm.html
>
>
> So, this creates some functions. How would I use your compiler to call
> these functions from my C code in your system?
My compilers are written as self-contained products. Inputs are source
files in the language, the output is a EXE or DLL binary.
External code from other languages is usually dynamically linked. You
provide a C header file, and a DLL, say yourlib.dll:
mcc prog.c yourlib.dll
For anything different, then you do this:
mcc prog.c -c
This produces a standard prog.obj object file. Now you can use regular
tools to statically link with code from other languages.
I don't have my own tool to read .obj files and statically link them.
That could be done, but it is not a priority for my stuff.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-02-04 20:56 -0800 |
| Message-ID | <upppq4$5g4n$2@dont-email.me> |
| In reply to | #381712 |
On 2/3/2024 2:19 PM, bart wrote: > On 03/02/2024 20:39, Chris M. Thomasson wrote: >> On 2/3/2024 3:54 AM, bart wrote: >> [...] >> >> Say I want to use your C compiler. How do I use it when I need to >> assemble and link external asm code? Say, I assembled something into >> an .o file, how can I make your C compiler use it, link it in, ect... >> >> Using the C ABI, I would create declarations for its functions. >> >> >> masm version, intel syntax: >> >> http://web.archive.org/web/20060214112539/http://appcore.home.comcast.net/appcore/src/cpu/i686/ac_i686_masm_asm.html >> >> >> So, this creates some functions. How would I use your compiler to call >> these functions from my C code in your system? > > My compilers are written as self-contained products. Inputs are source > files in the language, the output is a EXE or DLL binary. > > External code from other languages is usually dynamically linked. You > provide a C header file, and a DLL, say yourlib.dll: > > mcc prog.c yourlib.dll > > For anything different, then you do this: > > mcc prog.c -c > > This produces a standard prog.obj object file. Now you can use regular > tools to statically link with code from other languages. > > I don't have my own tool to read .obj files and statically link them. > That could be done, but it is not a priority for my stuff. Just an object file created from an assembler.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-02-04 20:57 -0800 |
| Message-ID | <uppprp$5g4n$3@dont-email.me> |
| In reply to | #381712 |
On 2/3/2024 2:19 PM, bart wrote: > On 03/02/2024 20:39, Chris M. Thomasson wrote: >> On 2/3/2024 3:54 AM, bart wrote: [...] > For anything different, then you do this: > > mcc prog.c -c mcc, humm. Is you assembler called mas?
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-01-31 20:36 +0000 |
| Message-ID | <upeb06$1m630$1@dont-email.me> |
| In reply to | #381174 |
On 29/01/2024 16:03, bart wrote:
> Working with Other Compilers
> ----------------------------
>
> Clearly, my scheme will only work with a suitable modified compiler.
> Without that, then I considered doing something like this, adding this
> block to my example from (2):
>
> #pragma module "cipher.c"
> #pragma module "hmac.c"
> #pragma module "sha2.c"
>
> #ifndef __MCC__
> #include "runcc.c"
>
> int main(void) {
> runcc(__FILE__);
> }
> #endif
I tried to do a proof of concept today. But there's one problem I'm not
sure how to get around yet. However, the odd behaviour of gcc comes to
the rescue here.
Going with the same 3-file test project, I created this version of the
above:
#pragma module "cipher.c"
#pragma module "hmac.c"
#pragma module "sha2.c"
#ifndef __MCC__
#include "runcc.c"
int main(int n, char** args) {
char* compiler = (n>=2 ? args[1] : "tcc");
runcc(compiler, __FILE__);
}
#endif
runcc.c is 100 lines of code, but it is only to test the idea works.
First build this short program with any compiler, here using gcc:
c:\c>gcc demo.c
Now run the a.exe file produced, here shown in two different ways:
c:\c>a
Invoking compiler: tcc -o demo.exe cipher.c hmac.c sha2.c
Finished building: demo.exe
c:\c>a gcc
Invoking compiler: gcc -o demo.exe cipher.c hmac.c sha2.c
Finished building: demo.exe
c:\c>demo
argument count incorrect! ...
It defaults to using tcc to build, but a compiler can be provided as
shown. It wasn't possible to pick up the compiler used to build 'demo.c'.
The main problem is that if demo.c is compiled to demo.exe (the stub
program that reads the #pragmas from demo.c and invokes the compiler),
it is not possible for demo.exe to then build the application as
'demo.exe'; they will clash, Windows doesn't allow it anyway.
So gcc's a.exe helps for this demo.
[toc] | [prev] | [next] | [standalone]
| From | thiago <thiago.adams@gmail.com> |
|---|---|
| Date | 2024-02-07 20:36 +0000 |
| Message-ID | <uq0pl8$1ivk4$1@dont-email.me> |
| In reply to | #381174 |
On Mon, 29 Jan 2024 16:03:45 +0000, bart wrote:
> By 'Build System', I mean a convenient or automatic way to tell a
> compiler which source and library files comprise a project, one that
> doesn't involve extra dependencies.
>
> This proposal comes under 'convenient' rather than 'automatic'. (I did
> try an automatic scheme in the past, but that only worked for specially
> written projects.)
>
> Here, the method is straightforward: the necessary info is simply listed
> in the designated lead module, within a set of #pragma lines.
>
> For my go-to small project demo, which comprises the three source files
> cipher.c, hmac.c, sha2.c, there are two ways to do it:
>
> (1) Add the info to top of the lead module cipher.c:
>
> #pragma module "hmac.c"
> #pragma module "sha2.c"
> ....
>
> I wasn't intending to actually implement it, but it didn't take long,
> and it seems to work:
>
> c:\cx>mcc cipher Compiling cipher.c to cipher.exe Adding module
> hmac.c Adding module sha2.c
>
> (2) Create an extra lead module and add it to the project.
>
> This allows the scheme to be superimposed on an existing codebase
> without having to modify it. If I try that on the above cipher project
> in a new module demo.c, it will contain:
>
> #pragma module "cipher.c"
> #pragma module "hmac.c"
> #pragma module "sha2.c"
>
> It works like this (in the real version those "Adding" lines will be
> silent):
>
> c:\cx>mcc demo Compiling demo.c to demo.exe Adding module cipher.c
> Adding module hmac.c Adding module sha2.c
>
> To get the original cipher.exe output needs an override option, but see
> below.
>
> Method (2) is attractive as it provides a means to easily set up
> different configurations of an applications, but mix-and-matching
> modules.
>
> Pragma Directives -----------------
>
> These are the ones I had in mind:
>
> module "file.c" As used above. Possibly, wildcards can work here
>
> import "file.c Incorporate a separate project which has its own
> set of pragma directives
>
> link "file.dll" Any binary libraries
>
> header "file.h" Specify a program-wide shared header
>
> Possibly the 'import' one can be dispensed with; it is simple enough to
> manually copy and past the necessary info. However that means it is
> listed in more than one place, and the original can change.
>
> The idea of 'header' is to specify big headers (windows.h, sdl2.h, etc)
> which are independent of anything else, which are then processed just
> once in the compiler, rather than once for each module that includes
> them. The usual '#include's are still needed.
>
> (The intention is not to create a whole-program compiler, or to
> introduce a module scheme, although this provides some of the benefits.
> The C language is unchanged.)
>
> Possibly, there can be a directive called 'name' to specify an
> executable file name.
>
> Working with Other Compilers ----------------------------
>
> Clearly, my scheme will only work with a suitable modified compiler.
> Without that, then I considered doing something like this, adding this
> block to my example from (2):
>
> #pragma module "cipher.c"
> #pragma module "hmac.c"
> #pragma module "sha2.c"
>
> #ifndef __MCC__
> #include "runcc.c"
>
> int main(void) {
> runcc(__FILE__);
> }
> #endif
>
> When run a compiler that is not MCC, this builds a small program (here
> still called demo.exe), which calls a function to read from this file,
> process the relevant #pragma lines, and use that info to invoke a
> conventional compiler.
>
> I haven't tested it, but it would mean a two-step process that looks
> something like this (possibly, it can pick up the name of the compiler
> that /is/ used, and invoke that on the actual program):
>
> c:\cx\tcc demo.c c:\cx\demo ... invoke tcc to build cipher.c hmac.c
> sha2.c ...
>
> (Tcc of course also has the -run option to save that second line)
>
> For this to work, the pragma stuff must be cleanly written: the runcc()
> function will only do basic string processing, it is not a C compiler.
>
>
> Using a Makefile ----------------
>
> One use-case for this would be if /I/ supplied a multi-module C program,
> or packaged someone else's.
>
> But people are mad about makefiles so, sure, I can also supply a 2-line
> makefile to do the above.
>
> Dependencies and Incremental Compilation
> ----------------------------------------
>
> This project is not about that, and is for cases where compiling all
> sources in one go is viable, or where a one-off build time is not
> relevant.
>
> That can mean when using fast a compiler and/or the scale of the project
> allows.
>
> Although the 'header' directive will also help, in cases where the
> application itself is small, but has dependencies on large complex
> headers. (I haven't quite figured out how it might work though.)
We already had some similar topics here. I think I have sugested
pragma source.
I am using a build system that is a C program.
This is the "build" file I use to build cake. It works on
windows and linux. gcc etc..
https://github.com/thradams/cake/blob/main/src/build.c
I will call "pragma module" as automaticaly source discover.
We can break the build in sub problems, one of then is source
code discovery.
The build I am using has a manual list of sources.
#define SOURCE_FILES \
" file1.c " \
" file2.c " \
...
The other problems are for instance, settings, like flags etc.
I also have "#pragma directory" to inform where the include dir are.
I think everthing should be controled with pragmas then we have a
choice to use a separated file, for instance a file just with
pragma modulo, or include pragma module inside normal source code.
I am not sure you realized this, but it is possible to create a tool,
with a C preprocessor that can scan source and discovery all the
sources automatically. It also could be a special comment instead of
pragma. Doing this the build system can be created without a new compiler,}
it is just a tool that collects source code and then call the compiler.
build source.c
where build is a program compiled to use gcc for instance.
The first pass it will scan the source.c and find all sources.
The next step it will compile each source.
my point is that this can be done today without changes in gcc clang etc..
I think "pragma source" or pragma module should be implemented in clang
etc... It does not need to be on the standard initially, all we need is a
tool and then compiler implementing this feature.
I think setting like warnings , include dir, library dir, also needs to
be controled inside source files.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-02-08 13:50 +0000 |
| Message-ID | <uq2m6o$203nb$1@dont-email.me> |
| In reply to | #382015 |
On 07/02/2024 20:36, thiago wrote:
> On Mon, 29 Jan 2024 16:03:45 +0000, bart wrote:
>
>> By 'Build System', I mean a convenient or automatic way to tell a
>> compiler which source and library files comprise a project, one that
>> doesn't involve extra dependencies.
>>
>> This proposal comes under 'convenient' rather than 'automatic'. (I did
>> try an automatic scheme in the past, but that only worked for specially
>> written projects.)
> We already had some similar topics here. I think I have sugested
> pragma source.
>
>
>
>
> I am using a build system that is a C program.
>
> This is the "build" file I use to build cake. It works on
> windows and linux. gcc etc..
>
> https://github.com/thradams/cake/blob/main/src/build.c
That certainly looks easier on the eye than most makefiles I've seen!
You seem to have solved the problem I had where here:
xcc build.c
build
I had to transfer the name of the compiler used (xcc) and make it known
to build.exe.
I tried to do it by looking at args[0]. You use compiler-specific macros
that each compiler exposes, and bake the results into the generated
build.exe.
But this limits the supported compilers to the ones you enumerated.
(I tried adding mine, but I found a bug where its identifier, __MCC__,
which is a predefined macro, doesn't work with 'defined'. I got around
that temporarily, but I haven't yet tried it out on a project.)
You've also easily turned what looked to me a two-step process into one
by using &&:
xcc build.c && build
with variations depending on compiler.
Of course makefile diehards will say this doesn't beat just typing:
make
but that doesn't really have cross-compiler support unless it's
built-in, somehow, to each makefile. (You can use any compiler you like
so long it's called 'gcc'!)
The answer here is to just supply a 2-line makefile that contains
something like 'xcc build.c && build'.
>
> I will call "pragma module" as automaticaly source discover.
> We can break the build in sub problems, one of then is source
> code discovery.
> The build I am using has a manual list of sources.
>
> #define SOURCE_FILES \
> " file1.c " \
> " file2.c " \
> ...
>
>
> The other problems are for instance, settings, like flags etc.
>
>
> I also have "#pragma directory" to inform where the include dir are.
>
> I think everthing should be controled with pragmas then we have a
> choice to use a separated file, for instance a file just with
> pragma modulo, or include pragma module inside normal source code.
>
> I am not sure you realized this, but it is possible to create a tool,
> with a C preprocessor that can scan source and discovery all the
> sources automatically.
My experimental code posted in the other Build thread used an array like
this instead of #defines:
char* source_files[] = {
"file1.c",
...
What's the advantage of using the preprocessor? (Where you have to be
more careful with syntax.)
[toc] | [prev] | [next] | [standalone]
| From | thiago <thiago.adams@gmail.com> |
|---|---|
| Date | 2024-02-07 20:42 +0000 |
| Message-ID | <uq0pve$1j65f$1@dont-email.me> |
| In reply to | #381174 |
On Mon, 29 Jan 2024 16:03:45 +0000, bart wrote: > By 'Build System', I mean a convenient or automatic way to tell a > compiler which source and library files comprise a project, one that > doesn't involve extra dependencies. I have also created a tool that generates the build program. https://github.com/thradams/buildgen I also have in my build - unit tests - documentation -
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-02-12 02:18 +0000 |
| Message-ID | <uqbv6c$175cj$1@dont-email.me> |
| In reply to | #381174 |
On 29/01/2024 16:03, bart wrote:
> By 'Build System', I mean a convenient or automatic way to tell a
> compiler which source and library files comprise a project, one that
> doesn't involve extra dependencies.
>
> This proposal comes under 'convenient' rather than 'automatic'. (I did
> try an automatic scheme in the past, but that only worked for specially
> written projects.)
This is a summary of the module scheme in my two main languages:
https://github.com/sal55/langs/blob/master/Modules24.md
The idea for this lite C version came from that, in listing the project
files at the start of the now /only/ module submitted to the compiler.
That C scheme needs revising, and could also use some ideas of Thiago
Adams in being able to work with other compilers like this:
gcc xxx.c -oxxx && xxx # build with gcc
mcc xxx # build with mcc
With mcc, xxx is the lead module. With gcc/etc, it's not clear what xxx
is; it might need to be a fixed file 'build.c' configured for this
project, as otherwise the extra support module name and project lead
name will clash.
It needs a bit more thought...
For for the time being, I'm sticking with my '#pragma module' scheme
which seems to work fine for the projects I've tried it on:
mcc lua
mcc bbx
mcc cjpeg
etc. What more could you want? This is beautifully simple.
[toc] | [prev] | [standalone]
Page 21 of 21 — ← Prev page 1 … 19 20 [21]
Back to top | Article view | comp.lang.c
csiph-web